Skip to content

Enable settings (`$`) reading and GPIO (de)activation (`M64/M65`) commands while in "blocking" states (e.g. Hold)

Gabriele De Blasi requested to merge wip-commands-relaxation into sambuca-2.2

Grbl has some states where it enters a sub-cycle of the main one which can be seen as blocking states.

The blocking events that causes Grbl to move into such a loops are:

  • EXEC_FEED_HOLD, EXEC_SLEEP and EXEC_SAFETY_DOOR and EXEC_MOTION_CANCEL events which leads to the "suspend procedure" basically consisting in a dedicated while loop.
  • Alarm_HardLimit, Alarm_SoftLimit, Alarm_EStop and Alarm_MotorFault critical events that brings Grbl into another dedicated loop from which it can only exit with a reset command.

Both loops are able to run real-time commands but not $- and g-code commands as the main loop does. In particular, the fist loop execute real-time commands through the protocol_exec_rt_system function (here), whilst the second via the grbl.on_execute_realtime (here).

Thus, based on the upstream's repo modifications, the idea is to loosen the Grbl's restrictions by continuing to poll the input stream and attempting to execute commands (only the allowed ones) during these blocking states.

The function intended for polling and execution is protocol_poll_cmd and is a semplified version of the one in the main loop (here) ensuring the processing of system ($-) and g-code commands. This function is then invoked in the two loops mentioned before:

  • suspend procedure -> here
  • critical procedure -> here

Regarding g-code commands, only the M64 and M65 are permitted when the system is blocked since it is only intended to allow the activation/deactivation of I/O pins. For system commands ($-), all those that do not cause changes to the Grbl's settings are accepted. For all others, the following error will be reported:

Command not allowed in this state. System MUST be IDLE.

NOTE: alarm states that the system may reach following a reset command should not be considered as "blocking" states (e.g. resetting during a motion) since all GRBL functionalities can be accessed after unlocking ($X) or homing ($H). Thus, in those cases it is possible to read and write settings but not to run g-code at all (otherwise an error will be displayed. See the code executed after each Grbl reset.

PLUS: this merge request also includes the fix for recovering g-code parsing after an error.

Unit-tests: grbl-gpiod@bafe8527

Edited by Gabriele De Blasi

Merge request reports