Duet3D Logo Duet3D
    • Tags
    • Documentation
    • Order
    • Register
    • Login

    3.5.0rc1: Input shaping causes layer shifts!?

    Scheduled Pinned Locked Moved Solved
    Beta Firmware
    19
    196
    15.3k
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • NeoDueundefined
      NeoDue @gloomyandy
      last edited by

      @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.

      gloomyandyundefined 1 Reply Last reply Reply Quote 0
      • gloomyandyundefined
        gloomyandy @NeoDue
        last edited by

        @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 … 15
        

        So a value of 0 will disable CoolStep but 1 will have it enabled. The RRF default is to set the COOLCONF register to 0.

        NeoDueundefined 1 Reply Last reply Reply Quote 0
        • NeoDueundefined
          NeoDue @gloomyandy
          last edited by

          @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 Spreadcycle
          

          Got 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
          
          gloomyandyundefined 1 Reply Last reply Reply Quote 0
          • gloomyandyundefined
            gloomyandy @NeoDue
            last edited by

            @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?

            NeoDueundefined 2 Replies Last reply Reply Quote 0
            • NeoDueundefined
              NeoDue @gloomyandy
              last edited by

              @gloomyandy That test is already running 🙂

              1 Reply Last reply Reply Quote 1
              • NeoDueundefined
                NeoDue @gloomyandy
                last edited by 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.

                gloomyandyundefined 1 Reply Last reply Reply Quote 0
                • NeoDueundefined
                  NeoDue @gloomyandy
                  last edited by 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.

                  gloomyandyundefined 1 Reply Last reply Reply Quote 0
                  • gloomyandyundefined
                    gloomyandy @NeoDue
                    last edited by

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

                    NeoDueundefined 1 Reply Last reply Reply Quote 0
                    • NeoDueundefined
                      NeoDue @gloomyandy
                      last edited by 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.

                      1 Reply Last reply Reply Quote 0
                      • gloomyandyundefined
                        gloomyandy @NeoDue
                        last edited by

                        @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.

                        NeoDueundefined 1 Reply Last reply Reply Quote 0
                        • NeoDueundefined
                          NeoDue @gloomyandy
                          last edited by

                          @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?

                          gloomyandyundefined oliofundefined 2 Replies Last reply Reply Quote 0
                          • gloomyandyundefined
                            gloomyandy @NeoDue
                            last edited by

                            @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.

                            NeoDueundefined 1 Reply Last reply Reply Quote 0
                            • NeoDueundefined
                              NeoDue @gloomyandy
                              last edited by

                              @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.

                              gloomyandyundefined 1 Reply Last reply Reply Quote 0
                              • gloomyandyundefined
                                gloomyandy @NeoDue
                                last edited by

                                @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.

                                NeoDueundefined 1 Reply Last reply Reply Quote 0
                                • NeoDueundefined
                                  NeoDue @gloomyandy
                                  last edited by 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.

                                  1 Reply Last reply Reply Quote 0
                                  • oliofundefined
                                    oliof @NeoDue
                                    last edited by 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)

                                    <>RatRig V-Minion Fly Super5Pro RRF<> V-Core 3.1 IDEX k*****r <> RatRig V-Minion SKR 2 Marlin<>

                                    NeoDueundefined 1 Reply Last reply Reply Quote 1
                                    • NeoDueundefined
                                      NeoDue @oliof
                                      last edited by

                                      @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!

                                      NeoDueundefined 1 Reply Last reply Reply Quote 2
                                      • vaike_peeterundefined
                                        vaike_peeter @dc42
                                        last edited by

                                        @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
                                        Printed parts image1
                                        Printed parts image2

                                        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
                                        
                                        1 Reply Last reply Reply Quote 0
                                        • NeoDueundefined
                                          NeoDue @NeoDue
                                          last edited by

                                          @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.

                                          gloomyandyundefined 2 Replies Last reply Reply Quote 0
                                          • gloomyandyundefined
                                            gloomyandy @NeoDue
                                            last edited by

                                            @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.

                                            NeoDueundefined 1 Reply Last reply Reply Quote 0
                                            • First post
                                              Last post
                                            Unless otherwise noted, all forum content is licensed under CC-BY-SA