G32 issue RRF v3.5.0b1

A Former User

This post is deleted!

Diamondback

I have the same issue on 3.5b1, it seems to work when there is very little to correct, but fails when there is a lot to correct. (Maybe something to do with the max correction we set in init?)

A Former User

This post is deleted!

Diamondback

Same issue here it seems: https://forum.duet3d.com/topic/30890/g32-bed-trim-bug-in-3-5b1

dc42

@Diamondback please provide a M122 report after the reset.

Alex.cr

I am also having an issue with G32 in 3.5.0b1. The system is not waiting for G32 to be complete before moving to other commands.

I have the following code in my slicer start code:

M104 S180
M190 S[first_layer_bed_temperature]
G10 P0 S[temperature]  R180;
M116 ; wait for tool temp

G32 ; home and level gantry 
M98 P"/macros/print_scripts/nozzle_purge_wipe.g"
M98 P"autoz.g"

M291 P"Cycle Start" S1 T30

G32 runs a homing command if needed and then performs the bed leveling routine. Before G32 has finished, I can see echo commands only present in "autoz.g" hit the console. The system will just hang after the completion of the G32 command and the print will never physicaly start.

The entire procedure worked well using 3.4.x versions.

Diamondback

@dc42 Maybe not related to how much it needs to correct after all, this time it failed first try with basically zero need to correct.

Here's an M122 after the failure:

M122
=== Diagnostics ===
RepRapFirmware for Duet 3 MB6HC version 3.5beta1 (2022-12-23 18:27:08) running on Duet 3 MB6HC v1.02 or later (standalone mode)
Board ID: 08DJM-9P63L-DJ3T0-6J1F4-3S06S-9A1V9
Used output buffers: 2 of 40 (18 max)
=== RTOS ===
Static ram: 151524
Dynamic ram: 110820 of which 0 recycled
Never used RAM 85472, free system stack 202 words
Tasks: NETWORK(ready,25.3%,227) ETHERNET(notifyWait,0.1%,551) ACCEL(notifyWait,0.0%,348) HEAT(notifyWait,0.0%,365) Move(notifyWait,0.0%,350) CanReceiv(notifyWait,0.0%,798) CanSender(notifyWait,0.0%,335) CanClock(delaying,0.0%,352) TMC(notifyWait,7.7%,90) MAIN(running,65.8%,953) IDLE(ready,1.1%,30), total 100.0%
Owned mutexes:
=== Platform ===
Last reset 00:00:10 ago, cause: software
Last software reset at 2022-12-31 00:56, reason: HardFault unaligned, none spinning, available RAM 84492, slot 2
Software reset code 0x4072 HFSR 0x40000000 CFSR 0x01000000 ICSR 0x00400803 BFAR 0x00000000 SP 0x2041f8c8 Task NETW Freestk 332 ok
Stack: 00000000 000000a5 00000000 00000000 20428cc8 00444053 004440c2 81030000 00000004 204311b0 00000000 00000000 00000000 2041f924 2045c438 20430374 204311b0 2045c438 2041f924 004420bf 204311b0 00000000 0048e9ea 00002a30 ffffd5d0 00005dc0 00000000
Error status: 0x00
Step timer max interval 125
MCU temperature: min 40.5, current 41.0, max 41.0
Supply voltage: min 23.8, current 23.8, max 23.9, under voltage events: 0, over voltage events: 0, power good: yes
12V rail voltage: min 12.3, current 12.3, max 12.4, under voltage events: 0
Heap OK, handles allocated/used 99/50, heap memory allocated/used/recyclable 2048/892/32, gc cycles 0
Events: 0 queued, 0 completed
Driver 0: standstill, SG min n/a, mspos 936, reads 60096, writes 14 timeouts 0
Driver 1: standstill, SG min n/a, mspos 936, reads 60096, writes 14 timeouts 0
Driver 2: standstill, SG min n/a, mspos 40, reads 60096, writes 14 timeouts 0
Driver 3: standstill, SG min n/a, mspos 360, reads 60097, writes 14 timeouts 0
Driver 4: standstill, SG min n/a, mspos 520, reads 60097, writes 14 timeouts 0
Driver 5: standstill, SG min n/a, mspos 936, reads 60097, writes 14 timeouts 0
Date/time: 2022-12-31 00:56:49
Slowest loop: 3.15ms; fastest: 0.06ms
=== Storage ===
Free file entries: 10
SD card 0 detected, interface speed: 25.0MBytes/sec
SD card longest read time 2.4ms, write time 0.0ms, max retries 0
=== Move ===
DMs created 125, segments created 0, maxWait 0ms, bed compensation in use: none, comp offset 0.000
no step interrupt scheduled
=== 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 -1 -1 -1 -1 -1 -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 0x0000000
Code queue 0 is empty
Q1 segments left 0, axes/extruders owned 0x0000000
Code queue 1 is empty
=== CAN ===
Messages queued 123, received 253, lost 0, boc 0
Longest wait 1ms for reply type 6018, peak Tx sync delay 4, free buffers 50 (min 49), ts 55/54/0
Tx timeouts 0,0,0,0,0,0
=== Network ===
Slowest loop: 3.68ms; fastest: 0.03ms
Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0) Telnet(0)
HTTP sessions: 1 of 8
= Ethernet =
State: active
Error counts: 0 0 0 0 0 0
Socket states: 5 2 2 2 2 0 0 0
= WiFi =
Network state is disabled
WiFi module is disabled
Failed messages: pending 2779096485, notready 2779096485, noresp 2779096485
Socket states: 0 0 0 0 0 0 0 0
=== Multicast handler ===
Responder is inactive, messages received 0, responses 0

dc42

@Diamondback @Alex-cr @Herve_Smith thanks for your reports. I have now reproduced this bug and I am investigating it.

My tests so far indicate that if the levelling error is greater than the allowed tolerance (M671 S parameter) then the failure to level is correctly reported and the Duet does not reset.

dc42

This issue is now fixed. See https://forum.duet3d.com/post/303514 for more details.

A Former User

This post is deleted!