3.5.0rc1: Input shaping causes layer shifts!?

NeoDue

@dc42 Wow, I did not expect you to work that late! Please call it a day, I do not want to be responsible for stealing your night's rest!

But to answer your question: as safe as I can be from just sitting in front of the printer, looking and listening, there are no blobs of a size that might cause a layer shift (or rather to be precise I did not note any blobs worthy of the name at all). I know from my initial tests with my filament how loud the printer can get while it rumbles over a filament blob without getting stuck, and in addition to watching no blobs, I also do not see any.

What I did notice however is an increased rumbling noise indicating an certain unevenness of the previous layer between layer shifts at times, but that might also be caused by the lack of support caused by the layer shift.

Did you test the print more than once, and up to which height? As can be seen from my tests, the amount of layer shifts varies, therefore I guess it is something that "just about might happen" and therefore I assume it requires a little bit of bad luck to cause a visible effect.

dc42

@NeoDue I am not doing a real print, I am running a bench system. I've run it up to more than 4mm height and so far I have only seen anomalies in the extruder step pulse timing. These anomalies go away if I set pressure advance to zero.

Can you please re-run part of that print with pressure advance set to zero, so that I can determine whether this anomaly is indirectly causing layer shifts or is irrelevant to this issue.

NeoDue

@dc42 okay, I hope I can do the test print this evening when I am home. At latest, it will be tomorrow.

Please try to test up to somewhere above 5.65mm though - the layer shift and bang that occurred at that height was by far the most reliable one.

NeoDue

@dc42 I got home early enough and just did the test print. However it works, commenting out M572 seems to cure the layers shifts that arised due to switching to Spreadcycle, so I guess your finding is indeed part of the solution even if I still could not spot any blobs.

dc42

@NeoDue thanks, that's very useful to know. When I have a fix for that interaction between PA and IS, I'll ask you to run the print again.

NeoDue

@dc42 thanks a lot! Let's see if that layer shift at 5.5..5.65 mm will disappear then as well - that was the only one that still persisted when I just tested. I did see however this time that it was caused when the second hotend was running, so I will investigate that further after you did your magic

gloomyandy

@NeoDue Did you disable any pressure advance on the 2nd hot end?

NeoDue

@gloomyandy yes, my config.g has just one M572 command for both hotends and I commented that one out.

oliof

I did a bit of testing myself to see whether I can reproduce and maybe find some counter measures.

TL;DR: IS makes your machine angry, give it some oomph

I did my testing on a Ratrig V-Minion, a machine that is known for high speed capacity in its stock configuration. My changes: LDO2504 stepper motors on X and Y, and a Fly Super5 H723 board with Fly 2209 steppers.

I originally ran the motors at 1.4A each, and with those I got heavy layershifting with IS and none without running at 5k accel and 900mm/min jerk on a Squircle vase mode test print. I got repeated layer shifts at the same layer heights (0.3mm and 8ish mm), so it was pretty clearly the issue @NeoDue saw.

Then I remembered I checked with Jason from LDO the other week, and the rating on the LDO motors is in RMS, not Peak. So 1400 PEAK is 1000RMS (give or take), or just 40% of the motor performance. I gave the test print a go at 1700 PEAK and the higher layer shift went away completely and the lower layer shift was much less pronounced. At 2000 PEAK the lower shift was almost invisible.

Now, this is with a test print that is pretty benign since except for the concentric infill on the bottom layers it has no sharp corners. But if you have some current you can add to your motors do so. Note that you need to add active cooling at these higher currents.

Next test will be running with 5160s from a 3HC expansion board to see if running the motors at 2.5A PEAK resolves this issue fully or not.

NeoDue

@oliof thanks for that information!

I had tried running my steppers at max current but that did not help at least for the layer shifts @dc42 is working on at the moment. As soon as I get some firmware to test I surely will check if increasing the motor current again might help with the last layer shift.

What I also take from all this testing so far is that StealthChop seems to be more resistant against causing layer shifts with IS than SpreadCycle, at least in some cases.

oliof

@NeoDue I don't understand? I thought a) stealthchop switches to spreadcycle at speeds where IS is relevant, and b) has less torque than spreadcycle to boot.

NeoDue

@oliof First of all, as I have set it in my printer - unless I do the tests here for this issue - , I use Stealthchop (less noisy) but simply do not let the printer switch between modes. See here for the reason: https://forum.duet3d.com/topic/33756/rrf-3-5-0-rc1-shaking-rattling-in-stealthchop/2?_=1707412028143 . In a nutshell: Either use Spreadcycle or use Stealthchop, but do not let the controller switch.

That being said, I also had thought that StealthChop reduces torque. But as you can see from the tests above, I get much more layer shifts if I use Spreadcycle for the x and y steppers than I get using Stealthchop. This and @dc42's claim from his recent bench test that he sees only extruder faults that I assume can only cause layer shifts by causing blobs leads me to the conclusion that for some reason Stealthchop is less affected by such blobs. And this means for some reason Stealthchop must create more torque to overcome these... ¯\_(ツ)_/¯

Edit: this works fine at least for the speeds and accelerations my printer can handle - if it would work for yours however is another thing

dc42

@NeoDue @oliof here is an update, and comment on your recent posts:

I am still working out exactly what isa going wrong, but I believe there are at least two issue with extrusion when input shaping and pressure advance are combined. I haven't got to the bottom of this yet.
Some users have reported "bang" noises from stepper motors when IS is enabled. These could be coming from extruder motors because of the issues I have found with IS+PA.
Using IS should not demand more of the motors when it is configured - if anything it should demand less. So if increasing motor current reduces or eliminates layer shifts that only occur when IS is enabled, most likely it is covering up the underlying issue.
@NeoDue reported that the layer shifts largely went away when pressure advance was disabled. I would welcome more data points on whether disabling PA eliminates layer shifts that only occur when IS is configured.

oliof

@NeoDue I am currently testing at 5k acceleration and 300mm/sec target speed (not always reached on short segments, hence my increase in jerk to 900mm/sec). This is mostly because I know the machine in use can easily reach those speeds and print well enough with Klipper, so I have a comparable baseline for performance and quality.

oliof

@dc42 PA or not has no effect in my testing.

The harsh noises I heard clearly came from the motion system with no blobs in sight. In my testing, the layer shifts were in the Y direction -- most likely because my test machine is a bed slinger so that is where the most weight is.

oliof

@dc42 here is a full video of the print. Disregard the underextrusion, I am outrunning the melt capacity of my hotend.

https://photos.app.goo.gl/SR5cKeJt6jaVshrC8

NeoDue

@dc42 thanks a lot! That lets me hope - I prefer in general to run the steppers with a somewhat reduced current to avoid them getting too hot if the printer is running closed since they are located inside the compartment.

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

@dc42 PA or not has no effect in my testing.

The harsh noises I heard clearly came from the motion system with no blobs in sight. In my testing, the layer shifts were in the Y direction -- most likely because my test machine is a bed slinger so that is where the most weight is.

@oliof Hm, due to the fan noise I could not hear any noise from the motion system in your video (by the way, the printer seems to fast for the camera ). I wonder though if it is coincidence that your printer creates that layer shift in the very moment it is speeding up...

While max speed of my printer is actually a little higher (but I tuned it down for print moves since I found that part strength becomes somewhat reduced when printing that fast) I use only modest jerk and acceleration values since the J1 has rather heavy print heads with a direct drive extruder included, and I made them even heavier by adding more substantial cooling fans... I do fear a bit for the linear guide which is positioned much more off-centre than in your printer.

But: that one layer shift that actually started this topic (height 5.5...5.65mm in my test part) was indeed in Y direction as well, and that one seemed also unaffected by PA, at least it still occurred in my last test for @dc42. On my printer, it is "just" the gantry with the two print heads and their x steppers that is moving there and the Y motor is definitely quite a bit more powerful than the X steppers, therefore I am unsure if that is actually mass related.

But one step after another - first I will wait for @dc42 to find and solve that IS/PA issue, and then (if that layer shift and bang does not vanish from the solution) I will continue tests about that issue.

dc42

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

@dc42 PA or not has no effect in my testing.

The harsh noises I heard clearly came from the motion system with no blobs in sight. In my testing, the layer shifts were in the Y direction -- most likely because my test machine is a bed slinger so that is where the most weight is.

Thanks for that info. Please can you run a print until you have had some of the harsh noises, then send M122 (just once, because sending it resets the data I am interested in) and post the report here.

oliof

@dc42 just after the noises, or at the end of the print? If the latter, here goes:

This is after a print without IS and without Layershift

M122
=== Diagnostics ===
RepRapFirmware for STM32H7 based Boards (fly_super5_h723) version 3.5.0-rc.3+102 (2024-02-05 10:38:45) running on STM32H723 (standalone mode)
Board ID: V1001-042KA-D43WN-6R1DU-YF6XX-70000
Used output buffers: 3 of 40 (29 max)
=== RTOS ===
Static ram: 44872
Dynamic ram: 92640 of which 0 recycled
Never used RAM 105536, free system stack 107 words
Tasks: NETWORK(2,nWait 7,11.5%,197) HEAT(3,nWait 6,0.0%,321) Move(4,nWait 6,1.1%,255) CanReceiv(6,nWait 1,0.0%,427) CanSender(5,nWait 7,0.0%,337) CanClock(7,delaying,0.0%,331) TMC22xx(4,nWait 6,0.7%,113) FSWRITE(2,nWait 4,0.0%,561) MAIN(1,running,86.2%,1094) IDLE(0,ready,0.4%,29), total 100.0%
Owned mutexes: BITIO(TMC22xx)
=== Platform ===
Last reset 00:05:18 ago, cause: software
Last software reset at 2024-02-08 12:10, reason: User, Gcodes spinning, available RAM 109544, slot 0
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x04454000 BFAR 0x00000000 SP 0x00000000 Task MAIN Freestk 0 n/a
Error status: 0x00
MCU temperature: min 36.2, current 37.6, max 37.6
Supply voltage: min 23.8, current 24.2, max 24.3, under voltage events: 1, over voltage events: 0, power good: yes
Heap OK, handles allocated/used 99/0, heap memory allocated/used/recyclable 2048/40/40, gc cycles 0
Events: 0 queued, 0 completed
Driver 0: standstill 2209, SG min 2, reads 25420, writes 6
Driver 1: standstill 2209, SG min 4, reads 25420, writes 6
Driver 2: standstill 2209, SG min 4, reads 25421, writes 6
Driver 3: standstill 2209, SG min 0, reads 25424, writes 2
Driver 4: 
Driver 5: 
Driver 6: 
Driver 7: 
Driver 8: 
Driver 9: 
Driver 10: 
Driver 11: 
Driver 12: 
Driver 13: 
Date/time: 2024-02-08 12:15:49
Slowest loop: 187.18ms; fastest: 0.02ms
=== Storage ===
Free file entries: 20
SD card 0 detected
SD card longest read time 1.3ms, write time 0.0ms, max retries 0
=== Move ===
DMs created 125, segments created 47, maxWait 80978ms, bed compensation in use: none, height map offset 0.000, max steps late 1, min interval 0, bad calcs 0, ebfmin -0.98, ebfmax 1.00
no step interrupt scheduled
Moves shaped first try 0, on retry 0, too short 0, wrong shape 0, maybepossible 0
=== DDARing 0 ===
Scheduled moves 20603, completed 20603, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 1], CDDA state -1
=== 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.3
=== GCodes ===
Movement locks held by null, null
HTTP is idle in state(s) 0
File is idle in state(s) 0
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
Daemon is idle in state(s) 0
Autopause is idle in state(s) 0
File2 is idle in state(s) 0
Queue2 is idle in state(s) 0
Q0 segments left 0, axes/extruders owned 0x80000003
Code queue 0 is empty
Q1 segments left 0, axes/extruders owned 0x0000000
Code queue 1 is empty
=== CAN ===
Messages queued 2747, received 0, lost 0, errs 0, boc 0
Longest wait 0ms for reply type 0, peak Tx sync delay 0 free buffers 50 (min 50), ts 1526/0/0
Tx timeouts 0,0,1526,0,0,1221 last cancelled message type 0 dest 1
=== Network ===
Slowest loop: 181.96ms; fastest: 0.07ms
Responder states: MQTT(0) HTTP(0) HTTP(0) HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0)
HTTP sessions: 1 of 8
Uploads/Errors: 0/0
=== WiFi ===
Interface state: active
Module is connected to access point 
Failed messages: pending 0, notrdy 0, noresp 0
Bad header: 0/0
Firmware version 2.1beta6-01
MAC address 54:43:b2:4a:17:90
Module reset reason: Power up, Vcc 0.00, flash size 4194304, free heap 181412
WiFi IP address 192.168.86.46
Signal strength -47dBm, channel 1, mode 802.11n, reconnections 0
Clock register 00003043
Socket states: 0 0 0 0 0 0 0 0

And this after a print with IS and Layershift

M122
=== Diagnostics ===
RepRapFirmware for STM32H7 based Boards (fly_super5_h723) version 3.5.0-rc.3+102 (2024-02-05 10:38:45) running on STM32H723 (standalone mode)
Board ID: V1001-042KA-D43WN-6R1DU-YF6XX-70000
Used output buffers: 3 of 40 (30 max)
=== RTOS ===
Static ram: 44872
Dynamic ram: 92640 of which 0 recycled
Never used RAM 105536, free system stack 107 words
Tasks: NETWORK(2,nWait 7,11.3%,197) HEAT(3,delaying,0.0%,321) Move(4,nWait 6,1.2%,251) CanReceiv(6,nWait 1,0.0%,427) CanSender(5,nWait 7,0.0%,337) CanClock(7,delaying,0.0%,331) TMC22xx(4,delaying,0.7%,113) FSWRITE(2,nWait 4,0.0%,561) MAIN(1,running,86.3%,1094) IDLE(0,ready,0.4%,29), total 100.0%
Owned mutexes:
=== Platform ===
Last reset 00:10:08 ago, cause: software
Last software reset at 2024-02-08 12:10, reason: User, Gcodes spinning, available RAM 109544, slot 0
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x04454000 BFAR 0x00000000 SP 0x00000000 Task MAIN Freestk 0 n/a
Error status: 0x00
MCU temperature: min 36.9, current 37.5, max 37.7
Supply voltage: min 23.8, current 24.2, max 24.3, under voltage events: 1, over voltage events: 0, power good: yes
Heap OK, handles allocated/used 99/0, heap memory allocated/used/recyclable 2048/72/72, gc cycles 0
Events: 0 queued, 0 completed
Driver 0: standstill 2209, SG min 2, reads 24155, writes 4
Driver 1: standstill 2209, SG min 2, reads 24155, writes 4
Driver 2: standstill 2209, SG min 4, reads 24155, writes 4
Driver 3: standstill 2209, SG min 0, reads 24156, writes 4
Driver 4: 
Driver 5: 
Driver 6: 
Driver 7: 
Driver 8: 
Driver 9: 
Driver 10: 
Driver 11: 
Driver 12: 
Driver 13: 
Date/time: 2024-02-08 12:20:39
Slowest loop: 187.01ms; fastest: 0.02ms
=== Storage ===
Free file entries: 20
SD card 0 detected
SD card longest read time 2.5ms, write time 0.0ms, max retries 0
=== Move ===
DMs created 125, segments created 47, maxWait 129214ms, bed compensation in use: none, height map offset 0.000, max steps late 1, min interval -3020, bad calcs 0, ebfmin -0.97, ebfmax 1.00
no step interrupt scheduled
Moves shaped first try 198, on retry 32, too short 929, wrong shape 15913, maybepossible 258
=== DDARing 0 ===
Scheduled moves 20597, completed 20597, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 1], CDDA state -1
=== 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.3
=== GCodes ===
Movement locks held by null, null
HTTP is idle in state(s) 0
File is idle in state(s) 0
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
Daemon is idle in state(s) 0
Autopause is idle in state(s) 0
File2 is idle in state(s) 0
Queue2 is idle in state(s) 0
Q0 segments left 0, axes/extruders owned 0x80000003
Code queue 0 is empty
Q1 segments left 0, axes/extruders owned 0x0000000
Code queue 1 is empty
=== CAN ===
Messages queued 2610, received 0, lost 0, errs 0, boc 0
Longest wait 0ms for reply type 0, peak Tx sync delay 0 free buffers 50 (min 50), ts 1450/0/0
Tx timeouts 0,0,1450,0,0,1160 last cancelled message type 0 dest 1
=== Network ===
Slowest loop: 181.97ms; fastest: 0.07ms
Responder states: MQTT(0) HTTP(0) HTTP(0) HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0)
HTTP sessions: 1 of 8
Uploads/Errors: 0/0
=== WiFi ===
Interface state: active
Module is connected to access point 
Failed messages: pending 0, notrdy 0, noresp 0
Bad header: 0/0
Firmware version 2.1beta6-01
MAC address 54:43:b2:4a:17:90
Module reset reason: Power up, Vcc 0.00, flash size 4194304, free heap 183532
WiFi IP address 192.168.86.46
Signal strength -47dBm, channel 1, mode 802.11n, reconnections 0
Clock register 00003043
Socket states: 0 0 0 0 0 0 0 0

dc42

@oliof thanks. Can you try a print with IS enabled and PA disabled? I'm interested n the "min interval" field in the Move section, but currently the combination of IS and PA causes this value to be wrong for extruders. I'd like to see what this value is when that interaction isn't present.

Solved 3.5.0rc1: Input shaping causes layer shifts!?