Jerky movement when printing with G17/G18/G19 in the file

[e4d]

Hello,

I have a problem with my printer. I try to do a multi-tool job on it (it's a tool changing machine). The file is alternating with two different tools. The first one is printing. The part contains a circular shape on one side. When printing the circular side the machine, it stops in multiple points, it's like a discretisation of the curve.

However when slicing the file using only one printing tool it works great. The only differences is that there are some G17/G18/G19 command in the first file and none on the second (you have the files linked). But for the first layers these commands are not used as you can see. I don't know then why it act like this.

The setup is :

• Duet 3 6HC + 3 3HC in SBC mode
• RRF 3.5-rc3 (i need some of the new features)

You can find a video of the problem happening here.
You can find here the first printing file.
You can find here the second printing file.

I really need to print this file as it is for business. Do you have a solution in mind ? Can it be a bug of the RC3 ?

I already thougt about the instantaneous speed change being too low but it's value is normal and I can have a good result using other conditions so I think it's not the problem.

;Parametres
M584 X0.0 Y0.1 Z0.3:0.5:0.2 E1.0:1.1:1.2:2.0:2.1:2.2:3.0:3.1 A0.4				; Apply custom drive mapping
M208 X-40.5:396 Y-32.8:370.0 A0:132.0 Z0:395 			    					; Set axis maxima & minima
M350 X16 Y16 Z16 A16 E16:16:16:16:16:16:16:16 I1								; Configure microstepping with interpolation
M566 X240 Y240 Z400 E1500:1500:1500:1500:1500:1500:1500:1500 A400	      		; Set maximum instantaneous speed changes (mm/min)
M203 X30000 Y30000 Z1000 E5000:5000:5000:5000:5000:5000:5000:5000 A2000   		; Set maximum speeds (mm/min)
M201 X4000 Y4000 Z500 E4000:4000:4000:4000:4000:4000:4000:4000 A500 		    ; Set accelerations (mm/s^2)
M906 X1800 Y1800 Z1200 A400 I30                         			    		; Idle motion motors to 30%
M906 E650:650:650:650:650:650:650:650 I10   							    	; Idle extruder motors to 10%
M92 X80 Y80 Z800 E400:400:400:400:400:400:400:400 A400   			    		; Set steps per mm assuming x16 microstepping
 

[droftarts]

@e4d Jerky movement on circles/arcs is usually related to jerk. Your XY jerk is set to 240mm/min, which is only 4mm/s, so I'd first try increasing that to see if it eliminates the problem. Was the problem not present in earlier firmwares? Can you post an M122 report? Can you try the latest rc3 bug fix firmware release: https://www.dropbox.com/scl/fo/yzchzlyxmxlzywjawqflu/h?rlkey=tl7dfs75yozhfgpze0jnkn32n&dl=0

Do you need G17/G18/G19 in your Gcode to change the plane? It looks like it prints in the XY plane only, so shouldn't be necessary. Or is it something the slicer puts in? If you do need to print arcs in the other planes, I would think stuttering will be an interaction between the low jerk on XY but higher jerk on Z (M566 X240 Y240 Z400) from your config), and low acceleration on Z (M201 X4000 Y4000 Z500 in your config.g).

Ian

[oliof]

@droftarts could also be due to low z jerk and mesh bed compensation

[Festivejelly]

After updating to 3.5.0-rc.2 from 3.4.something I also im getting these odd jerky movements. Never used to get them before.

[Festivejelly]

FYI for reference here are my settings. I dont think the Jerk is too low for me as it wasnt an issue before:

M350 X16 Y16 Z16 I1 ; Configure microstepping with interpolation
M566 X300 Y300 Z8 C2 E200:200:200:200 ; Set maximum instantaneous speed changes (mm/min)
M203 X35000 Y35000 Z600 C5000 E5000:5000:5000:5000 ; Set maximum speeds (mm/min)
M201 X4000 Y4000 Z100 C500 E4000:4000:4000:4000 ; Set accelerations (mm/s^2)

[gloomyandy]

@Festivejelly Your Z jerk is very low and could be causing problems if you are using a mesh.

[e4d]

@droftarts It was working correctly in earlier versions (3.5 betas). I rolled back in 3.4.6 to be able to continue printing and it worked great.

I try the zip you linked (3.5-rc3+4) and it worked too. I then put back standard rc3 and the problem reapered. The bug must be between rc1 and standard rc3. Is there already a changelog published ?

I tried the 3.5-rc3+4 on a standalone printer but I don't know how I can update it using the zip on a SBC setup ? I just upload the zip ? How will the DSF update ?

Thanks

[jay_s_uk]

@e4d for an SBC setup its probably best to wait for the next official release as you'll need the corresponding build of DSF to go with it.
the changelog for RRF since RC3 is here https://github.com/Duet3D/RepRapFirmware/wiki/Changelog-RRF-3.x-RC#changes-since-rc3
for DSF its here https://github.com/Duet3D/DuetSoftwareFramework/wiki/Changelog-DSF-3.x-RC#version-350-rc4-changes-since-350-rc3
and DWC is here https://github.com/Duet3D/DuetWebControl/wiki/Changelog-DWC-3.x-RC#version-350-rc4-changes-since-350-rc3

[Festivejelly]

@gloomyandy I cant see how the Z axis would be affecting this. Its the same config as ive always used and many others on the e3d tool changer. Besides even with bed level mesh behaviour is the same.

[gloomyandy]

@Festivejelly Z jerk can have an effect on X/Y movement because to implement mesh levelling X/Y moves are split into smaller segments to allow for the variation in Z provided by the mesh. If the Z jerk is not high enough then each of those moves becomes a stop/start movement. It may not make a difference for you but it is an easy thing to try increasing (I'm currently running the following jerk settings on my e3d toolchanger: M566 X500 Y500 Z50

[Festivejelly]

@gloomyandy I can see the thinking behind it, but I get the same issues even when disabling the mesh

[dc42]

@Festivejelly currently the G17/G18/G19 commands wait for all queued motion to stop before they are executed. So if they occur frequently in your file, that could cause the movement to be jerky. Your first file does have a G19 command just before each G2 or G3 command, so I think that explains it.

I think the reason why RRF waits for movement to stop before executing these commands is so that if power failure occurs, RRF is able to write a G17/18/19 command that is correct for the movement commands that will be executed if the job is resurrected. So I can't unconditionally remove that call to wait for motion to stop. However, I could remove that call in the case where the selected plane is not changed, which should help with your example.