RRF 3.4 input shaping preview available

Adrian52

@dc42 2021-07-25 09:41:53

skrotz

@dc42 here's the log data with some stepper errors:

0725printerlog.txt
config.g
CFFFP_xyzCalibration_cube_205.gcode

on closer inspection the "zits" I'm seeing don't seem related to where the stepper errors occurred. They only seem to happen on the X side of the cube, at occasional points where it is changing direction for the X indented in the cube. It looks like overextrusion as it is a small blob. You have to magnify things to be able to see them, but it's happening a fair bit and is different/worse than RRF 3.3 which looks very clean. It seems to happen in exactly the same place each print, and has been pretty consistent throughout all the various 3.4s I've tried.

sebkritikel

Just ran a print off the lasted BIN

M115
FIRMWARE_NAME: RepRapFirmware for Duet 2 WiFi/Ethernet FIRMWARE_VERSION: 3.4.0beta2-inputshaping ELECTRONICS: Duet WiFi 1.02 or later + DueX5 FIRMWARE_DATE: 2021-07-25 09:41:53

Parts look great, but end of print M122 reports 65 hiccups and 1929 stepErrors

M593 P"zvdd" F38.4
M572 D0 S0.020

config(1).g
LOG JP_smallPart1^2021 rifle gps mount-Split1.txt
Print file

dc42

@skrotz what PA did you use when you had those step errors? Was everything apart from PA the same as in the config.g file you posted earlier?

dc42

@sebkritikel thanks, I will run that print on my bench setup.

skrotz

@dc42 I did have PA enabled, that’s probably the only difference between the config files I posted, I think. The tests with these new firmwares had PA enabled.

dc42

@skrotz said in RRF 3.4 input shaping preview available:

@dc42 I did have PA enabled, that’s probably the only difference between the config files I posted, I think. The tests with these new firmwares had PA enabled.

How much PA?

skrotz

@dc42 M572 D0 S0.12 is my standard PA setting, that's what the config.g had that I have been using for current 3.4 tests.

Adrian52

Should add that I used daa to compare 3.3 with 3.4, so that an identical config.g could be used for both. I use pa 0.8 with my 700mm bowden. No errors or hiccups with both, but pa not working with 3.4.
If I use ei3 with 3.4, I get 2 Step errors with the calibration cube (no hiccups or underruns), and I get 2 filament monitor 'insufficient movement' pauses on layers 97/98 out of 100.

dc42

@adrian52 @skrotz @sebkritikel I have put a new Duet 2 binary at https://www.dropbox.com/sh/ja08b7qdzsl8kjc/AAAwUbkN2XJvurq5CuQTgx5Wa?dl=0. This fixes the issue with pressure advance and other issues that I was able to reproduce.

CadetC

@dc42 said in RRF 3.4 input shaping preview available:

@adrian52 @skrotz @sebkritikel I have put a new Duet 2 binary at https://www.dropbox.com/sh/ja08b7qdzsl8kjc/AAAwUbkN2XJvurq5CuQTgx5Wa?dl=0. This fixes the issue with pressure advance and other issues that I was able to reproduce.

As you said, tooboard build in accelerometer now works with SBC
I tried x and y axis - so now I'm going to take on IS

G1 X-50 G4 S2 M956 P121.0 S1000 A0 G4 P10 G1 X50 F20000

G1 y-50 G4 S2 M956 P121.0 S1000 A0 G4 P10 G1 y50 F20000

dc42

@cadetc currently I favour doing a sharp move and collecting data after it has completed. This removes motor and belt noise from the accelerometer output, making it easier to see what is going on. Here is a sample command for the X axis, for a machine set up with X0 Y0 being bed centre:

G1 X-100 F3000 G4 S1 G1 X0 F20000 M400 M956 Pxxx A0 S1000

skrotz

@dc42 with PA enabled the "clunking" noise has returned, usually when printing the infill portion. Disabling PA stopped the clunking, and oddly produced a small layer shift in the X direction and an even smaller one in Y. Definitely some strange extrusion or positioning errors on the part of the print with PA on. With PA off things seemed like previous builds, with some extrusion bubbles or zits in the exact same places as before (these don't happen in 3.3 with PA off). M122 reported some hiccups and errors:

=== Move ===
DMs created 83, segments created 35, maxWait 50682ms, bed compensation in use: mesh, comp offset 0.000
=== MainDDARing ===
Scheduled moves 11545, completed moves 11545, hiccups 1028, stepErrors 5, 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

This was all the same config and gcode as uploaded before. If helpful I could get a debug log later of the stepper errors.

bot

@skrotz which slicer are you using?

Could be gcode related.

E.g., stock prusaslicer is horrible at producing accurate gcode for very short movements. This pops up a lot in parts of infill.

dc42

@skrotz are you certain that the clunking doesn't happen using RRF 3.3 with the same gcode?

Edit: I just spotted that you had some step errors - odd that I didn't. I'll check the configuration and run your print again.

dc42

@skrotz I have now reproduced those step errors. I don't think it will be difficult for me to find the cause because they all show the same particular pattern.

Adrian52

@dc42 I got the clunking and step errors too, on 20mm cal cube.

DMs created 83, segments created 48, maxWait 516025ms, bed compensation in use: mesh, comp offset 0.000
=== MainDDARing ===
Scheduled moves 18073, completed moves 18073, hiccups 6217, stepErrors 102, 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

Also layer shift mainly in the X direction. Havent tried w/o pa yet

CadetC

@dc42
I did some testing.
Look like ie3 works best
With PA enabled and zvd - i had a layer shift - mainly in x

After PA disabled i could finish print with all settings
Counted from bottom - "no IS","ie3", "ie2", "zvdd", "zvd"
first two pictures - x-axis
and next two y-axis

skrotz

@dc42 The clunking is definitely something new from 3.3. I printed about a metric ton of calibration cubes when tuning my printer for various things with PA enabled on 3.3, and never heard noises like that. Of course now I also have input shaping on, so maybe it's the "new normal", but it doesn't sound like things are functioning properly.

I should add that the stepper errors seem to occur near the end of the print, and can't be responsible for the clunking it would seem. Lots of "hiccups" though, the quantity of those would correlate more with the amount of weird noises I hear, maybe..

skrotz

@adrian52 interesting that you got a layer shift also.. I assumed it was related to me disabling PA because it happened at roughly the same point as when I turned off PA to mercifully end the clunking, but sounds like maybe it would have happened no matter what... probably an input shaping bug then.