Issue with SZP on Secondary Idex Toolhead

Superbrain8

@T3P3Tony installed the new firmware, homed the printer but it still fails to home the Z axis
here is a M122 after the failed home attempt

=== Diagnostics ===
RepRapFirmware for Duet 3 Mini 5+ version 3.6.0-beta.4+2 (2025-02-18 10:06:11) running on Duet 3 Mini5plus WiFi (standalone mode)
Board ID: YQ6KF-K096U-D65J0-40KMG-4G03Z-H28XK
Used output buffers: 1 of 40 (22 max)
=== RTOS ===
Static ram: 94764
Dynamic ram: 97496 of which 12 recycled
Never used RAM 49196, free system stack 188 words
Tasks: NETWORK(1,ready,10.2%,235) LASER(5,nWait 7,0.0%,269) HEAT(3,nWait 6,0.0%,350) Move(4,nWait 6,0.0%,353) TMC(4,nWait 6,0.8%,99) CanReceiv(6,nWait 1,0.1%,794) CanSender(5,nWait 7,0.0%,336) CanClock(7,delaying,0.0%,353) MAIN(1,running,86.2%,659) IDLE(0,ready,1.8%,29) USBD(3,blocked,0.0%,147) AIN(4,delaying,0.8%,269), total 100.0%
Owned mutexes:
=== Platform ===
Last reset 00:00:14 ago, cause: software
Last software reset at 2025-02-23 14:59, reason: HeatTaskStuck, Gcodes spinning, available RAM 49124, slot 0
Software reset code 0x0143 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0000080f BFAR 0xe000ed38 SP 0x200117d8 Task Move Freestk 1018 ok
Stack: 00000000 2001112c 10000000 e000e000 20000f4c 0009f255 0009fa40 61000000 20016e08 200235b8 200235b8 20023530 00053f71 00007ff0 00000001 00056d53 a5a5a5a5 200235b8 20023538 00000000 a5a5a500 418a2040 a5a5a5a5 a5a5a5a5 a5a5a5a5 a5a5a5a5 a5a5a5a5
=== Storage ===
Free file entries: 20
SD card 0 detected, interface speed: 22.5MBytes/sec
SD card longest read time 0.7ms, write time 0.0ms, max retries 0
=== Move ===
Segments created 0, maxWait 0ms, bed comp in use: none, height map offset 0.000, hiccups added 0/0 (0.00/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 4, r/w errs 0/1, ifcnt 63, reads/writes 741/14, timeouts 0, DMA errs 0, CC errs 0
Driver 1: standstill, SG min 10, r/w errs 0/1, ifcnt 63, reads/writes 741/14, timeouts 0, DMA errs 0, CC errs 0
Driver 2: standstill, SG min 0, r/w errs 0/1, ifcnt 64, reads/writes 741/14, timeouts 0, DMA errs 0, CC errs 0
Driver 3: standstill, SG min 2, r/w errs 0/1, ifcnt 63, reads/writes 741/14, timeouts 0, DMA errs 0, CC errs 0
Driver 4: standstill, SG min 0, r/w errs 0/1, ifcnt 64, reads/writes 741/14, timeouts 0, DMA errs 0, CC errs 0
Driver 5: not present
Driver 6: not present
=== 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, 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
=== Filament sensors ===
Driver 11: no data received, errs: frame 0 parity 0 ovrun 0 pol 0 ovdue 0
Driver 10: no data received, errs: frame 0 parity 0 ovrun 0 pol 0 ovdue 0
=== CAN ===
Messages queued 168, received 761, lost 0, ignored 0, errs 0, boc 0
Longest wait 2ms for reply type 6061, peak Tx sync delay 351, free buffers 26 (min 25), ts 70/69/0
Tx timeouts 0,0,0,0,0,0
=== Network ===
Slowest loop: 5.21ms; 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.2.1
Module reset reason: Power up, Vcc 3.42, flash size 2097152, free heap 39332
MAC address f0:08:d1:02:e5:fa
IP address 192.168.178.47
Signal strength -42dBm, channel 6, mode 802.11n, reconnections 0
Clock register 00002002
Socket states: 0 0 0 0 0 0 0 0

gloomyandy

@Superbrain8 If you reduce the length of the homing moves you are using (they are currently set to -99999) to something like -9999, do you still see the board reset?

Superbrain8

@gloomyandy that fixed that issue, thanks.
will see how the original issue for this post is fixed too

Superbrain8

no that one still persists, the mesh is scanned in the Y axis instead of the X Axis but is generated as if scanned in the X Axis

droftarts

@Superbrain8 said in Issue with SZP on Secondary Idex Toolhead:

no that one still persists, the mesh is scanned in the Y axis instead of the X Axis but is generated as if scanned in the X Axis

I suspect this is because of the axis mapping of the second axis. It will need @dc42 to look at it, and probably fix in firmware.

As a workaround for now, I think your options will be either to put the SZP on the primary toolhead, or swap the X and U axes, so that the second tool is referred to as the X axis, and the first tool is the U axis.

Ian

dc42

@Superbrain8 thanks, we created this issue:

https://github.com/Duet3D/RepRapFirmware/issues/1094

It's scheduled to be fixed between 3.6.0-rc.1 and 3.6.0 stable.

gloomyandy created this issue in Duet3D/RepRapFirmware

closed Long homing moves can cause HeatTaskStuck software reset and/or Code 7 halts #1094

dc42

@Superbrain8 said in Issue with SZP on Secondary Idex Toolhead:

no that one still persists, the mesh is scanned in the Y axis instead of the X Axis but is generated as if scanned in the X Axis

Please try the 3.6.0-rc.2+1firmware from https://www.dropbox.com/scl/fo/kj7gwwzxg5lhe26twph5z/AAdwkPCTYi6bcogLmIIIup4?rlkey=8oo6z5il7wzk2u5b7qpykf3qv&dl=0.

Superbrain8

@dc42 Thanks for the reply,
running this firmware resolves the issue, it now Scans as expected in the X axis and the mesh generated also looks correct.

dc42

@Superbrain8 thanks for confirming!