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>

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

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!

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.

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….

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

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?

I started using Duet Ethernet with my Tevo Litte Monster a few days ago.

During printing the controller running that run FW 1.21 suddenly the printing is pauses and the following message is reported on G-Code Console:
<```
12:13:48 PM
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 cannot understand why this happens because I haven't set up any "printer resume after power failure feature" feature.

I noticed a power loss caused by the cables (about 0.5 - 0.8 V) so I replaced them with a couple of 1.5mm2 wires.
Now the readings of voltage at the input of duet boards are ok and my multimeter confirm this.

Anyway the issue still continues and the diagnostic command (M122) doesn't help me because after the event (no matter if pause, printing, or finished) instead of report the excepted diaggnositic it write only useless things:

// From g-code console
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

So I'm asking the following thing:
- Is there a undervoltage trigger built-in in the firmware?
- Reading on release notes I understood that there is a built-in overvoltage trigger. Am I right?
- How to make the M122 command to report the diagnostic during a print? Why it still doesn't work when the printing is finished? Am I doing something wrong?
- Please, can somebody help or give me some ideas for solving my issue?

PS: I thing that makes the M122 to work could help very much because in this way is possible to distinguish between under and overvoltage event: a good beginning in the troubleshooting process.

Thanks for your attention!