[FEATURE REQUEST]grblHAL tool changer support

[luc-github]

Per suggestion of @terjeio #252 (comment)
webui need to support grblHAL style tool change handling

here the operations: https://github.com/grblHAL/core/wiki/Manual,-semi-automatic-and-automatic-tool-change

@terjeio do you have some hardware suggestion for the tool changer ?
I need to setup one to understand the constraints

Also do you have any expectation of UI or actions you want to have in WebUI ?

As CNC newbie I need some advices 😸

[terjeio]

do you have some hardware suggestion for the tool changer ?

No, and if the machine has a tool changer and support code for it then no changes are needed for the WebUI.

The tool change protocol is for manual or semi-automatic tool changes where the tool itself has to be changed by hand, and the touch-off for setting the correct position is either manual or automatic. All modes works by the controller changing the state to Tool and wait for the sender sending acknowledge command character 0xA3. After this the user changes the tool and perform a touch-off to set the correct offset. When done either a cycle start command is sent, or the cycle start input pin is asserted, to restart program execution.

When WebUI detects the 'Tool' state it should change the Pause/Resume button to Pause state so that a cycle command can be sent. This is enough to support the protocol as I belive jogging and zeroing the offsets can be done at all times from the WebUI.

For more a more advanced implementation you may consider adding status markers (similar to the Input pins markers?) to indicate that the tool length reference has been set with the $TLR command and one to show that a tool length offset is active. I have such markers in ioSender in the Work Parameters grouping. (Macro) buttons for the $TLR and $TPW commands would also be nice? In ioSender I leave it to the user to define macros for those.

FYI Stefan Bauer, @S2000Stefan, has made some nice YouTube video tutorials for ioSender, among them one for tool changes.

A small program with tool changes:
Noname1.zip

[luc-github]

No, and if the machine has a tool changer and support code for it then no changes are needed for the WebUI.

sorry my question was more what do I need to do to add tool changer to my cnc ? because today I do not have any

The tool change protocol is for manual or semi-automatic tool changes where the tool itself has to be changed by hand

Ho ok I was thinking grblHAL support same as this one https://www.youtube.com/watch?v=3ikLcC5NidU in grbl_ESP32

For more a more advanced implementation you may consider adding status markers

Thank you I will have a look to these

FYI Stefan Bauer, @S2000Stefan, has made some nice YouTube video tutorials for ioSender, among them one for tool changes.

Great I will check these also - thank you

[terjeio]

sorry my question was more what do I need to do to add tool changer to my cnc ? because today I do not have any

You have to make or buy one - and then write a plugin to handle the motions involved. I have a Kress spindle in my machine, and the ATC and tool holders are very expensive so not something I would consider for my hobby use. But sure I would like to have one...

One day I might write a configurable plugin for ATCs - but I would need a test setup for debugging/testing.

[luc-github]

Thank you the ATC and tool holders are very expensive information what was I needed ^_^
Definitly out of my budget 😓

[errolt]

Don't know if I should file a separate bug, but with V3, when grblHAL goes into TOOL state, the GUI doesn't notice that is is a form of HOLD mode, and the pause button stays a pause button instead of changing to a play/resume button. So, no way to resume.

[luc-github]

as you see this is still in feature request, tool change is not yet implemented

to mitigate you can add a macro button with command to resume

[errolt]

That is fine. I couldn't figure out if this FR is only for semi auto/auto tool change, or for all tool change.

[luc-github]

tool is specific feature of grblHAL and I need to spend time on understand it to implement ui properly

[terjeio]

@luc-github I believe it should not be too difficult to implement as the WebUI runs gcode stored on the SD card - stream switching is taken care of by the SD card implementation.
You may try this:
When Tool state is reported send the acknowledge character (0xA3) and enable feed hold mode in the UI so that the cycle start character (~ or 0x81) can be sent. I believe jogging is possible per default so no need to change that.
If the Tool state is exited for some reason (could be the user signalling cycle start via a physical button) change the UI to match whatever the new state is.

[luc-github]

@terjeio thank you for the explanations, I did not had time to experiment tool state yet.

• if Tool state in report
  1 - send the acknowledge character (0xA3)
  2 - show resume button (~ / 0x81)

• if Tool state disappear
  1 - follow new state UI

I will check this - it is indeed simple to implement, I just need to track I send only one ack

[luc-github]

@errolt @terjeio sorry for the delay - I was busy on others topics, here the implementation of the support of Tool state as described above
https://github.com/luc-github/ESP3D-WEBUI/blob/3.0/dist/CNC/GRBLHal/index.html.gz

Please give a try , let me know if any other change are necessary

[terjeio]

I do not have a machine to test with, however a dry run looks good to me:

Even the message that can be associated with a tool change is displayed. 👍

@errolt can test with a machine?

[luc-github]

@terjeio I have a question - sorry I did not digged in grblHAL to grab the solution...
any impact of sending several 0xA3 ack ?
Like in this user case :
1- Webui detect the Tool change state => send one 0xA3 => Ok
2 - User close the web UI
3 - User open again the web UI => UI see state is unknown then at first ? report,see the Tool state => Send again 0xA3

Other user case:
1 - user use Sender that manage Tool change and webUI is closed => Sender send the 0XA3 =>Ok
2 - User open the web UI => UI see state is unknown then at first ? report, see the Tool state => Send again 0xA3

Any issue for getting a new 0xA3?

I could ignore the change state if just opening webui but if webUI is open after any Tool state change ack is sent, webui do not send 0XA3, and so the 0xA3 will be never send

It can be an edge case but because of Murphy law...

[terjeio]

@luc-github Sending more than one ack should have no ill effects since it is waited for after the state transitions to Tool. When the ack is received after the transition the wait is terminated and further acs are ignored.

[luc-github]

Perfect! thank you 😸

[errolt]

@errolt can test with a machine?

Will do, but might only happen over the weekend.

[errolt]

Looks good.

Can't do a probe, but that is ok. I can use jog to touch off manually.

Thanks!

[luc-github]

Can't do a probe, but that is ok. I can use jog to touch off manually.

Do you mean probe panel is not working ? is something wrong ?

[errolt]

I'm sorry. I should have been clearer. I was testing the jogging during Tool change state. In that state probing gives an Error 40, if I recall correctly. Something like "Only $ commands allowed". And I couldn't find any info in the grblHAL on if a probe can be done during a tool change. Jogging and zeroing works great though.

[luc-github]

@terjeio is that expected behavior ?

[terjeio]

And I couldn't find any info in the grblHAL on if a probe can be done during a tool change.

See here. Before starting streaming the gcode probe the workpiece, or a fixture, on a fixed position and set the initial tool reference with $TLR. After a tool change jog to the same fixed position and do the probe with the $TPW command - this performs a probe and sets the tool offset accordingly.

is that expected behavior ?

Yes. However, I can change the code to allow G38.x, but not sure if that will be helpful as a probe should change the tool offset to match the new tool?

FYI in ioSender I have "LED" indicators showing if the controller has the tool length reference set and if a tool length offset is active.
If a $TLR command is sent after a successful probe a |TLR element is added once to the real trime report. I use this to turn on the tool length reference set LED. The tool length offset LED is turned on when G43, G43.1 or G43.2 is present in the $G report and off when G49 is present.
Such functionality is "nice to have" but not required.

[luc-github]

I guess it can be close as original topic is implemented

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.