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):
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:
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:
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.