Manual tool change + tool lengh touch off

21 Mar 2017 09:21 #89988 by LukeH

swalts wrote: LukeH,

You may be the same person I subscribed to and asked to make a video about this very same subject.

The sub-routine looks for M6, when it finds it then it halts the machine tells me to insert a tool (Tn M6?).
Then after i change the tool it runs over to the location where i tell it to touch off the plate.

The process sounds simple enough. I think my hang up is where do i tell linuxcnc or fusion360 to invoke sub-routine on M6? How do i find the program (even an example copy) to remap m6 command to the new sub-routine?

Thank you again for your time.

Ha, yes I'm the same person.

An M6 calls the sub routine which in my case runs the Z to the top of travel then a message pops up on screen asking to insert Tn. Clicking okay then carries on with the measure routine.

Orangecat's reply on Page 4 of this thread will give you all the info you need to get started. It's what I based mine on however I modified it because I didn't want to automatically return to the part, so I could do a part touch-off each time the tool is changed. To make this practical I try to group my operations by tool and I post a separate g code file for each tool. It really doesn't take much time to load each file.

Also, note that some post processors will automatically add an M6 into the G code and will send the Z to zero before a tool change. I modified my post processor (Fusion360 LinuxCNC) so that I take care of tool changes entirely in the sub-routine. All the post processor does is insert an M6.

Give me a shout if you need any help. I'm happy to share my ini and sub-routine files to you.


Please Log in or Create an account to join the conversation.

22 Dec 2017 23:22 #103466 by trentster
Hey Luke, I also use Fusion360 and would appreciate you sharing your current sub routines. Thanks mate.

Please Log in or Create an account to join the conversation.

23 Dec 2017 07:28 #103477 by LukeH

trentster wrote: Hey Luke, I also use Fusion360 and would appreciate you sharing your current sub routines. Thanks mate.


I have been meaning to write this up ever since I got it all working. Hopefully this will be useful to some of you. It works for me and could probably be improved. I have produced lots of accurate parts on my mini CNC using this setup.

I have attached my LinuxCNC config files for reference.

Changes required

1. Created tool-change.ngc and saved in /macros/ folder on CNC - I've attached mine for reference
2. Downloaded LinuxCNC Post Processor from -
3. Saved Post Processor into - /luke/Autodesk/Fusion 360 CAM/Posts/ - you will need to locate your Fusion360 folder. I'm using a mac
4. Removed retract to G53 Z0 from post processor by deleting these lines (appeared twice)

else {
writeBlock(gAbsIncModal.format(90), gFormat.format(53), gMotionModal.format(0), "Z" + xyzFormat.format(0)); // retract

5. Edit your cnc.hal to include the manual tool change stuff. Refer to my mf70.hal for reference.
6. Edit your cnc.ini to include the M6 remap under this heading [RS274NGC] - refer to mine for reference. I also commented out

CNC config you will need to do

Note. Z zero for my CNC is at the top of travel i.e. tool furthest away from table. All of my tools have a negative length value and all z references in the config files are negative value as a result.

1. You will need to update the X & Y co-ordinates of the touch of sensor in the tool-change.ngc config file
2. You will need to update the height of the touch of sensor in the tool-change.ngc config file - I opened up the pin viewer for the probe pin, 13 in my case (I will update this section with more detail once I've gone through it again on my cnc) and jogged down to the sensor until the pin updated to True. This Z position was added to tool-chang.ngc under <_Ztravel> heading
3. You might need to update the min & max tool length values in the tool-change.ngc file

Fusion360 steps

1. Produce G code for each tool within your part. I try and group tool ops by the tool to avoid lots of tool changes. This isn't always possible.
2. Select the post processor stored on your computer rather than the cloud version - Fusion will remember this next time and use automatically.
3. I tend to add a comment into the g code before I save it with part coordinates and any tool order reminders.
4. I name my gcode in this format - sample_part_PT1.ngc, sample_part_PT2.ngc etc... - this makes it obvious when you come to run the g code on your cnc.

Bonus - getting your g code over to your mill

1. I have setup on my Fusion360 Mac and my CNC located in my garage. I have a "watched" folder on both systems so each time I generate a g code file in Fusion I save it to a folder called "CNC". This automatically syncs to my LinuxCNC machine so no need for USB sticks.
2. You could use Dropbox to achieve the same however, gives you 50GB free and its encrypted end-to-end so no fear of your files being leaked.

LinuxCNC setup routine

1. Launch LinuxCNC and Home all Axis
2. Open G code to run
3. Manually run Tn M6 (n being the tool number for that program) from MDI - auto tool touch off runs and sets Z offset by updating tool table.
4. Jog to material and touch off in all Axis using tool. - I use paper method to touch off in Z
5. Run program
6. Program initiates tool change by issuing Tn M6 command. A message will pop up on screen saying "tool already in spindle. no change required"
7. Program runs.


1. T0 M6 will reset selected tool back to nothing. Auto tool routine will only retract Z back to zero and will not run the touch-off routine.
2. T1 M6 in my case will select tool 1 and will not run the touch-off routine. This is due to tool 1 being a touch probe for me and I don't need to measure it.
3. If you have an accurate touch probe you can avoid doing the paper method touch off described above by doing a T1 M6 (1 being your probe number) first, touch-off your part in all axes and then just allow the tool-change routine to be called by gcode each time and measure the tool length. - my touch probe isn't highly repeatable so I prefer to touch off in z each time for each tool change.

I hope this helps. Feel free to ask any questions.

File Attachment:

File Name:
File Size:28 KB
The following user(s) said Thank You: pommen

Please Log in or Create an account to join the conversation.

27 Dec 2017 10:46 - 27 Dec 2017 10:47 #103742 by trentster
Thanks so much mate, much appreciated!

I am having a thorough look at some of your changes and will be implementing them on my machine over the coming days.
Last edit: 27 Dec 2017 10:47 by trentster.

Please Log in or Create an account to join the conversation.

24 Aug 2018 14:16 #116548 by stidrvr

LukeH wrote:

trentster wrote: Hey Luke, I also use Fusion360 and would appreciate you sharing your current sub routines. Thanks mate.

EDITED for length...

I hope this helps. Feel free to ask any questions.

File Attachment:

File Name:
File Size:28 KB

Hi Luke,

Great post. I too have a ER Collet gantry based CNC machine and use fusion 360 as well. Because you use a separate program for each tool, is it because of that that you do not use the M600 command?

Please Log in or Create an account to join the conversation.

26 Aug 2018 21:57 #116621 by jmr
I tried merging this example in my config:
and it did not work for me. When I finally found out what signals are expected (at first I did not use the VCP) and where they should go I had it ask for tool after M6 Tn and "measure" it. Did anyone use it in real world? In theory it was good, but trying to touch off in G54 (I think used G10 p20 as I did before) and then doing another tool change resulted in need for another touch off and TLO grew along with G54 offset and tool at Z=0 was always above the material. I think it did not change after I discovered the reference tool signal...
It looked like the probing took the G54 offset together with actual TLO and this was no good, and since I can not do G53 G38.3 I found the way from the MF70 files - G59.3 coordinate system which was by default at machine zero (or should be?), anyway it is not moving. With this before the probing I also inserted G49 which cancels actual tool offset - this seems to fix rest of the problem.
I wonder if there is a better way to have the probing relative to hard machine coordinate system? G59.3 worked, but it is "sacrificed" to the probing fun, and could be used for other purposes.

The MF70 code did not work out ouf the box either, so I stick to the first example - I believe it is good and I like the way of configuring it in .ini - after a period of WTF i found out that I have to copy the FEATURES=30 too - it would have helped IF i started by looking at this thread instead of the example config as Andy pointed that out...

@ stidrvr: I believe there maybe was a change at some point and M600 may not be required in the current code, as the reference tool is indicated by being tool number 1. I am not even sure if that makes sense to always update the reference height when this tool is put in the collet. It looks like it can be any tool, and it has to be done at least once after restart so the reference length is not undefined - if everything works it should be possible to do the touch off with any tool and z=0 at the material should stay there. manual-toolchange-with-tool-length-switch has different approach, it expects the "reference tool" button/signal to be present after putting in the tool - if it is present the thing acts similar to using M600 as per this thread some 8 years ago.

All of this should be clear to me after some more testing and I will try to make some kind of a readme/tutorial on this as there is a lot of confusion and not much documentation, and an awful lot of collet spindles.

well, another question: what is the table enable supposed to do? Turn the VCP panel on, apply power to the probe switch on the table or what?

Please Log in or Create an account to join the conversation.

02 Sep 2018 17:59 - 02 Sep 2018 18:01 #116986 by nkp
Last edit: 02 Sep 2018 18:01 by nkp.

Please Log in or Create an account to join the conversation.

03 Nov 2018 22:37 - 03 Nov 2018 22:39 #119889 by jmr
Is no one really using manual tool change with probe?
I looked at both setups and they all share the same problem and I could use some creative ideas to get around it and the tool change would then perhaps work fine in all scenarios.

Now it will break a programmed cycle if using multiple fixtures with anything else than G54. I can get around it by shifting G54 before moving to the next part. But if I run with G55 instead it will return to G54 after the tool change. I know I will want to have one tool do its work on all parts and then be changed for other tool before next operation. Like this it should work with no problem.

1)The basic problem is that G38.x does not give result in G53 system. As I said before, now I'm using G59.3 (which is set to 0) before probing. One way not to do it will be G53 G0 to probe position, then perform ultra-short probing G91 G38.3 Z.00001 (this is an example from other topic. Does G38 even care about G91?), store the result, then do real probing and calculate delta from the two results.

2) Another way is to get current coordinate system number and return to it after the tool change, or zero it in the process and then revert the values. I found a way to get the coordinate system number 0-9 from variable but there is no gcode to use that number again to select it. It would have to be an ugly if-elseif-elseif or case() thing.

3) Maybe even better would be to use the variable number of cs*20 + 5223 to get current Z offset and use that to get real value after probing? Less ugly? Does not require changing the coordinate system, is there anything else to consider?

Important thing is also to make it fail proof. The toolchange operation now has a timeout, and it would be very nice to return everything to a previous state if the change fails. Changing any offsets seems dangerous... There is another thread that got linked here:
It is mentioned there that Fusion360 post processor assumes Z=0 for the tool change or Z max. I will look into that as a friend will be using it.

Other than "that" the toolchange is fine. It was mentioned that routine should get back to a position where it was called from - what do You people think/believe? Of this two examples none does this. What is left is an assumed "safe" height so if next move is to XY it can be safe but does not have to - It will be, if first op after TC is a move to safe Z and then to XY in part area. This does not consider having anything on the machine table that may stick up a little bit more than Zsafe. Any safety advices?

Thanks. I hope someone can read this and have a response.
Last edit: 03 Nov 2018 22:39 by jmr.

Please Log in or Create an account to join the conversation.

05 Nov 2018 10:49 #119980 by andypugh
I think that the sample config is meant to be only that, a sample.
Specific implementations are likely to have rather different requirements.

It shouldn't matter which coordinate system you are operating in, a G10 command should set the tool length data correctly taking in to account the coordinate system offsets.

Please Log in or Create an account to join the conversation.

05 Apr 2019 00:32 #130321 by diep
Heh Marian - i basically have the same question. Did you ever find a solution to your question?

I have a toolsetter here for simple cnc machine yet it's manual changing the tool each time. What i would like is that it homes. I push the green button, then it should move to preset coordinates and measure tool length. Then move to preset coordinates where i have clamped the workpiece. After some time it should go back to home - and then ask for a new tool - and the proces above repeat itself.

But any other solution that improves the current situation here also are much appreciated :)

Note that even if i would build an autotoolchanger - it might be not repeatable load the tool at exact same spot. Just it manages to get in ok and that's all. Of course no good for quickly milling something - but heh - it's a simple machine that is not so accurate anyway. So after each toolchange again measuring the tool height in automatic manner seems pretty interesting to me.

Weird the feature is not there in linuxcnc. Is the commercial toolpath generating software this good that linuxcnc doesn't need to know all this?

If so which one for some sort of decent price can do that?

(as i'm currently struggling with pycam which doesn't even seem to know how to chamfer a workpiece with a chamfering cutter - instead it'll take an hour with a ball nose cutter).

Kind Regards,

Please Log in or Create an account to join the conversation.

Time to create page: 0.126 seconds
Powered by Kunena Forum