3.5.0rc1: Input shaping causes layer shifts!?

NeoDue

@dc42 Out of curiosity, I also tested what @oliof mentioned. Increasing currents to the maximum did not change anything either, however, layer shift at 1.75mm:

M122
=== Diagnostics ===
RepRapFirmware for Duet 3 MB6HC version 3.5.0-rc.3+ (2024-02-13 13:34:06) running on Duet 3 MB6HC v1.02 or later (standalone mode)
Board ID: 08DJM-956BA-NA3TN-6JTDL-3SN6L-998UU
Used output buffers: 7 of 40 (32 max)
=== RTOS ===
Static ram: 155208
Dynamic ram: 123544 of which 0 recycled
Never used RAM 63760, free system stack 128 words
Tasks: NETWORK(2,nWait 7,16.0%,172) HEAT(3,nWait 1,0.0%,323) Move(4,nWait 6,2.9%,239) CanReceiv(6,nWait 1,0.0%,940) CanSender(5,nWait 7,0.0%,334) CanClock(7,delaying,0.0%,334) TMC(4,nWait 6,9.7%,56) MAIN(1,running,70.1%,103) IDLE(0,ready,1.2%,30), total 100.0%
Owned mutexes: WiFi(NETWORK)
=== Platform ===
Last reset 00:22:55 ago, cause: software
Last software reset at 2024-02-13 19:10, reason: User, Gcodes spinning, available RAM 64672, slot 2
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x00400000 BFAR 0x00000000 SP 0x00000000 Task MAIN Freestk 0 n/a
Error status: 0x00
Aux0 errors 0,0,0
MCU temperature: min 43.9, current 46.4, max 46.6
Supply voltage: min 23.6, current 23.9, max 24.1, under voltage events: 0, over voltage events: 0, power good: yes
12V rail voltage: min 12.0, current 12.3, max 12.6, under voltage events: 0
Heap OK, handles allocated/used 99/3, heap memory allocated/used/recyclable 2048/248/196, gc cycles 4
Events: 0 queued, 0 completed
Driver 0: ok, SG min 0, mspos 750, reads 57987, writes 27 timeouts 0
Driver 1: standstill, SG min 0, mspos 264, reads 57987, writes 27 timeouts 0
Driver 2: standstill, SG min 0, mspos 504, reads 57991, writes 23 timeouts 0
Driver 3: stalled, SG min 0, mspos 53, reads 57989, writes 25 timeouts 0
Driver 4: standstill, SG min 0, mspos 466, reads 57995, writes 19 timeouts 0
Driver 5: ok, SG min 0, mspos 238, reads 57996, writes 19 timeouts 0
Date/time: 2024-02-13 19:33:15
Slowest loop: 816.19ms; fastest: 0.05ms
=== Storage ===
Free file entries: 18
SD card 0 detected, interface speed: 25.0MBytes/sec
SD card longest read time 4.3ms, write time 102.7ms, max retries 0
=== Move ===
DMs created 125, segments created 26, maxWait 117938ms, bed compensation in use: none, height map offset 0.000, max steps late 1, min interval 0, bad calcs 0, ebfmin 0.00, ebfmax 1.00
next step interrupt due in 64 ticks, disabled
Moves shaped first try 7, on retry 280, too short 2460, wrong shape 21310, maybepossible 1427
=== DDARing 0 ===
Scheduled moves 45790, completed 45740, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state 3
=== DDARing 1 ===
Scheduled moves 0, completed 0, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1
=== Heat ===
Bed heaters 0 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1, chamber heaters -1 -1 -1 -1, ordering errs 0
Heater 0 is on, I-accum = 0.4
Heater 1 is on, I-accum = 0.4
=== GCodes ===
Movement locks held by null, null
HTTP is idle in state(s) 0
Telnet is idle in state(s) 0
File is idle in state(s) 3
USB is idle in state(s) 0
Aux is idle in state(s) 0
Trigger is idle in state(s) 0
Queue is idle in state(s) 0
LCD is idle in state(s) 0
SBC is idle in state(s) 0
Daemon is idle in state(s) 0
Aux2 is idle in state(s) 0
Autopause is idle in state(s) 0
File2 is idle in state(s) 0, sync state 1
Queue2 is idle in state(s) 0
Q0 segments left 10, axes/extruders owned 0x80000007
Code queue 0 is empty
Q1 segments left 0, axes/extruders owned 0x0000000
Code queue 1 is empty
=== Filament sensors ===
check 14945236 clear 310047
Extruder 0 sensor: ok
Extruder 1 sensor: ok
=== CAN ===
Messages queued 12375, received 0, lost 0, errs 6525776, boc 0
Longest wait 0ms for reply type 0, peak Tx sync delay 0, free buffers 50 (min 50), ts 6878/0/0
Tx timeouts 0,0,6877,0,0,5496 last cancelled message type 4514 dest 127
=== Network ===
Slowest loop: 784.06ms; fastest: 0.00ms
Responder states: MQTT(0) HTTP(0) HTTP(2) HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0) Telnet(0)
HTTP sessions: 1 of 8
= Ethernet =
Interface state: disabled
Error counts: 0 0 0 0 0 0
Socket states: 0 0 0 0 0 0 0 0
=== WiFi ===
Interface state: active
Module is connected to access point 
Failed messages: pending 0, notrdy 0, noresp 0
Firmware version 2.1beta6
MAC address 70:04:1d:be:ad:b8
Module reset reason: Power up, Vcc 0.00, flash size 4194304, free heap 220536
WiFi IP address 192.168.178.31
Signal strength -59dBm, channel 2, mode 802.11n, reconnections 0
Clock register 00002002
Socket states: 0 0 0 0 0 0 0 0
=== Multicast handler ===
Responder is inactive, messages received 0, responses 0

But I also tried a print where I switched between IS on and off every couple of layers - and I finally could see one of the blobs you were talking about. I could directly turn blob occurrance (and therefore rumbling on the next layer) and off by switching between IS on and IS off.

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

adrian

@dc42 Here is my config

; Configuration file for RepRapFirmware on Duet 3 Main Board 6HC
; executed by the firmware on start-up
;
; generated by RepRapFirmware Configuration Tool v3.5.0-rc.1+1 on Mon Dec 11 2023 18:26:16 GMT-0600 (Central Standard Time)

; General
M550 P"SeaMonster" ; set hostname

; Accessories
M575 P1 S0 B57600 ; configure PanelDue support

; Network
M552 P0.0.0.0 S1 ; configure Ethernet adapter
M586 P0 S1 ; configure HTTP

; LED Strips
M950 E0 C"led" T2 U3 ; LEDs on SB Toolhead (3) (LED 0)
M950 E1 C"io7.out" T2 U25 ; Left Overhead LEDs (25) (LED 1)
M950 E2 C"io8.out" T2 U25 ; Right Overhead LEDs (25) (LED 2)

; ====================---------------------------------------------------------
; Driver config
; ====================

;          --- Drive map ---
; (While looking at the printer top down)
;			   B	   A
;             0.0-----0.1
;              |  0.5  |
;              |-------|
;              |0.3|0.4|
;               ---+---
;                Front

; Smart Drivers
M569 P0.0 S1 D2 ; driver 0.0 goes forwards (X axis)
M569 P0.1 S1 D2 ; driver 0.1 goes forwards (Y axis)
M569 P0.2 S0 D2 ; driver 0.2 goes backwards (extruder 0)
M569 P0.3 S0 D2 ; driver 0.3 goes backwards (Z axis) (Front Leftt)
M569 P0.4 S0 D2 ; driver 0.4 goes backwards (Z axis) (Front Right)
M569 P0.5 S0 D2 ; driver 0.5 goes backwards (Z axis) (Rear Center)

; Motor Idle Current Reduction
M906 I30 ; set motor current idle factor
M84 S30 ; set motor current idle timeout

; Axes
M584 X0.0 Y0.1 Z0.3:0.5:0.4 ; set axis mapping (Front Left, Rear Center, Front Right)
M350 X16 Y16 Z16 I1 ; configure microstepping with interpolation
M906 X1500 Y1500 Z1200 ; set axis driver currents (xy1300)
M92 X160 Y160 Z800 ; configure steps per mm
M208 S1 X13 Y-5 Z0 ; set axis minima
M208 S0 X350 Y350 Z215 ; set axis maxima
M566 X720 Y720 Z30 ; set maximum instantaneous speed changes (mm/min) (700)
M203 X36000 Y36000 Z900 ; set maximum speeds (mm/min) (X9000 Y9000 Z900)
M201 X6000 Y6000 Z150 ; set accelerations (mm/s^2) (X6000 Y6000)

; Extruders
M584 E0.2 ; set extruder mapping
M350 E16 I1 ; configure microstepping with interpolation
M906 E1000 ; set extruder driver currents
M92 E724.1379 ; configure steps per mm
M566 E120 ; set maximum instantaneous speed changes (mm/min)
M203 E7200 ; set maximum speeds (mm/min) (3600)
M201 E2000 ; set accelerations (mm/s^2) (250)

; Kinematics
M669 K1 ; configure CoreXY kinematics

; Bed Level
M671 X-35:175:390 Y3:420:3 S10;S0.5 ; position of leadscrew/bed pivot point at front left, rear middle and front right

; Probes
M558 P5 C"!io3.in" H10 F300 T6000 ; configure digital probe via slot #0
G31 P500 X0 Y0 Z-0.352 ;-0.269 ;-0.330 ; -0.346 ; -0.345 ; set Z probe trigger value, offset and trigger height

; Endstops
M574 X2 P"io4.in" S1 ; configure X axis endstop
M574 Y2 P"io5.in" S1 ; configure Y axis endstop
;M574 Z2 S2 ; configure Z axis endstop

; Sensors
M308 S0 P"temp0" Y"thermistor" A"Heated Bed" T100000 B4725 C7.06e-8 ; configure sensor #0
M308 S1 P"temp1" Y"pt1000" A"Nozzle" ; configure sensor 1 as PT1000 on pin temp1
M308 S2 P"temp2" Y"thermistor" A"Chamber" T100000 B4725 C7.06e-8    ; configure sensor #2

; Chamber (Fake)
M950 H2 C"out4" T2                            ; create a heater, but not actually anything connected to this output
M141 H2                                       ; set this to be chamber
M141 S0                                       ; set chamber to 0 - normal dont get too hot temperature

; Heaters
M950 H0 C"out0" T0 ; create heater #0
M143 H0 P0 T0 C0 S140 A0 ; configure heater monitor #0 for heater #0
M307 H0 R2.43 D5.5 E1.35 K0.56 B0 ; configure model of heater #0
M950 H1 C"out1" T1 ; create heater #1
M143 H1 P0 T1 C0 S285 A0 ; configure heater monitor #0 for heater #1
M307 H1 R2.43 D5.5 E1.35 K0.56 B0 ; configure model of heater #1

; Heated beds
M140 P0 H0 ; configure heated bed #0

; Fans
M950 F0 C"out2" ; create fan #0
M106 P0 S0 L0 X1 B0.1 ; configure fan #0
M950 F1 C"out3" ; create fan #1
M106 P1 S0 B1.1 H1 T45 ; configure fan #1

M950 F7 C"out7"                        ; create fan #7
M106 P7 C"Exhaust Fan" S0 L0 X1 B0.1   ; configure fan #7
M950 F8 C"out8"                        ; create fan #8
M106 P8 C"Electronics 1" S0 L0 X1 B0.1 ; configure fan #8
M950 F9 C"out9"                        ; create fan #9
M106 P9 C"Electronics2" S0 L0 X1 B0.1  ; configure fan #9

; Mesh Grid
M557 X15:335 Y15:335 P7                          ; define mesh grid 7x7

; Accelerometer
M955 P0 C"spi.cs1+spi.cs0" I56 ; configure accelerometer on board #0

; Input Shaping
;M593 P"MZV" F37.6 S0.0

; Taper
M376 H10

; Pressure Advance
M572 D0 S0.055 ; 0.04

; Tools
M563 P0 S"StealthBurner" D0 H1 F0 ; create tool #0
M568 P0 R0 S0 ; set initial tool #0 active and standby temperatures to 0C

; Miscellaneous
M501
T0 ; select first tool

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.

Solved 3.5.0rc1: Input shaping causes layer shifts!?