RRF 3.4 emergency stop causes board to hang

steve123

Ran into a problem with configuring an emergency stop today. By config.g contains the following configuration g-code:

; CNC Emergency Stop
M950 J0 C"io8.in"                           ; Define io8.in as input pin 0 (P0) for use as an emergency stop input
;M581 P0 T0 S1 R0                     ; Trigger an emergency stop (T0) when input pin 0 (P0) edge occurs
;M582 T0

If you edit config.g, uncomment the last two lines and reload it, and if the emergency stop button is not connected I observed that the firmware continually loops and the GUI is unresponsive. I surmise the firmware detects the estop condition and then reloads config.g which causes another estop condition. I had to power cycle the board in order to be able get control back so I could edit the board and disable the estop function.

oliof

@steve123 you can try inverting io8.in by prepending a ! if you have a normally open button for the emergency stop.

steve123

@oliof Thanks for the feedback, yes, I think I will do that. Notwithstanding doing so, I think the looping is something that suggests a RRF bug?

fcwilt

@steve123 said in RRF 3.4 emergency stop causes board to hang:

@oliof Thanks for the feedback, yes, I think I will do that. Notwithstanding doing so, I think the looping is something that suggests a RRF bug?

Well if you define the input pin such that it is active on power up it and it does an emergency stop it is going to do it over and over - as it should.

To recover in such a case just hold the button down making the input inactive on power up. While holding the button down you can edit the input pin configuration as needed.

Good luck.

Frederick

steve123

@fcwilt said in RRF 3.4 emergency stop causes board to hang:

Well if you define the input pin such that it is active on power up it and it does an emergency stop it is going to do it over and over - as it should.

Is that really the case? Shouldn't an emergency stop event first stop the machine and then pause? It doesn't seem appropriate to me to reload config.g when performing an emergency stop unless the user somehow confirms to do so?

To recover in such a case just hold the button down making the input inactive on power up. While holding the button down you can edit the input pin configuration as needed.

That is a good work around for the issue. Nevertheless, I suggest the constant reloading might not be intended or desired.

fcwilt

@steve123 said in RRF 3.4 emergency stop causes board to hang:

Nevertheless, I suggest the constant reloading might not be intended or desired.

There seems to be some difference in behavior. According to the docs a T0 trigger does the equivalent of a M112.

From the docs:

M112: Emergency Stop
Any moves in progress are immediately terminated, then RepRap shuts down. All motors and heaters are turned off. It can be started again by pressing the reset button or power cycling the board.

Notice the reference to hitting reset or power cycling to get things going again.

Have you observed this to be true?

Frederick

infiniteloop

@steve123

I suggest the constant reloading might not be intended or desired.

Right, but you provoke this behaviour with three methods:

define a pin which is triggered on both edges (up and down)
test for that event immediately after defining it in config.g
couple this with a reset of RRF (which presumably leads to a signal change of the pin on reboot)

First thing to note: you should not check the trigger in config.g with M582.

Second, you need a well defined signal to trigger an event: What level do you expect io8.in to represent if your switch is "open", i.e. disconnected? High, low, or something in between?
To overcome this issue, it is good practice to activate the pull-up of the pin and then switch to GND. This has the additional effect that you now only have to check the trigger signal on the falling edge.

Third, I strongly recommend not to trigger such a fundamental event directly. If you invoke a macro (which in turn calls M112), you can take optional measures against repetitive stops (i.e. implement a global variable), in case you encounter a similar behaviour as now.

Put something like this or similar into config.g:

M950 J0 C“^io8.in“ ; define io8.in as input pin 0 (P0), activate pullup (normally high)
M581 P0 S0 T3 R0 ; call macro „trigger3.g“ if button pulls P0 to GND

Create the macro "trigger3.g" in the /sys directory:

; trigger3.g - Emergency Stop
M112 ; do it

Note of caution: Usage is at your own risk. Untested, my Duet is currently out of reach.