Bug on 3.6.0? Layershifts & stuttering on arc travel moves

CaiJonas

dc42

@CaiJonas thanks for your example. Do you know whether firmware 3.5.4 exhibits the same behaviour?

droftarts

@CaiJonas Can you also post your config.g, and the response to M122, please. If you're using toolboards, please send M122 B#, where # is the CAN address of the toolboard.

Ian

CaiJonas

@dc42 as I can remember it was not the case before 3.6 but not 100% shure. If needed I can downgrade but I'm also not shure if the SZP will work with 3.5.4?

CaiJonas

@droftarts hope it's fine like the following

config.g

m122
=== Diagnostics ===
RepRapFirmware for Duet 3 Mini 5+ version 3.6.0-rc.2 (2025-03-31 12:16:33) running on Duet 3 Mini5plus WiFi (standalone mode)
Board ID: 8S6FD-V096U-D65J0-40KM0-4V03Z-RNJHW
Used output buffers: 3 of 40 (30 max)
=== RTOS ===
Static ram: 94764
Dynamic ram: 95664 of which 0 recycled
Never used RAM 51040, free system stack 198 words
Tasks: NETWORK(2,nWait 7,14.0%,207) LASER(5,nWait 7,0.0%,235) HEAT(3,nWait 6,0.0%,350) Move(4,nWait 6,0.0%,353) TMC(4,delaying,0.8%,99) CanReceiv(6,nWait 1,0.0%,794) CanSender(5,nWait 7,0.0%,336) CanClock(7,delaying,0.0%,348) MAIN(1,running,84.1%,661) IDLE(0,ready,0.2%,29) USBD(3,blocked,0.0%,147) AIN(4,delaying,0.8%,255), total 100.0%
Owned mutexes: WiFi(NETWORK)
=== Platform ===
Last reset 00:04:33 ago, cause: software
Last software reset at 2025-04-08 14:43, reason: User, Gcodes spinning, available RAM 40716, slot 1
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x00489000 BFAR 0xe000ed38 SP 0x00000000 Task MAIN Freestk 0 n/a
=== Storage ===
Free file entries: 20
SD card 0 detected, interface speed: 22.5MBytes/sec
SD card longest read time 3.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
No step interrupt scheduled
Driver 0: standstill, SG min 8, r/w errs 0/1, ifcnt 46, reads/writes 14381/13, timeouts 0, DMA errs 0, CC errs 0
Driver 1: standstill, SG min 160, r/w errs 0/1, ifcnt 173, reads/writes 14379/15, timeouts 0, DMA errs 0, CC errs 0
Driver 2: standstill, SG min 14, r/w errs 0/1, ifcnt 171, reads/writes 14379/15, timeouts 0, DMA errs 0, CC errs 0
Driver 3: standstill, SG min 2, r/w errs 0/1, ifcnt 46, reads/writes 14380/13, timeouts 1, DMA errs 0, CC errs 0, failedOp 0x71
Driver 4: standstill, SG min 0, r/w errs 0/1, ifcnt 46, reads/writes 14381/13, timeouts 0, DMA errs 0, CC errs 0
Driver 5: not present
Driver 6: not present
=== DDARing 0 ===
Scheduled moves 0, completed 0, LaErrors 0, Underruns [0, 0, 0]
Segments left 0, axes/extruders owned 0x00000803, drives owned 0x00000803
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 0 -1 -1 -1, chamber heaters -1 -1 -1 -1, ordering errs 0
Heater 0 is on, I-accum = 0.6
Heater 1 is on, I-accum = 0.2
=== 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
=== CAN ===
Messages queued 2398, received 2196, lost 0, ignored 0, errs 1, boc 0
Longest wait 2ms for reply type 6031, peak Tx sync delay 387, free buffers 26 (min 25), ts 1298/1297/0
Tx timeouts 0,0,0,0,0,0
=== Network ===
Slowest loop: 30.42ms; fastest: 0.00ms
Responder states: MQTT(0) HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0)
HTTP sessions: 2 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.39, flash size 2097152, free heap 39380
MAC address *************
IP address ************
Signal strength -65dBm, channel 6, mode 802.11n, reconnections 0
Clock register 00002002
Socket states: 0 0 0 0 0 0 0 0

M122 B0
=== Diagnostics ===
RepRapFirmware for Duet 3 Mini 5+ version 3.6.0-rc.2 (2025-03-31 12:16:33) running on Duet 3 Mini5plus WiFi (standalone mode)
Board ID: 8S6FD-V096U-D65J0-40KM0-4V03Z-RNJHW
Used output buffers: 1 of 40 (32 max)
=== RTOS ===
Static ram: 94764
Dynamic ram: 95664 of which 0 recycled
Never used RAM 51040, free system stack 198 words
Tasks: NETWORK(2,ready,20.2%,207) LASER(5,nWait 7,0.0%,235) 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.0%,794) CanSender(5,nWait 7,0.0%,336) CanClock(7,delaying,0.0%,348) MAIN(2,running,76.0%,661) IDLE(0,ready,2.1%,29) USBD(3,blocked,0.0%,147) AIN(4,delaying,0.8%,255), total 100.0%
Owned mutexes: WiFi(NETWORK) HTTP(MAIN)
=== Platform ===
Last reset 00:05:47 ago, cause: software
Last software reset at 2025-04-08 14:43, reason: User, Gcodes spinning, available RAM 40716, slot 1
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x00489000 BFAR 0xe000ed38 SP 0x00000000 Task MAIN Freestk 0 n/a
=== Storage ===
Free file entries: 20
SD card 0 detected, interface speed: 22.5MBytes/sec
SD card longest read time 3.4ms, 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
No step interrupt scheduled
Driver 0: standstill, SG min 8, r/w errs 0/0, ifcnt 46, reads/writes 927/0, timeouts 0, DMA errs 0, CC errs 0
Driver 1: standstill, SG min 160, r/w errs 0/0, ifcnt 173, reads/writes 927/0, timeouts 0, DMA errs 0, CC errs 0
Driver 2: standstill, SG min 14, r/w errs 0/0, ifcnt 171, reads/writes 927/0, timeouts 0, DMA errs 0, CC errs 0
Driver 3: standstill, SG min 2, r/w errs 0/0, ifcnt 46, reads/writes 927/0, timeouts 0, DMA errs 0, CC errs 0
Driver 4: standstill, SG min 0, r/w errs 0/0, ifcnt 46, reads/writes 927/0, timeouts 0, DMA errs 0, CC errs 0
Driver 5: not present
Driver 6: not present
=== DDARing 0 ===
Scheduled moves 0, completed 0, LaErrors 0, Underruns [0, 0, 0]
Segments left 0, axes/extruders owned 0x00000803, drives owned 0x00000803
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 0 -1 -1 -1, chamber heaters -1 -1 -1 -1, ordering errs 0
Heater 0 is on, I-accum = 0.5
Heater 1 is on, I-accum = 0.2
=== GCodes ===
Movement locks held by null, null
HTTP is ready with "M122 B0" 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
=== CAN ===
Messages queued 155, received 142, lost 0, ignored 0, errs 0, boc 0
Longest wait 0ms for reply type 0, peak Tx sync delay 6, free buffers 26 (min 25), ts 83/83/0
Tx timeouts 0,0,0,0,0,0
=== Network ===
Slowest loop: 21.25ms; fastest: 0.08ms
Responder states: MQTT(0) HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0)
HTTP sessions: 2 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.39, flash size 2097152, free heap 39168
MAC address *************
IP address ************
Signal strength -65dBm, channel 6, mode 802.11n, reconnections 0
Clock register 00002002
Socket states: 0 0 0 0 0 0 0 0

dc42

@CaiJonas the SZP doesn't work with 3.5.4.

CaiJonas

@dc42 ok, then I can't roll back, sorry

dc42

@CaiJonas the stuttering movements appear to be a feature of the moves generated. They are not arc moves, they are a sequence of line segments. Here's an example from line 2270 of your example file:

G1 X60.133 Y46.575 E.6074 ; perimeter
G1 E-.5 F3000 ; retract
G1 X60.509 Y46.911 F18000
G1 X75.371 Y60.871 ; move to first infill point
G1 X75.561 Y61.029 ; move to first infill point
G1 X75.728 Y61.145 ; move to first infill point
G1 X79.425 Y63.53 ; move to first infill point
G1 X79.396 Y63.585 ; move to first infill point
G1 X78.911 Y63.328 ; move to first infill point
G1 E.5 F3000 ;  ; unretract
;TYPE:Internal solid infill
;WIDTH:0.420424
G1 F12000
M106 S81 ; enable fan
G1 X77.989 Y64.25 E.0389 ; infill

The commanded speed is F18000 but RRF can't maintain that speed at the boundaries between moves because the direction changes between the moves would cause the jerk limit to be exceeded. So RRF reduces the speed at the boundary to a value that doesn't cause the jerk limit to be exceeded.

It's possible that you are getting movement queue underruns, which would contribute to the jerky movement. The M122 report you published doesn't show any, but perhaps you didn't run M122 after a print.

If you are getting layer shifts then it's likely that you have the maximum speed or acceleration or jerk set higher than the motor can handle at the current you are using. You can try increasing XY motor currents, if the motor rated current allows. This won't help if the speed is high enough for the torque to start reducing. You can use the calculator at https://www.reprapfirmware.org/emf.html to estimate that speed.

CaiJonas

@dc42

mhh I'm not shure if this is the root cause.

I played a little and tried the following without any problems:

same .stl file
increased print and travel speed to 300mm/s
activated avoid crossing perimeter
print speed is not limited by extrusion rate to guarantee 300 mm/s

m122 after print:

m122
=== Diagnostics ===
RepRapFirmware for Duet 3 Mini 5+ version 3.6.0-rc.2 (2025-03-31 12:16:33) running on Duet 3 Mini5plus WiFi (standalone mode)
Board ID: 8S6FD-V096U-D65J0-40KM0-4V03Z-RNJHW
Used output buffers: 2 of 40 (25 max)
=== RTOS ===
Static ram: 94764
Dynamic ram: 95644 of which 0 recycled
Never used RAM 40308, free system stack 130 words
Tasks: NETWORK(2,nWait 7,17.1%,191) LASER(5,nWait 7,0.2%,169) HEAT(3,nWait 6,0.1%,329) Move(4,nWait 6,2.5%,249) TMC(4,nWait 6,1.0%,65) CanReceiv(6,nWait 1,0.0%,771) CanSender(5,nWait 7,0.0%,336) CanClock(7,delaying,0.0%,348) MAIN(1,running,77.9%,661) IDLE(0,ready,0.3%,29) USBD(3,blocked,0.0%,147) AIN(4,delaying,0.9%,255), total 100.0%
Owned mutexes:
=== Platform ===
Last reset 00:21:19 ago, cause: software
Last software reset at 2025-04-23 09:37, reason: User, Gcodes spinning, available RAM 39248, slot 2
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x00000000 BFAR 0xe000ed38 SP 0x00000000 Task MAIN Freestk 0 n/a
=== Storage ===
Free file entries: 20
SD card 0 detected, interface speed: 22.5MBytes/sec
SD card longest read time 12.1ms, write time 49.4ms, max retries 0
=== Move ===
Segments created 448, maxWait 46510ms, bed comp in use: mesh, height map offset 0.000, hiccups added 131/0 (0.00/0.00ms), max steps late 1, ebfmin 0.00, ebfmax 0.00
Pos req/act/dcf: 0.00/0/0.00 0.00/0/0.00 54466.00/54466/0.00
No step interrupt scheduled
Driver 0: standstill, SG min 0, r/w errs 0/1, ifcnt 68, reads/writes 1424/16, timeouts 0, DMA errs 0, CC errs 0
Driver 1: standstill, SG min 0, r/w errs 0/1, ifcnt 158, reads/writes 1402/38, timeouts 0, DMA errs 0, CC errs 0
Driver 2: standstill, SG min 0, r/w errs 0/1, ifcnt 157, reads/writes 1400/39, timeouts 0, DMA errs 0, CC errs 0
Driver 3: standstill, SG min 0, r/w errs 0/1, ifcnt 68, reads/writes 1423/16, timeouts 0, DMA errs 0, CC errs 0
Driver 4: standstill, SG min 0, r/w errs 0/1, ifcnt 68, reads/writes 1424/16, timeouts 0, DMA errs 0, CC errs 0
Driver 5: not present
Driver 6: not present
=== DDARing 0 ===
Scheduled moves 86854, completed 86854, LaErrors 0, Underruns [0, 0, 0]
Segments left 0, axes/extruders owned 0x00000803, drives owned 0x00000803
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 0 -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
=== CAN ===
Messages queued 11374, received 10435, lost 0, ignored 0, errs 1, boc 0
Longest wait 3ms for reply type 6061, peak Tx sync delay 460, free buffers 26 (min 25), ts 6066/6065/0
Tx timeouts 0,0,0,0,0,0
=== Network ===
Slowest loop: 111.43ms; 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.39, flash size 2097152, free heap 37532
MAC address XXXXXXXXXX
IP address 192.168.X[adapter (1).gcode](/assets/uploads/files/1745395364873-adapter-1.gcode) .XXX
Signal strength -55dBm, channel 6, mode 802.11n, reconnections 0
Clock register 00002002
Socket states: 0 0 0 0 0 0 0 0

config file:

; Configuration file for Duet 3 Mini 5+ (firmware version 3.3)
; executed by the firmware on start-up
;
; generated by RepRapFirmware Configuration Tool v3.3.10 on Wed Jan 12 2022 22:48:14 GMT+0100 (Mitteleurop ische Normalzeit)

; General preferences
G4 S2																	; wait for expansion boards to start
M575 P1 S1 B57600														; enable support for PanelDue
G90																		; send absolute coordinates...
M83																		; ...but relative extruder moves
M550 P"COREXY"															; set printer name
M669 K1																	; select CoreXY mode

; Network
M552 S1		P"XXXXXXXXXXXXXXXX"										; enable network
M586 P0 S1																; enable HTTP

; Drives
M569	P0.0 S0	D2		 			 								    ; physical drive 0.0 goes forwards
M569	P0.1 S1	D2		 							    				; physical drive 0.1 goes forwards
M569	P0.2 S1	D2				    									; physical drive 0.2 goes forwards
M569	P0.3 S0	D2 		 							    				; physical drive 0.3 goes forwards
M569	P0.4 S1	D2 		 					        					; physical drive 0.3 goes forwards
M584	X0.1	Y0.2	Z0.3:0.4	E0.0								; set drive mapping
M350 	X16 	Y16 	Z16 		E16 	I1							; configure microstepping with interpolation
M92		X200	Y200	Z480		E562								; set steps per Z3200 E591
M201 	X6000	Y6000	Z900		E6000								; Set print accelerations (mm/s^2) Z1200
M201.1	X600	Y600	Z120		E6000								; Set accelerations for special moves (mm/s^2)
M204	P6000	T6000													;
M203 	X18000	Y18000	Z12000		E3000								; Set maximum speeds (mm/min) Z1200
M566	X900	Y900	Z900		E600	P1							; set maximum instantaneous speed changes (mm/min)
M906 	X900	Y900	Z1000		E800	I15							; set motor currents (mA) and motor idle factor in per cent
M84		S60																; Set idle timeout

; Axis Limits
M208 X0 Y0 Z0 S1														; set axis minima
M208 X120 Y120 Z113.5	 S0												; set axis maxima
		
; Endstops
M574 X1 S4																; configure sensorless endstop for low end on X
M574 Y1 S4																; configure sensorless endstop for low end on Y
M574 Z2 S1 P"io4.in"													; configure switch-type (e.g. microswitch) endstop for low end on Z via pin io0.in M574 Z1 S1 P"io4.in"
M915 X	Y	S8	R0	F0	H400											; Sensorless homing

; Scanning Z probe
M558 K0 P11 C"120.i2c.ldc1612" F12000 T12000							; configure SZP as probe 1, type 11, on CAN address 120
M308 A"SZP coil" S10 Y"thermistor" P"120.temp0"							; thermistor on SZP coil
G31 K0 Z2 Y15.5				       										; define probe 1 offsets and trigger height
M558.2 K0 S15 R135000													; set drive current and reading offset	18, offset is 139427
M557 X20:100 Y20:100 S10												; Define mesh grid for probe 1 (overwrites probe 0 mesh grid)

; Sensors
M308 S0 P"temp0" Y"thermistor" A"Heated Bed" T100000 B4725 C7.06e-8		; configure sensor #0
M308 S1 P"temp1" Y"thermistor" A"Nozzle" T100000 B4388 C7.06e-8			; configure sensor #1

; Heaters
M950 H0 C"out0" T0														; create bed heater output on out0 and map it to sensor 0
M143 H0 P0 T0 C0 S115 A0												; configure heater monitor #0 for heater #0
M307 H0 R1.086 K0.828:0.000 D3.71 E1.35 S1.00 B0						; disable bang-bang mode for the bed heater and set PWM limit
M950 H1 C"out2" T1														; create nozzle heater output on out1 and map it to sensor 1
M143 H1 P0 T1 C0 S285 A0												; configure heater monitor #0 for heater #1
M307 H1 R3.289 K0.416:0.048 D4.18 E1.35 S1.00 B0 V24.2					; configure model of heater #1

; Heated beds
M140 P0 H0																; configure heated bed #0

; Fans
M950 F0 C"out5" Q500													; create fan 0 on pin out3 and set its frequency
M106 P0 S0 H-1															; set fan 0 value. Thermostatic control is turned off
M950 F1 C"out1" Q500													; create fan 1 on pin out4 and set its frequency
M106 P1 S1 H1 T45														; set fan 1 value. Thermostatic control is turned on
M950 F2 C"out6" Q500													; create fan 2 on pin out3 and set its frequency
M106 P2 S0 H1 T45														; set fan 2 value. Thermostatic control is turned off
M950 F3 C"!out4+out4.tach" Q25000										; create fan 3 on pin out4 and set its frequency												
M106 P3 S1 X0.45 H1 T50													; set fan 3 value. Thermostatic control is turned off
	
; Tools
M563 P0 D0 H1 F0														; define tool 0
G10 P0 X0 Y0 Z0															; set tool 0 axis offsets
G10 P0 R0 S0															; set initial tool 0 active and standby temperatures to 0C

; Accelerometer
M955 P120.0 I24															; Add accelerometer on SZP with CAN address 120 and specify orientation

; Custom settings are not defined
M501																	;

print file
adapter (1).gcode

Are you sure it's related to max speed?

Best Regards
Cai

CaiJonas

@CaiJonas @dc42

I have to apologize, I'm wrong. I printed another part with exact same settings and there the layershift occurs again.

Is there a proper way to define the max speed with defined jerk an acceleration settings?

Best Regards
Cai

dc42

@CaiJonas please use the calculator at https://www.reprapfirmware.org/emf.html to check whether there is likely to be a significant reduction in torque at 300mm/sec speed. You could also try re-running the print with lower M566 X and Y values, e.g. 600 or 450.

CaiJonas

@dc42

when I reduce the m566 values for x and y I have some kind of stuttering/not smooth arc printing with artefacts on the surface.

may I raise here a related question. Is it better to have lower jerk settings and higher acceleration values or the other way around?

What I do not understand, if I run a simple script for diffegt G1 moves in different directions I can go up to over 500mm/s without any visible or noticeable loss of steps. but during a real printjob I have these layer shift with activated avoiding perimeter setting

Phaedrux

@CaiJonas said in Bug on 3.6.0? Layershifts & stuttering on arc travel moves:

I have these layer shift with activated avoiding perimeter setting

M566 X900 Y900 Z900 E600 P1

Do you get different behaviour if you set M566 P0?

CaiJonas

@Phaedrux With jerk policy 0 there was no layershift on the spicific print job. But to confirm I have to test more.

Currently I'm playing around with acceleration and print speed.

I'm surprised by the speed I can print:

M201 	X9000	Y9000	Z900		E6000								; Set print accelerations (mm/s^2) Z1200
M204	P9000	T9000													;
M203 	X30000	Y30000	Z12000		E3000								; Set maximum speeds
M566	X900	Y900	Z900		E900	P1							; set maximum instantaneous speed changes (mm/min)
M906 	X900	Y900	Z1000		E800	I15							; set motor currents (mA) and motor idle factor in per cent

all possible with not activated avoid crossing perimeter setting.

I still don't know what is going on

Phaedrux

@CaiJonas said in Bug on 3.6.0? Layershifts & stuttering on arc travel moves:

avoid crossing perimeter setting

It's been a long time since I've used that setting in Cura. I do recall that the travel paths were not straight and ended up being quite jerky. From your gcode sample that I viewed in the Prusa slicer gcode viewer it seemed like the travels were straight. Can you confirm?

CaiJonas

@Phaedrux

not all travelmoves are straight, some are arcs around the open parts.

I tested yesterday with Simplify3D, there I do not have layer shifts. Maybe the problem is slicer related and not firmware related

droftarts

@CaiJonas said in Bug on 3.6.0? Layershifts & stuttering on arc travel moves:

Is it better to have lower jerk settings and higher acceleration values or the other way around?

It used to be higher jerk and lower acceleration, but with the advent of input shaping, where the firmware can control the ringing better through the acceleration phase, low jerk and high acceleration is preferred. But it depends on the motion system components and frame design as to what works best.

In your last M122 it reports some hiccups and a late step:

=== Move ===
Segments created 448, maxWait 46510ms, bed comp in use: mesh, height map offset 0.000, hiccups added 131/0 (0.00/0.00ms), max steps late 1, ebfmin 0.00, ebfmax 0.00

I think it's the hiccups and late steps that causes the stutter, as @dc42 suggested. While this file didn't cause a layer shift, it's possible you get more stutters in other situations, enough to cause a layer shift. Hiccups and late steps are caused by a movement queue underrun, usually caused by a large number of very fast, very short moves, whose processing time means they don't get to the movement queue in time, or that the movement queue is too short and doesn't have time to refill before the next command.

I had a look at the two gcode files you posted; the first one (adapter.gcode) has no G2/G3 arcs in it, and while the second one (adapter (1).gcode) does, they are all have an extrusion (E) component to the command, so no travel moves are using arcs. So I think the travel moves are using very short, very fast, straight line moves around the holes, that may just be overwhelming the movement queue. Eg, from the first file, this is the travel move just as it's going around a hole:

You can see the speed set (F18000) and the number of very short moves.

I think you have a couple of options:

reduce the travel speed, so the firmware has enough time to process the commands
increase the length of the travel move line segments so there are less of them, if that's possible in the slicer. It might be this is what Simplify3D does.
increase the movement queue length until the hiccups go away. See https://docs.duet3d.com/User_manual/Reference/Gcodes#m595-set-movement-queue-length, try M595 P60 (default is P40).

The M122 also reports that you're using mesh bed compensation. Long travel moves can trigger a stall as it waits for the Z axis to move if the mesh requires a large change in Z. However, your Z jerk and acceleration seem pretty high, and the issue doesn't seem to be on the long travel moves (of which there aren't many) so I don't think this is causing the stutter.

Ian

CaiJonas

@droftarts said in Bug on 3.6.0? Layershifts & stuttering on arc travel moves:

hiccups

Thank you very much for the input and suggestions.

hiccups is excactly what it sounds like

I started witht he investigation from the beginning:

; Drives
M569	P0.0 S0	D2		 			 								    ; physical drive 0.0 goes forwards
M569	P0.1 S1	D2		 							    				; physical drive 0.1 goes forwards
M569	P0.2 S1	D2				    									; physical drive 0.2 goes forwards
M569	P0.3 S0	D2 		 							    				; physical drive 0.3 goes forwards
M569	P0.4 S1	D2 		 					        					; physical drive 0.3 goes forwards
M584	X0.1	Y0.2	Z0.3:0.4	E0.0								; set drive mapping
M350 	X16 	Y16 	Z16 		E16 	I1							; configure microstepping with interpolation
M92		X200	Y200	Z480		E562								; set steps per Z3200 E591
M201 	X9000	Y9000	Z900		E6000								; Set print accelerations (mm/s^2) Z1200
M201.1	X600	Y600	Z120		E6000								; Set accelerations for special moves (mm/s^2)
M204	P9000	T9000													;
M203 	X30000	Y30000	Z12000		E3000								; Set maximum speeds (mm/min) Z1200
M566	X900	Y900	Z900		E900	P1							; set maximum instantaneous speed changes (mm/min)
M906 	X900	Y900	Z900		E800	I15							; set motor currents (mA) and motor idle factor in per cent
M84		S60																; Set idle timeout

2025-04-25 13_25_42-RepRapFirmware.org.png

I use these steppers:

moons MS14HA5P4200

It is a super stiff frame and corexy kinematics. same size as Voron 0 but I designed it by myself with 40mmx20mm/60mmx20mm profiles. Maybe a little overengineered

Z axis is moved by two steppers of the same type with belts, no lead screw. This is why I think I can run Z axis with these high jerk and acceleration settings

I changed one other setting in the slicer --> resolution down to 0,025. This should result in shorter segments? I don't know.

the following gcode prints without any issue. "avoide crossing perimeter" is deactivated

adapter_no avoid perimeter setting.gcode

no avoid crossing.png

=== Move ===
Segments created 500, maxWait 352631ms, bed comp in use: mesh, height map offset 0.000, hiccups added 0/0 (0.00/0.00ms), max steps late 1, ebfmin 0.00, ebfmax 0.00
Pos req/act/dcf: 0.00/0/0.00 0.00/0/0.00 54459.00/54459/0.00
No step interrupt scheduled

and also the same part with activated "avoid crossing perimeter" runs now fine without any visible issues, but some hiccups

adapter_activated avoid crossing perimeter setting.gcode

avoid crossing.png

=== Move ===
Segments created 500, maxWait 2710474ms, bed comp in use: mesh, height map offset 0.000, hiccups added 199/0 (0.00/0.00ms), max steps late 1, ebfmin 0.00, ebfmax 0.00
Pos req/act/dcf: 0.00/0/0.00 0.00/0/0.00 54459.00/54459/0.00
No step interrupt scheduled

same gcode but with M595 P60

=== Move ===
Segments created 534, maxWait 190260ms, bed comp in use: mesh, height map offset 0.000, hiccups added 5/0 (0.00/0.00ms), max steps late 1, ebfmin 0.00, ebfmax 0.00
Pos req/act/dcf: 0.00/0/0.00 0.00/0/0.00 54453.00/54453/0.00
No step interrupt scheduled

samer gcode but with M595 P80

=== Move ===
Segments created 534, maxWait 200361ms, bed comp in use: mesh, height map offset 0.000, hiccups added 0/0 (0.00/0.00ms), max steps late 1, ebfmin 0.00, ebfmax 0.00
Pos req/act/dcf: 0.00/0/0.00 0.00/0/0.00 54450.00/54450/0.00
No step interrupt scheduled

So far I think the whole topic is much more clearer for me.

Thank you all very much.

Best regards
Cai

droftarts

@CaiJonas said in Bug on 3.6.0? Layershifts & stuttering on arc travel moves:

I changed one other setting in the slicer --> resolution down to 0,025. This should result in shorter segments? I don't know.

Yes, I'd think that creates smaller segments. If you can get it to create arc moves for the travel moves, that would probably help.

The M122 reports still say max steps late 1, but that might be a limit rather than the number of late steps. I'll check with @dc42.

For the M595 P parameter, it takes up extra memory as you increase it. If you increase it too much, you'll get a memory warning. You can check how much free RAM you have in the M122 report. Adding more to your config will increase the memory usage, too.

Ian

CaiJonas

@droftarts

what could affect the "max steps late 1" ?

I made some further testing and had print without max steps late 1. m1122 show max step late 0.

Much more interesting is the effect of the used slicer and the stl file resolution.

I can print with the following settings without having layer shifts:

M201 	X18000	Y18000	Z900		E18000								; Set print accelerations (mm/s^2) Z1200
M201.1	X900	Y900	Z120		E18000								; Set accelerations for special moves (mm/s^2)
M204	P18000	T18000													;
M203 	X30000	Y30000	Z12000		E3000								; Set maximum speeds (mm/min) Z1200
M566	X900	Y900	Z900		E1200	P1							; set maximum instantaneous speed changes (mm/min)
M906 	X900	Y900	Z900		E800	I15							; set motor currents (mA) and motor idle factor in per cent

I currently assume that my printer is suitable for these high acceleration and speed settings - at least on the hardware side.

What is realy surprising to me is that simplify3d is still the best slicer to have the smoothest movements and surface quality, even if it is on other things outdated.

Is there any option to manipulate the segmentation of duet3d firmware? As I understood the firmware itself generates short segmets out of g2/g3 code?

Best Regards
Cai