# Thing-O-Matic: Small Features

It seems most of the stuff I build with my Thing-O-Matic involves small features and thin sections that bump hard against the minimum possible sizes. I’ve found that forcing critical solid model dimensions to be integer multiples of the the extrusion width or thickness stabilizes the whole idea→model→G-Code→object chain by encouraging Skeinforge to make the choices I prefer.

Or perhaps I’m just constraining my choices to make Skeinforge happiest. One can view reality in many ways…

Anyhow, my OpenSCAD programs tend to have these lines up near the top:

```ThreadThick = 0.33;

function IntegerMultiple(Size,Unit) = Unit * ceil(Size / Unit);
```

The ThreadThick parameter matches the Skeinforge thread thickness parameter(s) and the 2.0 matches the w/t setting(s). Those correspond quite closely to the actual printed results, as tediously verified through many measurements. Throughout the rest of the OpenSCAD program, I compute the dimensions of key features using those sizes as building blocks.

The IntegerMultiple function returns the next higher multiple of the basic Unit that’s greater-than-or-equal-to the desired Size. Feeding in the thread thickness or width as the Unit ensures that the result will be an integer multiple of the smallest-possible dimension and won’t be smaller. The integer limit happens automagically, because the printer can’t lay down anything else, but a less-than-possible size can cause features to (unpredictably, in my experience) vanish without warning. This way your model reflects the printed reality and Skeinforge seems more likely to produce a predictable result.

So the parameter controlling the thickness of a flat sheet might look like:

```PlateThick = IntegerMultiple(2.0,ThreadThick);
```

Given ThreadThick = 0.33, the sheet will be 7 layers thick = 2.31 mm. If the sheet must not exceed 2.0 mm, however, then you need a similar function with floor(), which may eradicate very small features.

This trick seems most useful for thin wall sections, because the wall width directly affects the fill:

• Less  than 1 thread width can’t be built
• Exactly 1 thread width is the thinnest possible wall
• Widths between 1 and 2 thread widths may be either, depending on surrounding features
• Exactly 2 thread widths produces a nice wall
• Widths between 2 and 3 thread widths can’t fill properly
• Exactly 3 thread widths fills perfectly
• Over 3 thread widths generally fill properly

So making the rim around a recessed lid become an integral number of thread widths, with a minimum width of 1.0 mm, looks like this:

```LidMargin = IntegerMultiple(1.0,ThreadWidth);
```

With a 0.66 mm thread width, the nominal wall is 1.5 threads wide and could print as either 1 or 2 threads, depending on other factors. Rather than leave the results to chance, I force the solid model wall to be exactly 2 threads wide to make the printed result come out at 1.32 mm. Because I don’t care exactly how wide the lid margin is, as long as it’s at least one thread, that’s fine with me.

Generally, the values come from computations based on other dimensions, so quantizing the results keeps the printed result stable over small variations of those inputs.

If I ever get around to changing the nozzle to from 0.5 mm to 0.4 mm, I’ll probably change the thread dimensions to 0.25 mm x 0.5 mm (keeping the same 2.0 w/t ratio). A 1.0 mm wall would then still be exactly 2 threads wide and come out looking exactly the same, but with a total width of 1.00 mm.

That’s the intent, anyway.

## 5 thoughts on “Thing-O-Matic: Small Features”

1. The folks at work bought a Thing-O-Matic and there is a cadre of a half dozen or so of us, assembling it, making my academic interest in your
TOM posts suddenly more relevant. I was pleased that the model we bought has a cartridge heater, which seems likely due (directly or indirectly) to your post on heater resistor abuse.

The roundup/rounddown issue reminds me of one of the arcane features of PostScript, which specifies that a line will be rendered at least one pixel wide, no matter its width. Which leads me to use this feature to print hairlines at zero width. On a 300DPI printer, they’re pretty solid. On a 1200DPI printer, they’re hairlines indeed. The documentation recommends I not do this, as the result is dependent on the device resolution. Theoretically, I should just set them for 0.02mm or 0.07 point or somesuch, against the day a zero-width line gets printed 1 atom wide.

1. Ed says:

the model we bought has a cartridge heater

Which makes it a Mk6+ or some such, I think.

MBI introduces slipstream product improvements, which makes for difficult user documentation, but it’s probably the best way to handle such things.

Current-production TOMs are definitely much better than last year’s version! [grin]

2. Ed says:

23 years ago was doing military service. Sometimes we were cycling with mortars (a barrel 20kg, a base plate 20kg, a bipod 20kg), AN/PRC-77 Portable Transceiver or something more an exotic radio from ruskies.

http://en.wikipedia.org/wiki/AN/PRC-77_Portable_Transceiver

http://en.wikipedia.org/wiki/Sanomalaite_M/90

http://en.wikipedia.org/wiki/81_KRH_71_Y

[Ed: I moved Aki’s comment to the proper place. WordPress makes it easy to attach a comment to the wrong thread and impossible to move it later.]