Solved 3.5.0rc1: Input shaping causes layer shifts!?
-
@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.
-
@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.
