@omtek how is the PanelDue wired to the Duet, ribbon cable or 4-wire cable? Is it particularly long?

You also have the PanelDue serial comms speed set higher than we normally suggest. From your config:

M575 P1 S1 B115200

Try M575 P1 S1 B57600

I suggest checking the wiring, crimps and connectors for good connections, and make sure they are not running close to motor or heater wires, which could be sources of interference.

Ian

@gloomyandy

yes - I believe it was on.
even though after all these restarts I might have lost the track
here is another crash report

m122 === Diagnostics === RepRapFirmware for Duet 3 Mini 5+ version 3.5.1 (2024-04-19 14:41:25) running on Duet 3 Mini5plus WiFi (standalone mode) Board ID: PA279-4N6KL-K65J0-409N0-4Z02Z-HWYBD Used output buffers: 20 of 40 (36 max) === RTOS === Static ram: 103232 Dynamic ram: 122532 of which 12 recycled Never used RAM 15640, free system stack 182 words Tasks: NETWORK(2,nWait 7,14.4%,208) HEAT(3,nWait 6,0.0%,326) Move(4,nWait 6,0.0%,310) CanReceiv(6,nWait 1,0.1%,772) CanSender(5,nWait 7,0.0%,336) CanClock(7,delaying,0.0%,348) TMC(4,nWait 6,1.4%,102) MAIN(1,running,83.1%,651) IDLE(0,ready,0.0%,30) AIN(4,delaying,0.9%,260), total 100.0% Owned mutexes: WiFi(NETWORK) === Platform === Last reset 39:07:39 ago, cause: software Last software reset at 2024-05-11 16:34, reason: HardFault bfarValid precise, Gcodes spinning, available RAM 11100, slot 1 Software reset code 0x4063 HFSR 0x40000000 CFSR 0x00008200 ICSR 0x0047d803 BFAR 0x0000001c SP 0x20011ff0 Task NETW Freestk 483 ok Stack: 2002c610 20030848 200014e8 00000000 2003322f 0002ff99 0002feac 610f0000 0002ff85 00000000 00000000 00000000 20030854 00000800 2002c5f8 2002c5f8 00000002 2002c41e 200187fc 2001e9f8 0003011f 00000000 00000000 00000000 200120a0 00000014 46b8173e Error status: 0x00 Aux0 errors 0,0,0 MCU revision 3, ADC conversions started 140859060, completed 140859060, timed out 0, errs 0 MCU temperature: min 22.9, current 23.1, max 23.5 Supply voltage: min 23.9, current 24.0, max 24.1, under voltage events: 0, over voltage events: 0, power good: yes Heap OK, handles allocated/used 0/0, heap memory allocated/used/recyclable 0/0/0, gc cycles 0 Events: 0 queued, 0 completed Driver 0: standstill, SG min 2, read errors 0, write errors 0, ifcnt 81, reads 62161, writes 0, timeouts 0, DMA errors 0, CC errors 0 Driver 1: standstill, SG min 106, read errors 0, write errors 0, ifcnt 81, reads 62161, writes 0, timeouts 0, DMA errors 0, CC errors 0 Driver 2: standstill, SG min 0, read errors 0, write errors 0, ifcnt 45, reads 62161, writes 0, timeouts 0, DMA errors 0, CC errors 0 Driver 3: standstill, SG min 64, read errors 0, write errors 0, ifcnt 83, reads 62161, writes 0, timeouts 0, DMA errors 0, CC errors 0 Driver 4: standstill, SG min 66, read errors 0, write errors 0, ifcnt 84, reads 62161, writes 0, timeouts 0, DMA errors 0, CC errors 0 Driver 5: standstill, SG min 56, read errors 0, write errors 0, ifcnt 84, reads 62161, writes 0, timeouts 0, DMA errors 0, CC errors 0 Driver 6: standstill, SG min 68, read errors 0, write errors 0, ifcnt 83, reads 62161, writes 0, timeouts 0, DMA errors 0, CC errors 0 Date/time: 2024-05-13 07:41:49 Cache data hit count 4294967295 Slowest loop: 32.79ms; fastest: 0.16ms === Storage === Free file entries: 20 SD card 0 detected, interface speed: 22.5MBytes/sec SD card longest read time 3.7ms, write time 0.0ms, 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 1, completed 1, 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 4 -1 -1 -1, ordering errs 0 Heater 1 is on, I-accum = 0.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 6162, received 27379, lost 0, errs 0, boc 0 Longest wait 6ms for reply type 6024, peak Tx sync delay 261, free buffers 26 (min 25), ts 3419/3419/0 Tx timeouts 0,0,0,0,0,0 === Network === Slowest loop: 20.35ms; fastest: 0.06ms Responder states: MQTT(0) HTTP(1) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0) HTTP sessions: 2 of 8 === WiFi === Interface state: active Module is connected to access point Failed messages: pending 0, notrdy 0, noresp 0 Firmware version 2.1beta6 MAC address e8:68:e7:e1:4e:a5 Module reset reason: Power up, Vcc 3.41, flash size 2097152, free heap 33128 WiFi IP address 192.168.1.110 Signal strength -56dBm, channel 2, mode 802.11n, reconnections 0 Clock register 00002001 Socket states: 0 0 3 0 0 0 0 0

@o_lampe my test was at Z10, as was that done by @achrn. It's not the shape at the top we are concerned with here, it’s that it goes beyond M665 B parameter. The cone at the top is limited by the endstop switches, so I’m pretty sure the firmware takes account of that, though I didn’t test that. It’s why you always have to move down in Z after homing, before moving in X and Y. okay, rereading @achrn’s post, it’s trying to go outside the cone at the top too. I’ll update the issue on GitHub.

Ian

@dc42 Let me know if you need anything from me. I realize I am probably apart a small few experiencing this issue.

I stumbled on to this when upgrading an old Duet 2 Ethernet from v3.3 to the current 3.5.1. I set up my router to assign a specific IP address to the Duet based on the MAC address and had a slight freak out when the DWC couldn't reconnect to the Duet. Might be worth mentioning on the updating firmware page.

https://docs.duet3d.com/User_manual/RepRapFirmware/Updating_firmware

@droftarts Sounds great, just wanted to be sure I wasn't pulling from the wrong repo or anything 😉

Apologies about the long delay in replying, Time has been slipping away quite easily over here 😖

@dc42 Standalone mode, Behaviours seems consistent across a Duet 3 and a Duet 2.

@JayT I haven't tested the power resume behaviours as the current printers I use generally don't recover well from depowering the motors. Ill report back once I get some time in the workshop to setup a Power resume test.

@Gianluca I've just tested LEDs on io ports on a 6HC, and see the same as you, ie first LED is stuck green in RRF 3.5.1. I went back and tested on 3.5.0-rc.1 (works correctly), rc.2 (works correctly), and rc.3 (first LED stuck green) too. It seems there was a regression in function between rc.2 and rc.3. I've also tested in 3.5.1 on Duet 3 Mini 5+, and LEDs on io ports work correctly, so this seems to be specific to 6HC (and probably the 6XD, too).

I have raised an issue on Github, so @dc42 can fix it. https://github.com/Duet3D/RepRapFirmware/issues/996

Ian

droftarts created this issue in Duet3D/RepRapFirmware open [Bug]: MB6HC (maybe 6XD too) - LED strips connected to io ports set first LED incorrectly, always green #996

Has this happened again since?

@chrishamm said in 3.5.1 forgets whether filament is loaded with M999:

Edit: I've got a bug fix ready. I suggest you change something that modifies the move key at the end of your config.g (as I did with M906 E...) to work-around this problem for now.

Excellent thanks. I changed the 'real' M906 E1000 near the top of the config to a lower value (actually 500) and put my desired M906 E1000 as the last statement in config.g and it now doesn't forget about the filament, either for a M999 or for a full power down and power up again.

@T3P3Tony closing this issue, please comment once tested.

@Nate-Nygren please see my response to this thread which I see you have also contributed to https://forum.duet3d.com/topic/35611/my-printer-reboots-alone/14.

@benecito said in y slope with 3.5.0-rc1, not seen with 3.4.6:

want me to move it to a new thread.

probably would be a good idea to start a new thread. include as much info as you can.

@IndeX4D is ths forum still the right place for questions?

@R006 sounds like its a mechanical issue or you've set speed limits that are higher than your machine is capable of.
if it was a firmware issue, everyone would be affected

@dc42 just a follow upletting you and anyone following this issue that in my case the expression nesting was still too deep even under 3.5.1. I corrected it by making my macro a little cleaner. Basically not loading so much into one variable assignment. but spreading out the math 🙂

@Phaedrux, while not impossible, I don't really know what I am doing. Could you give me a hint as to what you expect to see? There is no apparent (at least to me) difference in printer behaviour between a printer that shows hiccups vs one that doesn't produce hiccups. I don't know if maybe one would see choppy motion for example ... but there is no hint of choppiness.