3.5.0rc1: Input shaping causes layer shifts!?

[gloomyandy]

@NeoDue Thanks for the picture! Unfortunately it has been resized (I think) so it is hard to see the details. Do both prints have layer shifts? I can see the shift on the right hand print, but I can't see anything very obvious in the left hand one. I'll try and take a look at the gcode tomorrow.

[NeoDue]

@gloomyandy No, the left print was the one without input shaping that was fine.

I also have the result with motor currents increased to the maximum: the additional layere shifts that came from switching to spreadcycle and removing the additional values disappear, but the layer shift at around 2.5...2.65mm stays.

[oliof]

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

But before I start the test: taking the current results into account, and keeping in mind that doing so did not help in the least with 3.5.0RC1, does it make sense to redo this test?

since you took the Marlin values and Marlin uses RMS for current, while RRF uses PEAK did you adjust the current values accordingly? If not you may have set current too low. (convert from RMS to OEAK by multiplying with 1.41)

[NeoDue]

@oliof You are right, I forgot that when I did the last test - which means I can further increase the current.

For the next two days or so, I probably won't be able to redo the test with a higher current, but I will do as soon as I can!

[vaike_peeter]

@dc42 Did test print with same old testfile and it was OK. Moved on to bigger testprint 6,5hour and untill going to sleep it was ok. Then when all small parts where finished and printer stayed to print the tallest one it layershifted at 25.2mm.

My printer config for IS testing is in github repo
New Printfile

Mainboard

M122
=== Diagnostics ===
RepRapFirmware for Duet 3 Mini 5+ version 3.5.0-rc.2+ (2024-01-15 11:56:10) running on Duet 3 Mini5plus Ethernet (standalone mode)
Board ID: KHLQ8-GU8LU-F65J0-409N2-1313Z-H6T1G
Used output buffers: 1 of 40 (31 max)
=== RTOS ===
Static ram: 103168
Dynamic ram: 116396 of which 16 recycled
Never used RAM 18092, free system stack 120 words
Tasks: NETWORK(1,ready,58.4%,182) ETHERNET(5,nWait 7,0.6%,568) HEAT(3,nWait 6,1.2%,326) Move(4,nWait 6,35.1%,239) CanReceiv(6,nWait 1,1.3%,772) CanSender(5,nWait 7,1.1%,327) CanClock(7,delaying,0.2%,348) TMC(4,nWait 6,19.6%,66) MAIN(1,running,233.3%,667) IDLE(0,ready,0.0%,30) AIN(4,delaying,20.9%,256), total 371.6%
Owned mutexes:
=== Platform ===
Last reset 14:54:07 ago, cause: software
Last software reset at 2024-01-21 18:48, reason: User, Gcodes spinning, available RAM 18180, slot 0
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x00487000 BFAR 0xe000ed38 SP 0x00000000 Task MAIN Freestk 0 n/a
Error status: 0x00
Aux0 errors 0,0,0
MCU revision 3, ADC conversions started 53648850, completed 53648850, timed out 0, errs 0
MCU temperature: min 19.3, current 19.7, max 35.7
Supply voltage: min 23.7, current 23.9, max 24.0, under voltage events: 0, over voltage events: 0, power good: yes
Heap OK, handles allocated/used 99/0, heap memory allocated/used/recyclable 2048/460/460, gc cycles 1
Events: 0 queued, 0 completed
Driver 0: standstill, SG min 0, read errors 0, write errors 1, ifcnt 12, reads 4592, writes 16, timeouts 0, DMA errors 0, CC errors 0
Driver 1: standstill, SG min 0, read errors 0, write errors 1, ifcnt 12, reads 4592, writes 16, timeouts 0, DMA errors 0, CC errors 0
Driver 2: standstill, SG min 0, read errors 0, write errors 1, ifcnt 165, reads 4586, writes 21, timeouts 0, DMA errors 0, CC errors 0
Driver 3: standstill, SG min 0, read errors 0, write errors 1, ifcnt 165, reads 4586, writes 21, timeouts 0, DMA errors 0, CC errors 0
Driver 4: standstill, SG min 0, read errors 0, write errors 1, ifcnt 166, reads 4587, writes 21, timeouts 0, DMA errors 0, CC errors 0
Driver 5: not present
Driver 6: not present
Date/time: 2024-01-22 09:43:02
Cache data hit count 4294967295
Slowest loop: 249.94ms; fastest: 0.10ms
=== Storage ===
Free file entries: 20
SD card 0 detected, interface speed: 22.5MBytes/sec
SD card longest read time 5.1ms, write time 155.8ms, max retries 0
=== Move ===
DMs created 83, segments created 37, maxWait 878063ms, bed compensation in use: mesh, height map offset 0.000, max steps late 1, ebfmin 0.00, ebfmax 0.00
no step interrupt scheduled
Moves shaped first try 28164, on retry 45285, too short 186833, wrong shape 464520, maybepossible 38218
=== DDARing 0 ===
Scheduled moves 923872, completed 923872, hiccups 0, stepErrors 0, LaErrors 8, 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, chamber heaters 2 -1 -1 -1, ordering errs 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 0x0000807
Code queue 0 is empty
Q1 segments left 0, axes/extruders owned 0x0000000
Code queue 1 is empty
=== CAN ===
Messages queued 1345257, received 1077788, lost 0, errs 1, boc 0
Longest wait 5ms for reply type 6024, peak Tx sync delay 315, free buffers 26 (min 24), ts 268239/268238/0
Tx timeouts 0,0,0,0,0,0
=== Network ===
Slowest loop: 224.59ms; fastest: 0.03ms
Responder states: MQTT(0) HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0)
HTTP sessions: 1 of 8
= Ethernet =
Interface state: active
Error counts: 0 0 6040 0 0 0
Socket states: 5 2 2 2 2 2 0 0

Toolhead

M122 B121
Diagnostics for board 121:
Duet TOOL1LC rev 1.1 or later firmware version 3.5.0-rc.2 (2023-12-14 08:58:51)
Bootloader ID: SAMC21 bootloader version 2.8 (2023-07-25)
All averaging filters OK
Never used RAM 2696, free system stack 89 words
Tasks: Move(3,nWait,9.7%,71) HEAT(2,nWait,7.0%,91) CanAsync(5,nWait,0.0%,54) CanRecv(3,nWait,2.9%,77) CanClock(5,nWait,0.5%,67) ACCEL(3,nWait,0.0%,53) TMC(2,nWait,79.9%,57) MAIN(1,running,157.6%,316) IDLE(0,ready,0.0%,27) AIN(2,delaying,119.7%,114), total 377.1%
Last reset 14:53:26 ago, cause: software
Last software reset time unknown, reason: OutOfMemory, available RAM 16088, slot 0
Software reset code 0x01c0 ICSR 0x00000000 SP 0x20002770 Task MAIN Freestk 784 ok
Stack: 00004000 00005e8b 00004000 000041cf a5a5a5a5 00004000 a5a5a5a5 a5a5a5a5 a5a5a5a5 0001d199 a5a5a5a5 0001d1b5 a5a5a5a5 00005a4f a5a5a5a5 a5a5a5a5 a5a5a5a5 a5a5a5a5 a5a5a5a5 a5a5a5a5 a5a5a5a5 a5a5a5a5 a5a5a5a5 a5a5a5a5 a5a5a5a5 a5a5a5a5 a5a5a5a5
Driver 0: pos 0, 617.6 steps/mm, standstill, SG min 0, read errors 20, write errors 1, ifcnt 195, reads 1718, writes 15, timeouts 17, DMA errors 0, CC errors 0, failedOp 0x6f, steps req 0 done 50163247
Moves scheduled 856045, completed 856045, in progress 0, hiccups 15615, segs 38, step errors 0, maxLate 1 maxPrep 687, maxOverdue 8978, maxInc 2966, mcErrs 0, gcmErrs 0, ebfmin -1.00 max 1.00
Peak sync jitter -5/9, peak Rx sync delay 260, resyncs 0/0, no timer interrupt scheduled
VIN voltage: min 18.3, current 24.6, max 24.7
MCU temperature: min 30.0C, current 30.4C, max 74.9C
Last sensors broadcast 0x00001002 found 2 137 ticks ago, 0 ordering errs, loop time 0
CAN messages queued 1076931, send timeouts 0, received 1344875, lost 0, errs 328, boc 0, free buffers 18, min 17, error reg 110000
dup 0, oos 0/0/0/0, bm 0, wbm 0, rxMotionDelay 428, adv 35657/74666
Accelerometer: LIS3DH, status: 00
Inductive sensor: not found
I2C bus errors 0, naks 6, contentions 0, other errors 0

[NeoDue]

@oliof @gloomyandy I was lucky and just had the chance to redo the test with increased currents - this time really shifted to the maximum (again no other parameters set, Spreadcycle and Input shaping active).

Result: again layer shifts, starting around 2.5mm. I stopped the print at about 4mm.

[gloomyandy]

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

dit: Just a correction in case someone stumbles over this sometime later: according to https://docs.duet3d.com/en/User_manual/Connecting_hardware/Motors_tuning the M915 T parameter defines TCOOLTHRS, not COOLCONF where the text above belongs.

I think you are correct.

@droftarts I think the documentation may need to change. The gcode dictionary for M915:

Tnnn (optional) Coolstep control register, 16-bit unsigned integer

Does not seem to be correct and likewise the following:

coolStep is configured using the T parameter of M915. This sets the coolStep control register, with a 16-bit unsigned integer. See the stepper driver documentation for sensible values. As coolStep needs to use the motor loads to dynamically adjust the motor current, stallGuard needs to be set up and tuned first. See Stall Detection and Sensorless Homing.

in https://docs.duet3d.com/en/User_manual/Connecting_hardware/Motors_tuning#configuring-coolstep seems wrong to me.

As to what setting M915 T actually does this is my take on it...

Because by default coolstep is disabled by RRF ( the coolstep control register is set to zero as I posted earlier) I think in this case the only impact TCOOLTHRS will have is on stall detection so this part of the 5160 datasheet applies:

TCOOLTHRS ≥ TSTEP
- Stop on stall is enabled, if configured
- Stall output signal (DIAG0/1) is enabled, if configured

However I'm not totally sure what values of TCOOLTHRS actually make sense to use because from the datasheet TSTEP is defined as:

Microstep velocity time reference t for velocities: TSTEP = fCLK / fSTEP

So it is not a simple value to select.

[gloomyandy]

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

@oliof @gloomyandy I was lucky and just had the chance to redo the test with increased currents - this time really shifted to the maximum (again no other parameters set, Spreadcycle and Input shaping active).

Result: again layer shifts, starting around 2.5mm. I stopped the print at about 4mm.

So just to take a step back with spreadcycle enabled and a higher current setting you are now getting a layer shift at 2.5mm? But previously you did not get a shift there, it was higher in the print, is that correct?

Can you also confirm that the gcode file in the very first post of this thread is the one you are currently using for the tests? If so I'll try and take a closer look at it.

[NeoDue]

@gloomyandy first of all (a little offtopic), thanks for forwarding that M915 topic to droftarts! I am actually quite curious what that value means - and how to use it. Maybe an example in the documentation would help there... I suspected you might need to convert the binary or hex value that you can get from the datasheet to a decimal value - but I could not find any confirmation about this, not even here in the forum.

But back to topic: the layer shift is almost exactly in the same area as it was with the original current settings and Spreadcycle enabled. Thus, with this new finding, I suspect that it is the same as noted initially with the tests with RC2 and StealthChop - layer shifts happen, but not in 100% of the cases. Thus, I deem the layer shift not happening at that lower height with the currents slightly risen just a lucky coincidence.

To sum up the results so far as I see them (anything you might read from the M122 reports above not included):

• Stealthchop and Input shaping enabled gives a "bang" and a significant mechanical impulse in y direction at 5.5...5.65mm height, sometimes resulting in a y axis layer shift. The gcode shows quite increased short motions there.
• Spreadcycle and Input shaping results often (but not always) in x layer shifts starting at about 2.5mm - without any obvious reason from the gcode. As might be expected, x axis layer shifts of one hotend do not affect the second one, therefore a miscalculation somewhere can be excluded. Until now, every part printed with that setup up that height showed a y layer shift at 5.5...5.65mm. Higher currents do not seem to reliably change this.
• as soon as Input shaping is deactivated, the part is printed fine, both with StealthChop and Spreadcycle.

The test part I print is indeed the gcode file attached to the first post. y direction is along the longer side of the part, x direction is along the shorter side. (edit: I might need to slightly change the temperatures specified in there soon however since the original filament rolls I used for that file are getting empty now...)

(2nd edit: remark about x layer shift not affecting 2nd hotend added, impulse accompanying bang added)

[dc42]

@NeoDue thanks for your report. Do you still get a bang at the point of the layer shift when running in spreadcycle mode?

[NeoDue]

@dc42 Yes, I still get that sound with Spreadcycle (edit) and Input shaping enabled (/edit) (noted above in the post about the first test with Spreadcycle) but I indeed forgot to mention that in the summary. It seems in relation to the printing noise more silent though. (On the other hand, the printer is quite noisy with Spreadcycle so that might the cause for the observation)

[dc42]

@NeoDue thanks, a bang that isn't related to stealthchop could mean that something is wrong with the step pulse train. However, your M122 reports all show the maximum late steps as 1, so it's not caused by steps being scheduled for times after the move is supposed to finish.

[gloomyandy]

@NeoDue Just to confirm, when you get the layer shift at 2.5mm in spreadcycle, do you hear a bang then or is that only at the layer shift at 5.5mm?

I had a look at the gcode and I could not see anything that was out of the ordinary around the 2.5mm layer height. Could you provide some information about your printer and the print? It looks like it may be an idex of some sort? With your test print I think you use both tools, but looking at the gcode it looks like the first layer shift at 2.5mm happens before the second tool is used, is that correct?

[gloomyandy]

@NeoDue Also what input shaper settings are you currently using when running this test?

[dc42]

@NeoDue I've tried printing your file twice on my E3D toolchanger and didn't get any layer shifts or hear any bangs up to 6mm height, which is where I stopped it. However the adhesion between the top part and the bed wasn't sufficient so that part broke away. I saw it curling up a little before it broke away.

I wasn't using the same config.g settings as you are, so I'll try again with those settings. Please provide your up to date config.g file including the input shaping setting you are using.

[NeoDue]

@gloomyandy Sorry! I forget that you have a lot of communications here and therefore probably do not remember previous discussions

The printer is a Snapmaker J1 (an IDEX printer indeed) where I replaced the original Marlin controller with the Duet. Apart from that, it is mostly as delivered from the factory - exceptions are parts of the hotends and the filament sensors, all not relevant in our case.
The steppers are from a company called Mocotech. You cannot find much about those since they do not seem to sell them separately, but I managed to dig out a datasheet for the y stepper:

Looks pretty standard to me...

The print is a battery box that was sliced in Prusaslicer. Black is printed with hotend 1, green with hotend 2. I did not choose this part deliberately, it simply was the first part I printed after activating Input shaping.

I have tested both of the two Input shaping settings noted in my config.pro, both behave identical in terms of the issue. The bang only happens at the 5.5...5.65mm y axis layer shift, but due to the construction of the printer (classic cartesian XY head printer, just a second printhead added), Y has a signifcantly higher mass which ends up in a much higher impulse than such an effect would have if it occurred on the X axis.

[NeoDue]

@dc42 did you use the config.pro from the post https://forum.duet3d.com/post/332000 ?

Both M593 Input shaping commands are included there and one is active. (There are two since the results from the plugin suggest these two produce identical results and I want to choose the one that creates better results in reality).

[NeoDue]

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

thanks, a bang that isn't related to stealthchop could mean that something is wrong with the step pulse train. However, your M122 reports all show the maximum late steps as 1, so it's not caused by steps being scheduled for times after the move is supposed to finish.

@dc42 thanks for that information. If I translate "step pulse train" correctly, something like this is what I would suspect, judging from what I see. Are there any thinkable cases where such a delayed step might happen without showing up in M122?

I also have an oscilloscope here which is however limited to 10MHz / 1MHz for single shots due to its age (it is an old Tek222). If it helps, I could try to measure something - stepper currents or such, but I am afraid my rusty electronics knowledge needs advice on what might be appropriate or what might be harmful (well, apart from the obvious risk of creating a short circuit... maybe some effects of the capacity of the probe or such ...?

[NeoDue]

@gloomyandy just an update on the M915 T topic: the current rc3 changelog makes it clear: "[Duet 3 MB6HC] [Duet 3 EXP3HC] [Duet 3 EXP1HCL] If you were using the T parameter of the M915 command, this value was incorrectly being written to the stall sensitivity register in previous releases. It is now written to the correct register (COOLCONF)."

This means your initial thought was right after all and the documentation at https://docs.duet3d.com/en/User_manual/Connecting_hardware/Motors_tuning#configuring-coolstep is wrong

[gloomyandy]

@NeoDue Yes we had a discussion about this offline @droftarts I think this section (which mentions using M915 T) may need reviewing: https://docs.duet3d.com/en/User_manual/Connecting_hardware/Motors_tuning#stealthchop-tuning

@NeoDue I thinik that this section is now correct: https://docs.duet3d.com/en/User_manual/Connecting_hardware/Motors_tuning#configuring-coolstep