Dimensional accuracy

I’m trying to nail down the dimensions on our printer. A 10x20x30 (mm) block comes out 9.98 x 20.62 x 30.63. Happy with the thickness (better than a quarter of a percent accuracy), but the width and depth are not too close. Now clearly, when designing my own stuff, I can compensate. But if I want to print something like Emmett’s cube gears, all the pins are too big, holes are too small, and AFAICS there aren’t editable files available. Given that, how do I tweak the parameters in Slic3r to get better dimensional accuracy. I’ve tried playing with the advanced settings, reducing extrusion widths, and so forth, with indeterminate results. Any hard and fast guidelines on what settings actually fix the problem?

Regards,
Martin

The TAZ ships calibrated- so you shouldn’t have a large dimensional accuracy discrepancy. Posting a photograph will help, as will the gcode file you used.

We discovered that in general a hole should be over-sized by roughly 0.012 inches and a round post should be undersized by roughly 0.012 inches.

Hole and round post sizes below 0.062 inches in diameter should be avoided. :open_mouth:

This gets us darned close to getting the actual size we want.

I’m experiencing the same problem.
Got a Mini today & tried printing this: http://www.thingiverse.com/thing:23030
However none of the pieces fit together.

On my previous printer (a Solidoodle 4) I printed it & everything fit together just right.

Could the oversized screws & undersized thread holes be a result of over extrusion or is there a problem with the X & Y axes?

I tried printing a 18.00x18.00x18.00mm cube & the part came out at 18.42x18.53x18.03mm, showing the height is as spot on as can be expected, but the X&Y axes were out by nearly half a mm.

This has been something I’ve been tracking down as well. Below is what looks to be happening, at least from what I’ve seen. (Note, some, including bot, might describe me as blind, so…)

First, why is Z so accurate? It’s because the absolute height of the bottom of the nozzle (in most cases) sets the top of the layer. The material could flow sideways, which is what helps it adhere, but there’s no place to go in the up direction, at least not the pressures we’re working with. When the head moves to the next vertical layer, that relative movement is quite accurate, and again, the material’s top surface is limited by the nozzle.

Now, all that changes on the X and Y axes, right? By way of example, imagine a 200mm, single-thread-perimeter square. As the left-side thread is put down, the centerline of the nozzle’s opening is effectively at 0.000000…mm relative for that part. When the nozzle is later moved to the right-hand side, based on the stepsPerUnit, the controller ticks off (at current defaults) 10,050 steps. The resulting position of the head, then is at 100.00000…mm, assuming everything is perfectly exact.

Makes sense, right, and we’d have a fit if that head DIDN’T move exactly 100mm!

Now imagine the plastic being pressed into those exactly-positioned lines. Notice something? Yup, that’s right…the plastic isn’t constrained in the direction parallel to the bed. So the actual far-left edge is 0.000 - (0.5 * lineWidth), and the actual far-right edge is 100.000 + (0.5 * lineWidth). On a normal print, where the perimeters are done inside-first to outside-last, that outside thread is constrained to the inside, but not to the outside, and can somewhat freely vary.

I just confirmed that this appears to be exactly the issue. Earlier today I had printed a circular part with a 70.0 diameter, printed with an 0.5mm nozzle at an 0.30 line width. And guess what…I just measured it, and the part diameter varies from 70.31-70.50mm.

So, it seems we’re looking at something that’s totally normal to the medium.

The “proper” way to correct this then, is indeed as the other poster mentioned: include compensating offsets to crucial and mating perimeters/edges, measures of 0.5 line-width.

Sure, we could change the Xsteps/min and Ysteps/min, but that is not going to solve the problem, it will make ti worse, because smaller parts will get too little, and large parts too much compensation. And, as they say, they come “calibrated”, if only because the motors have a fixed, exact number of steps per revolution, and the lead screws has a specific and exact number of threads and thread-per-inch. When you add those up, there’s not really an place where “error” is going to creep in, unless it’s the horrible step-swallowing nightmare.

What is especially unkind in this regard is that we now have to encode production-processing details into the 3D model. The very idea offends my object-oriented sensibilities.

I seem to remember “guidance” at some point being to remove some percentage of an ABS part, blah blah blah. Maybe this is the thing that drove that advice?

Regards,

Thom
\

Here’s another data point: I’ve had a Lulzbot Mini for a little over 2 years. Over a year ago I could successfully print snap-fit boxes that have a designed 0.5 mm clearance between the base outside measurement and the lid inside measurement. I noticed a few months ago that printing the same model now produces a box whose lid is too small for its base: the designed 70.0 mm wide base exterior measures about 70.3 mm, and the designed 70.5 mm lid interior measures (strangely) 70.3 mm as well, producing a box that can’t close. The dimensional difference seems to be similar on the X and Y axes. The box printed over a year ago on the same printer has a 70.2 mm base exterior and a 70.4 mm lid interior.

This is all being printed in PLA, by the way.

Meanwhile, 3D hubs’ (and others’) design rules for FDM printing recommend 0.5 mm designed clearance between printed parts that are to fit together: https://www.komacut.com/media/1338/3d-printing-design-rules-high-res-min.png

One big difference between now and then is that my X and Y idler mounts developed stress fractures, and I sent the printer to the factory for repair. I should note that the dimensional differences were the same before and after the repair, so I don’t believe it’s anything Lulzbot Repair did.

Other things that have changed: I used the same version of Cura LE that was current when I bought my printer, then a while ago (perhaps even a year ago) upgraded my Cura to the latest Cura LE version. I unfortunately don’t recall what version produced the good boxes. Also, I switched from directly controlling the Mini with a Linux laptop, to controlling it with OctoPrint/OctoPi running on a Pi 3.

I can’t believe that I was just lucky that my printer produced, for about a year, interiors and exteriors that worked with popular clearances. I’m more inclined to suspect either a change in Cura LE, some worn parts in my printer, or loose/too-tight belts.

I’ve attached the STL files for the base and lid I’m using, for testing on your own printers.
freecadBase.stl (4.57 KB)
freecadLid.stl (3.4 KB)

Update on my dimensional errors: I seem to have fixed the problems. 1) the right X carriage mount was lower than the left by about 1/8"; I fixed that by turning off the printer and manually turning the right screw until the two were at the same height. 2) the extruder idler tension was too high; I adjusted the tension and found the spot where no ripples (a different issue) appeared in the first layer

As I mentioned in a different post about the same issue (https://forum.lulzbot.com/t/tips-on-prints-that-fit-together/5964/1), I’ve put my complete notes on adjusting the Lulzbot Mini extruder idler tension at https://bluepapertech.com/3d-printing/extruder-gear-tension-the-overlooked-adjustment/.

Yet another update on my dimensional errors issues and fixes: A seemingly-unrelated problem with my Lulzbot Mini was that ever since it came back from Factory Repair, the nozzle had been missing the wiping area. It turns out, that’s a symptom of a Y axis dimensional error.

I replaced the 1.0.3 Y axis motor mount with the 1.0.4 part, and the nozzle started wiping in exactly in the right spot. That also means that the Y axis absolute dimensional error has been reduced.

My lengthy explanation of why I think changing the part fixed the problem, and what that has to do with Y axis dimensional errors, is at https://forum.lulzbot.com/t/y-axis-0-endstop-question/4486/8