Duet2 WiFi shuts down spontaneously during printing job

Triet

@dc42 said in Duet2 WiFi shuts down spontaneously during printing job:

Are you able to change your endstop wiring to use normally-closed contacts? When closed the connections are much less sensitive to interference.

If the Duet2 WiFi is able to do that, then I am too

Now I can understand a number of sudden layer shifting (seldom bur large shifts, always X axis). They were definitely not caused by sliding resistance, low tensioned belts, too low stepper current or violent movements - I made sure that would not happen. As the tool moves, I have observed that the switch arm dangles (but that may be unrelated).

I am considering disabling the endstops after homing and during the print, as long as I don't get the properly shielded two wire cables, but cannot find the correct g-command until now.

Triet

@Triet
Now I am responding to myself

I found that the LED is illuminated when the endstop switch is connected and triggered (otherwise unlit). If I understand the documentation correctly, this means that my endstop switches are "normally open" (NO).

I also found that they were connected to the Duet2 via 2 wires only. The 3.3V wire (in the middle of the terminal) was not connected. It was working nevertheless, at least most of the time. This might have made the cable more vulnerable to electromagnetic noise.

Do I correctly assume that I will have to replace my endstops in order to have the endstop switsches of the type NC?

For the time being I have twisted all three wires, but I cannot figure out the command the disable triggering of the endstops (similar to Marlin's M121), just to be save against layer shifts during printing due to erratic triggering until I get the NC type of endstops.

Triet

@Triet
OK, I rewired the connection to the endstops and changed the configuration from
M574 X1 S1 P"!xstop"
M574 Y2 S1 P"!ystop"
to
M574 X1 S1 P"xstop"
M574 Y2 S1 P"ystop"
so the microswitches are now "normally closed" and therefore less vulnerable to noise. The LEDs confirm that. Homing works fine.
Case close, unless you disagree.

Triet

@Triet Sorry to be back again

I had a shutdown again, no apparent cause.
Now, trying to diagnose I issued the M122 command, but I get no output...

What might be wrong?

The printer is back after switching it on and shows no other signs of irregularities.
But before I restart this job (it takes several days) I would like at least to know what is happening with my Duet2 WiFi that is not showing any diagnose information.

Thanks guys

Triet

@Triet After forcing the console to output just "Test using M291 P"Test", the M122 also started to work as expected. Strange!

Anyway, diagnosing the cause of my last spontaneous shutdown (after longer than a day), I found:

=== Platform ===
Last reset 01:08:02 ago, cause: power up
Last software reset at 2024-04-09 20:28, reason: StuckInSpinLoop, GCodes spinning, available RAM 9212, slot 2
Software reset code 0x4083 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0041f80f BFAR 0xe000ed38 SP 0x2000231c Task MAIN Freestk 763 ok
Stack: 0042c6eb 0045747c 61000000 3f800000 3e88b400 a0000000 bfe6a7ef 3331bb4c 00000000 20000c98 00000001 00000001 00000028 20004c64 40090000 0042c96d 00000000 00000001 00002283 0042d0fb 0042dd34 ea9b4b6c b5dde12a 0077ffff bb360b61 00000000 00000000
Error status: 0x04
Aux0 errors 0,0,0

I have no idea what that means exactly but it looks like a software crash.

I might be overthinking it but both times when I had this shutdown it happened after longer than a day of printing, while the job was about 30%.

Is there a timeout built-in somewhere limiting how long jobs can run?

Currently, I am unable to print a specific model I need, because it takes that long. This is the first time I ever printed anything taking over a day (this job: longer that two days).

Phaedrux

It may be worth trying the 3.5 RC4 that just released for testing. You may want to try a dry run without filament first to see if it can complete.

Have you been able to simulate the job successfully?

dc42

@Triet did you have the Duet USB port connected to anything? It's possible to get "stuck in spin loop" if the firmware is trying to generate debug output and the USB port is connected to a PC but no program on the PC is reading it.

Triet

@dc42 said in Duet2 WiFi shuts down spontaneously during printing job:

did you have the Duet USB port connected to anything?

I am now aware of M111 for diagnosing purposes but have not used it. I am afraid that I could be loosing my time since I am not acquainted with the interpretation of the output.

So no, nothing connected to USB.

Triet

@Phaedrux said in Duet2 WiFi shuts down spontaneously during printing job:

t may be worth trying the 3.5 RC4 that just released for testing.

That is a good idea. If it happens again I will try it.

My "simulation" consists of printing the model in parts and glue them when I am finished. I just measure the height up to the shutdown, then move the model down by the same amount in the slicer plate, and restart the job. This is not optimal and I hope I can glue the parts in an acceptable way.

Just at this very moment I am configuring the "resurrection" function: Letting the job continue just at the point where the shutdown occurred - assuming this shutdown was interpreted as a power failure and not as an intended interruption. That means, that during the print the current status is continuously saved to the SD card - something I dislike. This is all trial and error.

Triet

@Triet said in Duet2 WiFi shuts down spontaneously during printing job:

Just at this very moment I am configuring the "resurrection" function:

This is worth trying:
911 S23 R24 P"M913 X0 Y0 G91 M83 G1 Z3 E-5 F1000"

Actually, the current status does not need to be constantly saved to SD card. Using an oversized Meanwell power supply with 600 W I hope this would work well, assuming that writing to SD is fast enough.

Triet

@Triet said in Duet2 WiFi shuts down spontaneously during printing job:

This is worth trying:
911 S23 R24 P"M913 X0 Y0 G91 M83 G1 Z3 E-5 F1000"

Just to let you know: The resurrection function could not be implemented satisfactorily.

With following setting in the config.g:
911 S22 R24 P"M913 X0 Y0 G91 M83 G1 Z3 E-8 F1000"

and with a resurrect-prologue.g file like this:
M116 ; wait for temperatures
G28 X Y ; home X and Y, hope that Z hasn't moved
M83 ; relative extrusion
G91
G1 Z-3 E8 F3600 ; undo the retraction that was done in the M911 power fail script

the printer does everything as commanded, but it resumes printing at a slightly higher Z position, so it ends up printing in midair. It does not work, probably because after power loss the bed slides a bit downwards. Without a max endstop switch to re-home the Z axis this function is unusable.

Phaedrux

@Triet said in Duet2 WiFi shuts down spontaneously during printing job:

Without a max endstop switch to re-home the Z axis this function is unusable.

Or set the Z position manually.

Triet

@Phaedrux said in Duet2 WiFi shuts down spontaneously during printing job:

Or set the Z position manually.

Yes, but: which are the coordinates saved at time of power outage?