I’ve always been vaguely aware that z moves seemed to happen rather slowly on my Ultimaker, and this was especially true when I enabled Cura’s ‘Hop on moves’ feature – I would often get blobbing, and the moves seemed to introduce noticeable pauses into the printing process.

I made some enquiries in the forums and among other users about what z speed they use, and more generally what a good maximum z-speed is. Consensus was that probably 10, 20, 30 or more mm/s was quite sustainable as a z-speed – and yet the defaults in Marlin and Cura seemed very conservative – around 3 to 5 mm/s. My own testing showed that for large moves of the z-axis in non-printing scenarios, 60 mm/s was quite doable, and perfectly repeatable.

And yet… Z-moves during printing still seemed rather slow. For a 0.1 mm layer height change, at 30mm/s, simplistic math says that the layer change should take 1/300 of a second. But just looking at the printer, that wasn’t the case. A move that fast should look pretty much instantaneous to the naked eye. But while my z-moves were happening pretty quickly, I could just about track the movement with my eye.

In the course of all this, I started becoming familiar with the Marlin firmware, and indeed, found and fixed a bug that affected retraction speeds. In the course of all of this, I came to understand much better how Marlin manages the moves that it is asked to do, and particularly the role of acceleration in the motion planning module.

How Marlin Plans Moves

Every G1 (Move) instruction that Marlin processes is planned in the same way. The firmware identifies the requested speed for each axis involved in the move, and limits those if necessary to the configured maximum speeds for each axis. The speed graph for each axis is then calculated, to allow for acceleration, a constant velocity phase, and then a deceleration to a maximum allowable speed by the end of the move. This diagram from the Marlin source code shows the typical speed/time graph for a series of moves (‘blocks’ in Marlin-speak):

Marlin Planner Diagram

The firmware is configured with a standard acceleration rate which applies to all axes (except the E axis, during filament only moves, which has a separate rate). However, this desired rate is further limited by a maximum allowed acceleration for each axis. And the overall acceleration for the move is limited to the slowest acceleration allowed on any of the axes involved in the move. Once the acceleration rate for the move has been decided, then the plan for  each axis can be finalized.

The planner assumes that the axis starts at the whatever speed it is already moving. In the case of a normal layer-change z-move, this is going to be zero. And then it accelerates towards the nominal move speed (in this case the z-axis move speed specified in the slicer, or the firmware’s Z-max speed, whichever is lower).  At the end of the move, it then has to slow down again (not necessarily to zero – typically it is going to slow down to the Z-jerk speed configured in the firmware, and then come to an instantaneous stop from that speed).

But anyway, the point is that on a layer change, the z-axis has to accelerate from nothing, and then slow down again to almost nothing before the end of the move. And it has to do this within the constraints of the maximum speed and acceleration settings for the z-axis, and do it all within the time (and distance) of a single layer move.

Z-Axis Move Planning in Practice

And that is the big limiting factor with Z-moves: the distances are very small. A move of just 0.1 or 0.2mm doesn’t give much time or space to accelerate and slow down again. In fact, there isn’t anything like time to get up to speeds of 20 or 30 mm/s before stopping again. Rather than having a flat plateau of constant speed as shown above, a z-move is more of a triangle – it starts accelerating, and before it gets up to speed, it’s time to slow down again.

And this is compounded by the very slow default maximum acceleration rate for the z-axis of just 100 mm/s². When you apply that rate, even a maximum speed of 5mm/s is unattainable for typical layer height moves. In fact, as this table shows, applying the planner’s logic, layer moves end up happening at just 1.5 to 2.5 mm/s, and as a result, take much longer than you might otherwise expect – between 0.05 and 0.1 seconds:

Standard Speed Z Moves

Improving Z Speeds

Which rather begs the question: “So what can be done to speed up Z moves?”. And the most obvious answer would seem to be to raise the maximum acceleration rate and speed somewhat for the Z-axis. I’m not entirely sure why the defaults are so very low. In my testing, I found that while I could sustain a z-move at 60mm/s by itself, sometimes I got skipped steps and failed moves if I also moved the X & Y axes at the same time – particularly with very high acceleration rates on Z.  So far, I have settled on z-axis settings of 1500 mm/s² for maximum acceleration, and 30 mm/s for maximum speed.  This makes my z-moves about 4 times faster – which is enough to turn the quick chirp of a z move into a crisp click as the platform snaps to its new height:

Faster Z-Moves

 

Notice that even at these speeds, the actual peak move speed doesn’t make it even to 19 mm/s – and once the speeding-up and slowing-down is taken into account, the average speeds are under 10 mm/s. Still, this represents a good increase of the normal speeds, and should help to improve print quality (and reduce print times) – and especially make z-hop moves faster and more useable.

 

Tagged with →  

4 Responses to The Myth of Z-Speed

  1. andrey shur says:

    What you want to change is the jerk speed. This is the speed that Marlin will start at, before applying acceleration. The whole point of the jerk speed is to eliminate the “tiny triangle” effect that you think is happening during Z moves. Instead I believe it is just moving at the jerk speed.

  2. illuminarti says:

    I agree that increasing jerk might compensate for the effect as well to some degree, although I’m not clear how well the steppers can handle larger instantaneous speed changes. It seems that the defaults are over-cautious, for sure. However, in my tests, z-move failures typically happen right at the start of the move, it seems – so there is something about initial torque that seems to be a limiting factor. And the effect I am seeing isn’t just the jerk speed – the jerk speed is very low by default, and the move is a lot faster than that. Also, as noted above, increasing the acceleration and max z-speed while leaving the jerk unchanged significantly increases the move speed.

  3. Nick Foley says:

    Been using these settings for a while, but lately, I’ve been getting skipped Z steps during Cura’s initial “lower platform, then move to the starting position of the print” routine. This is extremely dangerous to the machine, since it is skipping steps during the “move down 10mm” portion, but then NOT skipping steps during the “move platform up 10mm” portion!!!

    This means that the machine drives the build platform 10mm or so INTO the hotend. It definitely bent some of my axes when doing so. Testing out lowering the acceleration settings to 1000 for the Z and seeing if it still happens….

    • illuminarti says:

      Yikes! Yeah you certainly don’t want to run into the hotend… but why isn’t your z=0 endstop preventing that from happening?

      In addition to changing the acceleration, you might also try changing the z-move speed in your start gcode; simply moving it more slowly might help the motor out. For reasons that I never entirely figured out, it always seems like I’m more likely to skip steps when moving in X,Y and Z axes all at once. The steppers should be constant current draw whether moving or not, so I don’t know why it would make a difference; I’m wondering it it is perhaps a timing issue in the firmware when there are multiple axis steppers to be managed at the same time.

Leave a Reply

Your email address will not be published. Required fields are marked *

%d bloggers like this: