resolution question

[dgsharp 0]

I printed up a part today using shiny black PLA, printed at 50 micron layer height, and 20 mm/s. It came out great, but it really highlights some interesting artifacts I was curious about. I've seen them before, but never quite so strongly, and I always assumed they were something else: there are concentric rings emanating from all 4 sides of a spherical section of the model.

I measured the diameter of the sphere and the diameter of the first concentric ring on one of the sides, and worked out that the effective X/Y resolution is around 47.8 um -- suspiciously close to 50. I was just curious what this is caused by. Here are some hypotheses:

- The stepper motor and driver's own inherent effective mechanical resolution. The website says the X/Y "precision" is 12.5um, but presumably that is microsteps, and maybe it just doesn't end up actually mechanically achieving the intermediate microsteps. This would imply a loss of a nice clean 4x the precision.

- Stepper controller firmware. Maybe everything in the system can handle down to 12.5 microns except there's some little bug in the firmware that doesn't do the microstepping as expected?

- Cura. I sliced it at 50 micron layer height. Maybe Cura imposed this limit? I looked at the G-code in this section and all the moves are on the order of 1mm, far larger than this limit I'm seeing. The smallest movement commanded on an individual axis appears to be around 30 microns in this slice [uPDATE: smallest X or Y move in this slice is exactly 10 microns, so Cura is not the culprit].

The part in question, exhibiting the concentric rings implying an X/Y resolution limit of 50 microns:

 

The part as seen in Cura. Triangles in this section are all visually identical, no signs of concentric artifacts:

 

The G-code from one of the slices near the center of the circle, plotted as X/Y positions (to verify that we're roughly looking at what we expect to be), and the distance between adjacent move locations (all in the ballpark of 1mm):

Anyone know anything about this? Any other theories? I wouldn't call this a gripe, I'm just exploring and trying to understand what I see. Although if there is anything we can do to up our effective X/Y resolution even higher, I'm all ears!

Thanks!

[uPDATE: I think I missed the first concentric ring as it's not readily visible, making my estimates for X/Y resolution look worse, perhaps due to just a touch of backlash. I gathered more data and re-calculated in such a way that knowledge of the first concentric ring (whether or not it exists, let alone how small it may or may not be) is irrelevant, and the X/Y resolution is actually more like 26.5 um -- presumably 25 um. So it still appears that we are losing 2x the precision somewhere along the line.]

-Dave

 

[takei-naodar 0]

How much infill did you use? Are that the points were the Infill connects?

 

[Dim3nsioneer 558]

Your print really looks great.

In Cura, go to layer view. You might see the concentric rings also there when choosing the right view angle. I think it's a numerical artefact from slicing as it is acutally producing a bunch of straight lines and no arc for a curved wall. But I think Cura is slicing with a resolution which fits to the UM resolution, at least I hope so.

 

[dgsharp 0]

How much infill did you use? Are that the points were the Infill connects?

 

I used 20% infill for this, but this is not related to infill. I have a different model of a partial sphere I printed with 0 infill and it exhibits the same exact thing.

 

Your print really looks great.

In Cura, go to layer view. You might see the concentric rings also there when choosing the right view angle. I think it's a numerical artefact from slicing as it is acutally producing a bunch of straight lines and no arc for a curved wall. But I think Cura is slicing with a resolution which fits to the UM resolution, at least I hope so.

 

I've confirmed that Cura's output resolution appears to be 10 microns. It uses 2 decimal places, but more importantly than that, the shortest distance between two moves along the X or Y axis is exactly 0.01 mm.

We are almost undoubtedly seeing the effective X/Y resolution of the system, and it's right around 25 microns. Cura clearly isn't the limit if it is commanding moves of as small as 10 microns. So that leaves something on the hardware / firmware side.

Here is a picture I pulled from Google Images of a sphere as it would appear in Minecraft:

Clear as day you can see the concentric rings exactly as I've described -- one set of concentric rings vertically oriented at the max X, max Y, min X, min Y, and of course also the min and max Z. And if you measure the diameter of the sphere and the diameters of two adjacent concentric circles, you can figure out how far the rings are separated along the X or Y axis -- the limit of the resolution.

I don't see another way this could be interpreted. So where is this 25 micron resolution limit coming from? It's a nitpick, totally, but.. where's the other 50% of the resolution going?

 

[dgsharp 0]

In case anyone is curious, here's how I found the X/Y resolution:

- I created a sketch in FreeCAD showing a pie wedge with the radius of my sphere, as measured with calipers (the radius shown is in fact half the diameter I measured).

- With calipers, measured the diameters of two concentric rings. In this case I believe they were the 2nd and 3rd rings, as the first one seems to be gobbled up by the backlash in the belts (25 microns of backlash ain't bad!), but it doesn't actually matter which rings they are as long as they are adjacent.

- Added constraints to the sketch in FreeCAD showing everything I know: the diameters of the two concentric circles (shown in the sketch as the vertical distance between points along the arc). The two arcs are both symmetrical about the X axis.

- At this point the sketch is fully defined, so we can measure the horizontal distance between the points of the smaller arc and the points on the larger arc (the smaller and larger concentric rings on the 3D print). This comes to about 26.5um. If I could measure the ring diameters with a microscope it would probably come out closer to 25um (just a guess).

UPDATE:

Ok, something is fishy with my results, the horizontal distance between those two slices appears to be 265 microns in that diagram (0.265mm, the dimension at the top), I goofed a decimal place in reading it off. I re-checked the numbers in SolidWorks and they agree with FreeCAD. I checked the horizontal distance to the next pair of concentric rings and it appears to be 170 microns. This suggests that we are seeing something other than the X/Y resolution of the machine. It is much more coarse even than the layer height.

I performed this again using a different printed sphere model, which was printed at 100um layer height. Using the approach described above on the top surface I was able to measure the layer height (Z) to be about 0.11 mm (110 microns), very close to expected. This was identical for two pairs of adjacent concentric rings, as you'd expect, since we know the Z step height is consistent. I think this shows that my approach works for finding the radial/planar distance between two adjacent concentric rings that appear on a spherical surface.

I'm re-printing a test model I made at 20um layer height and 20mm/s, it's 1" diameter (25.4mm) and has about 100k faces (many many more faces per mm^2 than the model that started this thread). I have one done at 20um but it was probably printed at 35mm/s and the surface, while very nice, isn't quite as crisp as the newer part. If I see rings that are the same planar spacing on the new 20um part with gobs of faces as on the 50um part with fewer faces, then it can't be related to the model itself, and apparently has to be in the slicer after all.

I'm guessing it is something in Cura like an angular deviation threshold. It's not actually snapping the points to a consistent X/Y grid as I'd first assumed, but just creating a new point when the angle between them is greater than some threshold. I just re-checked the points in the G-code and while the angle differences between them aren't identical, they are all pretty close to 5 degrees (some as low as 2.7, some as high as 7.1). Perhaps the rationale is that having too many move commands in a tight space would make the SD card a bottleneck, requiring slower prints to be consistent? This sounds very plausible to me.

-Dave