Hey all, thanks to @dannym and the folks over at the autodesk help center I have resolved issues I was having where my gcode was reconfiguring the defined zeropoints when changing tools on a multi-tool job. Since we all use the same machine it makes sense to share here if anyone finds themselves in a similar situation.
Check out my forum post here with solution:
So I’m kind of curious about this problem. My understanding is that G43 doesn’t actually command the ATC to change tools. It merely commands the controller to apply the length offset that was manually entered by the operator. So even if you don’t have the ATC, with something like the Tormach Tool System you can pre-set the tool lengths ahead of time and type them into the controller’s lookup table. But if you don’t want offsets, it should be enough just to set all the offsets to zero in LinuxCNC.
I also remember seeing an option in Fusion CNC passes where you could change tool offset to be handled by either computer (aka. Fusion), controller (LinuxCNC, PathPilot), or both. If you change it to “computer only” then Fusion should emit G49 codes instead of G43 and I assume it will apply the length offset from the Fusion tool library instead (which might already default to zero).
There’s also another setting called something like tool compensation or cutter compensation which is for tool radius. It also has the computer vs controller setting. If you were also getting X/Y changes between tools, then I would double check that one too.
One thing to love about VCarve is it doesn’t have the options to pull in these special-use functions. It does the simple movement stuff only.
The postprocessor should not be dealing with tool offsets or variable fixtures. Just the preamble for explicitly setting modes (like inch file), usually T1 M6 to specify “this is tool 1”, M3 S18000 (start spindle CW at 18K rpm), and M8 (turn coolant on, pointless as we don’t do coolant, but it’s traditionally there)
G43 establishes a tool length that shifts the Z coordinates for that tool. That’d be for an ATC, where you have different tools in mounts, grab one and say “this is 1” longer than the others, so when the code says go to Z= -0.25, you actually want to go to Z= +0.75. Not approp.
G49 cancels the tool offset. VCarve’s preamble in all g-code files includes a G49 to get us in a known state.
I do not see the benefit (in the case of the machine we have) of having the predefined lengths and have the gcode compensate automatically in the case where you manually have to fit the new tool. Surely this would be inaccurate given the process for zero-ing the Zaxis. Anyway, i prefer to go a little slower and have clear division of tasks. ie. I zero the machine and the gcode executes the machine paths. Fusion is a pain to learn but more native given the project im working on where there is loads of 3d considerations. I might be able to do in Vcarve/aspire but would involve “tricking” it to a certain extent to make it do what I need.
Thanks Wojo - I will take a look for those settings as well. I made the change in the post processor then gave it a test last night. it worked! Great success!
What I’d like to now know if F360 has a way of defining spoilboard screws that machine paths know to avoid! Ive had some feedback to define as a fixture in the setup; but i did a quick test and it did not work. Its funny I thought this would be really simple tool to have rather than defining stock selections for each toolpath etc etc.
I ran into this issue today and was wondering if anyone has come up with a better solution. What’s more bizarre is that the value that is passed into G43 is the clearance height of the toolpath. It has nothing to do with the tool length.
Even worse I ran code last week that has this G43 code in it and it ran without issue. I made some small modifications this week and for some reason when I came in today LinuxCNC stalled out on this code.