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.

[einencool]

Sounds interesting, I'll give it a try when it will be released :-)

[terjeio]

New release now available in the test branch. A compatible release of my sender application has also been published.

[S2000Stefan]

Hello,
a lot of things happened during the summer break I once allowed myself. You have been very active. I have to work on everything that is new.
Today I have taken a look at the new tool change mode and have also started a few attempts.
Unfortunately I did not get very far with my attempts. Everything refers to Beta 4.
My approach was to set workpiece Z zero point in the edge finder tab.

Then I set the reference offset in the tool length offset tab.

Unfortunately, when reaching the M6 command an error46 occurs.

Is my approach wrong or is the mistake somewhere else? ;)

Regards
Stefan

[terjeio]

The new tool change functions requires the machine to be homed, error 46 relates to that. See the status line in your last image, the message is a bit misleading - should be changed... Perhaps I should issue a warning before the program is started if not homed and there are tool change commands?

Note that I am currently working on improving tool changing - it is not working correctly in all circumstances. I am currently busy with other work so it is likely it will be a few days before any updates are ready.

[S2000Stefan]

Sorry i forgot to tell you that the machine will be homed at every startup. The error also occurred after immediate homing. Maybe my approach is wrong too?

Perhaps I should issue a warning before the program is started if not homed and there are tool change commands?

Would certainly be very helpful to avoid such errors.

Note that I am currently working on improving tool changing - it is not working correctly in all circumstances. I am currently busy with other work so it is likely it will be a few days before any updates are ready.

O.k. I am curious about the results.

[terjeio]

Could be that you have A-axis enabled? When homed the Home button should get a green background. Will have to check if a enabled A-axis is messing up checks in my code.

[S2000Stefan]

Could be that you have A-axis enabled? When homed the Home button should get a green background. Will have to check if a enabled A-axis is messing up checks in my code.

Yes the A-axis is activated, but only the linear axes are homed at my machine.

[terjeio]

I have commited a new version to the test branch as well as a new sender beta. Hopefully this will behave better.

[S2000Stefan]

Hi terjeio,
would it please be possible to write a small workaround how to proceed with a tool change, as you thought. After countless tests i can't find a solution. Of course everything refers to the last test branch grblhal and the last beta version of the GRBL GCode Sender.
First of all, to make it simple, it's all about that: manual touch off (1)
Here is a piece of g-code i use for testing:
G17
G21
G90
T1M06(MSG,End Mill 8 mm wood)
G0Z10.000
G0X0.000Y0.000
M3S18000
G4 P5
G0X0.000Y2.320Z3.000
G1Z-3.000F1400.0
G1X-0.305Y2.300F2800.0
G1X-0.619Y2.236
G1X-0.932Y2.125
G1X-1.233Y1.965
G1X-1.512Y1.759
G1X-1.759Y1.512
G1X-1.965Y1.233
G1X-2.125Y0.932
G1X-2.236Y0.619
G1X-2.300Y0.305
G1X-2.320Y0.000
G1X-2.300Y-0.305
G1X-2.236Y-0.619
G1X-2.125Y-0.932
G1X-1.965Y-1.233
G1X-1.759Y-1.512
G1X-1.512Y-1.759
G1X-1.233Y-1.965
G1X-0.932Y-2.125
G1X-0.619Y-2.236
G1X-0.305Y-2.300
G1X0.000Y-2.320
G1X0.305Y-2.300
G1X0.619Y-2.236
G1X0.932Y-2.125
G1X1.233Y-1.965
G1X1.512Y-1.759
G1X1.759Y-1.512
G1X1.965Y-1.233
G1X2.125Y-0.932
G1X2.236Y-0.619
G1X2.300Y-0.305
G1X2.320Y0.000
G1X2.300Y0.305
G1X2.236Y0.619
G1X2.125Y0.932
G1X1.965Y1.233
G1X1.759Y1.512
G1X1.512Y1.759
G1X1.233Y1.965
G1X0.932Y2.125
G1X0.619Y2.236
G1X0.305Y2.300
G1X0.000Y2.320
G1X0.000Y6.000
G1X-0.789Y5.948
G1X-1.600Y5.783
G1X-2.409Y5.495
G1X-3.189Y5.082
G1X-3.912Y4.550
G1X-4.550Y3.912
G1X-5.082Y3.189
G1X-5.495Y2.409
G1X-5.783Y1.600
G1X-5.948Y0.789
G1X-6.000Y0.000
G1X-5.948Y-0.789
G1X-5.783Y-1.600
G1X-5.495Y-2.409
G1X-5.082Y-3.189
G1X-4.550Y-3.912
G1X-3.912Y-4.550
G1X-3.189Y-5.082
G1X-2.409Y-5.495
G1X-1.600Y-5.783
G1X-0.789Y-5.948
G1X0.000Y-6.000
G1X0.789Y-5.948
G1X1.600Y-5.783
G1X2.409Y-5.495
G1X3.189Y-5.082
G1X3.912Y-4.550
G1X4.550Y-3.912
G1X5.082Y-3.189
G1X5.495Y-2.409
G1X5.783Y-1.600
G1X5.948Y-0.789
G1X6.000Y0.000
G1X5.948Y0.789
G1X5.783Y1.600
G1X5.495Y2.409
G1X5.082Y3.189
G1X4.550Y3.912
G1X3.912Y4.550
G1X3.189Y5.082
G1X2.409Y5.495
G1X1.600Y5.783
G1X0.789Y5.948
G1X0.000Y6.000
G0Z3.000
T2M6(MSG,V-Bit (60 deg 14 mm) wood)
G0X0.000Y10.768Z3.000
G1Z-3.000F1400.0
G1X-0.264Y10.765F2500.0
G1X-0.530Y10.755
G1X-0.799Y10.738
G1X-1.069Y10.715
G1X-1.342Y10.684

btw a bracket in the bracket at the tool change command gives an error, seen in the second tool change command, tool2
;)
btw 2 the error error 46 is fixed in the last beta

[terjeio]

If the bracket is the problem then your gcode is not compliant with NIST:

3.3.4 Comments and Messages

Printable characters and white space inside parentheses is a comment. A left parenthesis always
starts a comment. The comment ends at the first right parenthesis found thereafter. Once a left
parenthesis is placed on a line, a matching right parenthesis must appear before the end of the line.
Comments may not be nested; it is an error if a left parenthesis is found after the start of a
comment and before the end of the comment.

[S2000Stefan]

If the bracket is the problem then your gcode is not compliant with NIST:

no sorry the brackets were only a minor problem, they are very easy to delete.

The real problem is to know a tool change sequence, just as you thought. So here is a little tutorial on how the tool change should take place.
As I said before, I can't really handle the wiki. A short description would be very helpful.
I would like to help you a little bit, but I need to know the procedure to report possible errors.

[terjeio]

With $341 = 1:

Select first tool in the program (tool 1 in your example) by issuing M61Q1 in the MDI. The Q value is the tool number.

Select the probing screen and clear any tool offset in the Tool Length Offset tab - there will be a button there to clear it if it is set. [edit: "... any reference offset ..." -> "... any tool offset ..."]

• Place your touch plate on top of your work piece and enter its height in the Touch plate/fixture height box.

• Jog to place the tool in position over the touch plate and select the Edge finder tab and then probe Z. This will establish Z zero on top of the workpiece.

• Select Tool Lenght Offset tab and probe again with Establish reference offset checked.

IMO the two previous steps should be combined into one, in the Tool Lenght Offset tab?

• Remove the touch plate and start the program. The first tool change to tool 1 will be ignored as it is already set up.

• When the next tool (tool 2) is selected the Z axis will back off to the home position. Jog to XY where you want to change the tool and change it. Place the touch plate on top of the workpiece again and jog into position to probe it. Issue $TPW in the MDI (or run a previously created macro for it), this will establish the new tool offset. Remove the touch plate and press Cycle Start to continue the program.

"on top of your work piece" could be anywhere convenient to establish the reference needed, it does not have to be on top of the workpiece. If this is on a fixed position on the machine then $341 mode 2 or 3 may be a better choice.

I hope this helps for now - I am soon ready to dig into the tool change/probing stuff again so any feedback will be appreciated.

[einencool]

Thank you for this „manual“ :-)

I would like to test it tomorrow, so just two short questions for this.

IMO the two previous steps should be combined into one, in the Tool Lenght Offset tab?

Yes I would think that makes sense, because in the past I didn‘t know that you mentioned it this way.

So when I set the Z=0 on top of my Workpiece, then I can set the „Reference“ maybe in the Baseplate in front of my Workpiece (maybe 40mm deeper) and after a toolchange I can also set the second TLO in front of the Workpiece?

And I have to Enter „$TPW“ into the field in the bottom left? And this could be linked to an Macro which could be started with the shortcuts?

I want to use the $341=1 because sometimes I can‘t use the defined position for the TLS and then it would be easier to make it this way...

[einencool]

Oh, one more question :-)

When I use the 3D-Finder in my machine, I don‘t have a ATC-Spindle, so my Tool length changes every time.
When I Set my X & Y Zero with the 3D-Finder, can I Set the Z-Zero with the 3D-Finder and reference it on the TLS and when I start the Program, I will be able to set the Offset with the TLS?

[S2000Stefan]

Well, that's something to work with.
Thank you very much for the short description.
I will definitely do some tests tomorrow and report very soon.

[terjeio]

So when I set the Z=0 on top of my Workpiece, then I can set the „Reference“ maybe in the Baseplate in front of my Workpiece (maybe 40mm deeper) and after a toolchange I can also set the second TLO in front of the Workpiece?

Yes, this should work - it is important that the touch plate height is set correctly.

And I have to Enter „$TPW“ into the field in the bottom left? And this could be linked to an Macro which could be started with the shortcuts?

Correct. Cycle start will be ignored until this command has been run.

When I Set my X & Y Zero with the 3D-Finder, can I Set the Z-Zero with the 3D-Finder and reference it on the TLS and when I start the Program, I will be able to set the Offset with the TLS?

Not sure I understand or if this will work, you want to probe the touch plate with the 3D-Finder to set the reference and then set the actual offset by probing again with the tool?

[einencool]

When I Set my X & Y Zero with the 3D-Finder, can I Set the Z-Zero with the 3D-Finder and reference it on the TLS and when I start the Program, I will be able to set the Offset with the TLS?

Not sure I understand or if this will work, you want to probe the touch plate with the 3D-Finder to set the reference and then set the actual offset by probing again with the tool?

Yes i think you are right... i made a little mistake in my thinking...

I can’t connect the 3D finder and the TLS At the same time.

So i would like to touch off the workpiece directly with the 3d finder .
Then touch off the baseplate Directly as the reference...
I have to set the height of the probe plate also for the 3d finder, because only the difference between the two surfaces matter (i think)
And after that i have to measure the tool length offset with the tool and the TLS on the Baseplate.

Would this be the right workaround?

[terjeio]

I have to set the height of the probe plate also for the 3d finder, because only the difference between the two surfaces matter (i think)

You have to consider the difference between the probe and the tool as well?

Would this be the right workaround?

I could be, why not just try it to find out?

[einencool]

I'll try it today :-)

Just wanted to reduce my risk of killing the 3d finder, but now we are able to reduce all the speeds so I can push the button in case of any problems.

I'll report back, if it works or not. Then it could be really simple to measure the x y and z axis directly and then just generate the offset for the endmill

[S2000Stefan]

First results. I followed your instructions exactly and got the following error.

Also I do not get a clear button in the tab tool length offset.

But the tool window (Tool 1) turns green.
No TLO is visible in the console either.
The feed rate settings $344 have no effect or think only 1/10 of it.
With $341=2 the same error message.

Probe Fixture @G59.3 works as described above except for the feed rate. The procedure is o.k..

In the Probing Tab only one entry is possible for the profiles. That worked once? :)

[einencool]

Hmm, very strange,
I changed Tool no. 1 with the clickbox in the top right from your sender.
This should be for testing my 3D-Touch

Then I changed to the Probing Tab and touched off my workpiece Z=0
Like @S2000Stefan said, the Dropdown for different Touch Probes doesn't work...

Then I changed to the "Tool length offset" tab and make the "Reference measurement" on the Baseplate
Then I startet my GCode File (it is without turning the spindle on, it's only to see, if the workflow is correct.

It shows me in the status bar the message for Tool no. 1000 but the Z-Axis doesn't move up or anything else.
After around 5 seconds (it's my waiting time for the Spindle) my Z-Axis drives down and wanted to go into my Baseplate.
It was just starting in the next lines of the GCode.

Attached is the GCode File, can somebody tell me, whats wrong with it?
It doesn't matter if I "Strip" the M6 command or not...
Wechseltest atc.nc.txt

:EDIT:
One question, what is the difference between
Touch Plate
and Fixture heigth ?

[terjeio]

I have tested with a tool table enabled and not resetting the controller before each test - so I have missed some scenarioes. Testing a fix now.

I have edited the procedure above as I incorreclty wrote that any tool reference offset should be cleared, the correct one is any tool offset. The button only shows up if there is an offset active.

Note that setting the reference offset does not set any tool offset, it just records a reference for calculating the offset applied for subsequent tools. If set the reference offset is reported in a new message in the $# report: [TLR:nnn].

[terjeio]

Attached is the GCode File, can somebody tell me, whats wrong with it?

Likely nothing, I'll use it for testing - with the changes I have made it seems to run just fine.

One question, what is the difference between
Touch Plate
and Fixture heigth ?

Fixture height is not in use yet and may go away - or could be of use when probing with a tool at fixed touch plate @G59.3, this in to establish an absolute position above the table?

I think I should disable fields on the left side depending on which is relevant to the tab selected.

[einencool]

I've got a question for the Shortcut "Alt - R" for starting the Probing Routine.

When I press the Shortcut in the Software on the Keyboard, everything works fine. But when I try to use my Game Controller with the Shortcut set to Alt - R, it doesn't work.

Do you have an idea, why this doesn't work?

[terjeio]

What I believe is a fix is now committed to master for testing.

The feed rate settings $344 have no effect or think only 1/10 of it.

Feedrate is reported back correctly in the sender, but I have not timed it yet. Do you see a incorrect rate reported back?

In the Probing Tab only one entry is possible for the profiles. That worked once? :)

It did, but a property change on the control has changed its behaviour in an unexpected way. I need work around that.

When I press the Shortcut in the Software on the Keyboard, everything works fine. But when I try to use my Game Controller with the Shortcut set to Alt - R, it doesn't work.

Does it trigger Cycle Start in the Grbl tab? I cannot think of any reason it shouldn't work for probing if it does.

[S2000Stefan]

Fixture height is not in use yet and may go away - or could be of use when probing with a tool at fixed touch plate @G59.3, this in to establish an absolute position above the table?

So I would like that and I understood that the fixture heigth is for a fixed touch plate @G59.3, which I would like to use.

Feedrate is reported back correctly in the sender, but I have not timed it yet. Do you see a incorrect rate reported back?

I can't say whether the advertisement is correct, I didn't pay attention to that. I mean only when the tool moves to the fixed touch plate @G59.3, it makes almost no difference if I enter 200mm or 3000mm feed in $344. I always feel that the cutter moves at 100/300mm.

[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. 👍

[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. 👍
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.