Firmware 3.50.rc.4 stops working

Chriss

Hi @dc42
I use your latest firmware and it stops working from time to time:
Duet 3 Mini 5+ Mini5plus 3.5.0-rc.3+

All axes are unhomed:

And the print has not yet finished..... That happened the 3rd time now....

Cheers, Chriss

Chriss

chrishamm

@Chriss Please upgrade to 3.5.0-rc.4 and check if the problem persists. If it does, please share the output of M122.

Chriss

@chrishamm
I will give it a try and I hope that rc4 contains the fixes from rc3+. And I'm more than sorry that my English is broken today...
The problem is that it happened only once in three weeks, so it is hard to tell that it is fixed or not.

Chriss

@chrishamm

That releases seams to be a bit over sensitive. I got a complaint that the SD Card is almost full
Does this message really needs to get triggered so early?

And the printer behaves very strange now. The upload of g-Code is not possible anymore. The DWC is totally unusable now because it loos the the connection every 2-3 seconds and reloads.

I think that everything will be better after a massage on the SD card but you may want to rethink about the warning message and the strange behaviour than.

Chriss

Strage.... the filesysterm died on the card. It seams the printer boots with a new filesystem on the card. Strange...... Both at the same time? I

chrishamm

@Chriss Provided you're running in standalone mode, it may be a good idea to format your SD card again and delete the second partition. The second partition may still hold a file system for SBCs.

Chriss

@chrishamm Yes, that is what I did basically... But I do not have a lot of trust in that card anymore. I uploaded the new firmware and the filesystem gets corrupted at the same time? I should play lotto today....

chrishamm

@Chriss Yes, perhaps it's a good idea to replace it.

Chriss

@chrishamm That would explain many of the strange effects I see recently.

Btw: Did you guys reduced the max connections in the rc4? I have the feeling that it does not like the connection from 2 or three open browser taps.

Cheers, Chriss

Chriss

Hi @gloomyandy @chrishamm @dc42,

I just got the stuck of the printer again. I started a print the printer printed for about 20 minutes and there was a "tack" in the room like a stepper skip. I looked to the printer and everything was "off" only the hotend fan started to spin again.

Excuse me guys but this must be a problem with 3.5rc4. The SD card is new now, the g-code is brand new. My config has not changed a lot since rc3 and the printer just stops and reports no error?

My computer was not connected to the printer via telnet or USB at that point, so I do not have a log from the console.

Here is the output from M122, but I do not think that this really helps, you see a reset of the firmware only.

=== Diagnostics ===
RepRapFirmware for Duet 3 Mini 5+ version 3.5.0-rc.4 (2024-04-09 09:45:40) running on Duet 3 Mini5plus WiFi (standalone mode)
Board ID: V9NWJ-R296U-D65J0-40KM6-4113Z-HM83B
Used output buffers: 2 of 40 (40 max)
=== RTOS ===
Static ram: 103232
Dynamic ram: 124056 of which 12 recycled
Never used RAM 11260, free system stack 194 words
Tasks: NETWORK(1,ready,16.9%,212) HEAT(3,nWait 6,0.0%,326) Move(4,nWait 6,0.0%,355) CanReceiv(6,nWait 1,0.0%,797) CanSender(5,nWait 7,0.0%,336) CanClock(7,delaying,0.0%,348) TMC(4,nWait 6,1.4%,102) MAIN(1,running,80.7%,665) IDLE(0,ready,0.1%,30) AIN(4,delaying,0.9%,260), total 100.0%
Owned mutexes:
=== Platform ===
Last reset 00:10:46 ago, cause: software
Last software reset at 2024-04-13 04:50, reason: HardFault imprec, Gcodes spinning, available RAM 9756, slot 2
Software reset code 0x4063 HFSR 0x40000000 CFSR 0x00000400 ICSR 0x00446803 BFAR 0xe000ed38 SP 0x20012008 Task NETW Freestk 489 ok
Stack: 2002c5e0 20032048 200014e8 00000000 200331ed 00030019 0002ff30 61016000 20035d48 2002c5c8 200187fc 2002c41e 200187fc 2001e9f8 0003019f 00000000 00000000 00000000 200120a0 00000014 b5ddcef1 00000002 9de60050 0801a8c0 08000161 00000001 00034861
Error status: 0x04
Aux0 errors 0,0,0
MCU revision 3, ADC conversions started 646915, completed 646915, timed out 0, errs 0
MCU temperature: min 34.0, current 34.0, max 49.1
Supply voltage: min 24.3, current 24.4, max 24.4, under voltage events: 0, over voltage events: 0, power good: yes
Heap OK, handles allocated/used 99/22, heap memory allocated/used/recyclable 2048/1196/884, gc cycles 2
Events: 0 queued, 0 completed
Driver 0: standstill, SG min 0, read errors 0, write errors 1, ifcnt 214, reads 58777, writes 13, timeouts 0, DMA errors 0, CC errors 0
Driver 1: standstill, SG min 2, read errors 0, write errors 1, ifcnt 249, reads 58777, writes 13, timeouts 0, DMA errors 0, CC errors 0
Driver 2: standstill, SG min 62, read errors 0, write errors 1, ifcnt 251, reads 58777, writes 13, timeouts 0, DMA errors 0, CC errors 0
Driver 3: standstill, SG min 0, read errors 0, write errors 1, ifcnt 131, reads 58780, writes 10, timeouts 0, DMA errors 0, CC errors 0
Driver 4: standstill, SG min 2, read errors 0, write errors 1, ifcnt 214, reads 58777, writes 13, timeouts 0, DMA errors 0, CC errors 0
Driver 5: standstill, SG min 0, read errors 0, write errors 1, ifcnt 214, reads 58777, writes 13, timeouts 0, DMA errors 0, CC errors 0
Driver 6: standstill, SG min 0, read errors 0, write errors 1, ifcnt 214, reads 58777, writes 13, timeouts 0, DMA errors 0, CC errors 0
Date/time: 2024-04-13 05:00:49
Cache data hit count 1157031704
Slowest loop: 18.90ms; fastest: 0.17ms
=== Storage ===
Free file entries: 20
SD card 0 detected, interface speed: 22.5MBytes/sec
SD card longest read time 4.5ms, write time 1.3ms, max retries 0
=== Move ===
DMs created 83, segments created 0, maxWait 0ms, bed compensation in use: none, height map offset 0.000, max steps late 0, min interval 0, bad calcs 0, ebfmin 0.00, ebfmax 0.00
no step interrupt scheduled
Moves shaped first try 0, on retry 0, too short 0, wrong shape 0, maybepossible 0
=== DDARing 0 ===
Scheduled moves 0, completed 0, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1
=== DDARing 1 ===
Scheduled moves 0, completed 0, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1
=== Heat ===
Bed heaters 0 -1 -1 -1, chamber heaters -1 -1 -1 -1, ordering errs 0
=== GCodes ===
Movement locks held by null, 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
SBC is idle in state(s) 0
Daemon is idle in state(s) 0
Aux2 is idle in state(s) 0
Autopause is idle in state(s) 0
File2 is idle in state(s) 0
Queue2 is idle in state(s) 0
Q0 segments left 0, axes/extruders owned 0x0000803
Code queue 0 is empty
Q1 segments left 0, axes/extruders owned 0x0000000
Code queue 1 is empty
=== CAN ===
Messages queued 5840, received 12972, lost 0, errs 1, boc 0
Longest wait 2ms for reply type 6053, peak Tx sync delay 196, free buffers 26 (min 25), ts 3235/3234/0
Tx timeouts 0,0,0,0,0,0
=== Network ===
Slowest loop: 10.54ms; fastest: 0.00ms
Responder states: MQTT(0) HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(2)
HTTP sessions: 5 of 8
=== WiFi ===
Interface state: active
Module is connected to access point 
Failed messages: pending 0, notrdy 0, noresp 0
Firmware version 2.1beta7
MAC address f0:08:d1:02:e6:75
Module reset reason: Power up, Vcc 3.38, flash size 2097152, free heap 37440
WiFi IP address 192.168.1.69
Signal strength -66dBm, channel 6, mode 802.11n, reconnections 0
Clock register 00002001
Socket states: 0 0 3 0 0 0 0 0

Anyway, I leave the printer now how it is, just if you guys want me to do anything on it which may help you to debug it.

I have a spare Mini 5+ here at my desk, I can exchange it, if you think that this will help, just to strike out a possible hardware issue. My main problem is that I can not really reproduce it, other than the Wifi problem where I was able to tell that it happens latest after 2 days.

I'm more than willing to share my entire config (which is a bit complex I have to admit) with you guys and I can send you the board if that helps.... And as I wrote, I have a other mini 5+ but I do not have a other tool board in the same hardware revision, so I can not change the entire Duet platform on the printer with the same hardware to strike out a hardware problem.

Cheers, Chriss

Chriss

Btw: you can reach me via discord too, if you want to have a call. I'm on the Duet Discord, same avatar, known there as Chris or my Dicord username: warty_towel (Yes I love the hotel in Torquay)

gloomyandy

@Chriss Is this a repeatable problem? That is if you run the same print again does the same thing happen?

Chriss

@gloomyandy I did not executed the same g-code if you as for that.
It happened to me the 4th time now with 4 different objects. I can try to re-execute the g-code if this is what you want. Or I can re slice and print it. But again: It is not very easy to reproduce.... I had more than 10 successful prints between the failures. And all of failed prints happened with other objects.

Cheers, Chriss

gloomyandy

@Chriss If you search for similar problems on the forum you will see that this may be caused by static buildup on the printhead. Is your printhead grounded? See: https://forum.duet3d.com/post/325903

Chriss

@gloomyandy Let me do that.. but let me make one remark here: I have this problem since 3.5rc4, rc3 and earlier versions did not have that problem. And I have not chanced my printer hardware since a while...

But it would take me at least 10 days to "verify" that the problem has gone than.... I'm sorry, but I have some scars from my wifi problem, this scars teached me not to reboot my board to early.

(Btw, by other 4 printers with a Mini5+ work without constantly but on a lower firmeware level, and none of them have a "grounded nozzle)

gloomyandy

@Chriss I was not asking you to reboot your board I was simply asking if your toolhead was grounded and pointing out to you previous responses to similar problems.

Chriss

@gloomyandy Sorry, yes you are right. But I have disassemble the Voron Stealthburner for that... So I have to turn of the printer. I have to pull the power and can connection of the toolboard to disassemble SB to reach the Revo to make that connection.

Cheers, Chriss

gloomyandy

@Chriss As above I was simply asking you if you had already grounded the toolhead as that would have eliminated that as a potential cause. I have asked @dc42 to take a look at this problem so perhaps it is best to wait for him or one of the other duet folks to comment.

Chriss

@gloomyandy Sorry, my bad. I do not always understand the difference between a question and "you should do that".

Anyway, you are more than right.... I have to do a bigger maintenance job on the toolhead anyway. So I will do this job and ground the hotend, just in case. And lets see of David has a other idea what may cause this problem.

Cheers, Chriss