Jerky movement when printing with G17/G18/G19 in the file
-
@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.
