E-Stop Active error

[nickshl]

When "E-Stop Active" error pop up ioSender does not allow do anything, but exit. grblHAL doc says:

IMPORTANT! grblHAL defaults to normally closed (NC) switches for inputs, if none are connected when testing it is likely that the controller will start in alarm mode.
Temporarily short the Reset, E-Stop and Safety Door4 inputs to ground or invert the corresponding inputs by setting $14=73 to avoid that.

I get that, I can open PyTTY and send $14=64, then ioSener starts fine and I can invert all other inputs right in ioSensed. But is is not convenient. I think ioSender should allow to change grblHAL settings even if E-Stop is active to avoid one more step with terminal.

[terjeio]

Some $ commands (including settings) was made allowable in grblHAL during a critical condition (estop beeing one) recently. I guess I have to add an element to the real-time report to distinguish between a controller that can handle settings changes and those wo can not before I attempt to change ioSender. And legacy Grbl does not allow $ commands neither real time commands when a critical condition is active complicating the handling of this further. So be patient, I'll get around to implement this.

[terjeio]

The latest grblHAL commit in combination with the latest edge version now allows changing settings when the controller is in a critical condition mode.

[nickshl]

Thanks! It will be useful for people who want to try grblHAL without messing with terminal. As for me, I build another prototype PCB for https://github.com/grblHAL/STM32F4xx/blob/master/Inc/blackpill_alt2_map.h that we designed. Then I realized that reset signal is EStop signal and mapped to BlackPill "key" button which allow to press and hold it to clear EStop and change settings.

By the way, is there a reason why there two versions of ioSender: regular and XL one instead application settings "Interface: Standard/XL"? It may be easier in long run to build and release only one version instead of two.

[terjeio]

By the way, is there a reason why there two versions of ioSender: regular and XL one instead application settings "Interface: Standard/XL"? It may be easier in long run to build and release only one version instead of two.

Most of the code is shared between senders via dll's so it is fairly easy to create multiple versions. In fact I have three senders on top of these, plus two utilities. Maintenance is, IMO, easier as well as I do not have to write unified code to handle the different layouts, and building is fast - less than 30 sec per version.