If it's a bug we can reproduce we can try to fix it.

@chrishamm It appears to be happening much less with 3.5.1, though I was able to trigger a SPI reset; it happened after about 40 moves instead of one or two.

Instead it appears the data capture is being cut off somewhere, as the received data should be 1 second long but i am only getting around 150-350ms of data back for each run. Once in awhile (about every 10 runs) I get a complete data log.

Here's a screenshot showing my settings and the returned data:
db01f3ba-889e-418a-8981-56b10fd9b04e-image.png

EDIT: Looks like I spoke too soon, it seems to be resetting just as often on longer moves (100mm+).
I also validated that the endstop wasn't the culprit by unplugging it after homing, it still seems to reset without that connected.

@dc42 3.5 has gone stable AND you already managed to fix that??

Thanks a lot - and congratulations! That was some really hard work for you and the whole Duet team! If I remember correctly, 3.5. had the longest beta / RC phase of all the RRF versions I saw and used in the last seven or so years.

(edit - after upgrading the printer yesterday, I just took the chance to test the updated function: crash detection works, and now U behaves exactly as X did - i.e. U does not crash into the endstop any more, but the X carriage ends up at places where it should not go. But that bug is just an inconvenience, not critical for the printer)

@omtek thanks for reporting this, and I'm sorry that you suffered a broken nozzle.

I have created issue https://github.com/Duet3D/RepRapFirmware/issues/978 to be resolved in RRF 3.5.1. Meanwhile I have added a new entry in the Upgrade Notes for RRF 3.5.0 to say that any use of M400 in deployprobe.g or retractprobe.g or macros that they call need to have the S1 parameter added.

dc42 created this issue in Duet3D/RepRapFirmware open Using M400 in deployprobe.g causes machine to try to move outside limits #978

@Phaedrux

My resurrect-prologue.g
``

G1 Z{param.Z}
G28 X Y
M116
M83
M21 P1
G1 E5 F500
;mesh
G29 S1
;Buzz
M300 S600 P100
;Buzz
M300 S700 P1200
;Buzz
M300 S500 P300
;Abs
G90

homeall.g

G91 ; relative positioning
G1 H2 Z2 F100 ; lift Z relative to current position
G1 H1 X-300 Y-300 F600 ; move quickly to X and Y axis endstops and stop there (first pass)
G1 H2 X5 Y5 F1000 ; go back a few mm
G1 H1 X-300 Y-300 F200 ; move slowly to X and Y axis endstops once more (second pass)
G1 H1 Z304.1 F300 ; Z down
G1 H2 Z-2 F100 ; back
G1 H1 Z304.1 F100
G92 X0 Y0
G90 ; absolute positioning
G92 Z304.1

@dc42 :

with RC4, sometimes it resumes fine with minimal offset. Whereas sometimes it shift by 5-8mm in Y direction for me on resume after power failure. Mostly it shifting by >5mm happens when print height is <5mm. So i disabled meshbed compensation & tried. It still has the same problem.

There are instances when even at height 3mm, it resumes fine.
skew in YZ is included. Does that have any effect?

What should I check for ?
Shift is always in Y axis & amount of shift is more w.r.t X axis.

@droftarts Good news I updated to the version you sent here, and did a few prints with pauses and the issue did not came back. Also one other bug seems to went away where the z probe false triggers or not activates at all.

Have you tried running the same gcode file again to see if i stops at the same point?

Please share a M122 report after each reset.

Also please share your config set.

@OwenD
That worked. Funnily enough, I swear I tried that exact same format once before. In any case, thank you for the time to make the suggestion. All in all I think that solves the functionality issue, but still the formatting error is something @dc42 can look into in case its affecting others as well.

@Nate-Nygren Thanks for reporting this, I just fixed it in the configtool.

@Exerqtor @oliof this is a consequence of how GCode is parsed by RRF. The parameters to a GCode command are independent of order and the expected type (integer, float, array of floats, none etc.) depends on the command. So RRF doesn't do a linear parse of the command. Instead it extracts the G or M part and then depending on the command number, it looks to see whether each additional parameter that the command uses is present. Anything that isn't required (extra parameters, commas, other unused characters etc.) are ignored. That is why commas are ignored by RRF, except in meta commands and expressions.

So, after removing daemon.g, there are no pauses. Sorry for the false alarm.

@OwenD please try firmware 3.5.0-rc.4 which we intend to release today or tomorrow. I believe it fixes these issues:

SD card has open files error message Build object names not restored when resuming after power fail Error message when resuming after power fail if build object names were not provided

@dc42 thank you very much for the info!

@dc42 Ok, then i bet i've forgot to install rc8 or something, I'll have a look later!

Didn't try the command in DWC console, but the if i trued running the bed leveling from PD (that command is part of bed.g) nothing popped up on PD, so i went to check in DWC an there it was displayed.

Edit:
Just got home and checked PD, it's got 3.5.0-rc8 installed like I thought. And i just tried to run a tram from the button on PD, now it displayed the message like it should. So idk what was going on yesterday tbh.

Happy easter everyone!

@dc42
I haven't really had any issues with crashes in a while now, since "we" finally got the printer working again after patching out the extrusion bug I've had the printer going more or less non-stop and only with one instance of OrcaSlicer open and checking in on my phone (android & chrome browser) every now and then to not provoce any crashes.

However when I got to the printer this morning i saw it had rebooted during the night for some reason!

Here is the last entries to the eventlog (had to switch to event logging since debug it putting out SO MUCH DATA since a little while back):

2024-03-29 13:56:58 [warn] Started printing file 0:/gcodes/O*********r_0.2mm_ABS_0.4n_17m37s.gcode 2024-03-29 14:01:54 [warn] M150 sent for logo : yellow 2024-03-29 14:01:54 [warn] M150 sent for nozzle : yellow 2024-03-29 14:02:14 [warn] M150 sent for logo : teal 2024-03-29 14:02:14 [warn] M150 sent for nozzle : bright_white 2024-03-29 14:02:28 [warn] M150 sent for logo : green 2024-03-29 14:02:28 [warn] M150 sent for nozzle : bright_white 2024-03-29 14:02:42 [warn] 9 points probed, min error -0.014, max error 0.005, mean -0.005, deviation 0.005 Height map saved to file 0:/sys/heightmap.csv 2024-03-29 14:02:43 [warn] M150 sent for logo : dim_gray 2024-03-29 14:02:43 [warn] M150 sent for nozzle : dim_red 2024-03-29 14:02:44 [warn] M150 sent for logo : yellow 2024-03-29 14:02:44 [warn] M150 sent for nozzle : yellow 2024-03-29 14:03:09 [warn] M150 sent for logo : light_blue 2024-03-29 14:03:09 [warn] M150 sent for nozzle : bright_white 2024-03-29 14:03:20 [warn] M150 sent for logo : red 2024-03-29 14:03:20 [warn] M150 sent for nozzle : bright_white 2024-03-29 14:24:21 [warn] Finished printing file 0:/gcodes/O*********r_0.2mm_ABS_0.4n_17m37s.gcode, print time was 0h 27m 2024-03-29 14:24:26 [warn] M150 sent for logo : dim_gray 2024-03-29 14:24:26 [warn] M150 sent for nozzle : dim_red 2024-03-29 20:05:42 [warn] HTTP client 192.168.10.xx disconnected 2024-03-30 09:31:09 [warn] HTTP client 192.168.10.xxx login succeeded (session key 2606324820) 2024-03-30 09:44:34 [warn] HTTP client 192.168.10.xx login succeeded (session key 2283911350) 2024-03-30 17:13:44 [warn] HTTP client 192.168.10.xx login succeeded (session key 702406583) power up + 00:00:03 [info] Event logging started at level warn power up + 00:00:03 [info] Running: Duet 3 Mini5plus WiFi: 3.5.0-rc.3+5 (2024-03-27 11:34:04) power up + 00:00:04 [warn] WiFi module started power up + 00:00:04 [warn] M150 sent for logo : n/a power up + 00:00:04 [warn] M150 sent for nozzle : n/a power up + 00:00:05 [warn] M150 sent for logo : n/a power up + 00:00:05 [warn] M150 sent for nozzle : n/a power up + 00:00:09 [warn] WiFi module is connected to access point RV32-IOT2G, IP address 192.168.10.x power up + 00:00:10 [warn] HTTP client 192.168.10.xx login succeeded (session key 1857804272) 2024-03-31 03:37:09 [warn] Date and time set at power up + 00:00:10

And some reports:

M122 === Diagnostics === RepRapFirmware for Duet 3 Mini 5+ version 3.5.0-rc.3+5 (2024-03-27 11:34:04) running on Duet 3 Mini5plus WiFi (standalone mode) Board ID: XNHXF-HR6KL-K65J0-409N2-K9W1Z-RV2MZ Used output buffers: 18 of 40 (31 max) === RTOS === Static ram: 103264 Dynamic ram: 124000 of which 12 recycled Never used RAM 11284, free system stack 180 words Tasks: NETWORK(2,nWait 7,245.0%,231) HEAT(3,nWait 6,0.4%,326) Move(4,nWait 6,0.0%,341) CanReceiv(6,nWait 1,0.9%,771) CanSender(5,nWait 7,0.0%,337) CanClock(7,delaying,0.1%,349) TMC(4,nWait 6,12.7%,102) MAIN(1,running,113.1%,667) IDLE(0,ready,13.9%,30) AIN(4,delaying,13.1%,260), total 399.3% Owned mutexes: WiFi(NETWORK) === Platform === Last reset 08:29:06 ago, cause: software Last software reset at 2024-03-31 02:36, reason: HardFault invState, Platform spinning, available RAM 6444, slot 2 Software reset code 0x4060 HFSR 0x40000000 CFSR 0x00020000 ICSR 0x00000803 BFAR 0xe000ed38 SP 0x20012020 Task NETW Freestk 495 ok Stack: 2002c5f8 20030ba8 200014e8 00000000 ffffffff 0002ffb1 00000000 60010000 00000000 00000000 00000000 00000000 200120a0 00000014 b5dd8a35 00000002 e8610050 640aa8c0 080001a8 00000001 000347f9 2002c3c0 2002c3c0 00000007 0002f72d 20011744 00000000 Error status: 0x00 Aux0 errors 0,0,0 MCU revision 3, ADC conversions started 30546654, completed 30546654, timed out 0, errs 0 MCU temperature: min 33.8, current 35.5, max 37.6 Supply voltage: min 3.8, current 24.1, max 24.3, under voltage events: 0, over voltage events: 0, power good: yes Heap OK, handles allocated/used 99/32, heap memory allocated/used/recyclable 2048/664/248, gc cycles 6669 Events: 1 queued, 1 completed Driver 0: standstill, SG min 0, read errors 0, write errors 0, ifcnt 13, reads 34825, writes 13, timeouts 0, DMA errors 0, CC errors 0 Driver 1: standstill, SG min 0, read errors 0, write errors 0, ifcnt 13, reads 34825, writes 13, timeouts 0, DMA errors 0, CC errors 0 Driver 2: standstill, SG min 0, read errors 0, write errors 0, ifcnt 13, reads 34825, writes 13, timeouts 0, DMA errors 0, CC errors 0 Driver 3: standstill, SG min 0, read errors 0, write errors 0, ifcnt 13, reads 34823, writes 13, timeouts 1, DMA errors 0, CC errors 0, failedOp 0x51 Driver 4: standstill, SG min 0, read errors 0, write errors 0, ifcnt 13, reads 34824, writes 13, timeouts 1, DMA errors 0, CC errors 0, failedOp 0x6c Driver 5: not present Driver 6: not present Date/time: 2024-03-31 12:06:09 Cache data hit count 4294967295 Slowest loop: 27.00ms; fastest: 0.12ms === Storage === Free file entries: 18 SD card 0 detected, interface speed: 22.5MBytes/sec SD card longest read time 7.8ms, write time 45.9ms, 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 Heater 0 is on, I-accum = 0.4 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 doing "G4 P250" in state(s) 0 0, running macro 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 === Filament sensors === check 0 clear 0 Extruder 0 sensor: no filament === CAN === Messages queued 274931, received 626212, lost 0, errs 369, boc 0 Longest wait 2ms for reply type 6053, peak Tx sync delay 8721, free buffers 26 (min 25), ts 152733/152732/0 Tx timeouts 0,0,0,0,0,0 === Network === Slowest loop: 10.10ms; fastest: 0.00ms Responder states: MQTT(0) HTTP(0) 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.1beta7 MAC address c4:5b:be:ce:91:93 Module reset reason: Power up, Vcc 3.38, flash size 2097152, free heap 36388 WiFi IP address 192.168.10.x Signal strength -46dBm, channel 6, mode 802.11n, reconnections 0 Clock register 00002001 Socket states: 0 0 0 0 0 0 0 0 M122 B121 Diagnostics for board 121: Duet TOOL1LC rev 1.1 or later firmware version 3.5.0-rc.3+5 (2024-03-27 11:29:09) Bootloader ID: SAMC21 bootloader version 2.8 (2023-07-25) All averaging filters OK Never used RAM 3960, free system stack 136 words Tasks: Move(3,nWait 7,0.0%,127) HEAT(2,nWait 6,6.0%,107) CanAsync(5,nWait 4,0.0%,55) CanRecv(3,nWait 1,0.2%,71) CanClock(5,nWait 1,0.3%,59) ACCEL(3,nWait 6,0.0%,53) TMC(2,nWait 6,53.8%,53) MAIN(1,running,255.9%,315) IDLE(0,ready,0.0%,27) AIN(2,delaying,76.9%,112), total 393.2% Owned mutexes: Last reset 08:29:46 ago, cause: power up Last software reset at 2024-03-12 16:55, reason: StackOverflow, available RAM 2968, slot 0 Software reset code 0x0100 ICSR 0x0042600e SP 0x20007f34 Task Move Freestk 3342 ok Stack: 20004a80 20004ab4 0001cf33 20004c98 20004938 00000000 0001c011 20003320 fffffffd a5a5a5a5 00000000 20007f8c 00000000 20007f8c 0001cc97 00000000 200017c4 20001748 0001c4d7 20001748 200017c4 00000032 454c4449 00022700 0001ac77 200018e0 200018e0 Driver 0: pos 0, 568.8 steps/mm, standstill, SG min 0, read errors 0, write errors 0, ifcnt 11, reads 23207, writes 11, timeouts 2, DMA errors 0, CC errors 0, failedOp 0x6a, steps req 0 done 0 Moves scheduled 0, completed 0, in progress 0, hiccups 0, segs 0, step errors 0, maxLate 0 maxPrep 0, maxOverdue 0, maxInc 0, mcErrs 0, gcmErrs 0, ebfmin 0.00 max 0.00 Peak sync jitter -4/10, peak Rx sync delay 219, resyncs 0/0, no timer interrupt scheduled VIN voltage: min 24.5, current 24.7, max 24.8 MCU temperature: min 40.5C, current 44.4C, max 44.5C Last sensors broadcast 0x00000012 found 2 113 ticks ago, 0 ordering errs, loop time 0 CAN messages queued 627040, send timeouts 0, received 275294, lost 0, errs 0, boc 0, free buffers 18, min 18, error reg 0 dup 0, oos 0/0/0/0, bm 0, wbm 0, rxMotionDelay 0 Accelerometer: LIS3DH, status: 00 I2C bus errors 0, naks 3, contentions 0, other errors 0 === Filament sensors === Interrupt 5726621 to 0us, poll 2 to 1300us Driver 0: ok

@droftarts said in [3.5.0-rc3+] M108 (cancel heating) is not working.:

If you run M109 et al in a macro, cancel it by sending M108 from the console in DWC; I think that shouldn’t be blocked.

Yes, that works. Thank you very much for clearing that up!

@Ce72 @danzaywer @RYANPDX This issue has been fixed. Latest binaries are here: https://www.dropbox.com/scl/fo/wrp6hvr39vjxjlep89p5x/h?rlkey=hzka49sxnsqjpwsvy46m26ms0&dl=0

Ian

@wschadow I suspect DWC is reporting the tool state, not the heater state. The tool state is copied to the heater state when you release the tool or switch to the tool, but you can subsequently override it using M568, until the tool is next selected or freed.

@Johnnyg Please start a new thread.