[Grbl_Esp32 Issue#298] grbl_ESP32 does not handle a latching ESTOP or ‘reset’ switch

#1 – bdring 于 2019-11-24

E-Stop

A true E-Stop, for use in an emergency should cut all power to the system. You don’t want to rely on firmware, stepper or spindle drivers, which may be the cause of the emergency.

The problem is, most of the reasons you need to stop are not a true emergency, like a clamp coming loose or in the way of a cut. In that case you want to do a controlled stop that you can later resume. A controlled stop quickly decelerates the stepper motors, so no steps are lost.

There are 2 ways to do this. They are feed hold and safety door.

Feed hold

Feed hold “latches” in firmware. It will stay in the feed hold state until you send the cycle start command. Both of these can be sent via any of the control interfaces or by button. Feed hold immediately decelerates the motors. The spindle stays on.

Safety Door

Safety door is used on machines that have enclosures, where you want to prevent access to a running machine. If the door is opened. a feed hold will occur, the spindle will retract and stop. To clear this state, you must close the door and send the resume command. The spindle will spin up, return to the the work and resume the job.

Reset

The reset command is not designed to stop the machine. It is designed to reset the machine state. If you are doing a long move and send a feed hold command, the machine will pause. You have 2 options now. If you want to continue, you send the resume command. If you want to end the job, you need to clear out the rest of the job and related machine states with the reset command. You can now send new gcode.

It sounds like you might want to use the safety door command, even if you don’t use a “door”. This cannot be cleared until someone clears that switch.

Background

I used the safety door on the Carvey machine I designed for Inventables. We needed it to comply with safety regulations. We actually hired Sonny (Grbl) to add that feature to Grbl.

That machine also locked out spindle power when the door was open, so rogue firmware could not turn on the spindle while a person was changing the bit.

I have not used it since I did the ESP32 port. I don’t recall how much testing was done on it. It might need a few tweaks.

#2 – owenduffy 于 2019-11-24

Thanks for your thorough answer Bart.

Firstly I did not want to hack with code not fully understanding the RTOS implementation, and anticipating that simply blocking on the ESTOP will probably result in other problems due to failure to yield.

I understand all that you have said, and note that the VFD on my machine is very slow in normal response and does not seem to have an ESTOP (Chinese docco)… so in an ideal world, that is a problem.

Given there is a power switch adjacent to the ESTOP, I could regard that operationally as the true ESTOP where personal injury or machine damage was at risk. Reading your description, connecting my latching ESTOP to the safety door input may be a simple but effective measure. I will test that today and report back.

Thanks.

#3 – owenduffy 于 2019-11-24

On further reading (src) it seems safety door depends on homing, and I do not yet have limit switches installed (my fake homing is to use G28.1 for scripts that use G28xxx). I will try feed hold and see what happens with the latching switch… it that causes grief.

Sun is up soon, so it will be a few hours.

#4 – owenduffy 于 2019-11-24

It does not like the feed switch to latch. It does this then cyclicly reboots:

”’
[MSG:Axis count 3]
[MSG:RMT Steps]
An unexpected error was detected: Guru Meditation Error: Core 1 panic’ed (Cache disabled but cached memory region accessed)
Core 1 register dump:
PC : 0x400e0678 PS : 0x00060034 A0 : 0x800813b4 A1 : 0x3ffbe940
A2 : 0x00000000 A3 : 0xb0000000 A4 : 0x00060021 A5 : 0x3ffd0a40
A6 : 0x00000001 A7 : 0x3ffba610 A8 : 0x8008133d A9 : 0x00000001
A10 : 0x000002aa A11 : 0x3ffd0b90 A12 : 0x80134ddc A13 : 0x3ffd0b40
A14 : 0x00000020 A15 : 0x3ffd0ccc SAR : 0x00000017 EXCCAUSE: 0x00000007
EXCVADDR: 0x00000000 LBEG : 0x40001699 LEND : 0x400016aa LCOUNT : 0xfffffffe
Core 1 was running in ISR context:
EPC1 : 0x40062235 EPC2 : 0x00000000 EPC3 : 0x00000000 EPC4 : 0x400e0678
Backtrace: 0x400e0678:0x3ffbe940 0x400813b1:0x3ffbe960 0x40084de1:0x3ffbe980 0x40062232:0x3ffd0a80 0x40098b17:0x3ffd0aa0 0x40098b4e:0x3ffd0ad0 0x40098c0e:0x3ffd0b00 0x400994e1:0x3ffd0b20 0x40087dd4:0x3ffd0b40 0x40134dd9:0x3ffd0bb0 0x4013369d:0x3ffd0bd0 0x40133aeb:0x3ffd0bf0 0x4013246d:0x3ffd0c60 0x40132f60:0x3ffd0cb0 0x4013195d:0x3ffd0d10 0x40131f81:0x3ffd0d50 0x400ee583:0x3ffd0d70 0x400e918a:0x3ffd0da0 0x400d2964:0x3ffd0e10 0x400fa0af:0x3ffd0e30 0x4008f109:0x3ffd0e50
Rebooting…

”’

Considering your explanation, I think I am doing the wrong thing bringing the ESTOP back to the grbl_ESP32, I should use it inside the legacy control box to remove power from steppers and VFD.

Separately, making a pendant with hold, resume, reset may be quite worthwhile.

Thanks Bart… Owen.

#5 – bdring 于 2019-11-24

It is OK, to latch the door, but not feed hold.

With that said, it should not reboot with a long press. I will look at the code to fix that.

I think your idea of making a true E-Stop is best for your situation. Also, I think you should consider homing/limit switches.

IMHO: It is not fair to Grbl to ask it run in random space :smiley:

#6 – bdring 于 2019-12-07

Closing. This is not a bug