Z axis incorrect movement

Hi guys, hope someone can help me with a problem I'm having with my Z axis movement.

I'm using printrboard with marlin, slic3r and pronterface, everything is set as it should be but the Z axis is not moving as far as it should between layers.

If I tell it to move manually with pronterface, it moves as it should, but in print it moves about 85% of what it should according to the slic3r Gcode.

X and Y are fine and I'm using the same motors and screws to move all axes, I'm tearing my hair out now cos I've tried everything I can think of to get this working accurately.

Regards, Steve

Obviously your MAX Z speed is set too high and you are loosing steps.
You can set a maximum speed (and acceleration in some cases) in your firmware.
I don't know if you can set the MAX Z speed in Slic3r, but you can in Skeinforge.

---

Bob Morrison
Wörth am Rhein, Germany
"Luke, use the source!"
BLOG - PHOTOS - Thingiverse

firmware settings are the same for all 3 axes

THIS IS WRONG!

Your Z-axis can not move nearly as fast as your X and Y axis!

---

Bob Morrison
Wörth am Rhein, Germany
"Luke, use the source!"
BLOG - PHOTOS - Thingiverse

I'm printing slowly and accurately, using the same motors and 2mm leadscrews on all 3 axes

x and y have been slowed to the same speed as the z until i try a higher lead on the x and y later.
1600 steps per mm, max feed 5 mm per second and I'm getting great prints, but vertically challenged

Further to the above info, the forecast sizes in pronterface are incorrect, with X and Y being over-estimated but Z being correct. Is this a problem with pronterface or slic3r?

poissonrouge Wrote:
-------------------------------------------------------
> Further to the above info, the forecast sizes in
> pronterface are incorrect, with X and Y being
> over-estimated but Z being correct. Is this a
> problem with pronterface or slic3r?


The X and Y sizes indicated in pronterface will include any perimeter loops or brim that slic3r is set to generate. Does that make up the difference?

-Rob A>

Thankyou Rob, yes, the numbers add up that way, so the problem is most likely in the firmware. I'm trying an increased number of steps on Z to see if that works to correct the error there, fingers crossed

Ok, Z axis steps didn't work.
So now I'm opening an STL file in Repetier, factoring the Z, saving the STL, then opening it in Pronterface for slicing and printing. This works for me but is not a long term solution.
For some reason Repetier doesn't look in the config file when slicing and still uses defaults.

Repetier like marlin uses the values in the EPROM if they exist, Marlin does the same thing.
In marlin you can reset the values, I don't know if there is a repetier equivalent.
Just edit the Z step value in repetier host, it'll overwrite the EPROM value.