[3.6.0-rc.2] Code 3 move error
-
@MaxGyver thanks, I'll try to reproduce it. We haven't had any other reports of Code 3 errors since we released RC4.
-
@MaxGyver not related to the Code 3 errors, but I noticed this in your config.g file:
M205 X8 Y8 Z2 E10 ; M205 X5 Y5 Z2 E3 P0 ; set jerk;M566 X125 Y125 Z60 P0 ;set jerk
M205 and M566 no longer do the same thing with different units in 3.6. M566 sets the machine limits (in mm/min) while M205 sets the limits for the current print, if they are lower than the M566 limits when converted to the same units. See https://github.com/Duet3D/RepRapFirmware/wiki/Changelog-RRF-3.x-RC#upgrade-notes-from-354.
-
@MaxGyver I believe I have identified the cause of these errors. If I am right, they only occur when the input shaping frequency is below about 12Hz, which would explain why nobody else has reported Code 3 errors since we released beta4.
Please try the new 3.6.0-rc.2+2 main board firmware binary from https://www.dropbox.com/scl/fo/nlkfneaas1osgtdw37s17/AIS_H0KSAKCmfYSjSRTSOAE?rlkey=ad4omnq36zkdz3wl8i7kthqqt&dl=0. You may keep your expansion board binaries at 3.6.0-rc.2 or upgrade them to rc.2+1 from https://www.dropbox.com/scl/fo/kj7gwwzxg5lhe26twph5z/AAdwkPCTYi6bcogLmIIIup4?rlkey=8oo6z5il7wzk2u5b7qpykf3qv&dl=0.
-
I finally had a chance to test the latest 3.6.0-rc.3. When the input shaping frequency is set below 12Hz I still have a code 3 movement error always at the same code line early in the first layer. When the IS frequency is >12Hz it is working. I have attached the test pot.gcode file that is causing the error.
Error: Code 3 move error: new: start=335135293 overlap=3753 time now=335099122, existing: s=335096227 t=42819 d=20.49 u=8.1090e-4 a=-1.5526e-8 f=18
M122 === Diagnostics === RepRapFirmware for Duet 3 MB6HC version 3.6.0-rc.3 (2025-04-30 14:43:53) running on Duet 3 MB6HC v1.01 (SBC mode) Board ID: 0JD2M-999AL-D25S4-7J1D2-3SJ6K-T51V3 Used output buffers: 1 of 40 (19 max) === RTOS === Static ram: 137420 Dynamic ram: 98720 of which 0 recycled Never used RAM 107844, free system stack 130 words Tasks: LASER(5,nWait 7,0.0%,235) SBC(2,nWait 7,1.1%,813) HEAT(3,nWait 6,0.0%,368) Move(4,nWait 6,0.0%,209) TMC(4,nWait 6,3.0%,377) CanReceiv(6,nWait 1,0.1%,792) CanSender(5,nWait 7,0.0%,329) CanClock(7,delaying,0.0%,350) MAIN(1,running,83.7%,500) IDLE(0,ready,12.1%,29) USBD(3,blocked,0.0%,149), total 100.0% Owned mutexes: HTTP(MAIN) === Platform === Last reset 00:02:34 ago, cause: software Last software reset at 2025-05-12 11:06, reason: User, Gcodes spinning, available RAM 82500, slot 1 Software reset code 0x2003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x00400000 BFAR 0x00000000 SP 0x00000000 Task SBC Freestk 0 n/a Error status: 0x00 MCU temperature: min 33.9, current 34.3, max 35.0 Supply voltage: min 23.4, 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/320/52, gc cycles 0 Events: 599 queued, 599 completed Date/time: 2025-05-12 11:08:41 Slowest loop: 1545.84ms; fastest: 0.07ms === 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 3, maxWait 68608ms, bed comp in use: none, height map offset 0.000, hiccups added 0/0 (0.00/0.05ms), max steps late 0, ebfmin 0.00, ebfmax 0.00 Pos req/act/dcf: -464285.00/-463726/-0.50 0.00/0/0.00 804000.00/804000/0.00 Next step interrupt due in 22 ticks, disabled Driver 0: standstill, SG min n/a, mspos 8, reads 47118, writes 11 timeouts 0 Driver 1: standstill, SG min n/a, mspos 8, reads 47118, writes 11 timeouts 0 Driver 2: standstill, SG min n/a, mspos 8, reads 47118, writes 11 timeouts 0 Driver 3: standstill, SG min n/a, mspos 8, reads 47118, writes 11 timeouts 0 Driver 4: standstill, SG min n/a, mspos 8, reads 47118, writes 11 timeouts 0 Driver 5: standstill, SG min n/a, mspos 8, reads 47118, writes 11 timeouts 0 Phase step loop runtime (us): min=0, max=40, frequency (Hz): min=1744, max=2358 === DDARing 0 === Scheduled moves 6, completed 5, LaErrors 0, Underruns [0, 0, 0] Segments left 0, axes/extruders owned 0x80000007, drives owned 0x80000007 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 Heater 0 is on, I-accum = 0.0 Heater 1 is on, I-accum = 0.0 === GCodes === Movement locks held by Trigger, 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) 2 0 5 0, running macro 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 1431, received 9757, lost 0, ignored 0, errs 0, boc 0 Longest wait 4ms for reply type 6061, peak Tx sync delay 379, free buffers 50 (min 49), ts 734/733/0 Tx timeouts 0,0,0,0,0,0 === SBC interface === Transfer state: 5, failed transfers: 0, checksum errors: 0 RX/TX seq numbers: 6084/6084 SPI underruns 0, overruns 0 State: 5, disconnects: 0, timeouts: 0 total, 0 by SBC, IAP RAM available 0x27a24 Buffer RX/TX: 208/256-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 Trigger: Buffered code: G1 H1 X-1205 F{global.homingspeed/2} ; move slowly to X axis endstop once more (second pass) Buffered code: G90 ; absolute positioning Buffered codes: 96 bytes total >> Doing macro trigger2.g, started by system >>> Doing macro homeall.g, started by G28 >>> Suspended code: M98 P"homey.g" >>>> Doing macro homex.g, started by M98 P"homex.g" Code buffer space: 3840 Configured SPI speed: 8000000Hz, TfrRdy pin glitches: 0 Full transfers per second: 40.77, max time between full transfers: 1750.1ms, max pin wait times: 39.5ms/4.0ms Codes per second: 0.71 Maximum length of RX/TX data transfers: 4468/904
-
@MaxGyver thanks for your report. When that error was reported, did you still have input shaping set to 8.7Hz EI3 in config.g?
-
@dc42 Yes, Input shaping was Set to 8.7Hz EI3.
-
@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.
-
@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.
-
I have a chance to test the new version tomorrow. I will let you know asap.
-
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/1072On 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.
-
@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
-
@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.
-
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.
-
@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.