Navigation

    Duet3D Logo

    Duet3D

    • Register
    • Login
    • Search
    • Categories
    • Tags
    • Documentation
    • Order

    Microstepping pros/cons

    Tuning and tweaking
    6
    16
    5613
    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.
    • briangilbert
      briangilbert last edited by

      I have 0.9 degree steppers and have set my board to use 128x microstepping (M350 X128 I0)

      So far with my test prints I have noticed no issues with doing this, wondering if there are good reasons to use the lower or higher settings?

      1 Reply Last reply Reply Quote 0
      • curieos
        curieos last edited by

        Max speed is hampered with higher steps per mm values, so when you use high step per degree motors and high micro stepping the max speed is slower because the processor can't generate step signals fast enough. Also there are some problems with holding torque on finer step divisions I think but I don't know as much about this as dc or others.

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

          The issue you are likely to face is that at high travel speeds, the electronics can't generate the steps fast enough. because so many of them are needed. This will have two effects. The first is that the motors won't move as fast as you asked. The second is that the printer won't respond to any inputs for the duration of a high speed move, which could cause the web interface to disconnect.

          For example, suppose you do a pure Z movement at 300mm/sec. If your machine has 16t pulleys then it will have 1600 microsteps/mm so each of the 3 stepper motors needs stepping at 480kHz. But the maximum frequency at which the Duet WiFi seems to be able to step all 3 motors is a little lower than that.

          You can tell when you have hit the limit, because the speed won't go up as you request higher speeds. Also take a look at the "MaxReps" figure in the M122 output after high speed moves. If it goes above about 100 then you should reduce speed or microstepping.

          The fix for this will be dynamically-varying microstepping, which is on my firmware list.

          1 Reply Last reply Reply Quote 0
          • roboduet
            roboduet last edited by

            @dc42:

            Also take a look at the "MaxReps" figure in the M122 output after high speed moves. If it goes above about 100 then you should reduce speed or microstepping.

            Is it OK that I have [c]MaxReps: 5, StepErrors: 0. Underruns: 38[/c] after print?

            Is description for this diagnostic parameters available?

            I'm using the following settings:

            [[language]]
            M350 X16 Y16 Z16 E16 I1 
            M92 X100 Y100 Z100
            
            
            1 Reply Last reply Reply Quote 0
            • briangilbert
              briangilbert last edited by

              M350 X128 I100 ; Set 128x microstepping without interpolation

              M122 After a 30 minute print:

              [[language]]
              Diagnostics
              Used output buffers: 2 of 32 (5 max)
              Platform Diagnostics:
              Memory usage:
              Program static ram used: 13040
              Dynamic ram used: 60224
              Recycled dynamic ram: 464
              Current stack ram used: 2728
              Maximum stack ram used: 7772
              Never used ram: 49572
              Last reset 00:45:34 ago, cause: power up
              Error status: 0
              Bed probe heights: -0.466 -0.165 -0.180 -0.389 -0.604 -1.221 -0.480 -0.231 -0.276 -0.454 -0.541 -0.669 -0.327 0.000 0.000 0.000
              Free file entries: 10
              SD card interface speed: 20.0MBytes/sec
              SD card longest block write time: 0.0ms
              MCU temperature: min 17.0, current 33.6, max 37.7
              Supply voltage: min 11.5, current 11.8, max 12.0
              Slowest main loop (seconds): 0.184937; fastest: 0.000000
              Move Diagnostics:
              MaxReps: 12, StepErrors: 0\. Underruns: 0
              Heat Diagnostics:
              Bed heater = 0, chamber heater = -1
              Heater 0 is on, I-accum = 0.0
              Heater 1 is on, I-accum = 2.0
              GCodes Diagnostics:
              Move available? no
              Stack pointer: 0 of 5
              macro is idle
              http is ready with "M122"
              telnet is idle
              serial is idle
              aux is idle
              file is idle
              Network Diagnostics:
              WiFiServer is running
              SPI underruns 0, overruns 0
              Webserver Diagnostics:
              HTTP sessions: 1 of 8
              
              

              After seeing your example I'm guessing I should be specifying it for XYZ axis'?

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

                @roboduet:

                Is it OK that I have [c]MaxReps: 5, StepErrors: 0. Underruns: 38[/c] after print?

                Is description for this diagnostic parameters available?

                I'm using the following settings:

                [[language]]
                M350 X16 Y16 Z16 E16 I1 
                M92 X100 Y100 Z100
                
                

                MaxReps is the number of iterations that the interrupt service routine made before it completed. Each iteration generates one step pulse for one or more motors. If it gets very high then it means that the demand for step pulses is so high that the ISR is struggling to generate them fast enough, and you should reduce maximum speed or microstepping.

                StepErrors is a check that the last steps for a move were generated at the expected time. It's a check that the delta movement algorithm is delivering the correct results. It should always be zero.

                Underruns is the count of times that there were too few moves in the lookahead queue to generate continuous motion as fast as the machine parameters and the requested speeds permit. It is generally zero when printing from SD card. However, gcode files that contain sequences of a lot of very small moves may give rise to underruns. Simplify3D has a reputation for generating these types of move sequence, although it is claimed to be fixed in the latest release.

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

                  @briangilbert:

                  M350 X128 I100 ; Set 128x microstepping without interpolation

                  After seeing your example I'm guessing I should be specifying it for XYZ axis'?

                  That's correct, you are currently only increasing microstepping for the X motor. Also the I parameter should be 0 or 1.

                  1 Reply Last reply Reply Quote 0
                  • briangilbert
                    briangilbert last edited by

                    @dc42

                    Putting my hand up to help improve Wiki's if you are open to me calling you occasionally to clarify things?

                    1 Reply Last reply Reply Quote 0
                    • RCarlyle
                      RCarlyle last edited by

                      As far as the motor itself is concerned, there's absolutely no disadvantage to finer microstepping. No loss of torque, no change in heat production, no downside whatsoever. It simply vibrates less when the step position changes, because each incremental movement is smaller. So it's quieter and motion is smoother.

                      The driver also typically doesn't care, as long as you don't get into really extreme territory like if the pulse times and direction change delays get so short that it can't pick them up. Drivers with crummy chopper algorithms like the 8825 can miss some very fine low-current microsteps, which puts ripples into the print. It may be visually more appealing to have coarser evenly-spaced microsteps than very fine microsteps with repeating error ripples. But the 2660 shouldn't have that kind of issue, because it uses an adaptive chopper algorithm that monitors for missed microsteps and adjusts the decay times accordingly.

                      The controller is really the main limit for microstepping. You don't want to bog down the processor with step generation. I don't know what the ARM M4F in the Duet Wifi is capable of yet, but Repetier on an 84mhz ARM M3 can handle 80 khz and Smoothie can do, err, I think 100 khz or so with its slightly faster 120 mhz ARM M3.

                      At higher speeds, when the motor is inductance-limited and isn't actually reaching its target current, microstepping no longer adds any value whatsoever. You actually end up with slightly more torque at high speeds with full or half stepping. But you probably shouldn't be running 3d printers at that kind of speed.

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

                        I ran some timing tests on the 1.14 firmware. With just one axis motor moving, the Duet WiFi step pulse rate tops out at 240kHz. With all 3 motors moving at the same speed (e.g. pure Z movement on a delta), the step pulse rate tops out at 130KHz. However, these figures do not allow for anything else happening at the same time, so you should aim to keep the step frequencies well below these values.

                        It has just occurred to me that I can optimise the case of multiple motors moving at the same rate a little. I will implement this in the next release.

                        1 Reply Last reply Reply Quote 0
                        • RCarlyle
                          RCarlyle last edited by

                          Remind me, do you have step doubling implemented? That's a fairly straightforward solution that ends up acting much like dynamic microstepping.

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

                            Yes, the firmware switches to 2, 4 or 8x stepping when the frequency gets high enough. In my timing tests I could see on the oscilloscope that it was running at 8x.

                            1 Reply Last reply Reply Quote 0
                            • RCarlyle
                              RCarlyle last edited by

                              So, it's doing 8x pulsing to get to 130 khz? That's rather surprising.

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

                                The firmware currently switches to double stepping when the interval between step pulses falls below 70us. Then quad stepping if the average interval falls below 35us, and octal stepping below 17.5us. That figure was based on measurements using the wired Duet, and should probably be reduced for the Duet WiFi with its faster processor.

                                The main purpose of going to double etc. stepping is to reduce the number of delta movement calculations when the firmware is configured for a delta printer. Each delta calculation involves the calculation of the square root of a 60-bit number, so it is quite expensive in CPU time. Bear in mind that delta movement in RepRapFirmware does not use segmentation - except that when it switches to double etc. stepping I guess you could call that micro-segmentation.

                                In the next release, I'll probably reduce the 70us somewhat for delta movements in the Duet WiFi build, and use an even smaller value for Cartesian movements.

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

                                  I just made a few more optimisations to the step pulse generation. For non delta moves, the maximum step rate for 3 motors moving simultaneously has risen from 130kHz to 166kHz per motor (so about 500kHz total step pulse rate) , For just one motor moving, it is up from 240 to 280kHz.

                                  The experimental binary is at https://dl.dropboxusercontent.com/u/19369680/DuetWiFiFirmware.bin,

                                  1 Reply Last reply Reply Quote 0
                                  • bot
                                    bot last edited by

                                    Fantastic news. Are you seeing improvements due to the on-board FPU? These figures are approaching the performance specs of some rather pricey CNC controllers (KFLOP, to be exact), this is very exciting.

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