Testing the effects of microstepping and segmentation on print quality

Following a discussion in another forum, I decided to do some tests to see what effect varying microstepping and segmentation has on the print quality produced by a delta printer. I printed the same gcode file with four different settings so that the results can be compared. Brief details:

- The machine is the 1m high delta with 300mm build diameter described at at [miscsolutions.wordpress.com]
- The print is a spiral vase 50mm cube with 3 solid layers at the bottom, and the gcode file is here [dl.dropboxusercontent.com].
- Layer height is 0.1mm after the first layer
- The printer uses 0.9deg motors and 16 tooth pulleys, so the steps/mm @ x16 microstepping is 200
- Controller electronics is Duet Wifi, with TMC2660 drivers supporting up to 256x microstepping
- Firmware revision was 1.18RC1
- The extruder drive is a Titan with a 1.8deg motor and about 420 steps/mm. The extruder driver was set to x16 microstepping with interpolation to x256 for all prints.

Click on the images for a full-size version.

First a reference print using x16 microstepping with interpolation to x256 enabled, which is the default firmware configuration:



Next, still using x16 microstepping but with interpolation disabled (this is much noisier when printing):



Most firmwares divide any delta printer move other than a short one into short segments, calculate the endpoints of each segment, and generate motor steps at equal intervals within each segment, on the grounds that when a segment is small enough the difference between this approximated motion and true straight-line motion is small. Apart from the error within each segment, this forces each segment boundary to be quantised to the nearest microstep for each motor. RepRapFirmware is unique in that it calculates the precise step times for all the tower motors when driving a delta printer. The only time RRF normally uses segmentation is when using mesh bed levelling and a move is longer than the grid spacing. For this next test, I modified the firmware to force each move to be split into 0.5mm segments, still using x16 microstepping with interpolation off. Within each 0.5mm segment, each move is still executed precisely instead of using the approximation, so this doesn't fully simulate the way other firmwares behave:



Finally, because it was suggested in another forum that high microstepping might result in a reduction in precision, I ran a test with x256 microstepping, not interpolated. To remain within the maximum step pulse rate of around 180000 steps/second per motor supported by RRF on the Duet WiFi I had to reduce the travel speed; but the print speed was still 50mm/sec.



I am aware that all the prints display ringing at the left hand edge, and I should reduce acceleration and/or jerk to reduce it. Other than that, I will leave readers of this post to comment on the print quality and how it differs between the prints.

Edited 3 time(s). Last edit at 03/29/2017 04:40PM by dc42.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

Well I can see that segmentation free printing is really worthwhile. And that higher microstepping beyond 1/16 makes little difference to print quality only to noise levels. (though I am viewing on my phone). That's why I'm very pleased with my kossel Xl and RRF.

Minor thing, your steps/mm though should be 160 with 20t pulleys, or 200 with 16t pulleys.

Edited 1 time(s). Last edit at 03/29/2017 01:18PM by DjDemonD.

---

Simon Khoury

Co-founder of [www.precisionpiezo.co.uk] Accurate, repeatable, versatile Z-Probes
Published:Inventions

Quote
DjDemonD
Minor thing, your steps/mm though should be 160 with 20t pulleys, or 200 with 16t pulleys.

Well spotted! The machine has 16 tooth pulleys now. I've corrected the text.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

I'd reference this thread for some more segmented versus non segmented comparisons.

---

Simon Khoury

Co-founder of [www.precisionpiezo.co.uk] Accurate, repeatable, versatile Z-Probes
Published:Inventions

Your prints at 256x appear to have heavier ringing then at 16x.... Is this a lack of torque causing problems with acceleration maybe??

You can try also round objects (no corner ringing). For example, truncated cone (~50 mm diameter at bottom and ~20 mm at top, height is 30 mm). On such objects you can also see surface irregularities described in this topic about jerky movements.

Quote

For this next test, I modified the firmware to force each move to be split into 0.5mm segments, still using x16 microstepping with interpolation off. Within each 0.5mm segment, each move is still executed precisely instead of using the approximation

Can you explain where is the imprecision when within each 0.5 mm segment the move is executed precisely?

Normal segmentation (e.g. in Marlin or Repetier) causes the error to be biggest somewhere near to the segment center. And in these firmwares, the error is bigger with raising printing speed. So if anybody wants to discuss segmentation errors then he needs to specify both segments per second and the printing speed. That is because the actual segmentation error depends on the segment length and the position at the build bed. The dependencies go like this:

• the segmentation error depends on the XY position and the segment length
• how much the XY position influences the segmentation error depends on the printer geometry (especially the ratio of diagonal rod length to delta radius)
• segment length depends on the segments per second and the print speed
• the print speed specification can have two variants
  • constant carriage speed (at least the old Marlin)
  • constant head speed (at least the old Repetier)

Edit: And one more thing. For a printer with dimensions like the classical rostock, you need a segment length in the range of at least 3 mm to see a segmentation error of at least 1 micro step. So your segment length of 0.5 mm was probably way too small to see any errors due to segmentation itself.

Edited 1 time(s). Last edit at 03/30/2017 04:46AM by hercek.

Quote
roboprint
You can try also round objects (no corner ringing).

That is probably not a good idea because the firmware will create segments only within the STL file segments. When you convert a precise STEP file into imprecise STL file, you create segments. These STL file segments limit the maximum segment length Marlin/Repetier will use.

If you want to test this then print something with planar surface and just ignore the parts of the print which are far from plane center (where ringing from springy belts, lower stepper static moment at given microstepping, or elastic frame can happen).

Quote
Origamib
Your prints at 256x appear to have heavier ringing then at 16x.... Is this a lack of torque causing problems with acceleration maybe??

Probably not. Adding bigger micro stepping increases precision and decreases the static moment. But the static moment decrease is there only for maintaining the position withing the new smaller micro step length. In other words, by increasing micro stepping you increase the error relative to the new micro step length. You do not increase it relative to the old bigger micro step length.

Quote
dc42

Most firmwares divide any delta printer move other than a short one into short segments, calculate the endpoints of each segment, and generate motor steps at equal intervals within each segment, on the grounds that when a segment is small enough the difference between this approximated motion and true straight-line motion is small. Apart from the error within each segment, this forces each segment boundary to be quantised to the nearest microstep for each motor. RepRapFirmware is unique in that it calculates the precise step times for all the tower motors when driving a delta printer. The only time RRF normally uses segmentation is when using mesh bed levelling and a move is longer than the grid spacing. For this next test, I modified the firmware to force each move to be split into 0.5mm segments, still using x16 microstepping with interpolation off. Within each 0.5mm segment, each move is still executed precisely instead of using the approximation, so this doesn't fully simulate the way other firmwares behave:

This isn't quite how other firmware works, they divide movements into time-steps instead of distance-steps. This means that the distance between segments is dependant on speed, so they are closer together near the corners where the head is accelerating. It also means that the segments on successive layers might, or might not, line up. This is obvious from pictures on this thread: [forums.reprap.org]



Hercek,
It's not obvious how the imprecision creeps in, but what I think is happening is this:

When the next segment is calculated, the point at which it's calculated is forced to line up with a whole microstep (for all three axes). Where axes are moving slowly (like the Z tower on a delta, printing a flat plane) this error can result in a large physical offset.
At least I think that's what's going on.
It appears to me that increasing the number of segments per second won't actually help with visual artefacts.

I can't help thinking that randomising the segment time slightly would have a massive positive effect on the visual appearance of flat planes, without adding much processing time. It would mean that segments won't line up between successive layers, which in turn would make the vertical line artefacts pretty much disappear.


I'm almost finished setting up my Re-Arm, which can handle up to 1/128 microstepping. I'm going to run some tests on this as well, to see if increasing the microstepping will reduce the segment artefacts. That is, if smoothie uses segments (I think it does, but need to actually print something to be sure).

Edited 1 time(s). Last edit at 03/30/2017 12:04AM by nebbian.

Quote
hercek

Quote

For this next test, I modified the firmware to force each move to be split into 0.5mm segments, still using x16 microstepping with interpolation off. Within each 0.5mm segment, each move is still executed precisely instead of using the approximation

Can you explain where is the imprecision when within each 0.5 mm segment the move is executed precisely?

The imprecision is that the carriage positions have to be quantised to the nearest microstep at every boundary between segments. In practical terms this means that around the segment boundaries, step pulses are delayed or advanced by up to half the pulse interval. Around the point at which a carriage reverses direction, it may also cause an extra microstep of movement due to rounding the carriage position up to the next whole microstep.

Edited 3 time(s). Last edit at 03/30/2017 05:27AM by dc42.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

Ok, the nature of the errors you artificially introduced is quite different from the errors because of segmentation.
Here are two charts which give you an idea about errors from delta segmentation. The charts show only contribution to the error from one tower. It is only about the errors from the segmentation itself not the other kind of errors like e.g. rounding the position to the nearest micro step at the start/end of the segments or sub-optimal pulse timing because of using something like Bresenham's algorithm for stepping.
The examples assume 300 mm diagonal rod. Segments per second is 80. Print speed 120 mm/s. Contribution to errors from delta diagonal are ignored. It is about right when delta diameter is about the same as diagonal rods.
Firmware which limits carriage speeds (e.g. old Marlin, and maybe new one too):

Firmware which limits hot-end speed (e.g. Repetier):

Notice that the maximum tower position error is cut-off at 0.01225 mm because it is not really interesting. These are the cases when the diagonal rod is almost horizontal and carriage position error contribution to the hotend error is small. The red line is more interesting in this picture.

Quote
hercek
Ok, the nature of the errors you artificially introduced is quite different from the errors because of segmentation.

I disagree. There are at least two types of error introduced by classic segmentation-based implementation of delta printer motion control:

1. Approximating the carriage motion needed to make the effector move in a straight line as uniform movement of each carriage introduces error, because the actual motion will be a curve, not a straight line. The longer the line, the greater the error.

2. So delta firmwares that use this approximation divide long moves up into short segments. That introduces another type of error: the rounding of the motor positions to whole microsteps at the segment boundaries - which causes microsteps to be time-shifted relative to the ideal segment-free time pattern.

As you have pointed out, the error due to approximation is low if the segment length is less than 3mm. So I decided it wasn't worth looking for. Instead I decided to see whether I could detect the error caused by segmentation alone. As it is fairly common for firmwares to be configured for 100 segments/sec and I was printing at 50mm/sec speed, I decided that a segment length of 0.5mm was an appropriate value to use. This doesn't accurately simulate fixed time segmentation algorithms near the corners of the cube where the speed is accelerating and decelerating, but those regions are very small in this print.

I was surprised at how visible the effects of segmentation are in this print. However, there are other posts linked to in the thread by two other users running different firmwares that show similar patterns. So I don't think you can blame it on the details of how moves are segmented in RRF. Still, it would be good to see photos of this test piece printed using firmwares other than RRF.

Edited 2 time(s). Last edit at 03/30/2017 10:06AM by dc42.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

OK, so you simulated one from the two possible kinds of the errors related to delta segmentation. The error you simulated is at most 0.5 micro step big (due to rounding to a full micro step at the start/end of a segment). If you insist that it is quite similar then I can agree with you too.

But I guess we already know each other enough to know that you strive for each micrometer of precision and I ignore anything smaller than 1 micro step ... and rather go for speed instead of prettiness. And segmentation or rounding to the nearest full micro step are negligible at high speeds/accelerations. "Ringing" (and filament extrusion precision if there are retraces) will make any half micro step errors look like nothing.

I've gotta say that I agree with DC42 on this one... I think he did a valid test for the most part, at least it seems to agree with tests that I've done on a RAMPS board. The one area where it falls down in his simulation is that for his test, the segments all line up with the layer below, whereas in a time-based segment process, the segments sometimes shift for whatever reason.

This all started off with me thinking that anything smaller than 1 microstep is negligible, and can be safely ignored. I mean, that's like 0.006mm on my printer. In other words, "3/8 of fk all". A poofteenth. I could use other, ruder, words, but they all boil down to it being totally negligible.

I was wrong.

The segments DO produce visible artefacts. Nothing that you can actually measure with a caliper, and in the scheme of things it's tiiiiny compared to the myriad of other inaccuracies on the printer, but the visible artefacts ARE there when you shine light on the surface.


The smoothie code base is excellent, I've found where the segments are generated, and it looks like it's easy to shift them around randomly which might eliminate the visibility of this artefact. I'm looking forward to trying this out.

Edited 1 time(s). Last edit at 03/30/2017 11:22AM by nebbian.

Three questions, to which I think people might be looking for an answer:

1) Do these tests apply for cartesian printers?

2) Is RRP the only firmware doing that kind nonsegmented movement? Does Smoothieware have an alternative or is it using an approximation?

3) Does anybody with a cartesian printer, who used Marlin and upgraded to Duet has an objective proof about increased print quality. It goes without saying that there should be no mechanical modifications to the printer after the update, which could be the real reason for improved quality.

Thanks....

Of course segmentation can cause visible artifacts. With the right lightning one can see incredibly small things. Especially if they form some repeating pattern. And even if they are random you probably will be able to see some kind of moire. And if you care about look then it may very well bother you. Anyway the artifacts are negligible compared to the other errors you get. How many people have their printer calibrated to 1 micro step? Well not me at least. The micro step or two difference at the wall surface hardly matters if the whole wall is off by 0.1 mm. Or when you compare it to the problems from "ringing" or extrusion precision on places with many retracts. Micro step differences on the wall matter only for the visual look.

If you want to see the worst case then look at this example from Repetier which uses integers to represent coordinates. I.e. everything is rounded to 1 micro step. Not only the segment boundaries but also the part dimensions itself.

Print speed 50 mm/s, acceleration 8000 mm/s², segments per second 90, layer height 0.2 mm.

@drmaestro: Cartesian printers do not use segmentation so they will do better. Anyway for walls which are not exactly in the X or Y axe direction there may be some rounding to the nearest micro step too. And the abrupt position changes by one micro step will be visible too. You may get it better if you print "round" objects with more loose belts or lower stepper motor current ... and at higher speeds. The bigger springiness of belts and smaller static moment of the steppers will dampen the abrupt stepper changes. But if you do this then high speed prints with sharp corners will have more "ringing".

I run the printer at maximum currents and really tight steel core belts. Ø12 mm smooth rods with tight bearings. And moreover I use Repetier on a delta printer (i.e. integer arithmetic with delta segmentation). So it is as bad as it can possibly get. But high speed prints do not have that much "ringing" to them.
If you want the best quality prints and do not care about speed then get a cartesian which you can easily calibrate precisely and use very high micro stepping (like 256 or more) and to a lesser extend also some firmware like RR which will optimally time stepper pulses.

Quote
hercek
If you want to see the worst case then look at this example from Repetier which uses integers to represent coordinates. I.e. everything is rounded to 1 micro step. Not only the segment boundaries but also the part dimensions itself.

Surely that's true of every firmware? Even if the firmware does most of the calculations using floating point maths, at some point it has to decide how many step pulses to send to each motor. So part dimensions will always be rounded to the nearest microstep. This is unlikely to matter in the X and Y dimensions, because a microstep is normally no bigger than 12.5um which is small compared to the extrusion width. In the Z direction, it makes it important to choose a layer height that is a whole number of microsteps - or (preferably) a whole number of full steps.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

You have a point. I agree that computing everything in integers instead of floats may not make a difference if done carefully. If not done carefully then rounding errors can propagate and accumulate.

I think every firmware rounds start/end of lines to integers and does not try to optimize time spend at a given integer location with some kind of PWM like scheme (to achieve sub-micro-step precision). It is just easier to get a driver which can handle higher micro stepping. The two firmwares (Marlin,Repetier) I have experience with did not do any kind of PWM-like magic the last time I checked.

Edited 1 time(s). Last edit at 03/30/2017 03:42PM by hercek.

Quote
hercek
In the Z direction, it makes it important to choose a layer height that is a whole number of microsteps - or (preferably) a whole number of full steps.

Surely this doesn't apply to Deltas? As the hotend moves in XY, all 3 motors move. So Z-positioning will be on-the-fly and whether it's a whole microstep (or whole step) or not will depend on the XY position? Or have I completely misunderstood how Delta positioning is done?

@frankvdh: It si not my quote but you have a point.

Quote
frankvdh

Quote
hercek
In the Z direction, it makes it important to choose a layer height that is a whole number of microsteps - or (preferably) a whole number of full steps.

Surely this doesn't apply to Deltas? As the hotend moves in XY, all 3 motors move. So Z-positioning will be on-the-fly and whether it's a whole microstep (or whole step) or not will depend on the XY position? Or have I completely misunderstood how Delta positioning is done?

Yes the microstep position of each motor will depend on the XY position, and there will be a Z height error that varies with XY position. But by choosing a layer height that is a whole number of microsteps (or preferably full steps), we make the height error at any XY position the same on every layer. If the height error at a given position varied between one layer and the next, you would get varying layer thickness, which would reduce print quality due to the filament being squeezed more or less as the layer height varied.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

Quote
dc42

Next, still using x16 microstepping but with interpolation disabled (this is much noisier when printing):

50-0.1-x16-off.jpg

I guess this picture is taken of the side that faces left or right, not the side that faces towards you on the build plate? I would expect to see some moire due to slow Z tower movement if this were the side facing towards the front of the machine.

I just did a test with Smoothieware, at 1/16. It's different to Repetier. Not better or worse, just different.

Upon further testing, I can see a distinct moire pattern with the part printed on RE-Arm/Smoothie at 1/16 (as you'd expect), but no evidence of segments.

I tried the random segment code, but it made no difference.

I haven't looked hard at the code, but I'm thinking that perhaps smoothie might be doing something clever with floats and not making the microsteps line up with the segment boundaries.

I may have to try the TMC drivers again to be sure. I've got two new ones, one definitely broken, and three questionable drivers.

Quote
nebbian

Quote
dc42
Next, still using x16 microstepping but with interpolation disabled (this is much noisier when printing):

I guess this picture is taken of the side that faces left or right, not the side that faces towards you on the build plate? I would expect to see some moire due to slow Z tower movement if this were the side facing towards the front of the machine.

All four faces look very similar apart from the faint diagonal stripe pattern:

Quote
nebbian
I just did a test with Smoothieware, at 1/16. It's different to Repetier. Not better or worse, just different.

Pictures?

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

Thanks for that DC. 2 and 4 would be your front and back then. I've seen similar diagonal banding on my prints as well.

Can you double check that you were in fact, in 1/16 mode (no interpolation)? From my experience with three different firmwares and a few different drivers, they all show the moire tree rings pattern on the front and back faces. I'd expect it to be obvious on your prints too, if you're in basic 1/16 mode. Maybe the light needs to be just right to see them. Can you see if they are visible on face 2 or 4?

I'm still collating test prints, and verifying what's going on. It might take a day or two to get some good data on this. I find it interesting, seeing the difference between firmwares on the same machine. I've had unexpected results twice already in these tests

I am sure they were done with interpolation off because before doing the print I sent the M350 command to disable interpolation, then I ran M350 with no parameters to check that it was disabled. I can see some very faint vertical lines near the centres of faces 2 and 4 of the x16 print with interpolation off. There are no such lines on the print with interpolation on.

Bear in mind that I am using 0.9deg motors and 16t pulleys, so even at x16 microstepping the steps/mm is 200.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

Can you see any evidence of a tree ring pattern like this?

btw those diagonal bands on your prints might be caused by belt teeth, they have the right period. I doubt they're anything software related.