[3.6.0-rc.2] Code 3 move error

dc42

@MaxGyver thanks for your report. When that error was reported, did you still have input shaping set to 8.7Hz EI3 in config.g?

MaxGyver

@dc42 Yes, Input shaping was Set to 8.7Hz EI3.

dc42

@MaxGyver thanks.

I found a bug in the previous fix. Please try the 6HC build from https://www.dropbox.com/scl/fo/dumsdufoej44q97ek9joo/AIBRnU-wtKfMrbWPzZwH_XY?rlkey=idmyinvvcuiwmycbb1l2obz38&dl=0.

dc42

@MaxGyver are you able to test this? We expect to release RRF 3.6.0 very soon and I'd like to know whether this is fixed.

MaxGyver

@dc42

I have a chance to test the new version tomorrow. I will let you know asap.

MaxGyver

@dc42

I am sorry to report that the issue is not fixed with the latest Firmware binaries (3.6.0-rc.3+1)

With input shaping set to 13Hz, the part prints without issues.

With the latest binaries, the move 3 error is gone, but now my 1XD-Expansion board (YAxis) looses connection as soon as the printhead moves to print a couple of very short segments (Text) in the first layer.

23.5.2025, 10:34:21 M122
=== Diagnostics ===
RepRapFirmware for Duet 3 MB6HC version 3.6.0-rc.3+1 (2025-05-16 16:04:31) running on Duet 3 MB6HC v1.01 (SBC mode)
Board ID: 0JD2M-999AL-D25S4-7J1D2-3SJ6K-T51V3
Used output buffers: 1 of 40 (18 max)
=== RTOS ===
Static ram: 137420
Dynamic ram: 98756 of which 0 recycled
Never used RAM 79416, free system stack 128 words
Tasks: LASER(5,nWait 7,0.0%,155) SBC(2,nWait 7,0.9%,831) HEAT(3,nWait 6,0.0%,359) Move(4,nWait 6,0.2%,203) TMC(4,nWait 6,2.9%,375) CanReceiv(6,nWait 1,0.1%,768) CanSender(5,nWait 7,0.0%,327) CanClock(7,delaying,0.0%,350) MAIN(1,running,95.3%,500) IDLE(0,ready,0.6%,29) USBD(3,blocked,0.0%,149), total 100.0%
Owned mutexes: HTTP(MAIN)
=== Platform ===
Last reset 00:14:18 ago, cause: power up
Last software reset details not available
Error status: 0x00
MCU temperature: min 24.0, current 28.4, max 29.0
Supply voltage: min 23.3, current 23.5, max 23.6, under voltage events: 0, over voltage events: 0, power good: yes
12V rail voltage: min 12.0, current 12.1, max 12.1, under voltage events: 0
Heap OK, handles allocated/used 99/16, heap memory allocated/used/recyclable 2048/480/212, gc cycles 0
Events: 168 queued, 168 completed
Date/time: 2025-05-23 10:34:21
Slowest loop: 54.73ms; fastest: 0.06ms
=== Storage ===
Free file entries: 20
SD card 0 not detected, requested/actual speed: 0.0/37.5MBytes/sec
SD card longest read time 0.0ms, write time 0.0ms, max retries 0
=== Move ===
Segments created 1186, maxWait 145617ms, bed comp in use: mesh, height map offset 0.000, hiccups added 3/0 (0.00/36.69ms), max steps late 0, ebfmin 0.00, ebfmax 0.00
Pos req/act/dcf: 185328.00/185327/1.00 0.00/1/-1.00 803932.00/803931/0.97
No step interrupt scheduled
Driver 0: standstill, SG min n/a, mspos 8, reads 12143, writes 77 timeouts 6
Driver 1: standstill, SG min n/a, mspos 8, reads 12143, writes 77 timeouts 6
Driver 2: standstill, SG min n/a, mspos 8, reads 12143, writes 77 timeouts 6
Driver 3: standstill, SG min n/a, mspos 8, reads 12143, writes 77 timeouts 6
Driver 4: standstill, SG min n/a, mspos 8, reads 12143, writes 77 timeouts 6
Driver 5: standstill, SG min n/a, mspos 8, reads 12143, writes 77 timeouts 6
Phase step loop runtime (us): min=0, max=26, frequency (Hz): min=502, max=10273
=== DDARing 0 ===
Scheduled moves 736, completed 736, LaErrors 0, Underruns [112, 0, 0]
Segments left 0, axes/extruders owned 0x00000007, drives owned 0x00000007
Code queue is empty
=== DDARing 1 ===
Scheduled moves 0, completed 0, LaErrors 0, Underruns [0, 0, 0]
Segments left 0, axes/extruders owned 0x00000000, drives owned 0x00000000
Code queue is empty
=== Heat ===
Bed heaters -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1, chamber heaters 2 -1 -1 -1 -1 -1 -1 -1, ordering errs 0
=== GCodes ===
Movement locks held by null, null
HTTP* is doing "M122" 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 31: no filament
=== CAN ===
Messages queued 23076, received 56093, lost 0, ignored 0, errs 0, boc 0
Longest wait 3ms for reply type 6060, peak Tx sync delay 450, free buffers 50 (min 39), ts 4068/4067/0
Tx timeouts 0,0,0,0,0,0
=== SBC interface ===
Transfer state: 5, failed transfers: 0, checksum errors: 0
RX/TX seq numbers: 34620/34620
SPI underruns 0, overruns 0
State: 5, disconnects: 0, timeouts: 0 total, 0 by SBC, IAP RAM available 0x27a70
Buffer RX/TX: 0/0-0, open files: 0
=== Duet Control Server ===
Duet Control Server version 3.6.0-rc.3 (2025-04-30 10:29:48, 64-bit)
HTTP+Executed:

Executing M122
File 0:/gcodes/pot.gcode is selected, paused
Code buffer space: 4096
Configured SPI speed: 8000000Hz, TfrRdy pin glitches: 0
Full transfers per second: 39.05, max time between full transfers: 90.1ms, max pin wait times: 34.8ms/1.7ms
Codes per second: 7.30
Maximum length of RX/TX data transfers: 5404/1072

On another note: It would be nice if serious errors like a CAN board disconnecting or mesh probe fail would trigger a print cancellation or at least a pause. Luckily, I was monitoring the print closely and noticed that the Y-Axis has stopped moving. So I only had to clean a small blob of death.

jay_s_uk

@MaxGyver you can use the events system to setup what you want to happen on loss of CAN board https://docs.duet3d.com/en/User_manual/RepRapFirmware/Events

gloomyandy

@MaxGyver said in [3.6.0-rc.2] Code 3 move error:

With the latest binaries, the move 3 error is gone, but now my 1XD-Expansion board (YAxis) looses connection as soon as the printhead moves to print a couple of very short segments (Text) in the first layer.

That sounds like possibly a different problem (though maybe related). Can you post the output from running M122 b# (where # is the board number that lost connection). Hopefully that may provide some clues as to what is going on.

MaxGyver

@gloomyandy

I reckon the issue is related because the CAN-disconnect happened at the same time in the print where I previously had the move 3 error. And since everything works when IS-Frequency is >12Hz, just like before.

dc42

@MaxGyver thanks for your report. Please do some more tests to make suite sure that the disconnect is reproducible, and that it only occurs when IS is set to 12Hz (or lower if you prefer) and not when it is set to 13Hz. Then start a new thread about this disconnect issue. As @gloomyandy suggested, please include the result of M121 B# where # is the CAN address of the 1XD board.