Z skipping steps- How to Slow Down Z Axis?

[LordFrz]

I am having some trouble with my z-axis skipping steps when it moves too fast.
When I have it configured to move 0.5mm when told to go 1mm it works just fine.
But when I increase it to 1:1 ratio it moves much to fast and misses steps.

Currently I have lowered my acceleration to 5, and this makes anything less than 5-6mm
at a time functional. But it does slow my x, and y which where working just fine.

Is there a way to set a max speed for only my z axis or atleast only lower my z axiss' acceleration?

Here are my current grbl settings

Grbl 0.8c
-------------
$0=150.077 (x, step/mm)
$1=150.077 (y, step/mm)
$2=666.666 (z, step/mm) [This seriously gives my 1:1 with my setup]
$3=30 (step pulse, usec)
$4=250.000 (default feed, mm/min)
$5=500.000 (default seek, mm/min)
$6=0 (step port invert mask, int:00000000)
$7=45 (step idle delay, msec)
$8=5.000 (acceleration, mm/sec^2)
$9=0.025 (junction deviation, mm)
$10=0.100 (arc, mm/segment)
$11=25 (n-arc correction, int)
$12=3 (n-decimals, int)
$13=0 (report inches, bool)
$14=1 (auto start, bool)
$15=0 (invert step enable, bool)
$16=0 (hard limits, bool)
$17=0 (homing cycle, bool)
$18=0 (homing dir invert mask, int:00000000)
$19=25.000 (homing feed, mm/min)
$20=250.000 (homing seek, mm/min)
$21=100 (homing debounce, msec)
$22=1.000 (homing pull-off, mm)

Thanks in advance for any ideas on what may be the issue.

[cvoinescu]

This is a known limitation of GRBL 0.8 and earlier. There are several things you could do, none of them ideal:

1. You can use a version of GRBL that supports different speed and acceleration settings for each axis, such as the upcoming GRBL 0.9. However, last I checked that version was is still in development, so it may not work perfectly yet.

2. You can use different firmware, such as Marlin or TinyG. Unfortunately, no other firmware runs on the Arduino Uno. Marlin requires an Arduino Mega 2560 and is not compatible with grblShield or the buildlog.net stepper shield without some hacking; and TinyG requires the TinyG board, which has a bigger and faster CPU than the Arduinos, so it won't run on one no matter what.

3. You can refrain from using G0 "traverse" and always use G1 "feed" moves when the Z is involved, because G1 obeys the F parameter, so you can limit the speed. You'll have to configure your CAM, post-processor and/or g-code sender to do that. The acceleration limit is still shared between all axes, which is a bummer.

[LordFrz]

Alright, I appropriated the help. Ill look into those options, even if its not the best fix
as long as im able to get the job done its fine. I just ran my first successful run
of photovcarve so i think I can make this setup run.

I'll look into grbl 0.9

Thanks a bunch

[WillAdams]

Wouldn't using an Acme screw be another option?

(still waiting on mine to arrive)

[cvoinescu]

Forgot about the Acme screw, thanks Will.

4. Use an Acme screw on the Z axis. While this does not circumvent the limitation of the firmware, it allows the Z to move about twice as fast, so the limitation is less annoying. Even after you get a firmware/controller with separate axis configuration, the Acme screw is a great upgrade to have.

[WillAdams]

Thank you! Wikified!

[WillAdams]

It's notable that at least one Communication / Control program has an option to limit the Z-Axis --- Zapmaker's Grbl Controller:

http://zapmaker.org/projects/grbl-contr ... r-options/

Z-Rate Limiting

When sending a file, if Z-Rate Limiting is enabled, any commands in the file for the Z axis are assigned a feed rate (or the rate is modified). The assignment occurs at runtime; the actual file is not affected.

Z-Rate Limit

If Z-Rate limiting is enabled, this value modifies any Z axis command from the file if the file’s Z rate is greater than the limit. If no rate is specified, this rate will be assigned. If the Z-axis command is a G0, it is converted to a G1.