Snapmaker 2.0 Printing Defects - Z Feed Rate too high - Skipping Z steps

[jalapenopuzzle]

Description of the bug

I have experienced several issues using PrusaSlicer 2.8.0 with Snapmaker 2.0 A350T.

1. First layer speed 50mm/s is too fast and has poor adhesion. I reduced it to 20mm/s and had much better results, but I did not tune this value.
2. First Layer Height 0.3mm seems to be too high. I had better results with 0.2mm.
3. I have had HUGE issues with missing Z steps while printing. PrusaSlicer produced the following benchy:
   
   This benchy is only 35mm high (should be 48mm high).
   I did a lot of testing with this one.
   The Snapmaker 2.0 uses linear actuators with different screw pitches per axis:
   https://shop.snapmaker.com/products/linear-module-with-tmc2209-a350t-f350
   The consequence of this is that the Z axis has a lower feed rate limit than the X and Y axes.
   Feed Rate Limits (reference: Snapmaker's Luban slicer v4.13.0):

• X+Y: Slow: 40mm/s Medium: 50mm/s Fast: 60mm/s
• Z: 10mm/s (F600) - (Reference: Luban generated G-Code)

PrusaSlicer generates G-Code with Z feed rate of F7200 (120mm/s). It appears that this is causing the Z axis to skip steps.
PrusaSlicer appears to have the following parameters affecting the z speed:

• Print Settings -> Speed -> Speed for non-print moves -> Travel (default: 120mm/s -> F7200)
• Print Settings -> Speed -> Speed for non-print moves -> Z travel (default: 0, causes "Travel" value to be used)

I found that setting 10mm/s for the Z travel speed had no effect. PrusaSlicer continues to generate G code with F7200 on Z movements.
The only way that I could reduce the Z speed was to reduce the Travel speed.

I performed some manual Z movement tests with increasing speeds such as:
G1 Z50 F1000
G1 Z150 F2000
I found that the speed (and stepper tone) did not seem to increase after about F3400 (56.7mm/s) (but I only tested in units of 100).

It appears that faster speeds are coming to the Snapmaker 2.0 with the vibration compensation firmware currently in beta testing https://forum.snapmaker.com/t/vibration-compensation-firmware-open-beta-for-2-0-series-a-at-f-models/35729. I mention this because they claim a speed increase, depending on which linear modules (20mm or 8mm lead) are installed, from 100mm/s (no VC) to 120mm/s (with VC). I don't think this applies to Z axis.

Project file & How to reproduce

20240921_3DBenchy_One_Colour_Z_Speed_10mm_s.zip
I sliced and exported the G-Code.
To save time I have been checking the G-Code using sed:
sed --quiet -e "s/^G1 .* Z(-?[.0-9]+).* F(-?[.0-9]+)/\2/p" file.gcode | sort -u
This prints the Z feed speeds used in the G-Code file.
I get:
F200
F7200
The F200 comes from the initial movements to approach the bed.
F7200 is used while printing, including for Z-hop movements.

Checklist of files included above

• Project file
• Screenshot

Version of PrusaSlicer

2.8.1

Operating system

Ubuntu 22.04

Printer model

Snapmaker 2.0 A350T with upgraded linear modules TMC2209

[rtyr]

3rd party profiles are usually provided/maintained by the community. The last Snapmaker bundle was provided by @macdylan. @macdylan do you have any comments regarding this issue (1st layer height/speed etc.)?

There is indeed a bug regarding some Z travel commands, we will look into that. That being said, max. Z travel speed is supposed to be primarily limited by the firmware. I would expect appropriate limits in official Snapmaker FW.

I am not familiar with Snapmaker's FW, but if it's based on Marlin, you may try to add M203 Z10 command or set machine limits to "emit to g-code".

[jalapenopuzzle]

I poked around in the code a bit. The subroutine below appears to be relevant.

PrusaSlicer/src/libslic3r/GCode/GCodeWriter.cpp

Line 342 in 5dc04b4

std::string GCodeWriter::get_travel_to_xyz_gcode(const Vec3d &from, const Vec3d &to, const std::string_view comment) const {

It appears that

• speed_z is extracted appropriately from the configuration.
• The feed rate w.emit_f() is conditionally computed based on a factor, which is used to mix between the speed_z and travel_speed values as it changes from 0 ... 1.
• factor = 0 (0% travel_speed, 100% speed_z) when time_xy == 0. This is OK.
• factor = 1 (100% travel_speed, 0% speed_z) when time_xy == time_z. This is NOT OK.
• factor = 1 (100% travel_speed, 0% speed_z) when time_z == 0.This is OK.
• factor = 12 (100% travel_speed, 0% speed_z) when time_xy == 12 time_z. This is NOT OK.
• The factor appears to be computed incorrectly.

For the Snapmaker 2.0, in the ini file

PrusaSlicer/resources/profiles/Snapmaker.ini

Line 220 in 5dc04b4

travel_speed = 120

:
travel_speed = 120mm/s

Manually setting z travel speed = 10mm/s

For a layer height of 0.2mm, time_z = 0.2mm/10mm/s = 0.02s
and xy movement of [0.2 1 5 10 20] mm respectively
time_xy = [1.6667e-03 8.3333e-03 4.1667e-02 8.3333e-02 1.6667e-01] sec respectively.
factor = [0.083333 0.416667 2.083333 4.166667 8.333333] respectively
So for large horizontal movement, the factor > 1, and the speed_z is not used at all.
This explains why I only see F7200 in my GCode files.

Snapmaker notes on G1: https://snapmaker.github.io/Documentation/gcode/G000-G001
It is not obvious to me whether the feed rate is applied to each axis individually, or whether it is applied proportionately to each axis to maintain the desired head movement speed.

I note at this point that Snapmaker Luban emits separate G1 lines for XY vs Z movements, with the appropriate F command for each movement type. It does not attempt to fuse the movement into one command (with a composite fed rate) as PrusaSlicer does.

I will need to think more about how the calculation of factor could be corrected.

std::string GCodeWriter::get_travel_to_xyz_gcode(const Vec3d &from, const Vec3d &to, const std::string_view comment) const {
    GCodeG1Formatter w;
    w.emit_xyz(to);

    double speed_z = this->config.travel_speed_z.value;
    if (speed_z == 0.)
        speed_z = this->config.travel_speed.value;

    const double distance_xy{(to.head<2>() - from.head<2>()).norm()};
    const double distnace_z{std::abs(to.z() - from.z())};
    const double time_z = distnace_z / speed_z;
    const double time_xy = distance_xy / this->config.travel_speed.value;
    const double factor = time_z > 0 ? time_xy / time_z : 1;
    if (factor < 1) {
        w.emit_f((this->config.travel_speed.value * factor  + (1 - factor) * speed_z) * 60.0);
    } else {
        w.emit_f(this->config.travel_speed.value * 60.0);
    }

    w.emit_comment(this->config.gcode_comments, comment);
    return w.string();
}

[jalapenopuzzle]

I have prototyped a solution using GNU Octave.
This program provides a reference implementation for computing the speed of a G1 move subject to the configured speed and speed_z.
It also includes a unit test.
Test_Z_Speed.m.txt
Note that the file has been renamed to allow it to be uploaded to github.com. To use it with octave, remove the .txt extension and keep the .m extension.

When I run this example in GNU Octave, it produces the following output:

>> Test_Z_Speed
Computing TestAtSpeeds(120.000000,0.000000).
Completed TestAtSpeeds(120.000000,0.000000).
Computing TestAtSpeeds(120.000000,10.000000).
Completed TestAtSpeeds(120.000000,10.000000).
Computing TestAtSpeeds(120.000000,50.000000).
Completed TestAtSpeeds(120.000000,50.000000).
Computing TestAtSpeeds(50.000000,100.000000).
Completed TestAtSpeeds(50.000000,100.000000).
Computing TestAtSpeeds(100.000000,100.000000).
Completed TestAtSpeeds(100.000000,100.000000).
>>

I believe this code fixes the issue with the faulty computation of the factor in the existing code.
I have not yet attempted to correct the code in GCodeWriter::get_travel_to_xyz_gcode().

[jalapenopuzzle]

I modified PrusaSlicer to implement the speed limitation scheme described above, but it did not fix the problem. My Snapmaker machine still skips Z steps and produces prints that are too short.
I modified PrusaSlicer a second time to separate the Z travel moves from the XY travel moves. My Snapmaker 2.0 machine produces decent prints in this configuration.
Note that Snapmaker Luban emitz Z travel moves separately from XY travel moves. Perhaps there is a defect or an implementation limitation in the Snapmaker firmware relating to fused XYZ moves, which Snapmaker Luban works around by separating Z moves.
I will do some more experiments to determine exactly what G-code causes this issue.

[jalapenopuzzle]

Commit 85332f6 allows me to print properly on my Snapmaker 2.0.
It is a PROOF OF CONCEPT change only. It is NOT suitable for merging.

[lukasmatena]

Fixed in 2.9.0-alpha1. Closing.