Laser mode spindle enable after pause

[MadTooler]

When sending from UGS and rp2040 grblHal in laser mode, my M3 spindle/laser does not reactivate properly when resuming from a pause/halt of a program. It appears it will finish the rest of the g01 line it was halted within, then reactivate the spindle at the next g01. This means short distance segments are less noticeable in the issue as long segments.

I am not sure if this is UGS or grblHal issue, but my thinking is it may be in grblHal.

I also notice some of the same issue as noted in grblHal core issue #99 where the spindle/laser starts at the initial g00 of my program if the M3 S1 is set before the g00.

[terjeio]

This is a bug, can you try with changing:

https://github.com/grblHAL/core/blob/d10804433c2b1060bb8ad6c5fa04218c2cf435a8/state_machine.c#L564

to

            step_control_t step_control = sys.step_control;
            state_set(STATE_IDLE);
            sys.step_control = step_control;

?

I also notice some of the same issue as noted in grblHal core issue https://github.com/grblHAL/core/issues/99

Do you have an example for this? There is a bug but that will only show up if the G1 motion programmed after the G0 has the same target.

[MadTooler]

I tried the suggested change to state_machine.c and it appears to work. Thanks!

Do you have an example for this? There is a bug but that will only show up if the G1 motion programmed after the G0 has the same target.

While checking on this issue, I did find some of the troubled gcode did g0 to same coordinate as the following g1. The CAM posting is a bit odd from the software I am trying (inkstitch out of inkscape). When I removed the like lines, the issue did not appear to occur again. Even odder, this was before I made the change noted above to state_machine.c. During that test, I could not get the above restart issue to occur on the longer straight sections of that gcode, in which they happened to be single axis changes (example x1y1 to x0y1). I am wondering if there was also an element for the restart issue to occur, it needed to be a coordinated change to multiple axis. Either way, it seems better for now.

Somewhat related non bug, at some point I may need a short delay for the spindle/laser to start and restart. Is this possible within the current setup?

Thanks again. Your impressive work is making my project look good;)

[terjeio]

... I may need a short delay for the spindle/laser to start and restart. Is this possible within the current setup?

If you cannot use G4 then no - and it might be difficult to add for laser mode as the PWM value is set by the step interrupt handler.

[MadTooler]

I could use G4 at the beginning of the program, but I don't see how for a pause/start case. For now, it does not seem needed while all of my gear behaves.

[terjeio]

... but I don't see how for a pause/start case.

I could add a pre state change event you could subscribe to in a plugin.

[MadTooler]

... but I don't see how for a pause/start case.

I could add a pre state change event you could subscribe to in a plugin.

For now, all works well without the delay. My potential need is based on a concern the rpi node-red doing the task of "spindle" starting in laser mode (not actually a laser) may get delayed in processing by other tasks. When it is running well, there is no problem. I was only thinking of adding some insurance since the different processors I am using run open loop from each other.

That said, I wouldn't chase a solution as you suggested unless you think others will benefit now.

[terjeio]

Fix committed.