Jerky movement when printing with G17/G18/G19 in the file
-
@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
Cartesian bed-slinger with Duet 3 Mini 5+ WiFi and 1LC : RRP Fisher Delta v1 with Duet 2 Maestro : TronXY X5S with Duet 3 MB6HC and Roto toolboard
-
@droftarts could also be due to low z jerk and mesh bed compensation
-
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.
-
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) -
@Festivejelly Your Z jerk is very low and could be causing problems if you are using a mesh.
-
@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
-
@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 -
@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.
-
@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
-
@gloomyandy I can see the thinking behind it, but I get the same issues even when disabling the mesh
-
@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.
