travel_speed rather than machine_max_feedrate_z is used to set Z axis feedrate

[martinbudden]

The Z axis feed rate is set to the value travel_speed rather than the value machine_max_feedrate_z which means that when high travel speeds are used, high feed rates are also used for the Z axis. This can result in increased Z-banding, and in the extreme case, the Z motor can skip steps.

Version

PrusaSlicer Version 2.3.0+win64

Operating system type + version

Windows 10 Home Version21H1

3D printer brand / version + firmware version (if known)

Homemade CoreXY running Marlin 2.0.7.2

Behavior

Here's the layer change code

;LAYER_CHANGE
;Z:0.25
;HEIGHT:0.25
G1 Z0.250 F7800.000

as you can see, the feed rate is 7800 mm/s, that is 130 mm/minute.

The relevant settings in the gcode are:

; machine_max_feedrate_z = 12,12
; travel_speed = 130

This is important for two reasons.

1. In the extreme case this can cause the Z motor to skip, indeed this is how I discovered this. I've just build a CoreXY printer
   and was experimenting with increasing travel speed. At some point my Z motor started skipping. As you can imagine, this was a little difficult to track down, but it turned out to be because the feed rate for the Z axis was too high for the Z motor.

2. In the more common case, high feed rates for the Z axis cause Z-banding (aka Z-wobble).

It's quite difficult to photograph to show Z-banding, but I think it can be seen in the two photos below (it is quite obvious to the naked eye).

The only difference between the two prints is the travel speed. In the first, the default travel speed of 130 mm/s is used. The Z-banding is quite severe.

In the second print, I changed the travel speed to 30 mm/s, the Z-banding is much reduced.

The travel_speed should not effect the Z-axis movement - this problem can be rectified by using machine_max_feedrate_z for setting the feedrate for Z movements.

Update: I've just checked the source, https://github.com/prusa3d/PrusaSlicer/blob/master/src/libslic3r/GCodeWriter.cpp#L367-L377 , indeed config.travel_speed.value is used to set the Z feedrate.

std::string GCodeWriter::_travel_to_z(double z, const std::string &comment)
{
    m_pos(2) = z;
    
    std::ostringstream gcode;
    gcode << "G1 Z" << XYZF_NUM(z)
          <<   " F" << XYZF_NUM(this->config.travel_speed.value * 60.0);
    COMMENT(comment);
    gcode << "\n";
    return gcode.str();
}

[rtyr]

Intended behavior, travel speed is indeed used for z travels as well. Actual Z feedrate is limited by printer's firmware, no matter what feedrate is exported to the gcode.

Machine limits are currently available only for Marlin gcode flavor and it's main purpose is to provide precise time estimates.

There is already feature request related to this #2945 (independent setting for z travel). I think such setting shouldn't be needed for most of the printers with properly configured firmware. Correctly assembled and configured printer should be able to reliably operate within the limits set in it's firmware.

That being said, it would likely make sense to set lower than max z-lift/z-hop speed for some printer types (like corexy with heavy bed).

I am closing this as a duplicate of #2945. This issue will be linked.

[martinbudden]

Intended behavior, travel speed is indeed used for z travels as well.

Well that seems a bit mad to me. Setting a Z feedrate to a value that you know the printer cannot handle. And also Z movement is not really "travel".

Actual Z feedrate is limited by printer's firmware, no matter what feedrate is exported to the gcode.

Except that it isn't. If it was I wouldn't have got the Z skipping and the Z banding that I did. And it seems it is not just me - in #2945 several people report either print quality issues or Z motor skipping.

For reference, my feedrates are set at:

M203 X500 Y500 Z12 E120 ; sets maximum feedrates, mm/sec

[rtyr]

12mm/s may be too high value for your printer.

You can simply test it by sending M203 Z1, then G1 Zxxx Fxxxx through terminal.

[martinbudden]

My printer seems to work fine with Z travel of 30mm/s, as my photo above shows. It does seem that Marlin is not honouring the M203 command - other have reported this. Also, not all printer firmware supports M203.

Anyway, I've made a PR to address the issue see #6369 , I'd appreciate it if you review the PR.

[rtyr]

OK, thanks.