RRF 3.4 input shaping preview available

[dc42]

@jenpet I don't see any M572 command in config.g. Are you running without pressure advance?

[JenPet]

@dc42 M572 is in the start script of gcode

[dc42]

@jenpet ok, I am running your file now.

[Adrian52]

@dc42 just completed cal cube with ei3 and 0.8 pa, no clunking, nice finish - 0 hiccups, 0 errors, 0 underruns. Brilliant - thank you.

[dc42]

@jenpet I am getting the step errors now. Looking into it.

[skrotz]

@dc42 Happy to report significant improvement with this build printing with PA enabled and ei2 input shaping on. As mentioned clunking is greatly improved, and the print quality is significantly better. No major extrusion issues or jaggedness. There are a few layers, for example on the right side of the X (notably near the middle of it) on the calibration cube that seem slightly misaligned or overextruded, and are noticeably different from a 3.3 print. I do also notice that the X and Y of the calibration cube seem noticeably wider than previous prints. I suspect though that these issues are getting into the nitty gritty of input shaping, and away from the egregious bugs I was seeing, which seem fixed so far with this build.

I will try and do some more test prints today with various things enabled/disabled to gather more data for you. Many thanks for the rapid fixes!

oh and M122 reports no hiccups or errors on this print:

=== Move ===
DMs created 83, segments created 35, maxWait 54915ms, bed compensation in use: mesh, comp offset 0.000
=== MainDDARing ===
Scheduled moves 11545, completed moves 11545, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1
=== AuxDDARing ===
Scheduled moves 0, completed moves 0, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1

RepRapFirmware for Duet 2 WiFi/Ethernet version 3.4.0beta2-inputshaping (2021-08-02 17:37:04) running on Duet WiFi 1.02 or later + DueX5

[dc42]

@skrotz thanks for your feedback.

@skrotz said in RRF 3.4 input shaping preview available:

I do also notice that the X and Y of the calibration cube seem noticeably wider than previous prints.

Is that with input shaping disabled, or enabled? I do expect there to be slight extrusion differences when input shaping is used. I do not expect there to be significant differences from RRF 3.3 when input shaping is set to none in 3.4 and DAA is disabled in 3.3.

There will be a further update when I have fixed the step errors seen by JenPet, which I have reproduced

[skrotz]

@dc42 The print was with input shaping enabled:

M593 P"ei2" F41 S0.10

I'll try and do some more prints with input shaping and PA disabled in various combinations and see how they compare.

To my eye, the width of the X and Y changing seems likely to be due to input shaping.. not necessarily bugs, but just artifacts of the movement changes happening with ei2 input shaping on. The lines that look slightly misaligned or over extruded after the X feel more like a bug that is still rattling around. More prints with various knobs on and off should help identify that potentially.

[dc42]

@skrotz I've just found and I believe fixed the bug that was affecting JenPet. It might cause slight extrusion errors on other machines using PA. New binary coming soon.

[dc42]

@skrotz @jenpet I've put new binaries at https://www.dropbox.com/sh/ja08b7qdzsl8kjc/AAAwUbkN2XJvurq5CuQTgx5Wa?dl=0.

[JenPet]

@dc42 Thank you but I still get the issue

[dc42]

@jenpet please run M115 to check tbatb you really do have the latest version installed. It should report:

FIRMWARE_DATE: 2021-08-02 19:33:23

I ran your print and had zero step errors using this version, instead of lots of step errors using the previous version.

[JenPet]

@dc42 I have checked verison but everything is okay. I had also no step errors.

=== Move ===
DMs created 83, segments created 42, maxWait 236506ms, bed compensation in use: none, comp offset 0.000
=== MainDDARing ===
Scheduled moves 2873, completed moves 2873, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1
=== AuxDDARing ===
Scheduled moves 0, completed moves 0, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1

[dc42]

@jenpet said in RRF 3.4 input shaping preview available:

@dc42 I have checked verison but everything is okay. I had also no step errors.

=== Move ===
DMs created 83, segments created 42, maxWait 236506ms, bed compensation in use: none, comp offset 0.000
=== MainDDARing ===
Scheduled moves 2873, completed moves 2873, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1
=== AuxDDARing ===
Scheduled moves 0, completed moves 0, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1

So what is the problem now? Are you testing with input shaping enabled or disabled?

[JenPet]

@dc42 I'm testing with input shaping.
There is always not enough material at the end of lines. Maybe PA is not working right by deacceleration.

[dc42]

@jenpet, input shaping may affect the behaviour of PA. When you test this 3.4beta with input shaping turned off, are the results similar to what you get using RRF 3.3 with DAA disabled, using the same PA ni both cases?

[JenPet]

@dc42 I dont know if the quality is equal to RRF 3.3.
I have tested different setting with input shaping an PA.
I tried different PA values, acceleration values, jerk values and speed values but I always get the issue on the picture.
But when I turn PA off, the issue is gone.

[dc42]

@jenpet can you tell me exactly where in that image the issue is?

Perhaps you are just using too much PA.

[JenPet]

@dc42 the two contour lines get thinner and thinner at the end so that there is a gap between them.
Now I try to lower PA value again.

[dc42]

@jenpet said in RRF 3.4 input shaping preview available:

@dc42 the two contour lines get thinner and thinner at the end so that there is a gap between them.
Now I try to lower PA value again.

If you mean the two perimeter lines, they are joined in the perimeter at the top, joined for part of the length of the perimeter on the right, and not joined at all in the perimeter at the bottom. The difference between top and bottom suggests to me that you have chosen an unfortunate wall thickness and the slicer has failed to ensure consistent infill by altering the extrusion widths - so that whether the perimeters are joined or not is very sensitive to small changes. I am assuming that the thickness of all three walls is supposed to be the same.