RRF 3.4 input shaping preview available

[GeneRisi]

@dc42 Thanks! (and done!)

[Dudek23]

After a week of printing, I can confirm that the latest beta is very stable. Everything works just as good for me as in version 3.3. As for the input shaper, I am able to achieve good results with zvdd, but only on one axis at time, so I join the request for the possibility to use of different frequencies per axis.

[dc42]

@dudek23 thanks for the feedback!

[CR3D]

@dudek23 yes different frequencies and different shapers for the different axis would be a nice option

[dc42]

@cr3d an issue with using different shapers for different axes is that the axes will no longer move exactly in sync during acceleration and deceleration. For example, corners printed at 45deg to X and Y may become less square. However, I can make different shapers per axis an option to try, at least on Duet 3.

[PCR]

@dc42 how does klipper handle this? only curious how its done? are they syncing axis then?

[dc42]

@pcr said in RRF 3.4 input shaping preview available:

@dc42 how does klipper handle this? only curious how its done? are they syncing axis then?

Good question! The Klipper docs mention "smoothing" but don't elaborate. They also suggest use of low acceleration.

[PCR]

@dc42 https://github.com/KevinOConnor/klipper/blob/master/klippy/chelper/kin_shaper.c

static double
shaper_xy_calc_position(struct stepper_kinematics *sk, struct move *m
                        , double move_time)
{
    struct input_shaper *is = container_of(sk, struct input_shaper, sk);
    if (!is->sx.num_pulses && !is->sy.num_pulses)
        return is->orig_sk->calc_position_cb(is->orig_sk, m, move_time);
    is->m.start_pos = move_get_coord(m, move_time);
    if (is->sx.num_pulses)
        is->m.start_pos.x = calc_position(m, 'x', move_time, &is->sx);
    if (is->sy.num_pulses)
        is->m.start_pos.y = calc_position(m, 'y', move_time, &is->sy);
    return is->orig_sk->calc_position_cb(is->orig_sk, &is->m, DUMMY_T);
}

i am no coder but looks like the calculating it

[PCR]

@dc42 ah i think klipper can only use one shaper for x and y but diffrent freq.

So i think different freq. per axis should be possible?

[dc42]

@pcr if you use different frequencies per axis, the axes will move out of step. But the amount of out-of-step movement may be small enough to be acceptable, especially if the accelerations are low. It makes no difference whether the same or different input shapers are used per axis.

[CR3D]

@dc42

Sorry dc42 I have to contradict you. Without doing X and Y separately, it won't work properly and properly. Out of interest, I looked at clippers last week and took a measurement. As a result you get the following graphs and also the suggestions for the frequency and the shaper. and these are always different for X and Y.

In addition, you will also receive a recommendation for the respective max.accelerations per axis ...

[dc42]

@cr3d said in RRF 3.4 input shaping preview available:

Sorry dc42 I have to contradict you.

Which bit of my post are you contradicting?

[skrotz]

@dc42 I was able to do a print and captured some stepper errors with debug output. Included is my config.g, the gcode I was printing, and the output logs. Hopefully this helps diagnose the issues some of us are having with RRF 3.4. This was with PA disabled , and input shaping enabled via M593 P"ei2" F41 S0.10

config.g
printOutput.txt
CFFFP_xyzCalibration_cube_205.gcode

[dc42]

@skrotz thanks for that, it shows clearly some step errors on the extruder drive and that PA was not involved. I will investigate.

[CR3D]

@dc42

I ment this part here:

"if you use different frequencies per axis, the axes will move out of step. But the amount of out-of-step movement may be small enough to be acceptable, especially if the accelerations are low. It makes no difference whether the same or different input shapers are used per axis."

I think it is absolutely necessery and with klipper it also works...

Just for information We want the same perfect shaper here in RRF

[psychotik2k3]

i really think that at least different frequencies should be possible because i really don't see how the frequency should be the same on X and Y as the weight in movement is not the same at all, and thus the moment.

[oliof]

@psychotik2k3 could still be that the frequencies are close enough that the wider band from one configuration is enough to improve both X and Y

[Dudek23]

@dc42 This is exactly what happens in Klipper at high smoothing values. In recent versions, during the calibration procedure, the software gives the recommended acceleration values ​​so that the loss of accuracy is not noticeable. I think it is definitely worth testing how it will look in rrf, even for duet3 only, maybe the loss of accuracy will be acceptable.

[dc42]

@skrotz said in RRF 3.4 input shaping preview available:

@dc42 I was able to do a print and captured some stepper errors with debug output. Included is my config.g, the gcode I was printing, and the output logs. Hopefully this helps diagnose the issues some of us are having with RRF 3.4. This was with PA disabled , and input shaping enabled via M593 P"ei2" F41 S0.10

config.g
printOutput.txt
CFFFP_xyzCalibration_cube_205.gcode

With your files I was able to identify and reproduce the problem. It is now fixed and I can run your test print using your configuration without errors.

We will release a new beta with input shaping within the next few days.

[skrotz]

@dc42 great! More than happy to test out a pre-release version of it if you put it on the dropbox