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

    Bad Vibrations through printer

    Scheduled Pinned Locked Moved Solved
    Tuning and tweaking
    vibration 1hcl
    7
    31
    1.7k
    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.
    • dc42undefined
      dc42 administrators @samlogan87
      last edited by dc42

      @samlogan87 the only explanation I can think of for why changing the F parameter would resolve the issue regardless of what you change it to is if the TMC driver register that holds that F value (the chopper control register) is getting corrupted somehow, and rewriting that register restores the correct value. If it was just one of the motors that was affected, then I would suspect a faulty driver chip.

      The default value for F is 3. You can read the value in the chopper control register using this command:

      M569.2 P#.0 R{0x6c}

      replacing # by the CAN address of the board. If you haven't changed that F parameter, and assuming you are using x16 microstepping with interpolation, the value returned should be 0x14008053 if the driver has been enabled. The final digit will change with the F parameter, and will be zero if the drive is disabled (e.g. using M18).

      Duet WiFi hardware designer and firmware engineer
      Please do not ask me for Duet support via PM or email, use the forum
      http://www.escher3d.com, https://miscsolutions.wordpress.com

      samlogan87undefined 2 Replies Last reply Reply Quote 0
      • samlogan87undefined
        samlogan87 @dc42
        last edited by

        @dc42 hmm interesting, what could be causing that. I did check what the response was when I sent M569 P10.0 and P11.0 and it gave the valve as per what was set

        Custom Core-XY

        1 Reply Last reply Reply Quote 0
        • samlogan87undefined
          samlogan87 @dc42
          last edited by samlogan87

          @dc42 Hi David,

          I ran what you said plus M569 x.0 without parameters and thats what I got

          5/31/2023, 8:03:13 PM	M569.2 P11.0 R{0x6c}
          Register 0x6c value 0x14008050
          5/31/2023, 8:03:05 PM	M569.2 P10.0 R{0x6c}
          Register 0x6c value 0x14008050
          5/31/2023, 8:01:47 PM	m569 p11.0
          Driver 11.0 runs in reverse, active low enable, mode spreadCycle, ccr 0x0805a, toff 10, tblank 1, thigh 200 (46.9 mm/sec), hstart/hend/hdec 5/0/0, pos 168
          5/31/2023, 8:01:42 PM	m569 p10.0
          Driver 10.0 runs in reverse, active low enable, mode spreadCycle, ccr 0x0805a, toff 10, tblank 1, thigh 200 (46.9 mm/sec), hstart/hend/hdec 5/0/0, pos 184
          
          

          And after enabling the drivers, this is what I get

          5/31/2023, 8:06:39 PM	M569.2 P11.0 R{0x6c}
          Register 0x6c value 0x1400c05a
          5/31/2023, 8:06:35 PM	M569.2 P10.0 R{0x6c}
          Register 0x6c value 0x1400805a
          5/31/2023, 8:06:25 PM	M569 P11.0
          Driver 11.0 runs in reverse, active low enable, mode constant off-time, ccr 0x0805a, toff 10, tblank 1, thigh 200 (46.9 mm/sec), pos 424
          5/31/2023, 8:06:21 PM	M569 P10.0
          Driver 10.0 runs in reverse, active low enable, mode spreadCycle, ccr 0x0805a, toff 10, tblank 1, thigh 200 (46.9 mm/sec), hstart/hend/hdec 5/0/0, pos 248
          

          When they are enabled, they are not the same so not sure if that is anything

          Cheers,
          Sam

          Custom Core-XY

          o_lampeundefined 1 Reply Last reply Reply Quote 0
          • o_lampeundefined
            o_lampe @samlogan87
            last edited by

            @samlogan87 Just want to mention that the 'ccr value' is 0x0805a for both drivers after enabling, but the registers are different.
            Not sure if that has a meaning...

            samlogan87undefined 1 Reply Last reply Reply Quote 0
            • samlogan87undefined
              samlogan87
              last edited by

              Interesting, I started printing and those values change to the same as the odd one after I homed the axis above.

              5/31/2023, 9:36:55 PM	M569.2 P11.0 R{0x6c}
              Register 0x6c value 0x1400c05a
              5/31/2023, 9:36:49 PM	M569.2 P10.0 R{0x6c}
              Register 0x6c value 0x1400c05a
              5/31/2023, 9:36:43 PM	Printing paused at X309.3 Y24.4 Z0.2
              5/31/2023, 9:36:37 PM	M25
              Resume state saved
              5/31/2023, 9:35:13 PM	M32 "0:/gcodes/Film Hole Tester Top Piece.gcode"
              File 0:/gcodes/Film Hole Tester Top Piece.gcode selected for printing
              

              And when I go back and change the F parameter while I have paused the print, they change to what they were before the print started

              5/31/2023, 9:39:39 PM	M569.2 P11.0 R{0x6c}
              Register 0x6c value 0x1400805a
              5/31/2023, 9:39:34 PM	M569.2 P10.0 R{0x6c}
              Register 0x6c value 0x1400805a
              5/31/2023, 9:39:24 PM	M569 P11.0 F10
              5/31/2023, 9:39:20 PM	M569 P10.0 F10
              

              The printer is not quite and does not resonate/vibrate/annoy the wife

              Cheers
              Sam

              Custom Core-XY

              1 Reply Last reply Reply Quote 0
              • samlogan87undefined
                samlogan87 @o_lampe
                last edited by

                @o_lampe Yeah I am not 100% know what all the registers do but something is going wrong when I start a print

                Cheers
                Sam

                Custom Core-XY

                dc42undefined 1 Reply Last reply Reply Quote 0
                • dc42undefined
                  dc42 administrators @samlogan87
                  last edited by

                  @samlogan87 if the driver is in spread cycle mode (the default) then the default value of that register should be 0x14008053 when the driver is enabled and 0x14008050 when it is disabled. The lowest 4 bits are the TOFF time when the driver is enabled, so 0x1400805a would be correct if you used M569 with an F parameter of 10.

                  The value 0x1400c053 would be correct if the driver was put into constant off-time mode using M560 P# D0. I notice that one of your M569 commands did indeed report that the driver was in constant off-time mode:

                  @samlogan87 said in Bad Vibrations through printer:

                  Driver 11.0 runs in reverse, active low enable, mode constant off-time, ccr 0x0805a, toff 10, tblank 1, thigh 200 (46.9 mm/sec), pos 424

                  The driver is put into constant off-time mode using command M569 P# D0 where # is the full address of the driver. Do you have any such commands in your config.g or homing files?

                  What firmware version do you have on your 1HCL boards? Use M115 B11 and M115 B10 to check.

                  Duet WiFi hardware designer and firmware engineer
                  Please do not ask me for Duet support via PM or email, use the forum
                  http://www.escher3d.com, https://miscsolutions.wordpress.com

                  dc42undefined 1 Reply Last reply Reply Quote 0
                  • dc42undefined
                    dc42 administrators @dc42
                    last edited by dc42

                    PS - what I think is happening is:

                    1. You have M569 P10.0 D0 and M569 P11.0 D0 commands somewhere in your homing or config.g files, that are putting the drivers into constantoff-time mode;
                    2. Your motors are noisy when operated in constant off-time mode;
                    3. I have found a bug in the firmware that causes constant off-time mode to be cancelled (reverting to stealthChop mode) when the M569 F parameter is used.

                    Duet WiFi hardware designer and firmware engineer
                    Please do not ask me for Duet support via PM or email, use the forum
                    http://www.escher3d.com, https://miscsolutions.wordpress.com

                    samlogan87undefined 1 Reply Last reply Reply Quote 0
                    • samlogan87undefined
                      samlogan87 @dc42
                      last edited by

                      @dc42 Hi David,

                      Bugger that was it. I hadn't commented out those lines in my homing files from when I had it set up for closed loop homing and calibration. I will try and see if it makes a difference tonight. In the example homing files you have for the 1HCL board, it has those lines M569 #.0 D0, could I make them D3 I think it is for stealthchop?

                      They are both running Duet EXP1HCL firmware version 3.5.0-beta.3 (2023-04-14 13:08:48) not that I think it matters anymore

                      Cheers
                      Sam

                      Custom Core-XY

                      1 Reply Last reply Reply Quote 1
                      • samlogan87undefined
                        samlogan87
                        last edited by

                        Hey everyone,

                        Thanks for your help. It has been sorted. I stupidly did not comment out all of my homing files from disabling all of my closed loop stuff.

                        Cheers
                        Sam

                        Custom Core-XY

                        1 Reply Last reply Reply Quote 0
                        • samlogan87undefined samlogan87 has marked this topic as solved
                        • First post
                          Last post
                        Unless otherwise noted, all forum content is licensed under CC-BY-SA