3.5.0rc1: Input shaping causes layer shifts!?
-
@dc42 [2nd part of message]
And here is the M122 readout, taken about a mm (6..7 layers) after the layer shift occurred:
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: 7 of 40 (34 max) === RTOS === Static ram: 155184 Dynamic ram: 123028 of which 0 recycled Never used RAM 64156, free system stack 122 words Tasks: NETWORK(2,nWait 7,15.4%,228) HEAT(3,nWait 1,0.0%,321) Move(4,nWait 6,2.7%,214) 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.9%,56) MAIN(1,running,71.5%,103) IDLE(0,ready,0.4%,30), total 100.0% Owned mutexes: WiFi(NETWORK) === Platform === Last reset 01:16:09 ago, cause: software Last software reset at 2024-01-19 23:05, reason: User, Gcodes spinning, available RAM 64316, slot 2 Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0044a000 BFAR 0x00000000 SP 0x00000000 Task MAIN Freestk 0 n/a Error status: 0x00 Aux0 errors 0,0,0 MCU temperature: min 45.6, current 47.3, max 47.6 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/1420/1368, gc cycles 13 Events: 0 queued, 0 completed Driver 0: standstill, SG min 0, mspos 216, reads 27266, writes 28 timeouts 0 Driver 1: ok, SG min 0, mspos 453, reads 27266, writes 28 timeouts 0 Driver 2: standstill, SG min 0, mspos 984, reads 27271, writes 23 timeouts 0 Driver 3: ok, SG min 0, mspos 794, reads 27268, writes 26 timeouts 0 Driver 4: ok, SG min 0, mspos 306, reads 27275, writes 19 timeouts 0 Driver 5: standstill, SG min 0, mspos 714, reads 27276, writes 19 timeouts 0 Date/time: 2024-01-20 00:21:28 Slowest loop: 212.54ms; fastest: 0.05ms === Storage === Free file entries: 17 SD card 0 detected, interface speed: 25.0MBytes/sec SD card longest read time 4.6ms, write time 2.8ms, max retries 0 === Move === DMs created 125, segments created 32, maxWait 119504ms, bed compensation in use: none, height map offset 0.000, max steps late 1, ebfmin -1.00, ebfmax 1.00 next step interrupt due in 326 ticks, disabled Moves shaped first try 21, on retry 2279, too short 16527, wrong shape 66349, maybepossible 10398 === DDARing 0 === Scheduled moves 139469, completed 139424, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state 3 === 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 Heater 2 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) 3 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 S10" 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, sync state 1 Queue2 is idle in state(s) 0 Q0 segments left 10, axes/extruders owned 0x4000000e Code queue 0 is empty Q1 segments left 0, axes/extruders owned 0x0000000 Code queue 1 is empty === Filament sensors === check 50750242 clear 353671 Extruder 0 sensor: ok Extruder 1 sensor: ok === CAN === Messages queued 41120, received 0, lost 0, errs 21703023, boc 0 Longest wait 0ms for reply type 0, peak Tx sync delay 0, free buffers 50 (min 50), ts 22850/0/0 Tx timeouts 0,0,22849,0,0,18269 last cancelled message type 30 dest 127 === Network === Slowest loop: 103.88ms; fastest: 0.00ms Responder states: MQTT(0) HTTP(0) HTTP(2) 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 221836 WiFi IP address 192.168.178.31 Signal strength -62dBm, 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 0The layer shift (in y axis direction) occurred at 5.5 or 5.65mm height. It might be worth to point out though that while I got a layer shift of several millimeters with rc1, now it is only some tenths of a millimeter.
Luckily, I sat directly at the printer and watched it while that happened. One thing is worth noting:
I got an audible low-frequency-"bang" from the printer twice around this height and the whole table (which is a solid 40kg wood plate mounted on electric frame) was shaking - something it only does if the y axis does some really hefty acceleration or deceleration. One of these "bangs" created the small layer shift. The printer was printing one of the inner perimeters of the outside surface of the print and did not cross any perimeters or holes in the structure at the time.
Please note no protruding material or such was there that might have blocked the nozzle, and the noise was also quite different from when that happens - such a print error usually creates more of a"rumbling" noise on my printer, with a higher-pitched "klack" or rattling noise if the motor looses one or more steps that it wants to make.
If I would have to conclude what might have created that noise, I would say the Y axis got... well... delayed and had to hurry to catch up, if that does make any sense... -
@NeoDue you need to switch to spreadcycle to avoid the bangs which happens when stealth chop switches modes, change M569 to use D2 rather than D3.
-
@oliof Thanks, but a bang that happens only with Input shaping active has nothing to do with StealthChop unless I overlook something serious. Apart from that, I already had this problem and had solved it - take a look at the additional V parameter in my config.g, that switch you mention never happens
I rather fathom if dc42 can find why I have such an amount of CAN errors (without actually using CAN for anything, probably apart from internal Duet communication...?) the problem might vanish.
-
@NeoDue if the switch never happens you reduce the attainable torque of your motors. You really want spreadcycle for faster motion.
-
@NeoDue said in 3.5.0rc1: Input shaping causes layer shifts!?:
@oliof Thanks, but a bang that happens only with Input shaping active has nothing to do with StealthChop unless I overlook something serious. Apart from that, I already had this problem and had solved it - take a look at the additional V parameter in my config.g, that switch you mention never happens
I think it would be worth running a test to be sure. Do you still get the layer shift if you run the same print with the motors in Spreadcycle? If not that might help us determine what is causing the layer shift. It may be that something in the way the IS pulses are generated is triggering a mode switch.
-
@oliof Well, I simply copied the behaviour of the original Snapmaker Marlin board there which probably means they chose the motors accordingly, and I do not have any issues obviously resulting from lacking motor torque. On the contrary - the printer is very well capable of getting the nozzle over significant buildups in the currnet configuration which makes me more fear for the linear bearings
Therefore I do not see any need for Spreadcycle. The only thing that does is making the printer noisy, at least for the speeds I am running at.
But you are right: the basic noise did sound like the "StealthChop -->SpreadCycle-Bang".@gloomyandy I will test that. One more thing: I did a second print over night, and is seems the layer shift does not occur as reliable as it did with rc1. Therefore I will rather focus on whether the "bang" will occur or not since that seems to be an indication of the primary fault which then may cause the shift, okay?
-
@gloomyandy I just ran the test with every "M69...D3..." in the above config replaced with an "M569... D2...", and I got a layer shift of about 1,5mm in x direction at 2.8mm height. Here is the M122 message:
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: 13 of 40 (33 max) === RTOS === Static ram: 155184 Dynamic ram: 122892 of which 0 recycled Never used RAM 64436, free system stack 134 words Tasks: NETWORK(2,nWait 7,15.8%,172) HEAT(3,nWait 1,0.0%,321) Move(4,nWait 6,2.7%,218) 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.0%,103) IDLE(0,ready,0.6%,30), total 100.0% Owned mutexes: WiFi(NETWORK) === Platform === Last reset 00:35:43 ago, cause: software Last software reset at 2024-01-20 17:07, reason: User, Gcodes spinning, available RAM 65188, slot 0 Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0044a000 BFAR 0x00000000 SP 0x00000000 Task MAIN Freestk 0 n/a Error status: 0x00 Aux0 errors 0,0,0 MCU temperature: min 41.9, current 46.2, max 46.4 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.6, under voltage events: 0 Heap OK, handles allocated/used 99/3, heap memory allocated/used/recyclable 2048/848/796, gc cycles 6 Events: 0 queued, 0 completed Driver 0: standstill, SG min 0, mspos 968, reads 34287, writes 32 timeouts 0 Driver 1: standstill, SG min 0, mspos 232, reads 34287, writes 32 timeouts 0 Driver 2: ok, SG min 0, mspos 344, reads 34296, writes 23 timeouts 0 Driver 3: standstill, SG min 0, mspos 904, reads 34294, writes 26 timeouts 0 Driver 4: standstill, SG min 0, mspos 750, reads 34301, writes 19 timeouts 0 Driver 5: ok, SG min 0, mspos 630, reads 34301, writes 19 timeouts 0 Date/time: 2024-01-20 17:43:20 Slowest loop: 210.67ms; fastest: 0.05ms === Storage === Free file entries: 18 SD card 0 detected, interface speed: 25.0MBytes/sec SD card longest read time 4.4ms, write time 2.8ms, max retries 0 === Move === DMs created 125, segments created 26, maxWait 147856ms, bed compensation in use: none, height map offset 0.000, max steps late 1, ebfmin -1.00, ebfmax 1.00 next step interrupt due in 19 ticks, disabled Moves shaped first try 8, on retry 806, too short 4137, wrong shape 32361, maybepossible 2891 === DDARing 0 === Scheduled moves 65368, completed 65308, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state 3 === 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.2 Heater 1 is on, I-accum = 0.3 === 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) 3 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, sync state 1 Queue2 is idle in state(s) 0 Q0 segments left 1, axes/extruders owned 0x80000007 Code queue 0 is empty Q1 segments left 0, axes/extruders owned 0x0000000 Code queue 1 is empty === Filament sensors === check 23485446 clear 403402 Extruder 0 sensor: ok Extruder 1 sensor: ok === CAN === Messages queued 19281, received 0, lost 0, errs 10170873, boc 0 Longest wait 0ms for reply type 0, peak Tx sync delay 0, free buffers 50 (min 50), ts 10717/0/0 Tx timeouts 0,0,10716,0,0,8563 last cancelled message type 30 dest 127 === Network === Slowest loop: 203.98ms; 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 225180 WiFi IP address 192.168.178.31 Signal strength -63dBm, 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 0I will let the print run on until it reaches the height where got issues before and add the result to this post.
Edit:
a second layer shift occurred as expected - same height and same direction (y) as in the test above, again with a "bang" (which did however sound more silent as when I use StealthChop.
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: 13 of 40 (40 max) === RTOS === Static ram: 155184 Dynamic ram: 122892 of which 0 recycled Never used RAM 64292, free system stack 134 words Tasks: NETWORK(2,nWait 7,15.4%,172) HEAT(3,nWait 1,0.0%,321) Move(4,nWait 6,2.6%,214) CanReceiv(6,nWait 1,0.0%,940) CanSender(5,nWait 7,0.0%,334) CanClock(7,delaying,0.0%,334) TMC(4,nWait 6,10.0%,56) MAIN(1,running,71.7%,103) IDLE(0,ready,0.2%,30), total 100.0% Owned mutexes: WiFi(NETWORK) === Platform === Last reset 01:17:48 ago, cause: software Last software reset at 2024-01-20 17:07, reason: User, Gcodes spinning, available RAM 65188, slot 0 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 46.1, current 47.2, max 47.5 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/1900/1848, gc cycles 13 Events: 0 queued, 0 completed Driver 0: standstill, SG min 0, mspos 200, reads 7160, writes 0 timeouts 0 Driver 1: ok, SG min 0, mspos 248, reads 7160, writes 0 timeouts 0 Driver 2: standstill, SG min 0, mspos 856, reads 7159, writes 0 timeouts 0 Driver 3: ok, SG min 0, mspos 155, reads 7160, writes 0 timeouts 0 Driver 4: ok, SG min 0, mspos 558, reads 7160, writes 0 timeouts 0 Driver 5: standstill, SG min 0, mspos 150, reads 7160, writes 0 timeouts 0 Date/time: 2024-01-20 18:25:25 Slowest loop: 5.71ms; fastest: 0.07ms === Storage === Free file entries: 18 SD card 0 detected, interface speed: 25.0MBytes/sec SD card longest read time 4.2ms, write time 0.0ms, max retries 0 === Move === DMs created 125, segments created 32, maxWait 8579ms, bed compensation in use: none, height map offset 0.000, max steps late 1, ebfmin -1.00, ebfmax 1.00 next step interrupt due in 65 ticks, disabled Moves shaped first try 11, on retry 1436, too short 12206, wrong shape 33206, maybepossible 7359 === DDARing 0 === Scheduled moves 137991, completed 137931, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state 3 === 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 Heater 2 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 doing "G1 X-14.075 Y-6.155 E.00556" 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, sync state 1 Queue2 is idle in state(s) 0 Q0 segments left 1, axes/extruders owned 0x4000000e Code queue 0 is empty Q1 segments left 0, axes/extruders owned 0x0000000 Code queue 1 is empty === Filament sensors === check 51690012 clear 403402 Extruder 0 sensor: ok Extruder 1 sensor: ok === CAN === Messages queued 22723, received 0, lost 0, errs 11996865, boc 0 Longest wait 0ms for reply type 0, peak Tx sync delay 0, free buffers 50 (min 50), ts 12624/0/0 Tx timeouts 0,0,12624,0,0,10099 last cancelled message type 30 dest 127 === Network === Slowest loop: 20.30ms; fastest: 0.07ms Responder states: MQTT(0) HTTP(2) 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 220964 WiFi IP address 192.168.178.31 Signal strength -60dBm, channel 2, mode 802.11n, reconnections 0 Clock register 00002002 Socket states: 5 0 0 0 0 0 0 0 === Multicast handler === Responder is inactive, messages received 0, responses 0(edit: corrected height of 1st layer shift)
(2nd edit: I just saw that I did two additional smaller layer shifts in Y between the two that are mentioned in this post, so there are four in total) -
@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.
