3.5.0rc1: Input shaping causes layer shifts!?
-
@NeoDue Thanks for running that test, I notice that you have a number of custom driver settings using M569 and M915, how did you choose those values?
-
@gloomyandy yes, you are right - my X and Y steppers are set with an M569 P0.0 S0 F4 Y1:2 D2 H5 V25.
This means:- F4 = off-time 4 - the Duet default value is F3, the value that was set by Snapmaker was F6. I settled with something in between that worked and "sounded good". According to the TMC data sheet, the value does not play a role in StealthChop anyway.
- Y1:2 Hysteresis start and end values in the chopper control register --> taken from the original Marlin code for the TMC2209 drivers since the datasheets claim those have the same range for both drivers. I admit the code I had to go through was more than chaotic, but I hoped for the best and it... well, worked, that is why I left those values. Again, according to the TMC data sheet, these do not play a role in StealthChop.
- V25 = tpwmthrs: first of all, the TMC steppers do create issues when dynamicly switching from StealthChop over to SpreadCycle, as Oliof correctly pointed out. Since I know that the TMC steppers on the original controller board of my printer use StealthChop all the time, I went to mimick that behaviour and followed the advice from @dc42 given here: https://forum.duet3d.com/topic/22436/missing-steps-cant-print-spreadcycle-stealthchop-tuning-help/131 --> in order to not switch over to Spreadcycle, I set V25 which translates to 375mm/s - which then is high enough never to leave StealthChop mode.
-
@NeoDue @oliof I'm a little surprised that using spreadcycle made the problem worse. Usually as mentioned above spreadcycle is a more "powerful" mode and tends to have less issues with lost steps.
I wonder if any of the custom settings you have (that would then have been enabled) could have come into play?
It looks like you have enabled CoolStep with M915 T1. My understanding of how that works is that with the settings you have the motor current could be reduced to 50% of the selected value if the motor loading during the previous moves is low. I wonder if that might be causing problems with your print?
@NeoDue If you can face another test print it may be worth using the default RRF spreadcycle settings with no special timing and no coolstep options?
Just to explain why I'm asking about all of this... There have been very few reports of this problem from others, this may mean that there is something in your configuration that makes the problem more likely to show up.
-
@gloomyandy Yes, I understand
As noted above, I had tried that for the Y axis alone with RC1 (did not help back then), but I will retry right now.From my understanding, M915 T1 effectively turns off Coolstep, that is the reason for these lines.
-
@NeoDue From my reading of the code and of the TMC 5160 datasheet a value of 1 will be setting the lowest bit of the COOLCONF register which will set the SEMIN value to 1. The datasheet says:
If the StallGuard2 result falls below SEMIN*32, the motor current becomes increased to reduce motor load angle. %0000: smart current control CoolStep off %0001 … %1111: 1 … 15So a value of 0 will disable CoolStep but 1 will have it enabled. The RRF default is to set the COOLCONF register to 0.
-
@gloomyandy That went fast - tested with the following stepper settings:
M569 P0.0 S0 D2 ; testweise auf Spreadcycle umgestellt. M569 P0.1 S1 D2 ; testweise auf Spreadcycle umgestellt. M569 P0.2 S1 D2 ; Antrieb an DRIVER_2 (Z) läuft vorwärts mit Spreadcycle M569 P0.3 S0 D2 ; testweise auf Spreadcycle umgestellt. M569 P0.4 S0 D2 ; Antrieb an DRIVER_2 (E1) läuft rückwärts mit Spreadcycle M569 P0.5 S1 D2 ; Antrieb an DRIVER_3 (E2) läuft vorwärts mit SpreadcycleGot the same layer shift in x direction again, this time a little earlier at 2.2mm and aborted the test...
M122 === Diagnostics === RepRapFirmware for Duet 3 MB6HC version 3.5.0-rc.2+ (2024-01-15 11:56:21) running on Duet 3 MB6HC v1.02 or later (standalone mode) Board ID: 08DJM-956BA-NA3TN-6JTDL-3SN6L-998UU Used output buffers: 11 of 40 (40 max) === RTOS === Static ram: 155184 Dynamic ram: 122892 of which 0 recycled Never used RAM 64436, free system stack 130 words Tasks: NETWORK(2,nWait 7,15.7%,208) HEAT(3,nWait 1,0.0%,323) Move(4,nWait 6,2.6%,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.8%,56) MAIN(1,running,71.3%,103) IDLE(0,ready,0.6%,30), total 100.0% Owned mutexes: WiFi(NETWORK) === Platform === Last reset 00:36:51 ago, cause: software Last software reset at 2024-01-20 20:43, reason: User, Gcodes spinning, available RAM 64292, slot 1 Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0044a000 BFAR 0x00000000 SP 0x00000000 Task MAIN Freestk 0 n/a Error status: 0x04 Aux0 errors 0,0,0 MCU temperature: min 42.4, current 46.6, max 46.7 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.7, under voltage events: 0 Heap OK, handles allocated/used 99/3, heap memory allocated/used/recyclable 2048/1448/1396, gc cycles 6 Events: 0 queued, 0 completed Driver 0: standstill, SG min 0, mspos 200, reads 16312, writes 29 timeouts 0 Driver 1: standstill, SG min 0, mspos 232, reads 16312, writes 29 timeouts 0 Driver 2: standstill, SG min 0, mspos 296, reads 16318, writes 23 timeouts 0 Driver 3: standstill, SG min 0, mspos 792, reads 16319, writes 23 timeouts 0 Driver 4: standstill, SG min 0, mspos 906, reads 16323, writes 19 timeouts 0 Driver 5: standstill, SG min 0, mspos 42, reads 16323, writes 19 timeouts 0 Date/time: 2024-01-20 21:20:11 Slowest loop: 212.34ms; fastest: 0.05ms === Storage === Free file entries: 17 SD card 0 detected, interface speed: 25.0MBytes/sec SD card longest read time 4.3ms, write time 2.8ms, max retries 0 === Move === DMs created 125, segments created 26, maxWait 138976ms, bed compensation in use: none, height map offset 0.000, max steps late 1, ebfmin -1.00, ebfmax 1.00 no step interrupt scheduled Moves shaped first try 8, on retry 803, too short 4102, wrong shape 32067, maybepossible 2863 === DDARing 0 === Scheduled moves 64822, completed 64822, hiccups 0, 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 -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) 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 doing "G4 S1" in state(s) 0 0, running macro 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 0x8000000f Code queue 0 is empty Q1 segments left 0, axes/extruders owned 0x0000000 Code queue 1 is empty === Filament sensors === check 23245648 clear 1679404 Extruder 0 sensor: ok Extruder 1 sensor: ok === CAN === Messages queued 19891, received 0, lost 0, errs 10499544, boc 0 Longest wait 0ms for reply type 0, peak Tx sync delay 0, free buffers 50 (min 50), ts 11056/0/0 Tx timeouts 0,0,11055,0,0,8834 last cancelled message type 30 dest 127 === Network === Slowest loop: 106.55ms; fastest: 0.00ms Responder states: MQTT(0) HTTP(0) HTTP(0) 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 225160 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 -
@NeoDue Interesting, though it is a bit concerning though that this seems to be a different layer shift to what you were seeing with your original settings. Can you try disabling input shaping and see if this "new" layer shift goes away?
-
@gloomyandy That test is already running
-
@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.
-
@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.
-
@NeoDue That's just my take on what the datasheet says, I've not experimented with any of those settings for COOLSTEP.
-
@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 configuredTo 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.
-
@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.
-
@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?
-
@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.
-
@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.jpgIf 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.
-
@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.
-
@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.
-
@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)
-
@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!
