Bug on 3.6.0? Layershifts & stuttering on arc travel moves

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

droftarts

@CaiJonas @dc42 has replied with the following regarding hiccups and late steps:

Re hiccups, in 3.5 and earlier the number displayed is the number of delays introduced by the board that is reporting during its generation of step interrupts. A hiccup is inserted when the ISR has been looping for more than a particular amount of time because additional step keep becoming due.
In 3.6 the main board M122 report shows two values. The first is hiccups introduced while preparing moves for execution. These should be rare. The second is hiccups generated in the step ISR as before.
In 3.6 two figures are also shown for total hiccup duration in milliseconds. The first is for hiccups introduced by the reporting board; the other is for hiccups introduced by other boards.

Regarding the "max steps late" figure, when RRF calculates when the next motor step is due, it checks that the calculated time is no later than the time at which the current move segment is supposed to be complete. Due to floating point rounding error, it sometimes happens that the calculated time is slightly later than the intended segment completed time. RRF generates any such steps at the intended segment completed time, and records how many steps it needed to generate to complete the segment. It's normally only the vary last step of the segment that is "late" in this way, so maxStepsLate is typically 1, although it may be 0 if there has not been much movement.

So it's the hiccup figure we need to keep an eye on, and 'max steps late 1' is generally okay.

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

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?

Yes, with M669 S and T parameter (see https://docs.duet3d.com/User_manual/Reference/Gcodes#m669-set-kinematics-type-and-kinematics-parameters). However, it can't make longer moves out of short segments, it can only split up long moves into shorter segments. Yes, the firmware generates short, straight segments from G2 and G3 arcs. The minimum arc segment length was reduced in RRF3.5.1 from 0.1mm to 0.02mm. I think it also scales with the radius of the arc.

Ian