Emergency Stop! Please wait while firmware is restarting

[vacalos]

I am attempting to determine the cause of consistent print interruptions. The issue I am experiencing is that in the middle of a print the machine stops and displays "Emergency Stop! Please wait while firware is restarting". At that point the machine resets itself and the current print is abandoned.

Is there a way I can trouble shoot this issue?

Is this possibly a bug in the firmware? (I am using RepRapFirmware for Duet WiFi version 1.20 running on Duet WiFi 1.0)

I have ran and saved the results of a M122 command, however I don't know if this information is relevant. Below is a section of this text that may be.

Last reset 00:00:46 ago, cause: software
Last software reset at 2018-07-22 10:11, reason: User, spinning module GCodes, available RAM 3848 bytes (slot 0)
Software reset code 0x0003 HFSR 0x00000000, CFSR 0x00000000, ICSR 0x0441f000, BFAR 0xe000ed38, SP 0xffffffff

[T3P3Tony]

@vacalos thats odd, you don't happen to have M112 in your gcode file you are printing (odd if it would be in there)

Can you try upgrading to firmware 1.21

[vacalos]

Thanks for the reply.

I checked the gcode and there is no M112 present.
I also upgraded to firmware version 1.21 and that did not make a difference.

Is there a way to troubleshoot the cause using the information available to Duet Web Control?

[deckingman]

Do you have any external triggers set up. Are there any M581 commands anywhere? M581 T0 would trigger an emergency stop.

[vacalos]

No, I don't see M581 anywhere in the code.

Attached is the gcode file.0_1532297882953_EL.gcode

[Danal]

Just as a data point, I have two Delta printers on:

 
Firmware Name:	RepRapFirmware for Duet 2 WiFi/Ethernet
Firmware Electronics:	Duet WiFi 1.02 or later
Firmware Version:	2.0(RTOS) (2018-06-05b3)
WiFi Server Version:	1.21
Web Interface Version:	1.21.2-b2

Emergency Stop works correctly from the Web interface (had to use it earlier today), and I have not seen an print failures (of any kind) across about six or eight prints, longest being about 10 hours.

[vacalos]

Thank you for the reply.

Yes, I imagine that the problem is specific to me and is caused by some error in my part.

To clarify, the emergency stop works perfectly when I select it from Duet Web Control.
The problem is that the Emergency Stop is somehow being automatically activated (or initiated) in the middle of a print.

In the middle of a print the machine stops and displays "Emergency Stop! Please wait while firmware is restarting". At that point the machine resets itself and the current print is abandoned.

I was hoping that there was a way to isolate the cause using the information available in the Duet Web Control. Or at least determine if the problem is being caused by hardware, software or my gcode.

[Danal]

That would be pretty darn frustrating.

Just for debugging: Next long print, maybe disconnect all the web clients?

[dc42]

If the printer restarts automatically after the emergency stop and you are able to send commands without you needing to do reset the board explicitly, then the firmware has executed M112 followed by M999. That can normally only happen if the Emergency Stop button in DWC is clicked, or the Emergency Stop button in PanelDue is pressed. Both of those actions will send both commands.

If DWC reports "The firmware still reports to be halted after an emergency stop. Would you like to reset your board now?" when you try to send a command from DWC after the Emergency Stop has occurred, then the firmware has executed just M112, or you have a M580 trigger set up to do an emergency stop when the state of an endstop input changes.

HTH David

[vacalos]

Thanks for the reply and for the help.

You helped me to isolate the problem.

I believe the problem originated with the cabling I used for the PanelDue. I used 22 Gage, 4 conductor, stranded copper wire to connect the PanelDue to the Duet. With this wire the PanelDue was always a bit "buggie" and never really worked consistently. I don't know if it was the cable itself or a combination of the cable type and length.

I unplugged the PanelDue and retried the previous print and it worked perfectly.
So, I assume that the PanelDue was initiating an Emergency restart due to the cabling.

Thanks for the help.

Can anyone recommend a cable that can adequately carry the signal from the Duet to the PanelDue roughly 40 inches?

[timcurtis67]

I use a Cat5 patch cable. Gives you 4 extra wires for lights or an on/off switch.

Plus the shielding is a plus.

[Emily]

I would tend to think a noise or ground loop problem would cause the device to lock up rather than cause it to send unintended commands over serial. That is unless there is an analog input somewhere for E stop that is getting affected. Not sure what the max spec is but 40" doesn't seem particularly long.

[dc42]

The cable type isn't critical provided that the resistance per conductor is no higher than 0.1 ohms. Unshielded 4-core cable works well.

If you have a M575 P1 command in config.g, make sure it includes the S1 parameter so that the firmware ignores commands from the PanelDue port that have invalid checksums.

[vacalos]

DC42,

Thank you for the reply.

I have another question that is not related to this exact topic.

I have built a large Kossel based on the instructions you posted in your blog.
Can you tell me what retraction settings you use for PLA?
I am using Simplify3D and have been tweaking these settings but haven't achieved the results I am after.

Below are the settings I am currently using:
- Retraction Distance: 3.00mm
- Extra Restart Distance: 0.00
- Retraction Vertical Lift: 6.00
- Retraction Speed: 25.0
- Temp.: 205°C
- Speed: 50mm/s

[dc42]

I use 6mm retraction (was 7mm before I changed the Bowden tube to Capricorn), no extra restart distance, 0.3mm vertical lift, 60mm/sec retraction speed. Also pressure advance 0.2sec in M572.