Proportionally slow down non-print moves as the object gets taller

[antirez]

It is universally known in the 3D printing world that printing very tall objects with cartesian printers is often not easy since the Y axis will move fast, make the object vibrate and cause all the kind of issues: detaches from the printing bed and printing glitches.

In order to improve printing of tall objects, the common trick is to print them slowly. However actually the only slow part that is required is the non-printing moves because:

1. Printing movements are anyway not as fast as non printing ones, that are the main source of high vibrations.
2. This problem is particularly an issue with objects that have a small surface and are tall. Because of the minimum time for the material to cool down, anyway printing movements will be slow, while non-print moves will continue to be very fast.

So PrusaSlicer should consider adding the following features that could greatly improve the situation.

Feature A: non-print movement speed that is inversely proportional to the current object height. As we print higher and higher layers, we need to slow down more the non-print movements. The slicer should detect if this is needed and should hint the user to enable the option, as it already does for other stuff.

Feature B: when the layer needs to be slowed down because of cooling time of the material, it should not print (as apparently does right now) very slow and then move very fast. The additional time should be partitioned in order to be as much as possible in non-printing moves. This way we can reduce the maximum speed reached by the Y axis without affecting the actual time to print each layer.

I tried to Google to see if this feature was already implemented or proposed but could not find anything during my (admittedly not very long) research.

Thank you for the awesome software you build.

[gudvinr]

It's only relevant for bed slingers (although most prusa printers are bed slingers) so it's not universal issue.

Also speed doesn't matter. Depending on part complexity, you might not even reach set travel speed simply due to short travel distance.
But acceleration is what will cause rapid shaking moves especially when you have short moves.

And good news is that you can already limit travel acceleration with M204 T gcode and there's no need to bake that into slicer.
Just insert custom gcode that changes acceleration with macro depending on current layer like so:

{if travel_acceleration > 0}M204 T{travel_acceleration * (1 - layer_z/(2*max_print_height))}{endif}

That'll linearly decrease travel acceleration from X at Z=0 to X/2 at Z=max_print_height

You can modify that however you want to achieve desired results

[antirez]

Thank you @gudvinr, indeed most Prusa printers will have this issue (but the XL), and also many entry level printers in general. It's awesome that there is a macro to reduce acceleration, I'll start using it, however this remains outside the real of many entry level users that don't know this is possible. I believe the macro solution would be great of this was a very niche problem. But with the MK4 and Input Shaping, I saw this happening in many real world prints, so I've the feeling that a slicer option would be extremely useful. Thanks for the insights provided on the matter! Also with the macro you solved the problem at least for myself :)

[rtyr]

We are actually already limiting the acceleration based on weight of already extruded material in IS MK4 profiles. See custom g-code sections in printer profile.

[antirez]

That's cool, @rtyr, but why to use weight of extruded material? A cube as large as the printer bed will have a lot of mass, yet it will not create any issue with acceleration. On the contrary an object with just 10x10mm touching area and very long will require a lot more that the acceleration is decreased, but the total weight of the extruded material will not be so big. Since here the physics at play is complex, and depends on the overall features of the object and it's ability to vibrate, probably a more conservative estimate to reduce speed is just the current printing Z height.

[rtyr]

A cube as large as the printer bed will have a lot of mass, yet it will not create any issue with acceleration.

It will of course.

The issue you mentioned is different topic, but you can use similar interpolation as I mentioned for current Z height, if you need it.

[gudvinr]

I went to see how it's done for MK4 and it's similar to what I suggested earlier.
Although it seems like 2.6.0 added new macro which makes things easier:

;[layer_z]
M201 X{interpolate_table(extruded_weight_total, (0,4000), (1400,2500), (10000,2500))} Y{interpolate_table(extruded_weight_total, (0,4000), (1400,2500), (10000,2500))}

Although I strongly dislike these hardcoded values. It's very easy to forget to edit gcode if you want to change accel values. You'll change acceleration in print settings and will be pulling hair out when acceleration doesn't change.

@antirez With new gcode macro capabilities, Z-based interpolation of travel accel will look sort of like this:

Add to start_gcode:

{
global accel_to_interp = travel_acceleration > 0 ? travel_acceleration : default_acceleration;
global accel_low_limit = accel_to_interp / 2;
global accel_min_z     = 30;
}

before_layer_gcode:

;[layer_z]
{if layer_z > accel_min_z}M204 T{interpolate_table(layer_z, (accel_min_z, accel_to_interp), (max_print_height, accel_low_limit))}{endif}

This should pull values from print settings so you'll never forget to edit gcode.

Above accel_min_z it should start linearly decrease acceleration from accel_to_interp to accel_low_limit.

I guess it's even possible to make some really sophisticated macro code that'll use both material amount and z value and will adjust acceleration to lower value dictated by either of those.
In that case both bottom heavy and tall models should be covered.

[Henk72]

Should your last code block not use M201 (acceleration) instead of the M203 (feedrate)?

[gudvinr]

@Henk72 it should've been M204 (Set Starting Acceleration) but I more or less wrote that to make an example of how it could be done with new macro rather than providing copy-paste solution

[Henk72]

Thank you, I’m using your suggestion now in my standard printer settings.