Tool change (M6) support discussion

[terjeio]

I have implemented three new tool change options and would like some input on what I have done and if it makes sense.

See the Wiki page for details.

I have not yet published the build needed - will do so soon to the test branch.

[S2000Stefan]

I also noticed that if I execute length offset in the Probing Tab Tool and then want to execute a macro from the tab, this is not possible. You have to select another tab first to be able to run a macro.

It works for me, another Gremlin? Is this replicable, and if so for all macros regardless of content?

Hit, you are right, it is only one macro. All others work. The macro contains a G0 X0 Y0 command.

Control panel > Administrative tools > Event Viewer then Windows Logs, Application (in Win7, if you have a later version it may be hidden somewhere else).

Hope you can do something with it, I have created a file, if it doesn't work I have taken screenshots. Absturz.rar.txt Renamed in rar.

Did the sender fail to open the port or was it waiting on the controller?

I didn't pay much attention to it but the status line said "Controller does not answer" or something similar.

@S2000Stefan : Maybe I have forgotten so I ask again just in case: do you have an EEPROM connected to the controller?

No I have not connected an EEPROM to the controller. Maybe I should do that?

Sorry no tests today, too little time.

[einencool]

@S2000Stefan What is your opinion about the order of the probing Moves, when the "Z-Probe" button is activated?

Maybe it's only my thinking, that the Z-Probe should be the first thing to measure.

If it's only my opinion about this, maybe it should not be modified?!?

[S2000Stefan]

@S2000Stefan What is your opinion about the order of the probing Moves, when the "Z-Probe" button is activated? Maybe it's only my thinking, that the Z-Probe should be the first thing to measure. If it's only my opinion about this, maybe it should not be modified?!?

@einencool Sorry if I'm honest, I don't care. Unfortunately I don't see any advantages in doing the z-probing first, you can determine the depth of the probe on the work piece yourself. So you can jog the probe to the right height yourself.

[terjeio]

Hit, you are right, it is only one macro. All others work. The macro contains a G0 X0 Y0 command.

It is likely due to when in the probing tab distance mode is set to relative, it is restored to whatever it was on leaving the tab. For now use G90G0X0Y0 instead to ensure absolute mode.

Hope you can do something with it, I have created a file, if it doesn't work I have taken screenshots.

I'll take a look tomorrow.

I didn't pay much attention to it but the status line said "Controller does not answer" or something similar.

Thanks, then the sender waited for a response from the controller - it was not totally crashed. I have had a closer look at my code again, there is a somewhat tricky part where I have to trigger execution of code from an asynchrounous event (cycle start) by posting a message to the foreground process. It could be this that is randomly making the controller unresponsive. I have changed the way I am doing this to a simpler method that should be more robust - will update grblHAL later when I have done some more testing.

No I have not connected an EEPROM to the controller. Maybe I should do that?

The flash in the STM32 has a guarateed life of 10.000 write cycles - not a lot. E.g. setting a offset is one cycle - if you do this often then it adds up... Also writing data to flash is slow as the whole area used for settings has to be erased before each write. EEPROM is a lot better, FRAM even more so.

What is your opinion about the order of the probing Moves, when the "Z-Probe" button is activated? Maybe it's only my thinking, that the Z-Probe should be the first thing to measure. If it's only my opinion about this, maybe it should not be modified?!?

My opinion is that I do not want to change it for now as this complicates the streamlined program flow I have. I may consider making it an option later when the sender is out of beta.

[einencool]

Well, then please leave it as it is... Then I’ll work with an macro for the Z-Probe so that I’ll have always the same starting height. Because with jogging i don’t get a defined position for probing... But that’s ok :-) I think it’s to much work with not so much effort for other people.

[S2000Stefan]

The flash in the STM32 has a guarateed life of 10.000 write cycles - not a lot. E.g. setting a offset is one cycle - if you do this often then it adds up... Also writing data to flash is slow as the whole area used for settings has to be erased before each write. EEPROM is a lot better, FRAM even more so.

Ok you have convinced me, the eeprom is ordered and will be integrated immediately when it is there. ;)

Today I took a closer look at the tool change mode $341=3. I could not find any abnormalities in the process - everything works fine. But maybe the tool change point is not so well chosen on very large machines? I only have a very small machine - it does not bother me. :)

But now, as always, when the spindle moves to the home position for tool change, wouldn't it be better to show a message in the status line or even open a pop up window to tell the user what to do? Something like "Please change tool when finished press start button". And by pressing the start button the window could close again. Also in tool change mode $341=2, a message at the tool change point what to do would be very helpful for a user. "Please change the tool and jog to the touchplate to execute a $TPW command" or something like that, I'm not very good at that ;)

I also noticed in tool change mode $341=2 that I don't get MSG for the tool, which was once thought about? And when the MSG comes "Remove any touch plate........" this message remains until an M30 command comes "MSG Pgm End".

I have also added interlocks for the fields on the left hand side, this means that the only the fields used for the selected probing action will be enabled for input. This will make it clearer which values are actually used.

Completely forgotten, really very helpful. :+1:

[terjeio]

Don't forget pullup resistors for the EEPROM signal lines.

But maybe the tool change point is not so well chosen on very large machines? I only have a very small machine - it does not bother me. :)

You mean backing off to the Z home position could be too far?

But now, as always, when the spindle moves to the home position for tool change, wouldn't it be better to show a message in the status line or even open a pop up window to tell the user what to do? Something like "Please change tool when finished press start button". And by pressing the start button the window could close again. Also in tool change mode $341=2, a message at the tool change point what to do would be very helpful for a user. "Please change the tool and jog to the touchplate to execute a $TPW command" or something like that, I'm not very good at that

I decided against pushing a message from the controller as this would remove any message from the program, e.g:

T1M6 (MSG,End Mill 8 mm wood)

you do not want that message to go away. And I think it will not be easy to check if the program has a message related to the tool change or not. A pop up message could interfere with remote control (thinking of @eiencool and his gamepad) so I decided against that too. Pressing cycle start to early will issue a reminder though.

I also noticed in tool change mode $341=2 that I don't get MSG for the tool, which was once thought about?

It works for me in my test setup, are you sure about this?

And when the MSG comes "Remove any touch plate........" this message remains until an M30 command comes "MSG Pgm End".

Then I guess you are pressing a cycle start button connected to the controller. It is removed when pressing the Cycle Start button in the sender. I will update the controller to send an empty message so it will be removed in both scenarioes.

I have also added interlocks for the fields on the left hand side, this means that the only the fields used for the selected probing action will be enabled for input. This will make it clearer which values are actually used.

Completely forgotten, really very helpful. +1

This was a part of the discussion over at the pull request for the sender . This should continue, but IMO in a less overwhelming way...

Edit: fixed pull request link.

[S2000Stefan]

Don't forget pullup resistors for the EEPROM signal lines.

I hope they are already on the board. I have one more question. Is only PB10/11 connected as SCL/SDA or also Vcc and GND?

You mean backing off to the Z home position could be too far?

For very large machines I think so. But since we are only in the hobby sector it should not be a problem.

I also noticed in tool change mode $341=2 that I don't get MSG for the tool, which was once thought about? It works for me in my test setup, are you sure about this?

Yes, I am very sure. ;)

Then I guess you are pressing a cycle start button connected to the controller. It is removed when pressing the Cycle Start button in the sender. I will update the controller to send an empty message so it will be removed in both scenarioes.

Yes, often use the start button on the machine, you are right.

This was a part of the discussion over at the pull request for the sender . This should continue, but IMO in a less overwhelming way...

Then I will have to read everything through, for better or worse. ;)

[terjeio]

I hope they are already on the board.

Could well be, I do not know which board you have ordered so cannot tell.

Is only PB10/11 connected as SCL/SDA or also Vcc and GND?

Vcc and GND has to be connected as well.

I also noticed in tool change mode $341=2 that I don't get MSG for the tool, which was once thought about? It works for me in my test setup, are you sure about this?

Yes, I am very sure. ;)

And I am as well. Strange... The user should not have to scroll back in the program listing to se the message if it was added earlier in the program and become hidden. Or if using a pendant with a screen and not seeing the monitor, or streaming from a SD card and not having the program listing available in the monitor at all...

[S2000Stefan]

Unfortunately I could only make very short tests with the new versions today. Everything went very well so far. The new features give it a professional touch ;)

There is one little thing I noticed. In the Probing Tab if you create a new profile, make entries and then add it with add and want to make a change immediately afterwards, for example if you have entered the Touch Plate thickness incorrectly, it is not possible to do this via update, only add is possible. You must first select another profile and then select the previous profile to make changes.

Btw, Unfortunately I still don't get an MSG when changing the tool.

[einencool]

Can you please change one thing in the Probing tab? While in Probing Tab, the Sender doesn't take any Shortcut commands like "F1" or "F2" I have the Z-Probe on one Shortcut and can't use it while in Probing tab. Thank you in advance

[einencool]

Wanted to test a file with many toolchanges without Spindle speed. When I used the Checkmode, this failure came up with the first tool change.

[terjeio]

Btw, Unfortunately I still don't get an MSG when changing the tool.

You do not see any in the Console either? Wait a bit... - it could be that asynchronous message handling is not enabled in the driver you use. I'll have to check that.

Can you please change one thing in the Probing tab? While in Probing Tab, the Sender doesn't take any Shortcut commands like "F1" or "F2" I have the Z-Probe on one Shortcut and can't use it while in Probing tab.

Ok, I have to add support for that in the probing tab as well then. Key handling is local to the active tab, that is why it does not work.

Wanted to test a file with many toolchanges without Spindle speed. When I used the Checkmode, this failure came up with the first tool change.

My bad, I will add check for check mode in the next grblHAL update. Note that the sender parses the gcode on load and will (should?) report any errors as well. The parser even checks if the controller is grbl or grblHAL based and will report errors accordingly. So check mode in grbl and and parser check on load basically does the same thing if I have managed to write a good parser...

[terjeio]

New edge version uploaded.

Fix for Center finder and start of macros via function keys added to Probing tab. Will look at the Profile combo box issues later, weather has improved and I have some pending work outdoors. Same for single direction Center finder request, will try later to handle that by allowing zero size for direction not to probe.

[terjeio]

@S2000Stefan The missing tool change message is due to the driver not having support for gcode message handling. There is enough memory for adding it so will do so soon.

[einencool]

Good Morning @terjeio Your new Version with the abillity to activate the macros works really fine. Love it. It makes the workflow much easier and I can Touch off the surface with the macro and then I have always the same heigth for the Probing depth :-)

[S2000Stefan]

@S2000Stefan The missing tool change message is due to the driver not having support for gcode message handling. There is enough memory for adding it so will do so soon.

Don't worry about it. ;) Take your time. To be honest, such things are not that important to me, I just noticed that there was no advertisement (MSG) on my site.

Today, after a successful tool change programme, I noticed, for example, that I had three tool changes, the tool display shows the last tool and I then change the tool manually to tool one and start the existing milling programme again - the first tool change is carried out. Shouldn't the milling program stop at the first tool, because the TLO cannot match? Apart from the fact that the tool may not be the right one. ;) Hope you understand what I mean.

[terjeio]

Today, after a successful tool change programme, I noticed, for example, that I had three tool changes, the tool display shows the last tool and I then change the tool manually to tool one and start the existing milling programme again - the first tool change is carried out. Shouldn't the milling program stop at the first tool, because the TLO cannot match? Apart from the fact that the tool may not be the right one. ;) Hope you understand what I mean.

Not sure I do... A tool change is triggered by a tool number change followed by a M6 command. If you want to always force a tool change then set the current tool with M61 to something else than the first tool in the program, for example M61Q9999. You can add that to your post processor. Normally M61 is used to set the current tool in order to avoid a tool change on the first M6.

RS274:

The tool change may include axis motion while it is in progress. It is OK (but not useful) to program a change to the tool already in the spindle. It is OK if there is no tool in the selected slot; in that case, the spindle will be empty after the tool change. If slot zero was last selected, there will definitely be no tool in the spindle after a tool change.

LinuxCNC:

M61 Q- - change the current tool number while in MDI or Manual mode. One use is when you power up LinuxCNC with a tool currently in the spindle you can set that tool number without doing a tool change.

For me this implies that a tool change command to the tool currently in the spindle does not initiate a tool change sequence.

[S2000Stefan]

Yes in explaining I am a niete. I try it again. The milling program with tool change is finished. Tool list is on e.g. Tool 5. I then manually change the tool list to Tool 1. Unclamp the old workpiece and insert the new one. Change the milling cutter to the first tool in the milling program. Press start. The milling program is the same. The milling program runs through at the first cutter change (tool 1) because I have already selected tool 1 by mistake. TLO is not correct in this case because no $TPW has taken place. Wouldn't it be better to reset the TLO automatically every time you manually change the tool in the tool list? So that the sender then demands a $TPW.

[S2000Stefan]

The more I think about my proposal, the more I have to admit that it is complete nonsense.

For me this implies that a tool change command to the tool currently in the spindle does not initiate a tool change sequence.

I think you interpret Linux CNC right and I am wrong.

[terjeio]

Complicated stuff?

I have changed M61 handling to allow M61Q0 instead of returning an error in the next version - tool 0 may mean no tool in the spindle. Not allowing tool 0 was not compliant with the specification.

LinuxCNC on T in 5.6.3:

When LinuxCNC is configured for a nonrandom toolchanger (see the entry for RANDOM_TOOLCHANGER in the EMCIO Section), T0 gets special handling: no tool will be selected. This is useful if you want the spindle to be empty after a tool change.

and

When LinuxCNC is configured for a random toolchanger (see the entry for RANDOM_TOOLCHANGER in the EMCIO Section), T0 does not get any special treatment: T0 is a valid tool like any other. It is customary to use T0 on a random toolchanger machine to track an empty pocket, so that it behaves like a nonrandom toolchanger machine and unloads the spindle.

Which is the grblHAL implementation, random or not?

If random then no special action can be taken on selecting tool 0. And a tool change sequence should be performed if the current tool is not 0.

If nonrandom then a tool length offset for T0 does not make sense and should not be added? It could be argued that the tool length reference offset should be cleared on M61Q0 if defined nonrandom.

It seems my tool change implementation is wrong regarding coolant, LinuxCNC on M6 in 5.4.6.2:

No other changes will be made. For example, coolant will continue to flow during the tool change unless it has been turned off by an M9.

And this warning:

The tool length offset is not changed by M6, use G43 after the M6 to change the tool length offset.

Should grblHAL be changed to adhere to this as well? Maybe not as the tool length reference offset is my idea, no such concept (as I am aware of) is found in either of the RS274 or LinuxCNC specifications. And by default there is no tool table in grblHAL containing tool offsets. It is a different story if one is compiled in and there is an ATC connected...

Confusing, you bet... I have to try to make the behaviour consistent across configurations, and it is not alwasys easy to get the details right.

[einencool]

And this warning:

The tool length offset is not changed by M6, use G43 after the M6 to change the tool length offset.

Should grblHAL be changed to adhere to this as well? Maybe not as the tool length reference offset is my idea, no such concept (as I am aware of) is found in either of the RS274 or LinuxCNC specifications. And by default there is no tool table in grblHAL containing tool offsets. It is a different story if one is compiled in and there is an ATC connected...

The G43 Command was in my old Postprocessor after the M6 and I got a warning with the first trials. I don‘t know much about these things, but the important thing is, it works for me g

I also don‘t know what would be the benefit for using the G43...

Yesterday I made several tests with a bunch of tool Change test files, and they all work without any failures.

[S2000Stefan]

Should grblHAL be changed to adhere to this as well? Maybe not as the tool length reference offset is my idea, no such concept (as I am aware of) is found in either of the RS274 or LinuxCNC specifications. And by default there is no tool table in grblHAL containing tool offsets. It is a different story if one is compiled in and there is an ATC connected...

Confusing, you bet... I have to try to make the behaviour consistent across configurations, and it is not alwasys easy to get the details right.

As I wrote this morning, I thought a lot about it and came to the conclusion that everything is very good as it is and nothing should be changed.

As einencool writes:

I don‘t know much about these things, but the important thing is, it works for me g

I stand fully behind this statement. Find the tool change is very convenient and easy to use.

[S2000Stefan]

Today we did some more tests. I noticed that if I zero my axis of rotation (a axis) with $HA manual, the TLO reference is lost but the normal TLO remains. Is that what you want? Otherwise I could not find any abnormalities with the many tool changes I have made. :)

[terjeio]

Today we did some more tests. I noticed that if I zero my axis of rotation (a axis) with $HA manual, the TLO reference is lost but the normal TLO remains. Is that what you want?

It is what I did ;-)

Tool reference offset is normally the linear axis (Z) so could change the code to only clear it if that is part of the axis/axes to be homed. Currently only the linear axis is supported for tool reference offset but the code is prepared for multi axis reference offsets, this is at least relevant for lathe mode where both Z and X may be used - so have to keep that in mind.

Is it likely to ever be a need for tool offsets for the A, B and C axes? If not then I could make the check for clearing the reference simple.

Otherwise I could not find any abnormalities with the many tool changes I have made. :)

Good, thanks again for testing!

[terjeio]

@S2000Stefan from build 20201003 the TLO reference will only be cleared when homing the linear axis (Z).

[S2000Stefan]

@S2000Stefan The missing tool change message is due to the driver not having support for gcode message handling. There is enough memory for adding it so will do so soon.

Today I made a short test with the new grblHal version and can report that the tool change massage is now displayed. Thanks for that. Very good support. :+1: Another question, since i have now connected a FRAM EEprom to my controller would it be possible to test the odometer plugin? If it is possible, what exactly do I have to change to install the plugin or is that too complicated for a non-programmer like me?

[terjeio]

@S2000Stefan I have just committed an update adding the odometer option to the STM32 drivers. Note that I have not extensively tested this, it is a preview version. Enable in my_machine.h after copying the odometer plugin code to the project.

[terjeio]

Closing this as I believe the new tool change functionality is now completed.