Implementation of Simultaneous Laser & Spindle in Lathe Mode

[engigeer]

I've been using grblHAL to control a 4-axis laser machine with great success, but there have been a few times where I would have preferred to use some of the features of lathe mode (e.g., CSS, feed / rev, independent spindle + feed overrides) rather than controlling my rotary as a 4th axis. I think the (relatively) new stepper spindle makes this application possible, but there are a few sticking points I'm struggling to resolve:

1. For both safety and functionality reasons, I would prefer to continue controlling my laser output as a (laser-mode) spindle. With support in the core for multiple simultaneous spindles, I am wondering how difficult it would be to enable a secondary (laser mode) spindle while also in lathe mode. Or perhaps there is a better way to achieve a similar result?

2. It is not clear to me, what would be the preferred method to handle overrides with multiple spindles active. Perhaps there would need to be a real-time command that could be used to toggle the active spindle during execution of a g-code program?

3. Ideally I would like to be able to "claim" and "release" the stepper motor back to functioning as a normal 4th axis at run-time rather than compile-time. I know that in some beta version of the stepper-spindle code this was possible, but maybe more of a bug than a feature. Interested to hear thoughts on what would be the best way to handle this? Should/could this be a modal state toggled via G/M-codes?

Any and all thoughts and suggestions are welcome and gratefully received.

[terjeio]

1. Support for multiple simultaneous spindles are in an early phase, there are several tricky issues to tackle to make it fully/seamlessly integrated. Overrides, simultaneous CSS and laser mode are some. Perhaps spindle data should (or rather must) be passed as a linked list from gcode parser down to step generation?

2. I do not like the term "toggle" since that hints at the current spindle switching mechanism with M104 or tool <> spindle binding. "Addressing" a spindle is more correct? At the gcode level it is by the $-word. There are issues related to this too, one is how to integrate this into senders?

3. When the stepper spindle is off it can be controlled as an axis - and there is a recent option added that allows position sync between axis/spindle.

[engigeer]

1. Support for multiple simultaneous spindles are in an early phase, there are several tricky issues to tackle to make it fully/seamlessly integrated. Overrides, simultaneous CSS and laser mode are some. Perhaps spindle data should (or rather must) be passed as a linked list from gcode parser down to step generation?

As far as I can tell both CSS and laser mode use data that is stored in the sspindle struct. So maybe the first step would just be to change machine_mode_t to a bit map so that Mode_Laser and Mode_Lathe are not exclusive? I think there would still be some small issues, (e.g., safety door handling) which would need to be updated to act on the individual spindles based on the hal.cap, but it looks like this is already implemented in many cases (e.g., feed-hold).

2. I do not like the term "toggle" since that hints at the current spindle switching mechanism with M104 or tool <> spindle binding. "Addressing" a spindle is more correct? At the gcode level it is by the $-word.

Yes, I agree toggle is not the best phrasing. Currently the overrides apply to the spindle which was most recently "addressed". I was thinking it should be possible to add a real-time command which changes the spindle the overrides apply to (without interrupting the g-code buffer). Although perhaps it is not possible (or desirable?) to change the gc_state with a real-time command and it seems that this function is currently used to select the spindle for applying overrides.

There are issues related to this too, one is how to integrate this into senders?

If this "last addressed" spindle was identified in the real-time report, then maybe you could use just a single command to "cycle" through the various spindles, and it would still be possible for a sender to identify which spindle the override is applied to and display this to the user (kind of like how toggling jog mode / jog-modifier works with the keypad plugin).

3. When the stepper spindle is off it can be controlled as an axis - and there is a recent option added that allows position sync between axis/spindle.

Hmm, this looks exactly like what I was proposing, and would even enable me to adjust this functionality within a program by setting $677 as desired.

However, in some testing with $677 = 0, I am still able to control the 4th axis from both the jog panel in ioSender and using G-code (e.g., G01 A10 F50). Am I perhaps misunderstanding how this is intended to work?

(edit: It seems that the claim_motor function may only be implemented so far in the STM32F4XX and ESP32 driver, and I have been testing with an RP2040. Likely this explains why $677 is not working for me.)

Not sure if it is related, but I am also getting a strange "clicking" noise when I test ran my stepper as a spindle. This was not present when moving the stepper with an A-axis command at the exact same feed-rate.

[terjeio]

You can add claim_motor() to the driver? And play around with other changes as well?
I have limited/sporadic time available for grblHAL at the moment (at least for the coming month) and this stuff is kind of complicated so I do not want to dig into it just yet .

[engigeer]

You can add claim_motor() to the driver? And play around with other changes as well? I have limited/sporadic time available for grblHAL at the moment (at least for the coming month) and this stuff is kind of complicated so I do not want to dig into it just yet .

Sounds good. Adding claim motor() to the RP2040 driver proved straightforward. Seems that all the functions were already there but it was just missing a definition of hal.stepper.claim_motor = stepperClaimMotor; in driver.c.

As you suggest, I will play around with some other things related to simultaneous laser + lathe mode and update here as things progress.