Serious safety deficiencies in GRBLhal: EMERGENCY STOP + Feed-Stop

[digidiver11]

Serious safety deficiencies in GRBLhal:

• EMERGENCY STOP - function faulty
• Feed-Stop - function faulty

I have noticed the following errors:

BOTH above inputs are correctly displayed in the IOSender but internally only the level change is evaluated.

The NOT-STOP can NOT be activated correctly in idle mode !
I.e. in spite of activated EMERGENCY STOP the axes can be moved by JOG commands!
If the EMERGENCY STOP has been activated (statically set) in idle mode (the IOSender also shows the activation correctly !),
the machine can be started normally in spite of activated EMERGENCY STOP !!!

Here is missing in my opinion the real port query of the NOT-STOP and the prevention that a command is accepted at all.

The FEED-Stop should also as above in any case NOT (only) evaluate the level change but the static FEED-Stop signal.
It is very important, that the machine can NOT start automatically, if the FEED-Start should be set because of an error.
Here the "machine protection law" already demands an automatic restart.
I.e. the FEED-Start should evaluate the level jump with a small time delay.
In no case the pure static signal should be evaluated here.

Good function:
The values of the X-, Y- and Z-axes are retained during EMERGENCY-STOP and FEED-STOP, please keep it that way !

Note:
In the past, with the normal GRBL (ATMEGA), at the EMERGENCY stop, the MCU was simply pulled to RESET.
Thus a real EMERGENCY STOP was present, but unfortunately also the values of the X, Y and Z axes were lost.
This should no longer be so.

With best regards

[terjeio]

EMERGENCY STOP - function faulty

Are my mixing Reset (or soft reset, inherited from legacy Grbl) with the grblHAL Emergency stop signal? The former does not block execution if asserted unless $64 (Force init alarm) is set true (at startup only), the latter should block execution until the input is deasserted. Drivers typically implement one of these bound to the same input pin, the default mode is driver and compatibility mode dependent. In ioSender the reset signal "LED" is denoted by "R", emergency stop by "E". Safety wise it is better to have the reset input routed as emergency stop and to relay(s) that cuts power to the spindle and steppers when it is asserted.

The NOT-STOP can NOT be activated correctly in idle mode !

I do not understand what you mean by "NOT-STOP".

The FEED-Stop should also as above in any case NOT (only) evaluate the level change but the static FEED-Stop signal.
It is very important, that the machine can NOT start automatically, if the FEED-Start should be set because of an error.

This is carried over from legacy Grbl and, if changed, would likely result in a lot of support noise? It seems to me that many do not connect any of the control signals to switches at all... I could add interlock options for feed hold and cycle start , maybe like this: if cycle start is permanently asserted it should block any movement (even when asserted during motion?), if feed-hold is permanently asserted likewise so - and it should in addition block any cycle start command or signal.

The values of the X-, Y- and Z-axes are retained during EMERGENCY-STOP and FEED-STOP, please keep it that way !

This is only true if a soft reset or and emergency stop is detected when no motion is ongoing. If ongoing the physical position is likely to be different from what the controller believes due to no system having infinite deceleration. Feed hold executes a controlled deceleration to a stop so that will keep the position in both grblHAL and legacy Grbl. What is new in grblHAL is that homed position can be kept over a soft reset or an estop if position is not deemed lost - a $22 (homing cycle) option.

In the past, with the normal GRBL (ATMEGA), at the EMERGENCY stop, the MCU was simply pulled to RESET.

Legacy Grbl does not have an emergency stop input that is handled by firmware. Resetting the MCU is the same as cold start. You can still connect the MCU reset input on most grblHAL controllers (?) to an estop switch if you want, but note that this will sever any native USB or network connection and any data in memory will be considered lost.

Here is what it looks like in ioSender when estop is asserted:

Jogging is blocked (by the sender), error 9 is returned from the gcode parser and error 79 from the $ command parser until the estop input is deasserted and Reset/Unlock commands are sent.

[digidiver11]

Hello Terje Io,

thank you for your quick answers !!!

First of all about the EMERGENCY stop:

The board used was a "BSMCE04U".
The MCU is a GD32F303RCT6, seems to be a STM32F103CBT6 clone.

First of all, as a developer for MCU hardware, I intend to develop a completely new board.
That's why I'm testing a lot of ready-made boards at the moment. An absolute Karnkheit is meanwhile the crap,
that comes from China. Unfortunately the STM32F CPUs are copied or cloned extremely often.
Partly with extreme errors and very often not working USB ports !

I personally would go for the TEENY 4.1 as MCU in the future, similar to the T41U5XBB board.
I hope for a much higher MCU quality and the suitability for a lathe.

Now back to the subject of EMERGENCY stop:

I have the pins of the above mentioned "BSMCE04U".

PB8 - feed hold
PB9 - reset

used.

I wanted to use the RESET pins, presumably a soft RESET, as "EMERGENCY stop".
With "EMERGENCY STOP" I mean the big emergency stop buttons, which have to be unlocked after operation.
Since the function did not work properly, in that for example a machine that is in idle mode, can NOT be
can be locked with this switch. This RESET PIN (PB9) is NOT polled when the machine is idle.
This allows the machine to be moved by JOG command.
Furthermore, with the RESET-PIN locked in this way, the machine can even be started, via G-code.
Only if the RESET PIN is released once briefly and then set again,
the machine goes into ALARM and stops completely.
I.e. this RESET-PIN reacts only to a PEGEL-change not to a static H- or L- signal.
Here is missing in my opinion a simple "AND-connection" in the software, for the gesmaten machine start.

You are of course right, there is ALWAYS an additional hardware shutdown necessary !

With the FEED hold signal (PB8) I can live with the error.
If necessary, the restart can be prevented by external hardware.

Surely it is true what you had written, most users will simply not use many PIN.

Thank you very much for your great project.
I would like to know what is the difference between the T41U5XBB and the T41U5XBB-Pro board.
I have already seen the modifications for a lathe spindle encoder.

with best regards

[terjeio]

I wanted to use the RESET pins, presumably a soft RESET, as "EMERGENCY stop".

This is not supported by the STM32F1xx driver, it is a relatively small change so give me a little bit of time and I'll fix it.

As for designing a new board I would definitely go for a MCU with a FPU - currently you will need it for lathe spindle sync. And I am not likely to add spindle sync support to more than a few selected drivers, this to keep support issues down. BTW I have "upgraded" my lathe to a STM32F446 MCU so that is going to be my test platform.

I would like to know what is the difference between the T41U5XBB and the T41U5XBB-Pro board.

In addition to rerouting pins for spindle sync I believe a pin was added to control direction of a RS485 serial breakout (for Modbus) and, IIRC, it was to have FRAM for settings storage per default. And a connector for host mode USB? (no code support for that as for now). @phil-barrett can give a more precise answer as he designed the boards.

[terjeio]

I have now committed a version that routes the reset input as emergency stop as default. I will add mode selection as a Web Builder option later.

FYI I have not tested this change due to lack of time, but I assume it will work as the changes was copied from the STM32F4xx driver...

[digidiver11]

Hello Terje Io,

Thank you for your quick responses and remedies. Sorry it is taking me a little longer to respond at the moment.
I'm still dealing with my hay fever ....

I think it is great that you have so quickly made a remedy, better software adjustment.

I gladly accept your suggestion to also upgrade my lathe with the STM32F446 MCU.
Tomorrow I will order the NUCLEO F446RE board at Reichelt Elektronik. There it costs only about 22,- Euro.
I had planned to use the STM32F411 before.

Since I like to work with the STM controllers, also professionally, this MCU is ideal for my project.
Probably I will use my lathe and a board similar to yours.
In any case, this board combination will be used for testing. If this has proven itself,
the board will remain permanently in the lathe.

A short question in addition, how many impulses does your turning encoder at the spindle.

Thank you very much for your commitment and the great project!

with best Regards

[terjeio]

Tomorrow I will order the NUCLEO F446RE board at Reichelt Elektronik. There it costs only about 22,- Euro.
I had planned to use the STM32F411 before.

The F411 can be used as well, it somwhat slower than the F446 but still capable of running a lathe.

A short question in addition, how many impulses does your turning encoder at the spindle.

120 PPR. However this is configurable and can be significantly more (or less) as the interrupt generated from it is automatically adjusted according to the PPR setting.