Shutdowns

[gloomyandy]

@SonnyD1 said in Shutdowns:

Last software reset at 2025-03-08 21:47, reason: AssertionFailed, Platform spinning, available RAM 22784, slot 2

One for @DC42 I think.

What was the printer doing when it shutdown? If you can get a repeatable test case that will probably help.

[SonnyD1]

@gloomyandy It was printing. Just an ordinary print. I'm beginning to see a pattern though. It only shuts down when its printing at the same time as the Railcore that's sitting right next to it is. Could be a coincidence but I don't think so.

[Notepad]

@SonnyD1 This is going to sound real odd. But what powersupply are you using.
I know the M122 says the reason is a software shutdown. But I have experienced in the past a weird brownout situation where one printer with a cheap PSU was browning the entire power ring for my house, and it would randomly do weird power spikes which caused machines to fail

[dc42]

@SonnyD1 please post further M122 reports if it happens again. The one you posted indicates what appears to me to be a very strange failure within FreeRTOS. If further shutdowns show the same cause then this would suggest a firmware issue; however if the causes look random then that would indicated an issue with ESD or mains transients - which would tie in with the issue only occurring when another piece of equipment is running.

Also please check that the VIN terminal block screws of the Duet and DueX are still tight.

[SonnyD1]

@Notepad Meanwell LRS-350-24. I don't buy cheap parts. I considered the possibility of a bad or faulty power supply because lets face it, it does happen. However, with this power supply it would be the least likely culprit I think. That said, I'm not opposed to replacing it since they are pretty affordable. I'd like to pursue other possibilities first.

[Notepad]

@SonnyD1 The power supply is good as it has integrated filtering. If you did want a cheap solution without changing the PSU, have a look at filter EMI power receptacles.

[SonnyD1]

@dc42 That was the first check I made. Everything is snug with a good connection. I'm in the middle of a long print and the neighboring Railcore isn't running. No shutdowns yet. If is does point to only happening when a neighboring machine is running, how would I resolve that?

[SonnyD1]

@dc42 So that long print I was talking about shut down again in the middle of the night with nothing else running. Here is the M122: Thoughts?

M122
=== Diagnostics ===
RepRapFirmware for Duet 2 WiFi/Ethernet version 3.6.0-rc.1 (2025-02-28 14:56:47) running on Duet WiFi 1.02 or later + DueX5v0.11
Board ID: 0JD0M-9P6B2-NJ4S4-6JKFJ-3SJ6Q-T82AK
Used output buffers: 10 of 26 (24 max)
=== RTOS ===
Static ram: 24016
Dynamic ram: 68252 of which 0 recycled
Never used RAM 30532, free system stack 156 words
Tasks: NETWORK(1,ready,9.7%,222) HEAT(3,nWait 5,0.1%,328) Move(4,nWait 5,0.0%,288) DUEX(5,nWait 5,0.0%,23) MAIN(1,running,90.2%,734) IDLE(0,ready,0.0%,29), total 100.0%
Owned mutexes:
=== Platform ===
Last reset 02:18:04 ago, cause: software
Last software reset at 2025-03-11 06:24, reason: HardFault bfarValid precise, Gcodes spinning, available RAM 24264, slot 0
Software reset code 0x4063 HFSR 0x40000000 CFSR 0x00008200 ICSR 0x0041f803 BFAR 0xc9900000 SP 0x200022f8 Task MAIN Freestk 922 ok
Stack: 80fe8000 43300000 00000000 407f4000 86600000 004601f3 0046262c 810e1a00 004084f3 00000000 00000064 004601f3 200023d3 00000001 00000001 00000000 00000066 0045c543 0000000a 00000000 41ec9c4c 20002418 00000000 40490000 0000000e 00000073 20002410
=== Storage ===
Free file entries: 10
SD card 0 detected, interface speed: 20.0MBytes/sec
SD card longest read time 3.3ms, write time 0.0ms, max retries 0
=== Move ===
Segments created 2, maxWait 264ms, bed comp in use: none, height map offset 0.000, hiccups added 0/0 (0.00ms), max steps late 0, ebfmin 0.00, ebfmax 0.00
Pos req/act/dcf: 0.00/0/0.00 0.00/0/0.00 0.00/0/0.00 0.00/0/0.00
No step interrupt scheduled
Driver 0: standstill, SG min n/a
Driver 1: standstill, SG min n/a
Driver 2: standstill, SG min n/a
Driver 3: standstill, SG min 0
Driver 4: standstill, SG min n/a
Driver 5: standstill, SG min n/a
Driver 6: standstill, SG min n/a
Driver 7: standstill, SG min n/a
Driver 8: standstill, SG min n/a
Driver 9: standstill, SG min n/a
Driver 10: 
Driver 11: 
=== DDARing 0 ===
Scheduled moves 1, completed 1, LaErrors 0, Underruns [0, 0, 0]
Segments left 0
Code queue is empty
=== Heat ===
Bed heaters 0 -1 -1 -1, chamber heaters -1 -1 -1 -1, ordering errs 0
Heater 1 is on, I-accum = 0.0
=== GCodes ===
Movement locks held by null
HTTP is idle in state(s) 0
Telnet is idle in state(s) 0
File is idle in state(s) 0
USB is idle in state(s) 0
Aux is idle in state(s) 0
Trigger is idle in state(s) 0
Queue is idle in state(s) 0
LCD is idle in state(s) 0
Daemon is idle in state(s) 0
Autopause is idle in state(s) 0
=== Filament sensors ===
Driver 11: ok
=== DueX ===
Read count 1, 0.01 reads/min
=== Network ===
Slowest loop: 10.20ms; fastest: 0.00ms
Responder states: HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0)
HTTP sessions: 1 of 8
=== WiFi ===
Interface state: active
Module is connected to access point 
Failed messages: pending 0, notrdy 0, noresp 0
Firmware version 2.2.1
Module reset reason: Power up, Vcc 3.38, flash size 2097152, free heap 39372
MAC address f4:cf:a2:68:3b:2f
IP address 192.168.1.243
Signal strength -53dBm, channel 2, mode 802.11n, reconnections 0
Clock register 00002002
Socket states: 0 0 0 0 0 0 0 0

[dc42]

@SonnyD1 once again this is a very strange failure, this time inside the floating point maths library. So I still think it was caused by either a power brownout or by an ESD event. Are the metalwork of your hot end and the body of the extruder motor connected to Duet ground?

[SonnyD1]

@dc42 No. Frankly I suspected that may be the issue.