RPi v0.92.2 not properly recovering/reconnecting after hard firmware halt/reset

Mongoose

Hello!

Recently updated 2 out of 5 of my hub Pi's to 0.92.2, but had one throw a thermal runaway due to a fan issue (All machines are running Marlin 1.1.9). In previous versions, the firmware would automatically recover and reset the machine, but I noticed that the machine was halted.

I hard-reset the controller, and when it came back on, the hub did not automatically try to reconnect. It was still "green/active" in the interface, but the bed temperature was zeroed out and no data was being passed. I had to deactivate/reactivate printer for it to successfully reconnect.

Is this a new bug, intentional behavior change, or something wonky with my own setups? Normally i'd say it was this one hub, but I forced one into a firmware-halting error on a different installation/board, and it did the same thing.

Repetier

Connection stays green as long as linux offers the serial connection. I guess when this happened and you go to console you start seeing timeout messages also they stop after some amount from being reported.

The problem is if the serial driver is hanging somehow a reset on printer side is not enough. It does not reset the serial driver chip on printer. Unplugging usb and depowering printer would do that and then it should automatically recover.

This is something happening outside of servers control. At least if the above procedure helps. Would also mean that the printer serial converter did go to error state. Did you update by using the buster image so that you have a new kernel?

Repetier

What you also can do is trying emergency stop. That will close and reopen the connection. Will only help if linux is still communicating correctly or if that causes the hang to get removed as for a short time no one is then connected to the serial. Do not know how linux driver do that internally. Just an idea.

Mongoose

When I E-stop it, it will recover but seems to have an issue. Bed temp reports 0 degrees, and the printer won't accept any new commands until I deactivate/reactivate.

I updated from the menu-- so have not redeployed the image in some time (hard to take the machines offline for that). I'll test using another card then update you with results.

Repetier

Image update should not matter here if you are on same image as before and only server is updated.

I think I might have changed error handling. In marlin.xml firmware description you have

<response type="halted">^Error:Printer halted</response>
<response type="halted">^!!</response>

which puts it in halted state. In earlier versions it would deactivate printer so you would have needed to activate. This could lead to disturbing loops without user being able to see the messages in console or with automatic activation even an automatic error loop. It also confused users that the printer was suddenly not active. You should also have gotten a message about the halt i the messages list in gui.

Will see why emergency stop does not help here. Always thought it also restarts connection.

Mongoose

I see- so it's not a bug but an intended behavior.

Is there a way to restore the old behavior?

Repetier

No, it is internally wired. You could of course modify the marlin.xml file and remove the halted detection rules. Then it will not go in that mode and emergency stop might work (if it causes a reset of the printer). Otherwise deactivate/activate should give you back the control - which is what I now have added to server for next release so it goes down to 1 click. But it important that you can analyse why your firmware stopped to solve the problem. And that means you need to read the log in console which only works that way.