We noticed that when door is opened (generating a feed hold), the lightburn communication with GRBL is frozen, lightburn shows it as “busy”.
The same happens when sending manually a feed hold ("!").
The thing is that GRBL doesn’t reply to commands when on hold, so no “ok” back. Only e.g. status command ("?") or resume ("~") works when tested on a serial terminal. But even in lightburn interface we can’t sent that “?” or “~” because lightburn assumes the serial stream is still busy.
Tested on a grbl 1.1h and a grbl 1.1f.
One can easily test by just sending “!” in lightburn console then trying to recover from it.
Note that there are other situations when GRBL becomes unresponsive to other commands than realtime commands, e.g. when receiving ‘0x84’ (safety door) and entering Door state.
So please making sure the lightburn interface can understand and handle grbl when on hold/door states and allows the sending of grbl realtime commands at any moment (?, !, ~, ctrl-x,…)
I cannot make LightBurn allow realtime commands through at any moment, but I could make LightBurn see the [DOOR] message, assuming there is one, and put it internally into pause mode, so you could then click the pause button again to have it resume. Would that be sufficient?
I flashed a firmware with ENABLE_SAFETY_DOOR_INPUT_PIN so now it triggers a Door state instead of Hold state.
IMHO what could be done:
Catch the “[MSG:Check Door]” which is the signal a door open event occurred. At this stage, serial comm should not be “busy” anymore, to allow manual sending of commands such as “?” and “~” in the console.
When a “[MSG:Check Door]” occurs, lightburn should probe regularly (with “?”) the status. It’s “<Door:0|…” when door is still open and “<Door:1|…” when it is closed. So when the door is closed, then it can be considered “paused” and can be resumed via your button (which sends “~” ?) or stopped (which sends ctrl-x?).
I tested Openbuilds CONTROL behavior and it’s like this:
opening the door →
[MSG:Check Door]
“?” → <Door:0|…
Message displayed in GUI: door opened, paused
closing the door →
“?” → <Door:1|…
Message displayed in GUI: door closed, ready to resume
“~” (resume) →
“?” → Idle (or it continues the interrupted command if door was firstly opened during a command)
Message displayed in GUI: idle or run
When lightburn is stuck in “busy” state because of a Hold or Door and is waiting for a never coming ack from grbl, it could be nice to be able to still reset the serial communication, e.g. via the stop button clearing the “busy” state and sending a soft reset (ctrl-x)
If LightBurn leaves the “streaming” state and goes back to command processing, it will lose its place (and your job). If I make it trigger the “paused” state internally, the “Pause” button would become “Resume” and the resume button will trigger the immediate mode command to continue. Stop triggers Ctrl+X, so it should all behave.