F/W 3.1.1 Cold Boot PT100 Heater Fault

tj

I just update three printers from firmware 2.05 to 3.1.1 and all three are having the same issue during a cold boot.

The boot looks normal on the PanelDue display and heater temps read normal for the first 25 second, then I get the message "Emergency Stop! reset the controller to continue." and when that message disappears the heater1 temperature display reads a normal temp but in yellow.
On the DWC side, it is trying to connect and giving me the message "Please stand by..." with a "RESET MACHINE" button as my only option.
The warm reset is always normal and the Temperature Chart in DWC show an off the scale, single line, spike reading on heater1 has occured after the cold boot, which is obviously what triggered the emergency stop.
This happens every time, on all three printers during a cold boot, but never happens any other time.
All three printers are using a PT100 probe with the Duet PT100 board for the heater1 hotend.
I can post the config.g files if needed but they were all created by the "reprap configurator" web site with only minor tweaks made to a few parameters.
Once I do a warm reset after the cold boot issue, the printers all work just fine on f/w 3.1.1

Thomas

Phaedrux

Yes please post your config.g and config-override.g if present.

Also post the results of M122.

tj

config.g config-override.g console.txt

Here are the files from one of the printers. I ran the M122 as soon as control returned to DWC after restart.

Thomas

Phaedrux

I find it very strange that all three machines are doing the same thing. I haven't seen anything similar reported before.

If you go back to firmware version 2.05.1 does the cool boot behaviour stop?

tj

To be precise I was never on 2.05.1, I started from 2.05 and I have not tried to revert. I wanted to post on the forum before I did much else to first see if this was a known or obvious problem. I guess no such luck there.

Remember that this only happens on a cold (power on) reset and it happens on every POR. I have (so far) never seen it happen on a reset where the power is already on. This makes it fairly benign to live with.

My own hunch is that it has something to do with the PT100 RTD adapter. All my Duet printers have this and most Duet installations probably do not. It appears to be some kind of false high read on heater1 that triggers this event.

If no one else has a better idea, my plan of attack will be to start commenting out lines in the config.g file to see if we can find a line that is related this problem.

Thomas

tj

OctoPi_console.txt

For those who can understand the output result of an M122 command (not me) this one might be more helpful than the one I posted earlier.

The previous console.txt came from DWC after DWC required me to "RESET MACHINE". I was able to use OctoPi to issue an M122 without needing to do a reset first.

Hopefully this will let you see more about what happened between "power up" and the "machine reset".

Thomas

dc42

I found this in your log:

Changing monitoring state from "Opening serial port" to "Connecting"
Send: N0 M110 N0*125
Recv: Error: Bad command: WiFi module is cN0 M110 N0*125
Changing monitoring state from "Connecting" to "Error: Bad command: WiFi module is cN0 M110 N0*125"
Send: M112
Send: N1 M112*32

Octoprint says it is sending "N0 M110 N0*125" but RRF is behaving as though it has received "WiFi module is cN0 M110 N0*125". It's as though the message "WiFi module is connected to access point..." has been sent by RRF but either RRF or Octoprint or the USB CDC port driver on the PC has echoed part of it back to the input. Octoprint then sends the M112 emergency stop command.

It might be worth asking Gina (the author of Octoprint) whether Octoprint can handle receiving messages as soon as it opens the port. There may be several lines of text buffered from running commands in config.g. Octoprint should drain these from the buffer before it starts sending commands to the Duet.

tj

Octoprint says it is sending "N0 M110 N0*125" but RRF is behaving as though it has received "WiFi module is cN0 M110 N0*125". It's as though the message "WiFi module is connected to access point..." has been sent by RRF but either RRF or Octoprint or the USB CDC port driver on the PC has echoed part of it back to the input. Octoprint then sends the M112 emergency stop command.

I looks like this was the problem. All three of my printers have an OctoPi board which powers on at the same time as the Duet WiFi board. I use a DC to DC converter to take Duet VIN and make the power for the Pi board.

I just tested two of the printers by changing the Pi power source to a separate switch and now with the Pi boards left unpowered the Duet boards will cold boot like they should. I don't know yet how long the delay needs to be before the Pi power can be applied.

None of this was changed when I migrated to v3x firmware, it all worked fine on v2.05.

Also, now if I power up the Pi with the Duet power source off, the Duet will turn on through the USB power (from the Pi) and I do see the cold boot fault again.

So that't it! Now it is just a question of whether Octoprint or RR3 need to change anything and I will leave that question to others.

Thanks all,
Thomas

Phaedrux

@tj said in F/W 3.1.1 Cold Boot PT100 Heater Fault:

All three of my printers have an OctoPi board

Might have been helpful if you'd mentioned that at the start.

@tj said in F/W 3.1.1 Cold Boot PT100 Heater Fault:

Now it is just a question of whether Octoprint or RR3 need to change anything and I will leave that question to others.

Have you created a ticket at the octoprint github?

tj

Have you created a ticket at the octoprint github?

No, and I don’t think that would be appropriate. I have been using this Duet/OctoPi configuration since my first Duet Wifi installation (v1.17) and it has never had the slightest problem until now. This does not point me to the conclusion that there is something wrong with OctoPrint that needs to be corrected. It does not point me to any conclusion. My working knowledge of RRF and OctoPrint is good enough to get by, but no better. That is why I said I would leave it to others.

Thomas

Phaedrux

Fair enough.