So let’s say I’m doing a job that has a mix of 3d items and pockets and profiles, and I touch off the first tool on the surface of my project stock, would I have to zero each tool to the top of the workpiece? Cause it seams like that is what is happening. I just ATC picked up the next tool in line and as a check I stopped it to check zero and it is about 0.229 off. Any thought from the hive? I was just thinking back in the day one tool measured was all you needed.
It took me a while to understand how ATC and tool touch-off worked (caveat: my cnc is custom linuxcnc, so my config won’t help). But I have some suggestions:
- The ATC code needs to know the relative differences between tool lengths. Ideally, it has a “known origin” for the tool tips, and each tool has a “I’m here relative to that” in the tool table.
- On some machines you manually measure each tool before you install it into the machine, and record that measurement as the Z in the tool table’s offsets.
- On other machines, the machine knows how to measure each tool and adjust the “tool offsets” relative to what it’s measuring.
My machine does a combination of those; if the table doesn’t have an offset, it carefully measures the tool and records the offset, but next time it can measure it faster just to verify it’s the same tool and unbroken.
When a machine knows the relative offsets of all the tools, changing tools should not effectively change your “workpiece origin” - that’s kind of the whole point. I like to check those using 1-2-3 block and asking the machine to position the tool 3, 2, or 1 inch above where I set Z=0. It’s safer than asking to move to Z=0 and having it crash.
If your machine doesn’t know the relative offsets of the tools, you have the situation you describe, where the tool isn’t in the right place. You should NOT have to re-zero each tool to the workpiece, but it only works if you’ve figured out some other way to give the machine the info it needs.
Thanks for that D, I think I will recalc with the spoilboard as the Z zero and see if that works.
With Ex you should have to zero only once off the top of the work piece, and then only remeasure the tool when tools are changed. I have been doing this successfully since Ex came out - strange that you are getting error.
Yeah, very, I started out with a TBN that was measured and in the TL, next tool was a 1" EM and it was .2219 off so I zeroed it next call was a .125 and it was off by .165. I’m thinking I might shuck all my tool heights and redo the tool library. I loved the tool table system in mach4 and still use it on my other machine. I am sure it is something I have overlooked and I have been doing a lot of testing which involved copying the cncm folders.
Even though I wrote 2 or 3 messages about this problem I was still too stupid to catch the last toolpath before it got me it’s hell to get old
Damn!! I thought it was just the small shelf around the alligator… then I saw the hole :0
Definitely over my head but I bet @Eric will have some tips of what to check tomorrow!
It’s only wood, I can fix it.
No. With a properly measured tool when you use it to touch off to the top of your work the Z offset is stored.
Z offset + Tool Length = Top of work (or wherever you zeroed)
Z offset + NEW tool length = SAME PLACE on the top of work (or wherever you zeroed)
See this: https://youtu.be/g3MMSJ8NxzQ?t=805
Sounds like the length of that tool was incorrect in the tool library. Was it touched off after it was pulled from the rack?
This is exactly how the system is supposed to work.
This used to get me ALL THE TIME after I got ATC. I don’t know the source of your particular problem, but I’ll share what was behind mine:
First, if you follow the zeroing procedure as it’s written by Centroid (or Avid), you shouldn’t have the issue. But that wasn’t the workflow I used so I created a problem for myself.
The tool library is working with height offsets. Each tool has an offset (“Hn”) when you measure your tool.
If you zero your surface using a tool (Tn) with an unassociated tool offset (Hn), you will be off by the difference of the tool offset when that offset is used. When we run G-Code there is a G43 command that assigns tool length compensation using the correct Hn for the tool. At parts of the program, you can often get a G49 command that turns it off. When that happens you won’t have proper tool height association. That can happen at the end of a program, or if you abort a program early.
At the upper center of the screen you’ll see Tool: Tn Hn
If you are not seeing the tool number Tn with it’s appropriate tool offset Hn when you zero, you are not zeroing correctly for that tool.
I’ve done two things that avoid this now. I’m more conscientious about following the correct routine (I use swissi’s CHIPS software), or I make sure to manually assign a tool offset with the tool I’m using. I have a Set Tool # macro button that prompts me to set the tool and tool height offset before I zero things manually.
It’s worth noting that our M6 script wipes out all tool heights of every tool when a new one is picked. It will remeasure every tool as it grabs it. This approach may change when we release ATC, but this decision was made to accommodate a tool change system for people with collet/nut setups. (essentially folks that never have a fixed tool height)
We have mitigated this by packing G43 commands into the M6 script.
If you change to a tool like this:
T4 M6 it automatically does a G43 H4 for you. If you CAM program spits out a G43 that’s fine too, it’s just redundant.
This means that even if you did do a G49 by accident, when you start your program again it will re-assert G43 for you.
The S30 uses collets but my M6 script still measures the tool to verify some shop monkey (i.e. me 
didn’t swap it for a different tool.
The stuff I wrote should work fine with this. I bet switching back/forth from profiles left the “wrong” spoilboard offset set, and that is where the tool height is referenced from.
I think if you switch back/forth from profiles you should zero out your tool heights (hit the X in my app next to the Tool Height).
PS Brian - if you are using Vectric, you have to fix the Avid post processor to add a G43! That also could be a potential problem point. I hope Avid will fix this at some point.
Corbin
G43 is called in the tool change script. It’s not needed in our post processor. As soon as you switch to any tool in CNC12 a G43 command is issued to match that tool.
I need to somehow convince you that this is not usually done Every other CNC software separates the two concepts (Tormach, LinuxCNC, etc, and the standard Centroid macros). I understand why you do it: It is easier for the user to make less mistakes. I think if all the post processors do the right thing then the user won’t make mistakes.
Brian is using my M6 which doesn’t do a G43.
FWIW, Here’s Google’s AI response to “Should an M6 call G43”:
These are all mill-centric implementations of controls where there are realistic scenarios where you might want a different height number than your tool number.
Why would someone want a height measurement that doesn’t match the current tool number while using a router?
Every other router CNC I’ve seen seems to require a G43 after an M6. Tormach’s 24R router does this; everyone using LinuxCNC and Centroid (non-Avid) with a router do it this way. Laguna does it this way and I’d make a bet that all the other major CNC router players also do it; I can find out if you want! (Just look at their provided posts)
Why would you want a CNC router to behave any differently than a CNC mill?
In theory, someone might want to have a macro that disabled tool heights to do something special…like measure offsets as though the tool wasn’t there. I specifically had a problem with this in Mach 4 with crashes into the touch plate!
But part of it is not restricting people to limitations just because I can’t really think of a good scenario for it.
All the post processors (except the Avid Vectric) – including the default Centroid one in Vectric’s database – do the right thing.
Is there some reason you don’t want to add the G43 to your Vectric post processor? It’s an easy fix.
Is there also some reason you really want to have M6 call G43? There shouldn’t be anytime they get out of sync, unless people are mucking around in the MDI, in which cases they should have the power to do whatever they want.
That is impossible because our tool length is from the top of a travel to the tool height setter, plus or minus the height of the spoilboard. This makes your effective tool length the distance of Z travel from top of travel to the tool tip on your work surface.
This is a very good reason to have G43 in our M6.
You have to remember we have thousands of customers out there, the less chances we give them to make mistakes the better. It reduces our support burden.
This decision is one of those. Given that there’s no real reason to have tool heights separate from tool numbers we tied them together.
It is an open system ( and will remain that way) so that means you’re welcome to take a different approach if you have a need to do so.
Until there’s a compelling reason our posts won’t have a G43 in them because it’s in our M6 script.
My recommendation would be to follow we have done. I think it’s less than ideal for users to not be able to use all of the posts we have put there that are branded EX
If you were really paranoid, you’d have G43 in both places…