Solved 3.5.0rc1: Input shaping causes layer shifts!?

[NeoDue]

@gloomyandy That test is already running

[NeoDue]

@gloomyandy I got the "T1" from somewhere deep inside this forum when we had our last discussion about the topic ( https://forum.duet3d.com/topic/33756/rrf-3-5-0-rc1-shaking-rattling-in-stealthchop ). But thanks, as you put it, it sounds more logical.

Edit: judging from a finger test of the Y motor temperature, the two settings do not seem to make any difference though.

[NeoDue]

@gloomyandy Confirmation completed: With Spreadcycle enabled, default M569 and M915 settings otherwise and Input shaping turned off as the only change relative to the previous attempts with Spreadcycle, the first 6mm of the part come out perfectly fine.

I need to slightly correct my first Spreadcycle report though - I did not get two but rather four layer shifts then. I added this to the corresponding post above.

[gloomyandy]

@NeoDue That's just my take on what the datasheet says, I've not experimented with any of those settings for COOLSTEP.

[NeoDue]

@gloomyandy No, you are right - see the table on page 71 of the data sheet: "SEMIN - Range 0: disable CoolStep". That means I can obviously discard those M915 commands.

Edit: 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.

That one says:

Set this parameter to disable CoolStep at low speeds, where it 
cannot work reliably. The stall output signal becomes enabled 
when exceeding this velocity. In non-DcStep mode, it becomes 
disabled again once the velocity falls below this threshold.
TCOOLTHRS ≥ TSTEP ≥ THIGH:
- CoolStep is enabled, if configured
- StealthChop voltage PWM mode is disabled
TCOOLTHRS ≥ TSTEP
- Stall output signal (DIAG0/1) is enabled, if configured

To disable CoolStep, that notice can be interpreted as "value needs to be set and very low" - hence the "1", unless I overlooked something the datasheet is unclear about what happens if that value is "0" = not set.

[gloomyandy]

@NeoDue That's interesting, thanks for taking the time to run those tests. I've no idea what may be causing the problem, but I think we have eliminated some possibilities.

The only final test I can think of is for you to try running with input shaping on but to increase the current to your steppers (assuming they are not already on the limit in terms of heat or anything else). We have had a couple of folks that had a similar problem and increasing the current solved the issue. Those cases were not as clear cut as this one though because the firmware change was also associated with other changes so it was not possible to test earlier versions etc. and it may have simply been that the stepper current was not high enough in the first place.

[NeoDue]

@gloomyandy I had tried that as well before making the first post of this thread (noted there). I operate the motors at the same current as the printer manufacturer does. There is not that much much left until I reach the specified value...

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?

[gloomyandy]

@NeoDue I hesitated to ask you to run this test, but I'm puzzled as to why switching to spreadcycle made things worse and one possibility would be that in some situations the current setting is not enough. I guess the good news is that it sounds like you are currently seeing the problem pretty early on in the test so hopefully you would not need to run it for very long? But obviously it is your call, maybe hold off on running that test for now?

One further request could you post a picture of the print so we can see roughly where the layer shitf(s) happen? If you look at the print in the slicer is there anything obviously "different" about those parts of the prints to other sections of it (or other prints that have been ok)? I know you mentioned that the code had a lot of acceleration/deceleration changes in the previous area you looked at, it would be interesting to see if that was also the case with the new shifts.

I've not been able to look at the actual gcode you uploaded (I don't have easy access to tools for doing that at the moment), are you using slicer based control of acceleration/deceleration? If so that may be something else for us to consider. If you can identify a possible location within the file where the shift happens, could you post a sample of the sort of gcode that has been generated?

Thanks again.

[NeoDue]

@gloomyandy Okay, understood I will crank up motor currents and repeat the tests as you asked for.

First of all, here is a picture of the last print and one of the previous ones:
20240120_233631.jpg

If you open the gcode file I supplied in a gcode viewer, you will note at the most critical point (height 5.5mm and a bit above), Prusaslicer created numerous short short moves in a row, probably to even out line thicknesses.

At layer height 2...2.8mm where the prints with Spreadcycle started to fail, I cannot see any difference from the layers below, they are just a rounded rectangle with infill.

[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)