Jerking when having queued commands on different axis

[SimosMCmuffin]

I recently built my first cnc router and I have it set up nicely and I have done a lot of 2d .dxf CAM to Gcode drawings already but I noticed some weird jerkiness in it's operation.

This is particularly easy to spot with the ball-point pen attached to Z axis (modded with suspended head), it slowly descends during active running, specifically every time the Z axis needs to move up. The cause is that when the Z axis pulls up to move the pen to a new position, it jerks to a stop at the end and doesn't decelerate smoothly, so it misses a couple of steps and in the long job these missed steps start to accumulate to a noticeable amount. The result can be observed as the pen is pressed much harder and deeper onto the paper at the end of a long job.

The firmware let's you set acceleration limits for each axis and I have confirmed them to work with single G0 and G1 commands for each axis. The jerking manifests itself when you have X or Y and Z axis move commands queued up. I'm guessing it has something to do with the G17 XY-plane command.

For example with G0 commands: (these examples assume starting coordinates X0 Y0 Z0) No jerking will be apparent when running a single move command on multiple axis. G0 X100 Y100 Z50 //smooth acceleration at start and deceleration at end

No jerking will also happen when running two consecutive commands on the same axis before the first line finishes. G0 Z50 //starts movement as normal and entered the second line during movement G0 Z0 //decelerates normally and starts the second command normally

Jerking manifests when you have two consecutive commands one being on the X or Y and the other being on the Z axis. G0 Z50 //start movement normally and entered the second line during movement G0 X100 //The Z axis start to slow down at the end but doesn't completely decelerate before jerking to a halt, at which point the X axis starts it's movement

EDIT: After running some tests I can tell that the jerking happens always when it's queued Z axis movement before X or Y axis movement.

[LETARTARE]

Hello, Which version Grbl are you using ? how do you send your g-code to Grbl ? Regards

[SimosMCmuffin]

I'm using 0.9f on Arduino Uno and below I have pasted my firmware settings: Grbl 0.9f ['$' for help]

$$ $0=5.000 (x, step/mm) $1=5.000 (y, step/mm) $2=100.000 (z, step/mm) $3=10000.000 (x max rate, mm/min) $4=10000.000 (y max rate, mm/min) $5=400.000 (z max rate, mm/min) $6=100.000 (x accel, mm/sec^2) $7=100.000 (y accel, mm/sec^2) $8=5.000 (z accel, mm/sec^2) $9=200.000 (x max travel, mm) $10=200.000 (y max travel, mm) $11=200.000 (z max travel, mm) $12=10 (step pulse, usec) $13=0 (step port invert mask:00000000) $14=0 (dir port invert mask:00000000) $15=25 (step idle delay, msec) $16=0.100 (junction deviation, mm) $17=0.010 (arc tolerance, mm) $19=0 (report inches, bool) $20=1 (auto start, bool) $21=0 (invert step enable, bool) $22=0 (invert limit pins, bool) $23=0 (soft limits, bool) $24=0 (hard limits, bool) $25=0 (homing cycle, bool) $26=0 (homing dir invert mask:00000000) $27=25.000 (homing feed, mm/min) $28=500.000 (homing seek, mm/min) $29=250 (homing debounce, msec) $30=1.000 (homing pull-off, mm)

I have tried GRBL Controller (3.6.1) and Universal Gcode Sender (1.0.7) and I'm able to replicate the problem. I also during my searches on google, I discovered a discussion about this and they spoke how the acceleration ramps were being cut prematurely. I'll edit the Link to this post when I find it.

EDIT 1: Also this problem was present in the 0.9e firmware and that's why I updated to the 0.9f EDIT 2: Before mentioned discussion was about Teacup. I can provide video example of the problem if wanted and needed.

[SimosMCmuffin]

I tried to flash back to 0.9d and test if it had the problem, but even though Arduino IDE reported no problem in uploading the sketch, the board still replies back with 0.9f when opening serial communication. Weird thing is that it doesn't seem to jerk the Z axis anymore, but I'll run couple test jobs and report back.

Here are my current settings with 0.9d firmware, but it reports back with the 0.9f (eeprom clearing or start block editing needed?):

Grbl 0.9f ['$' for help]

$$ $0=5.000 (x, step/mm) $1=5.000 (y, step/mm) $2=100.000 (z, step/mm) $3=10000.000 (x max rate, mm/min) $4=10000.000 (y max rate, mm/min) $5=200.000 (z max rate, mm/min) $6=100.000 (x accel, mm/sec^2) $7=100.000 (y accel, mm/sec^2) $8=5.000 (z accel, mm/sec^2) $9=200.000 (x max travel, mm) $10=200.000 (y max travel, mm) $11=200.000 (z max travel, mm) $12=10 (step pulse, usec) $13=0 (step port invert mask:00000000) $14=0 (dir port invert mask:00000000) $15=25 (step idle delay, msec) $16=0.020 (junction deviation, mm) $17=0.002 (arc tolerance, mm) $19=0 (report inches, bool) $20=1 (auto start, bool) $21=0 (invert step enable, bool) $22=0 (invert limit pins, bool) $23=0 (soft limits, bool) $24=0 (hard limits, bool) $25=0 (homing cycle, bool) $26=0 (homing dir invert mask:00000000) $27=25.000 (homing feed, mm/min) $28=500.000 (homing seek, mm/min) $29=250 (homing debounce, msec) $30=1.000 (homing pull-off, mm)

[LETARTARE]

Hi, I do not maintain OFFICIAL VERSIONS, only unofficial versions (readme.md) View Grbl website: https://github.com/grbl/grbl Best regards