3.5.0rc1: Input shaping causes layer shifts!?

dc42

@NeoDue the reason I wanted to investigate the blob was that it could have been caused by either incorrect extrusion or by incorrect axis movement, for example a short pause in axis movement; and incorrect axis movement is likely responsible for the layer shifts.

Investigating in depth the lines of GCode you provided has given me a better understand of what your print is doing. As a result I've identified another possible error in the code. Please can you try a print using the new files at https://www.dropbox.com/scl/fo/p0136wx04h8xf6ejwdnn9/h?rlkey=efrfwyb6o5tqid11gustz3uvy&dl=0. I'm interested both in whether there are any layer shifts, and in whether you still see the blobs that only occurred when you enable IS.

Thanks for your patience! You feedback has been invaluable to help me get this far.

NeoDue

@dc42 On the contrary - I have to thank you for taking the time to dive into this problem so deeply! This is what makes owning a Duet so different from the other printer controllers: the dedication of the team behind it.

I will do the test print for you as soon as I can, but unless I am very lucky, it might take until the weekend until I can deliver!

adrian

@dc42
I only had time to run my print again with your new firmware. Layer shifts even worse now.

My first run I forgot to enable IS and it ran fine. With IS on it layer shifted way more frequently than ever before.

m122
=== Diagnostics ===
RepRapFirmware for Duet 3 MB6HC version 3.5.0-rc.3+ (2024-02-19 14:31:56) running on Duet 3 MB6HC v1.02 or later (standalone mode)
Board ID: 08DJM-956BA-NA3TJ-6J1F8-3S06Q-1U86S
Used output buffers: 6 of 40 (40 max)
=== RTOS ===
Static ram: 155208
Dynamic ram: 124316 of which 592 recycled
Never used RAM 62228, free system stack 100 words
Tasks: NETWORK(1,ready,115.5%,162) ETHERNET(5,nWait 7,0.2%,117) ACCEL(6,nWait 6,0.0%,344) HEAT(3,nWait 6,0.2%,321) Move(4,nWait 6,7.8%,214) CanReceiv(6,nWait 1,0.0%,940) CanSender(5,nWait 7,0.0%,334) CanClock(7,delaying,0.1%,334) TMC(4,nWait 6,41.8%,54) MAIN(1,running,238.3%,103) IDLE(0,ready,0.3%,30), total 404.1%
Owned mutexes:
=== Platform ===
Last reset 02:06:49 ago, cause: software
Last software reset at 2024-02-19 20:45, reason: User, Gcodes spinning, available RAM 62324, slot 0
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x00400000 BFAR 0x00000000 SP 0x00000000 Task MAIN Freestk 0 n/a
Error status: 0x04
Aux0 errors 0,1,0
MCU temperature: min 33.8, current 34.3, max 35.3
Supply voltage: min 23.9, current 24.1, max 24.2, under voltage events: 0, over voltage events: 0, power good: yes
12V rail voltage: min 11.7, current 12.1, max 12.8, under voltage events: 0
Heap OK, handles allocated/used 99/0, heap memory allocated/used/recyclable 2048/56/56, gc cycles 0
Events: 0 queued, 0 completed
Driver 0: standstill, SG min 0, mspos 344, reads 49790, writes 21 timeouts 0
Driver 1: standstill, SG min 0, mspos 360, reads 49790, writes 21 timeouts 0
Driver 2: standstill, SG min 0, mspos 536, reads 49792, writes 21 timeouts 0
Driver 3: standstill, SG min 0, mspos 952, reads 49792, writes 21 timeouts 0
Driver 4: standstill, SG min 0, mspos 952, reads 49792, writes 21 timeouts 0
Driver 5: standstill, SG min 0, mspos 952, reads 49792, writes 21 timeouts 0
Date/time: 2024-02-19 22:51:54
Slowest loop: 236.02ms; fastest: 0.05ms
=== Storage ===
Free file entries: 20
SD card 0 detected, interface speed: 25.0MBytes/sec
SD card longest read time 19.3ms, write time 1.8ms, max retries 0
=== Move ===
DMs created 125, segments created 33, maxWait 313188ms, bed compensation in use: mesh, height map offset 0.000, max steps late 1, min interval -13129, bad calcs 1068, ebfmin 0.00, ebfmax 1.00
no step interrupt scheduled
Moves shaped first try 11555, on retry 6745, too short 23528, wrong shape 45799, maybepossible 2852
=== DDARing 0 ===
Scheduled moves 101503, completed 101503, hiccups 456, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], 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 2 -1 -1 -1, ordering errs 0
Heater 0 is on, I-accum = 0.3
Heater 1 is on, I-accum = 0.2
Heater 2 is on, I-accum = 0.0
=== 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) 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
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
Queue2 is idle in state(s) 0
Q0 segments left 0, axes/extruders owned 0x80000007
Code queue 0 is empty
Q1 segments left 0, axes/extruders owned 0x0000000
Code queue 1 is empty
=== CAN ===
Messages queued 68487, received 0, lost 0, errs 36169280, boc 0
Longest wait 0ms for reply type 0, peak Tx sync delay 0, free buffers 50 (min 50), ts 38049/0/0
Tx timeouts 0,0,38048,0,0,30437 last cancelled message type 4514 dest 127
=== Network ===
Slowest loop: 213.93ms; fastest: 0.03ms
Responder states: MQTT(0) HTTP(0) HTTP(2) HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0) Telnet(0)
HTTP sessions: 2 of 8
= Ethernet =
Interface state: active
Error counts: 0 0 13 0 0 0
Socket states: 2 5 3 2 2 0 0 0
=== WiFi ===
Interface state: disabled
Module is disabled
Failed messages: pending 0, notrdy 0, noresp 0
Socket states: 0 0 0 0 0 0 0 0
=== Multicast handler ===
Responder is inactive, messages received 0, responses 0

dc42

@adrian thanks for testing that firmware.

Please can you try the firmware at https://www.dropbox.com/scl/fo/618dnwt7u1gxjs88hxvlg/h?rlkey=efh8iqql2nsbofa0n6k44zktc&dl=0. In this build I have disabled part of the input shaping so that I can determine which part the bug lies in.

dc42

@NeoDue @adrian I've found a likely cause of RRF trying to apply input shaping to moves when it was not possible, which is likely to lead to jerky motion. So please can you try the new firmware at https://www.dropbox.com/scl/fo/p0136wx04h8xf6ejwdnn9/h?rlkey=efrfwyb6o5tqid11gustz3uvy&dl=0.

PS - a check I added has just found an anomaly that I need to fix; so you may wish to wait for a new build from me tomorrow.

adrian

@dc42
I’ll try and test tomorrow with the upcoming version

dc42

@adrian @NeoDue and anyone else having layer shift issues in 3.5.0-rc3 when IS is enabled, please try the new main board binaries at https://www.dropbox.com/scl/fo/p0136wx04h8xf6ejwdnn9/h?rlkey=efrfwyb6o5tqid11gustz3uvy&dl=0.

This version fixes a probable cause of layer shifts in previous versions. It also produces debug output if it detects a malformed movement segment. To avoid having to connect a USB terminal to see any debug messages, you can use the new M111 B parameter. If you are running on any Duet 3 board then I suggest M111 B4096. If you are running on Duet 2 or Maestro then you won't have enough free RAM for that, but you can try M111 B256 and accept that the messages will be truncated.

Please report any debug messages you see here, as well as whether you get any later shifts (and a M122 report at the end of the print if you do).

NeoDue

@dc42 Perfect! And I was lucky and have some time right now. Just a quick question regarding M111: if I use "P1", I get flooded with messages such as

Received 365 bytes
New conn on socket 0 for local port 80
Found responder
Received 378 bytes
New conn on socket 0 for local port 80
Found responder

How can I turn that off?

dc42

@NeoDue don't use P1, use P0. Or don't use P at all. The debug messages I was talking about are sent regardless of the debug enable status.

NeoDue

@dc42 This means "M111 S1 P0 B4096" or "M111 S1 B4096"? Okay, thanks!

edit: 1st "dry" test (print w/o filament, measure x and y offset) ist running right now!

NeoDue

... and once again @dc42 has fulfilled the picture of an electronics wizard that I have of him:

electronics wizard created with hotpot.ai_art-generator.png
(no, I cannot draw at all, this was generated with hotpot.ai art-generator, and I could not get that stupid KI to make the PCB larger)

Three prints up to over 6mm without filament and one with filament, all with Input shaping enabled - and not a single "bang" or layer shift! For the first time ever!

Congratulations, Sir!

As far as I can tell, it seems you have solved the issue!! THANK YOU!

Now I guess I can finally throw all these away

(By the way, the larger blob is still there, however not in the first affected layer but in the other two for some reason. But now the printer simply runs over it, so this is a minor annoyance now and nothing more. I will check if including the retract/unretract command into the print file instead of letting it the Duet do has an effect or such. In case I find something, I will open a new thread for that)

Edit: @adrian @oliof Please also write here if the current version solves the issue for you, then I would mark this as solved

adrian

@NeoDue Testing... Fingers crossed

Update: 35% finished, so far no shifting... I have few more hours to go to complete the print.
Update 2: 46% and going strong...

Checked this morning: finished correctly

Working for me

adrian

@dc42
Newest version works with IS on. It was quieter during infills, as well. Thanks for all your work

NeoDue

@adrian Great! Then @oliof is the last one missing.

balajiramani

@NeoDue I too, previously had layer shifts. With the newer firmware, there are no layer shifts and it works great!

Thank you, @dc42!!

oliof

@NeoDue I did a quick test today and the new version has no issues for me (but that's not worth a lot since I fixed my previous issues with increased current).

NeoDue

@oliof well, maybe you can reduce currents now again

But thanks for the feedback! I will mark the thread as solved then.

Once more @dc42: thank you very, very much for all that detective work you did!

dc42

My thanks to all of you who provided data to help me solve this issue.

balajiramani

I tried a different model and I see the layer shift with the newer firmware.

When I switched back to 3.4.6, It prints fine. So, it looks like the problem still exists.

NeoDue

@balajiramani you need to help me there... where is the layer shift in your picture? I only see some ringing...