Control box hangs up unless i/O sender is connected

[Meliusja]

Hi,
I'm just asking to find out if this behavior is expected or if I screwed something up. I made a control box that interfaces over modbus. I notice that grbl seems to get hung up when I try to use the control box without a sender being connected. For example activating hold mode gets stuck,

2nd question, is there a way for a plugin to detect when a sender is actively running a gcode file?

Jeff

[terjeio]

I notice that grbl seems to get hung up when I try to use the control box without a sender being connected.

This will happen if the primary stream is via USB as this blocks if no client is connected and the buffers are full. I have it on my todo list to add an event for client connect/disconnect and use that to set the hal.stream.state.connected flag. But I have not yet managed to implement this...
A possible workaround is to hook into the hal.stream_blocking_callback, this will called when the USB stream blocks - you can then exit the blocking loop and stop replicating data to the USB stream.

is there a way for a plugin to detect when a sender is actively running a gcode file

By checking that the status is STATE_IDLE by calling state_get()? It is not perfect but it is the best option unless the gcode is delimited by % which allows the use of the gc_state.file_run flag.