For mSLA is “important” to accelerate and deaccelerate at different rates to optimize the lift sequence/time.
In mSLA (Only have Z axis) we need a lift to peel the layer and refresh the resin under the toolhead, then retract back to next layer position.
The peel should be slow but stop can be “instant” , also retracting back can accelerate fast but deaccelerate slow.
Example of a lift sequence:
G1 Z+10 F600;
G1 Z-9.95 F600;
Does the klipper code base allow to have a acceleration and deacceleration value?
The low-level Klipper code that generates the step pulses can have different acceleration and deceleration values. The “trapq” code controls this, and each acceleration and deceleration ramp is stored separately. (See, for example, trapq_append() in klippy/chelper/trapq.c.)
However, all the gcode processing in Klipper is written with just one acceleration value. So, I don’t know of any way to feed custom acceleration/deceleration values to the low-level code without notable code changes.
That what I afraid of… Even with a custom Kinematic there’s no way to pass such right?
Any plans to allow deacceleration in SET_VELOCITY?
That would allow such like:
SET_VELOCITY_LIMIT ACCEL=5,500 -> Slow detach but fast stop
G0 Z7.2 F600; -> Safe lift, detach from fep + refresh resin
SET_VELOCITY_LIMIT ACCEL=500,5 -> Fast retract but slow stop
G0 Z0.2 F600; -> Retract to cure the layer at 0.2mm pos
Can you explain in more detail why this is “important” for mSLA printing? Are you just trying to decrease print time? Why is there a need to accelerate/decelerate differently?
I understand how mSLA printing works, I have a resin printer. I just don’t understand the need for a different acceleration/deceleration profile.
I might be missing something of course, but as far as I’ve ever understood it the lifting and lowering is just to refresh the resin under the print as you stated. Why is this dependent on asymmetric acceleration/deceleration?
Is to optimize the print time. If you familiar with mSLA you know about TSMC introduced by some brands to tackle the problem of fast lift and to optimize lift time. But we don’t need TSMC at all, we just need two acceleration values to do it right.
Ideally we peel the layer slow (eg. 5mm/s^2 at max speed), stop fast, start retract fast and stop slow (again at 5mm/s^2). Other than that we are just losing time in two regions. May look small but the time gains can be large if using very slow accels for peel.
Is this a critical feature for mSLA? No. But a good to have. Some people cry for TSMC, myself I hate the concept in favor of two accels. I have write about here.
Anyway, the value of having two tunnable accel values is a good addon for any motion control.
If your goal is to move slowly and then move fast (or vice versa) why not just split the move into two in the first place?
Won’t work as desired, that is TSMC and with current klipper that lead to deoptimize. (Worse results)
Either the lookahead or the buffer set acceleration while in first lift that the stop of first lift looks at 100mm/s^2 rather than the expected 5mm/s^2. It saves about 1s compared to 2xG1 at same accel value (5).
This verbose method is working but I still think that two acceleration values gain value to the firmware.
As of TSMC presentation, there is nothing to do with acceleration, this is slow and fast speed.
You just can use average acceleration “500” and make slow moves, and fast moves.
G0 Z0.1 F10
G0 Z0.2 F30
G0 Z7.2 F600
And then backward
G0 Z0.2 F600
G0 Z0.1 F30
G0 Z0.05 F6
Yes, either speed and/or M204 works when splitting the lift into 4xG1.
My main question/request was aimed by having just two optimized G1, that is only possible if we can have a deaccel value, which klipper supports but is not exposed.
@sn4k3 Sorry to be a pedant but the opposite of acceleration is deceleration not deacceleration.
But yes having a decel value as well as accel sounds like a useful idea.