Decrease acceleration on very tall models

[myself248]

Is your feature request related to a problem?

On printers with a bed that moves in the Y (or X? do those exist?) axis, the taller a part gets, the more likely it is to simply torque itself off the bed while being flung around by rapid moves.

Describe the solution you'd like

As the old saying goes, it's not the fall that kills you, it's the sudden stop at the end. Travel speed isn't the problem, as long as the accelerations to reach that speed are sufficiently gentle. By reducing the Y-axis acceleration (and jerk?) rates as the Z-height climbs, short models and the base of a tall model could take advantage of the printer's full speed, but the motion could tune itself down towards the latter part of a print, to avoid exceeding bed adhesion.

I imagine this implemented as two parameters, the first one being "When a model is skinnier than aspect-ratio N, reduce acceleration", and then the second parameter expressing how much to reduce it, but I don't have a good suggestion for how to express that. Then when slicing a model, at each layer, compute the instantaneous aspect ratio (on the appropriate axis, probably current-Z-over-footprint-Y) and set acceleration for that layer accordingly. Moving up the print, the taller it gets, the slower it goes.

Describe alternatives you've considered

Globally reducing acceleration in the machine config would solve the problem, but at the price of all prints being slow all the time. This measure is only necessary on tall prints, specifically tall prints with narrow bases, specifically the later part of the printing session as the part has grown tall enough to matter. This feature doesn't seem like a good fit for machine firmware because the machine isn't aware of things like aspect ratio; I think the slicer is the best place for it.

Affected users and/or printers

Every machine with a moving Y-axis.

Additional information & file uploads

No response

[fvrmr]

Hi @myself248 thank you for your feature request. I will bring this up with the team. Keep you posted!

[GregValiant]

Actually you can do this using the SearchAndReplace post-processing plugin. Search ;LAYER:150 Replace ;LAYER:150\nM201 X200 Y200

Cura always adds ";LAYER:xx" so your layer choice will be there to find. (Layers in Gcode start at zero.) SearchAndReplace accepts the newline characters "\n" and so you can insert multiple commands. The example above removes ";LAYER:150" and then replaces it with ";LAYER:150" but with new M201 max acceleration numbers in the line below. Whatever you had Cura start with in regards to Acceleration will be over-ridden by the printer to keep within the Max Accel. If you were printing "One at a Time" then after the first Accel change in the Gcode the rest of the print would be at that accel. I suppose you could search for Layer:0 and reset the accel at the beginning of each part.

[fvrmr]

I have discussed it with the team and we decided to defer this feature request. It doesn't have value for our printers because the print bed doesn't move on the y axis. I hope you understand.

[myself248]

Makes complete sense! It sounds like it might be good fodder for a plugin or post-processor, too. Thanks for your consideration!

[github-actions[bot]]

Hi 👋, We are cleaning our list of issues to improve our focus. This feature request seems to be older than a year, which is at least three major Cura releases ago. It also received the label Deferred indicating that we did not have time to work on it back then and haven't found time to work on it since.

If this is still something that you think can improve how you and others use Cura, can you please leave a comment? We will have a fresh set of eyes to look at it.

If it has been resolved or don't need it to be improved anymore, you don't have to do anything, and this issue will be automatically closed in 14 days.

[myself248]

Well, according to the bot's rubric of "improving how I and others use Cura", yes, this still qualifies. But I understand that none of Ultimaker's own printers are bedslingers so it's probably a non-starter regardless.

Doing it in a postprocessor does work, but it blows out the estimated print time, which I think is the one remaining gain to be made by having it integrated in the slicer itself.

I don't know the global policy on implementing features specific to particular printer geometries, since these are mostly handled by the printer firmware, but some call for slicer integration. IMHO it's a better user experience to have them in upstream Cura versus having every printer maker distributing a weird customized fork, but you do you. I won't be offended if this gets closed, just sad.

[GregValiant]

Ha. Timing is everything. I just finished this post processor when I saw the email about this request. It could use more debugging if you care to give it a test drive. It will limit the Y (and/or X) Accel from a layer to a layer or to the end. You can alter the jerk as well. Unzip it and (in Windows) put it in the "C:\Users...username....\AppData\Roaming\cura\5.4\scripts" folder. LimitXYAccelJerk.zip

I've completed a pull request #15954 . Let me know if you come across any issues or have any suggestions.