So I’ve been working through a bunch of tests in 6061 bar stock to develop test recipes for feeds and speeds along with cutting strategies. The last 3 attempts have just been total fails and it has to do with being able to relocate reliably the wcs after shutting down a session and returning to it later. My workflow is an xl with hdz, tool setter and probe. I was working on finishing strategies today on what I would describe as a bearing block , after finding the center if my work piece because it was off after home , I checked my z- 0 and reset it to the top of my model since. When I went to run my contour to clean up the outer walls using multiple depths it over shot the final depth. I slammed stop , checked the came measured the stock and model reset everything and reran the op… same thing. Then I rigged up some indicators to see what the issue was and something wacky is going on with my offset post tool probing. I plan to take it out of the loop tomorrow and see what the deal is but this has just started happening… it’s always bad when you here a 3 flute plunging into stock when it shouldn’t be, which is odd because the roughing didn’t have this problem. It’s also interesting to measure after a cold start how much drift there is after a rehoming event and jog to x/y zero.
Do I read correctly that you see a mix of:
- a) positioning repeatibility issues when you re-home the machine between jobs
- b) Z/depth errors even after you reset Z0 just before running the job ?
On a), there have been a number of threads on positioning repeatibility/accuracy after homing, some conclude that you get better results with proximity sensors than with mechanical limit switches, others that they are just fine (if not abused), but the general conclusion I often see is “don’t re-home the machine between jobs if you can avoid it”.
On b), if the depth error shows up after the tool change, you could maybe double check if your probe/bitsetter workflow is correct ? Maybe describe the sequence you used, in detail? By how much this the finishing pass overshoot the final depth ?
For the repeatability of home and WCS I’m pretty familiar with that and just accepted there isn’t much I can’t do if that precision matters. If I don’t have time to run all my ops and have to stop and pick up the next day, that is what I’m working on now is making sure I have a workflow to be able to relocate my origin and Z-0 continue on. Not much I can do about not rehome since these tests are intentional from power off to program op2. For part B I’ve check thed Gcode and the Cam and it looks fine. The Model bottom and Heights are correct and I’m intentionally asking it to leave .010 from the floor so that means something is happening the second time the tool gets touched off at the bit setter that is shifting my Z deeper. My work flow is start carbide motion, connect to machine, insert tool, relocate x,y,z 0 and before you ask I surfaced the stock before I start my ops so that if I need to relocate z 0 its not moving around by much, check my wcs but jogging to the location and touching the tool off on the surface to confirm 0. Then load program and run. As it stands there has to be ~.015" of error if I’m intentionally trying to avoid the floor. Once the operation gets to the button its colliding with the floor, and trying to drag the bit out. It managed to pull it out the first try before I could hit pause. I did a test without the bitsetter this morning to check that my cam was ok and it worked fine, so I know something odd is now out of no where going on with my bit setter.
So this is a single tool job, and the only time the machine goes to the BitSetter is during that initial forced tool length probing after the initial “insert tool” prompt during machine initialization ? Or do you do a “load new tool” at any time ?
I can’t see how the bitSetter presence/absence might influence a single tool job where zero is properly set manually. And yet apparently it does, so there must be something else in the workflow I missed…
It’s odd and it started to occur all of a sudden and it makes since it would occur during the tool probe just before running the op. The real question is why? Is there a way to pause after the tool probe and echo the new tool offset from the mdi? I haven’t thought about checking it till now
If I understand correctly, things happen like this:
- you do “connect to cutter”
- you click “initialize machine”
- you get the “tool change required”, install the tool, click ok. The machine goes to the BitSetter to probe initial tool length.
- you do “load new file”
- you go to the Jog menu, install the touch probe (right ?), jog above it, start a probing cycle (Z only ?)
- (or do you touch off manually ?)
- you then go back the “Run” tab, and click Start Job
Is there anything missing or anything extra in that list compared to what you do ? Each detail matters.
If the sequence is as I describe above, you can jog freely after the BitSetter probing (since this is what you do to go and probe/set the zeroes), but what matters is your zeroing procedure, the BitSetter is irrelevant at this point, it won’t influence the zeroes that you set.
So the question becomes: are you using the touch probe to set Z zero, and if so are you maybe overhanging the lip by mistake while probing Z only? That would explain the extra depth during the cut.
Ok so the short of it is it doesn’t matter if I’m using the touch probe or just manually touching off Z. I’ve tried it with no change, but since the reference is the top of the circle I’m manually touching off. That is easy to confirm after setting Z-0 since I can jog Z to what it thinks is the Z-0 location to confirm what I told it to be 0. It would make since that at this point it wouldn’t effect my ability to set zero based on what the initial tool offset is, whats odd is that this just started. I need to see if G43.1 is changing after I run the program now when the program checks the tool length before the program starts. In theory it should be the same…but my guess for some reason its not.
I’m having a hard time following what the problem is, but…
Have you checked the log?
G43.1 will reset on a controller reset.
I haven’t checked the log yet but the short of it is in my latest testing I’m noticing that my tool offset or z-0 is shifting when I’m running ops, enough that my tool is overshooting and plunging when it shouldn’t be hitting the floor. I took the tool setter out of the loop and the problem went away so I know that the setter is doing something to the offset when the program runs…just trying to figure out why this just started.
OK, so you’re off on the Z when using the BitSetter, but the same thing doesn’t happen without?
Are you changing tools?
No. No tool change. I was testing strategies for relocating my x,y,z WCO when I need to resume a project after a cold start and then magically this issues started. My guess is something is now wrong with my bit setter because this is exactly how it would manifest…just not sure why. Its not extreme but you can see in the picture during a contour op where on the final depth it over shot and plunged into the floor.
How did you set Z-zero on that operation?
What did the BitSetter have to do with it if you’re using only one tool?
Which version of Carbide Motion are you using?
Manually set Z-zero and used the probe and verified both bet checking the zero with jogging the tool to current Z-0 position. If you have the bitsetter in the loop it always touches the tool off twice before it starts cutting, once when the machine initializes and then again after you load and run the program.
I’m not near my Mac, but off the top of my head its 431 for OS X, not the beta.
Off of what surface?
Was that after the facing operation?
Yes my WCO and reference Z for this test was post facing, so that I could do exactly what I’m attempting. Like I said previously, I reran the test and disabled the bitsetter and the issue with over shooting went away so I know something nefarious is going on with the bitsetter just not sure why. The protocol didn’t change. I haven’t had a chance to check logs and see why the tool offset is changing
See if the problem is fixed in the beta?
Possibly…but after weeks of using it…and I didn’t update the CM software between ops…what would cause the gremlin out of no where…and why would removing the hardware fix the issue?
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.