Microstepping pros/cons
-
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 -
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 8After seeing your example I'm guessing I should be specifying it for XYZ axis'?
-
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 Z100MaxReps 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.
-
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.
-
Putting my hand up to help improve Wiki's if you are open to me calling you occasionally to clarify things?
-
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.
-
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.
-
Remind me, do you have step doubling implemented? That's a fairly straightforward solution that ends up acting much like dynamic microstepping.
-
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.
-
So, it's doing 8x pulsing to get to 130 khz? That's rather surprising.
-
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.
-
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,
-
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.
