RRF 3.4 input shaping preview available

dc42

@adrian52 and @skrotz, thanks for your feedback. Please provide your config.g files and the gcode files that you printed. Also tell me what input shaping if any you were using.

@skrotz are you quite certain that you had PA disabled in the 3.3 print? Excess extrusion when changing direction without PA is common.

Adrian52

@dc42 The gcode was generated by superslicer and has M593 commands embedded to change the shaping through none, zvd, zvdd, ei2, ei3 and daa at 10 mm intervals. The config used actually had PA set to 0.5, and M593 set to "none".
20210713 config.g.txt
ringing_tower 10mm bands incl daa 210 195 30mm_sec.gcode

skrotz

@dc42 Pretty certain PA was off, I used the console to set the S value to 0 for it to disable. I see bulging corners and telltale signs of no PA on the print, but there's the occasional blips that don't show on the same print with no PA on 3.3.

I may have had some input shaping enabled though on the 3.4 PA disabled print, I can do another quick test and super verify turning off PA and input shaping to see if the "blips" go away doing that. I'll try and capture some more debugging data soonish also.. getting things hooked up to a PC is a bit tricky, I should get a longer USB cable to be able to do it more easily on my setup..

JenPet

@dc42 Hi I still have the issue that the extruder extrudes not enought filament at the end of of a line/move. This happens only when PA (0.08) is enabled. Im printing with input shaper ZVDD F55.0. I thing there is still a bug in firmware. I use Duet2Wifi and extruder is connected to main board.

skrotz

@dc42 I was able to do a 3.4 print with PA disabled and input shaping completely disabled (My previous 3.4 print with PA off had DAA enabled still, as that was my default start up) - with no PA and no input shaping, there are no zits or bubbles, things look perfect. M122 reports no stepper hiccups or errors.

So it seems confirmed that input shaping is causing some extrusion issues, and they are amplified by PA.

update: I enabled input shaping (ei2 f41 s0.10) and got the zits/blobs, same location each time. PA still off. M122 reported 4 step errors, 0 hiccups. Next I'll try and do the print with the debugging enabled and catch the step errors.

sebkritikel

From what I've seen so far, print quality improvements from input shaping are only really seen when the motion into and out of a 'junction' are straight lines. Input shaping as implemented seems to have negligible impact on more complicated motion paths - splines after a junction, etc.

Please ignore the faint zebra stripes... perhaps there are very faint artifacts there, but its chiefly a trick of the light and camera combination.

Vase/spiral mode, so no z-hops. With ZVDD, targeting 22-23Hz, the straight surfaces look excellent. Once the lofts begins (and input shaping is on), you can hear an audible change in the printer's motion (not an unusual sound, it simply sounds as if input shaping is missing). During the lofted sections I would turn off input shaping, collect some accelerometer data, and then turn it back on after verifying frequencies of note. No real difference in print quality is seen in the lofted sections when shaping is on or off.

FWIW circles (cylinders, cones, anything with a true circular cross section) looks great.

dc42

@sebkritikel you are quite right. Input shaping is applied only to individual move segments. Applying IS to curves that start or end at a sharp corner would require analysis and modification of several segments that make up the curve.

In future we may be able to apply IS to whole G2 and G3 moves. Then you could use Arc Welder to preprocess the file.

GeneRisi

@dc42 Will you always post a message if you have updated the firmware? Thanks!

dc42

@generisi we always post a message when we do a new official release (including a beta or RC release). If you have a github account then you can get additional notifications. To set them up, go to https://github.com/Duet3D/RepRapFirmware and click on Watch.

bot

Very interesting post, thank you for sharing.

This is encouraging news, to me. It really shows that it works but that it's not magic.

IMO, you can tune your printer to achieve better results than shown. The amount that the input shaping is reducing the ringing on the flat sections is tremendous. You had an absolutely enormous amount of ringing showing through (but I grant that the lighting may be showing it worse).

If, before applying input shaping, you tune your jerk/accel/feedrate settings to be much more conservative, I bet you will either see some effect from input shaping on those smaller moves or those smaller moves will at least be less noticeably problematic.

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.