Duet 3D goes in pause state without any apparent reason

tceccarini

Thanks for your reply.
Is what I was doing without success (actually I used to press enter instead of clicking on the send button).

Nevertheless I've tried again and this time the M122 worked.

This is what it have reported:

6:02:09 PM
M122
Resume-after-power-fail state saved
Printing paused

Printing resumed
=== Diagnostics ===
Used output buffers: 6 of 32 (16 max)
=== Platform ===
RepRapFirmware for Duet 2 WiFi/Ethernet version 1.21 running on Duet Ethernet 1.02 or later
Board ID: 08DDM-9FAM2-LW4S8-6J9FJ-3S86S-TJY7W
Static ram used: 16152
Dynamic ram used: 100336
Recycled dynamic ram: 2296
Stack ram used: 1224 current, 7792 maximum
Never used ram: 4496
Last reset 08:11:41 ago, cause: power up
Last software reset at 2018-03-31 23:19, reason: User, spinning module GCodes, available RAM 7760 bytes (slot 0)
Software reset code 0x0003 HFSR 0x00000000, CFSR 0x00000000, ICSR 0x0441f000, BFAR 0xe000ed38, SP 0xffffffff
Error status: 8
Free file entries: 9
SD card 0 detected, interface speed: 20.0MBytes/sec
SD card longest block write time: 12.8ms
MCU temperature: min 33.9, current 35.5, max 36.1
Supply voltage: min 23.9, current 24.1, max 24.2, under voltage events: 0, over voltage events: 0
Driver 0: ok, SG min/max 0/1023
Driver 1: ok, SG min/max 0/339
Driver 2: ok, SG min/max 0/348
Driver 3: ok, SG min/max 0/1023
Driver 4: standstill, SG min/max not available
Date/time: 2018-04-01 18:01:28
Slowest main loop (seconds): 0.041106; fastest: 0.000050
=== Move ===
MaxReps: 5, StepErrors: 0, LaErrors: 0, FreeDm: 120, MinFreeDm 120, MaxWait: 2ms, Underruns: 0, 0
Scheduled moves: 638529, completed moves: 638500
Bed compensation in use: mesh
Bed probe heights: -6.933 -6.174 -4.739 -4.343 -5.052
=== Heat ===
Bed heaters = 0 -1 -1 -1, chamberHeaters = -1 -1
Heater 0 is on, I-accum = 0.0
Heater 1 is on, I-accum = 0.4
=== GCodes ===
Segments left: 1
Stack records: 2 allocated, 0 in use
Movement lock held by null
http is idle in state(s) 0
telnet is idle in state(s) 0
file is doing "G1 X35.022 Y27.291 E0.02095" in state(s) 0
serial is idle in state(s) 0
aux is idle in state(s) 0
daemon is idle in state(s) 0
queue is idle in state(s) 0
autopause is idle in state(s) 0
Code queue is empty.
=== Network ===
Responder states: HTTP(1) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0) Telnet(0)
HTTP sessions: 3 of 8
=== Network ===
State: 5
HTTP sessions: 3 of 8
=== Expansion ===

According to diagnostic info there wasn't any power issue event so I cannot understand the reason why the printer has paused just a couple of minutes ago.

I noticed that on diagnostic is wrote "Error status = 8". Can it be useful? What is its mean?

5:59:05 PM
Resume-after-power-fail state saved
Printing paused

Printing resumed
5:53:53 PM
Resume-after-power-fail state saved
Printing paused

5:53:51 PM
Resume-after-power-fail state saved

2:55:32 PM
M122
69 points probed, mean error 0.072, deviation 0.072
Height map saved to file heightmap.csv
File MYLM_motor-holder.gcode selected for printing

Resume-after-power-fail state saved

I'm using Cura 1.2.3 under CentOS 7 for slicing. Could the slicer causes a unexpectable behavior of duet?
Other ideas?

Phaedrux

Do you have an M911 command in your config.g?

tceccarini

No, Neither in the config files (which includes config.g) neither in the gcode file to printing.

tceccarini

It's out this conversation but is it compulsory to connect the "Earth Bonding for shielded cable" somewhere? I have a plastic box so I decided to leave it unconnected….

dc42

Yes! Connect one end of the shield to ground. If your Duet is mounted in a grounded metal enclosure to reduce EMI then connect it to that enclosure. Otherwise, connect it to Duet ground.

dc42

Error status 8 does mean something, but I'm out of the office and replying on a tablet, so I can't look it up right now. Feel free to remind me tomorrow.

Causes of a print pausing include:

M25 received from any input channel
M226 seen in the GCode file
Filament sensor reported a problem
Heater fault
VIN voltage dropped below the threshold set by M911

The last 3 should all cause a popup in DWC or a message in the GCode Console page.

tceccarini

Hello,
Thanks for your replies.

I checked and my gcode is free of M25 and M226 commands, moreover DWC never popped out a message error different from the one I've already reported.

Unfortunately I cannot wire the shield to ground until tomorrow: In my toolbox I don't have a so small faston so I have to wait tomorrow for the shop to be open. Hope is will not be the causes of the issue.

@dc42 This is also as reminder for you for error status 8 meaning.

dc42

Error code 8 means "output stack overflow". Are you using DWC on more than one device to access the Duet, e.g. PC and smartphone?

Output stack overflow shouldn't cause pausing, but it is likely to result in some messages being lost.

tceccarini

Thanks for your reply.
Yes, I usually leave a window always open on the PC and then check the status from PC or Smartphone: i.e. nearest one.

Today I decided to disable the web server and use only ftp and USB console; I also connected the Ethernet's shield to the ground ( I finally managed the missing of the faston but I'm a little bit ashamed of the style)

Now I'm going to send another print.. I'll report you what will happen.

Have a great day!

dc42

The output stack overflow is probably caused by the PC or smartphone going to sleep with the connection still open. There is a known bug when this happens and you have more than one device using the web interface, which is close to the top of my priority list for fixing. Meanwhile, pressing the Disconnect button before the device goes to sleep avoids the issue.

tceccarini

ok.

Alter a few experiments, I think that the problem could be caused by bad configuration of filament run out trigger for E0.

I reviewed my configuration but by now I cannot see anything wrong… even if there there should be.

Here my configuration files:

https://drive.google.com/drive/u/0/folders/1fVkJjVDBfn9F5m76dgao4u8epiJoJ4-G

tceccarini

I hope I found the problem that generated the malfunction: the filament run-out switch which wasn't positioned correctly; this causes a fast random switching and a false signaling on E0 connector.

Every time this was happen my duet wrote on USB console [c]Resume-after-power-fail state saved <cr><lr>Printing paused[/c]
In my opinion not a very appropriate description since it drove me in the wrong hypothesis of a power failure.

Obviously in the trigger there was a[c]M117 No Filament!!![/c] but I wasn't able to see it because this command write only on web interface (that was malfunctioning due to a firmware bug) and at display that I don't have.

My solution:
I moved the switch closer to the filament in order to avoid fast switching (so the false signaling on E0). Than I added to the trigger code the following line in order to receive the message also on USB console. [c]M118 S"Hello Duet"[/c]

My 2cent:
@dc42 I strongly suggest to replace the [c]Resume-after-power-fail state saved <cr><lr>Printing paused[/c] message with something that can't be associated so easily to a real power issue.

PS: I'm using this Filament Detector: https://www.thingiverse.com/thing:2629228</lr></cr></lr></cr>