3.5.0rc1: Input shaping causes layer shifts!?

dc42

@NeoDue thanks for testing the latest firmware. TBH I wasn't really expecting this latest change to fix bangs and/or layer shifts, because it shouldn't directly affect axis motors. However, the anomalies reported by the "min interval" report in the Move section have disappeared in your latest M122 reports, also the ebfmin value is now zero as expected instead of -1.

I ran your compete print (without filament) on my bench system, apart from the first few layers which I had previously removed because no anomalies were detected in them. The print completed without incident. I didn't hear any bangs, but I can't say whether there were any layer shifts because the motors were not connected to axes.

I would love to have a print in which bangs always occur at the same places, because that would give me a chance to replicate the issue. However, the impression I have from the reports in this thread is that the bangs and layer shifts are somewhat random, because they don't consistently occur at the same places in the print. Would you agree?

Are you still confident that the bangs and layer shifts don't occur when IS is not enabled?

NeoDue

@dc42 said in 3.5.0rc1: Input shaping causes layer shifts!?:

I would love to have a print in which bangs always occur at the same places, because that would give me a chance to replicate the issue. However, the impression I have from the reports in this thread is that the bangs and layer shifts are somewhat random, because they don't consistently occur at the same places in the print. Would you agree?
Are you still confident that the bangs and layer shifts don't occur when IS is not enabled?

Yes, to doublecheck that was the intent behind the test I mentioned in my second post today.

The blob I mentioned there seems to reliably be created with IS on even if it is obviously not large enough to create a layer shift every time. The randomness of the layer shifts (edit: except the one at 5.65mm, which seems to be reliable so far!) might indicate that these are created by such blobs as well - there are numerous occurrances of such short moves in the code file.

Edit: Maybe one more question...: let's assume my thought above is correct. On the other hand, I am confident that you dug out and eliminated all the issues of the code.
Can you think of a setting or a combination of settings that - with the RRF input shaping code working as intended - might be responsible for creating a larger blob with IS enabled for this given gcode snippet than it does with IS off? I am thinking of things like "IS changes Pressure Advance which may have such an effect on very small moves if PA is not 100% correctly calibrated" or such.
In addition, I would assume it should be something that does not happen in the Marlin implementation of IS since I did not have any of such issues prior to switching to the Duet.

adrian

@dc42
My layer shifts are in random places and directions. Mine seem like it decides randomly to turn early.

adrian

@dc42
I would upload my gcode on here but its capped 4mb. Even zipped its 5mb plus.

Here is the stl
01_K.stl

gloomyandy

@adrian Can you place the gcode file on a file sharing service and make it available via that?

Have you confirmed that if you print the same part with input shaping turned off (and no other changes), that you do not see any layer shifts?

dc42

@NeoDue I would like to check whether extrusion issues (blobs and similar) are responsible for the layer shifts or not. This is what I propose:

Adapt the attached macro for your machine and test it. It measures where the homing switches are found and compares this with where they should be. It doesn't seem to work very well when using stall homing, but I am hopeful that it will work fairly well on a machine with real homing switches.
Edit your print file if necessary to remove any homing command at the end
Remove the filaments from your machine
Home the printer and run this macro to check it is working as expected
Disable your filament monitors (M591 D0 S0 M591 D1 S0)
Run the print like that, using your usual IS and PA parameters that provoke layer shifts
When it has finished, make sure that the print head is clear of the print, then run this macro again to check whether either X or Y has shifted.

AxisShiftCheck.g

adrian

@gloomyandy
I’ll work on getting that code shared out.

It works fine without IS on.

dc42

@adrian please can you do the same test that just asked NeoDue to do, i.e. run the same print without filament and use the macro to see whether either X or Y has shiftted.

adrian

@gloomyandy
gcode:
https://fastupload.io/K2qmozelOP3eK4A/file

NeoDue

@dc42 thanks! I have rewritten the file to save its data in a file:

; Parameters to control motion to sense endstops. Copy these from the homing files.
var xHomingSpeed = 500
var yHomingSpeed = 320
; uncomment and set current if stall homing is used
;var xHomingCurrentPercent = 25
;var yHomingCurrentPercent = 25


T0 ; activate correct Tool - the one on the X axis

G91                      ; relative positioning
G1 Z5 F360               ; get some distance between nozzle and bed / part
G90                      ; absolute positioning

; Go to bed centre
G1 X{(move.axes[0].max + move.axes[0].min)/2} Y{(move.axes[1].max + move.axes[1].min)/2} F3000

; Reduce currents in case we are using stall homing - uncomment if stall homing is used
; M913 X{var.xHomingCurrentPercent} Y{var.yHomingCurrentPercent}

M400

; Check Y axis
if sensors.endstops[1].highEnd
  G1 H4 Y{move.axes[1].max+20} F{var.yHomingSpeed}
  echo >>"axisshiftcheck_results.txt" "Y homing error was "^{move.axes[1].machinePosition - move.axes[1].max}^""
  echo "Y homing error was", move.axes[1].machinePosition - move.axes[1].max
  G1 Y{move.axes[1].max-20}
else
  G1 H4 Y{move.axes[1].min-20} F{var.yHomingSpeed}
  echo >>"axisshiftcheck_results.txt" "Y homing error was "^{move.axes[1].machinePosition - move.axes[1].min}^""
  echo "Y homing error was", move.axes[1].machinePosition - move.axes[1].min
  G1 Y{move.axes[1].min+20}

; Check X axis
if sensors.endstops[0].highEnd
  G1 H4 X{move.axes[0].max+20} F{var.xHomingSpeed}
  echo >>"axisshiftcheck_results.txt" "X homing error was "^{move.axes[0].machinePosition - move.axes[0].max}^""
  echo "X homing error was", move.axes[0].machinePosition - move.axes[0].max
  G1 X{move.axes[0].max-20}
else
  G1 H4 X{move.axes[0].min-20} F{var.xHomingSpeed}
  echo >>"axisshiftcheck_results.txt" "X homing error was "^{move.axes[0].machinePosition - move.axes[0].min}^""
  echo "X homing error was", move.axes[0].machinePosition - move.axes[0].min
  G1 X{move.axes[0].min+20}

; Restore motor current
M400
M913 X100 Y100
M400

G91                      ; relative positioning
G1 Z-5 F360              ; move bed back to where it was
G90                      ; absolute positioning

... and have added an M98 command into the appropriate places of the print file. I will let that run tonight.

NeoDue

@dc42 1st attempt:

Y homing error was 0.000
X homing error was 0.012
Y homing error was -0.012
X homing error was -0.012

Those offsets are within the tolerance of the endstops...

I will repeat the test once or twice tomorrow, but it seems it is indeed caused by the filament.

Edit: the printer had likely IS disabled in this test, please ignore it.

NeoDue

@dc42 test prints will follow tomorrow. I finished two test runs this evening - only to find out I accidentially verified that there is no issue when IS is disabled...

dc42

@NeoDue said in 3.5.0rc1: Input shaping causes layer shifts!?:

Edit: In case it matters: the "test-blob" I found occurs on layer 2, 4 and 6 in the middle of the last line of the solid infill of my test part. Prusaslicer decided in its wisdom to split this line into two long pieces which are connected by two very short ones. This is the gcode that causes the blob:

; (tool position before this snippet begins: X-7.877 Y28.826)
G1 X-7.823 Y28.723 E.00266
G1 X-7.815 Y-7.037 E.75823
G1 X-7.867 Y-7.142 E.00277
G1 X-7.919 Y-7.246 E.00303
G1 X-7.922 Y-42.252 E.91196

Thanks, that's useful information. I will investigate what is happening there.

NeoDue

@dc42 Okay, here is the full set of tests, three with IS off and three with IS on - it is nothing extruder related after all

test 1 (IS most likely off)
Y homing error was 0.000
X homing error was 0.012
Y homing error was -0.012
X homing error was -0.012

test 2 (IS off)
Y homing error was 0.000
X homing error was 0.012
Y homing error was -0.012
X homing error was -0.012

test 3 (IS off)
Y homing error was -0.012
X homing error was 0.000
Y homing error was -0.012
X homing error was 0.000

test 4 (IS on)
Y homing error was 0.000
X homing error was 0.012
Y homing error was -0.012
X homing error was -0.788

test 5 (IS on)
Y homing error was -0.012
X homing error was 0.000
Y homing error was -0.012
X homing error was -0.012

test 6 (IS on)
Y homing error was -0.012
X homing error was 0.000
Y homing error was -1.613
X homing error was -3.188

That means something still must be wrong with Input shaping... but what?

And one more thing puzzles me: the offsets measured here are quite a bit lower than the amount of layer shifts I get if I print the real part.
The only logical reason I can think of that might cause this would be that... something... related to Input Shaping causes a significant temporary loss of torque in the steppers which causes them to loose some steps in free air, but also causes them to be more vulnerable against the slightly larger blobs which then result in more lost steps? The EMF calculator says the stepper configuration is okay. I had doublechecked that when I saw increasing motor currents did tendencially rather in- than decrease the layer shift occurrances...

oliof

@NeoDue what IS algo are you using? I haven't tested thoroughly yet but I feel ZVDD may cause more issues than MZV.

NeoDue

@oliof I used EI2 for all recent test cases here - measuring with the input shaping plugin gave me the result that either ZVDDD or EI2 should be the best two options for my printer. Which one will be ultimately the best is something I need to find out when I can finally use it

oliof

@NeoDue I haven't tried EI2, but I have had much less issues with MZV than with ZVD. With my squirqle test, ZVD seems to be applied somewhat more irregularly than MZV; I would suspect that the variations in speed could affect extrusion as well which might contribute to the blobbing / extrusion irregularities.

NeoDue

@oliof at least according to my tests with the accelerometer MZV seemed quite a bit less effective, that was the reason why I had discarded that one. The options the Duet offers should work after all

But I will keep that in mind, thanks for the hint.

NeoDue

@dc42 one more test: I wanted to check if the TMC stepper maybe detects skipped steps while running the test and ran a M569.2 P0:0 and P0:3 R{0x73} (i.e. read the "LOST_STEPS" register) in regular intervals during the "print".

The register stayed at 0 all the time, while your macro yielded the following result:

test 7 (IS on)
Y homing error was -0.012
X homing error was 0.000
Y homing error was -0.692
X homing error was -5.600

dc42

@NeoDue thanks for running all those tests.

I am trying to find the cause of the blobs you reported when IS is enabled that you said you believed were caused by particular lines of code. So I've been running this print job with full debug output, using your machine configuration, with IS enabled and with IS not enabled:

; testing IS on short segments generated by PrusaSlicer

M83
M302 P1
M591 D0 S0
T0
G92 E0
G92 X-7.974 Y29.422 F3000			; set initial position

;WIDTH:0.398828
G1 F8190
G1 X-7.953 Y29.175 E.00567
;WIDTH:0.425466
G1 X-7.932 Y28.928 E.00608
G1 X-7.877 Y28.826 E.00284
;WIDTH:0.398828
G1 X-7.823 Y28.723 E.00266
;WIDTH:0.37219
G1 X-7.815 Y-7.037 E.75823
;WIDTH:0.411061
G1 X-7.867 Y-7.142 E.00277
;WIDTH:0.449932
G1 X-7.919 Y-7.246 E.00303
G1 X-7.922 Y-42.252 E.91196

The movement commands are taken from your print file. They include the lines you thought were where the blob occurs and a few preceding lines.

What I found is that IS isn't applied to any of those moves, mostly because they are too short (which is because you have segmentation enabled). The attempt to apply IS does change one of the moves very slightly but not in a way that significantly affects the step generation. So I haven't been able to find any cause of the blob you report.

Are you absolutely certain that these are the moves where the blob occurs when you run the print job with IS enabled?

I've put a new build of RRF for the 6HC at https://www.dropbox.com/scl/fo/p0136wx04h8xf6ejwdnn9/h?rlkey=efrfwyb6o5tqid11gustz3uvy&dl=0. I don't expect this to change the behaviour significantly, except that if you execute a G92 E command with a tool selected it now clears the fraction of an extruder step that is left over from the last move, for all extruders used by the current tool. I did this so that we can get consistent results regardless of the previous printing history.

Solved 3.5.0rc1: Input shaping causes layer shifts!?