Ed Nisley's Blog: Shop notes, electronics, firmware, machinery, 3D printing, laser cuttery, and curiosities. Contents: 100% human thinking, 0% AI slop.
Category: Software
General-purpose computers doing something specific
Come to find out that Ubuntu 11.10 uses NFS V4 by default, which means the various clients scattered around here, all of which use NFS V3 by default, report all files have user & group 232 – 2: an awkward and unforgettable unsigned 4294967294. That’s -2 in 2’s complement notation with 32 bit hex numbers, corresponding to the unsigned 16-bit 65534 = -2 for the nobody user & group.
Fix that by editing /etc/default/nfs-common to set NEED_IDMAPD=yes. Unmount the NFS share, do sudo start idmapd, remount, and it’s all good. The next time the client boots, the idmapd daemon starts automagically, and that’s all good, too.
Adding the -t nfs4 filetype in /etc/fstab seems to be not necssary.
How I got into this mess: the Intel Atom D525 that had been driving the Thing-O-Matic has a bog-standard Intel graphics chip that, despite (or perhaps because of) having an open-source video driver, reports doing only OpenGL 1.4. OpenSCAD, however, requires OpenGL 2.0 and those hacks don’t allow it to run properly, which makes it awkward for demos. The AMD that’s currently the file server has, IIRC, better graphics that might improve the situation; I think it sports a somewhat peppier processor, too. The fact that it’s running Ubuntu 8.10 says that it’s time for an update.
Soooo, I swapped in a new 1.5 TB SATA drive, installed hot-from-the-oven Ubuntu 11.10, replaced Unity with XFCE, inhaled all the current data from the file server’s external USB backup drive, configured ssh / nfs / etc, and I’m now doing some simpleminded tests before I swap the IP addresses.
Now, if the AMD has craptastic graphics hardware, it’s unhappy dance time…
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;
ThreadWidth = 2.0 * ThreadThick;
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.
A long time ago, in a universe far away, I wrote a book that (barely) catapulted me into the ranks of the thousandaires. Time passes, companies get sold / fail / merge / get bought, and eventually the final owners decided to remainder the book; the last royalty check I recall was for $2.88.
Anyhow, now that it’s discontinued and just as dead as the ISA bus, I own the copyright again and can do this:
They’re both ZIP files, disguised as ODT files so WordPress will handle them. Just rename them to get rid of the ODT extension, unzip, and you’re good to go. Note, however, that I do retain the copyright, so if you (intend to) make money off them, be sure to tell me how that works for you.
The big ZIP has the original pages laid out for printing, crop marks and all, so this is not as wonderful a deal as it might first appear. The little ZIP has the files from the diskette, which was unreadable right from the start.
Words cannot begin to describe how ugly that front cover really is, but Steve’s encomium still makes me smile.
The text and layout is firmly locked inside Adobe Framemaker files, where it may sleep soundly forever. The only way I can imagine to get it back into editable form would be to install Windows 98 in a VM, install Framemaker, load up the original files, and export them into some non-proprietary format. Yeah, like that would work, even if I had the motivation.
If you prefer a dead-tree version, they’re dirt cheap from the usual used-book sources. Search for ISBN 1-57398-017-X (yes, X) and you’ll get pretty close.
Or, seeing as how I just touched the carton of books I’ve been toting all these years, send me $25 (I’m easy to find; if all else fails, look up my amateur callsign in the FCC database) and get an autographed copy direct from the source. Who knows? It might be worth something some day…
A discussion on the MHV LUG mailing list pointed to the Gibson Research DNSBench utility. Letting it chew on all the nameservers it can find, then mulling over the results for a bit, produced this short list:
NY Public Library: 68.88.88.2
Level 3 Comm: 4.2.2.3 or .5
Yale: 130.132.1.10 or 11
NTT: 129.250.48.98
Feed those into Network Manager (or /etc/resolv.conf) in some permuted order and away you go… at least if you’re near Poughkeepsie and using Optimum Online. Change anything and the results will differ.
I’d been using OpenDNS at 208.67.22[02].22[02], but the new ones test out as marginally faster and are certainly more diverse. Who knew NYPL ran a DNS?
For Tux pix, one should start with Larry Ewing’s drawings; I used the EPS version to get a scalable vector drawing. Run it through The GIMP, close the outline at the flippers, fill with black, save as PNG. Then import into Inkscape, trace the outline, and something like this pops out:
Tux Outline
The reason for using Inkscape is that OpenSCAD imports a very limited subset of all possible DXF files and, while Inkscape can (with some care) produce a DXF format that OpenSCAD can import, somehow the shape lacked interior fill. Sean took a slightly different approach with the same tools and managed to create a useful DXF file that produced this chunk o’ bits:
Tux Slab – solid model
The DXF import still didn’t work dependably, so I exported the Tux Slab from OpenSCAD to an STL file; if you want to extrude a solid Tux, that’s probably the way to go. Importing the STL in the next steps worked fine.
The Parametric Cookie Cutter by nateoostendorp creates thin cutter walls by subtracting a linear dimension from the X- and Y-axis extents of the shape. Unfortunately, Tux has crazy flipper feet that didn’t respond well to that; the walls developed gaps at the inflection points from self-intersections.
So I started from scratch with a Minkowski sum, which in this case amounts to rubbing a cylinder all over the Tux shape, then intersecting the resulting mega-penguin-post with a slab of the appropriate thickness sitting on the Z=0 plane. The Minkowski enlarges the XY outline by the cylinder’s radius and the Z thickness by twice the cylinder’s height, which I picked to be grossly excessive. Three Minkowskis produce the lip, wall, and tip of the cutter, which then stack up with a Tux-shaped hole subtracted from their midst:
Tux Cookie Cutter – solid model
The thicknesses and heights all derive directly from the extrusion parameters used to print the thing, because there’s not much room for roundoff. The middle section (the wall) is four threads wide, but Skeinforge divides the interior pair of threads into shorter sections with breakpoints at each sharp corner. The cutter section (the lip) is one thread wide, because I couldn’t get a good result with two threads.
The OpenSCAD preview has trouble with the Minkowski result and produces weird rendering glitches, but the CGAL model comes through fine. Note that Tux now has the opposite chirality, a gross oversight that became obvious only after the third cutter emerged from the Basement Laboratory. Here’s the second cutter:
Tux Cutter – reversed
Each cutter takes about 35 minutes to build, so I boiled the highlights down into a thrilling 6 minute movie.
The OpenSCAD source code, into which you can substitute your very own STL shape file:
// Tux cookie cutter using Minkowski sum
// Ed Nisley KE4ZNU - Sept 2011
//- Extrusion parameters - must match reality!
ThreadThick = 0.33;
ThreadWidth = 2.0 * ThreadThick;
function IntegerMultiple(Size,Unit) = Unit * ceil(Size / Unit);
MaxSize = 110; // larger than any possible dimension ...
//- Cookie cutter parameters
Size = 100;
TipHeight = IntegerMultiple(8,ThreadThick);
TipThick = 1*ThreadWidth;
WallHeight = IntegerMultiple(7,ThreadThick);
WallThick = 4*ThreadWidth;
LipHeight = IntegerMultiple(1.5,ThreadWidth);
LipThick = IntegerMultiple(5,ThreadWidth);
//- Wrapper for the shape of your choice
module Shape(Size) {
Tux(Size);
}
//- A solid slab of Tux goodness in simple STL format
// Choose magic values to:
// center it in XY
// reversed across Y axis (prints with handle on bottom)
// bottom on Z=0
// make it MaxSize from head to feet
module Tux(Scale) {
STLscale = 250;
scale(Scale/STLscale)
translate([105,-145,0])
scale([-1,1,24])
import_stl(
file = "/mnt/bulkdata/Project Files/Thing-O-Matic/Tux Cookie Cutter/Tux Plate.stl",
convexity=5);
}
//- Given a Shape(), return enlarged slab of given thickness
module EnlargeSlab(Scale, WallThick, SlabThick) {
intersection() {
translate([0,0,SlabThick/2])
cube([MaxSize,MaxSize,SlabThick],center=true);
minkowski() {
Shape(Scale);
cylinder(r=WallThick,h=MaxSize);
}
}
}
//- Put peg grid on build surface
module ShowPegGrid(Space = 10.0,Size = 1.0) {
Range = floor(50 / Space);
for (x=[-Range:Range])
for (y=[-Range:Range])
translate([x*Space,y*Space,Size/2])
%cube(Size,center=true);
}
//- Build it
ShowPegGrid();
//cube(5);
difference() {
union() {
translate([0,0,(WallHeight + LipHeight)])
EnlargeSlab(Size,TipThick,TipHeight);
translate([0,0,LipHeight])
EnlargeSlab(Size,WallThick,WallHeight);
EnlargeSlab(Size,LipThick,LipHeight);
}
Shape(Size); // punch out cookie hole
}
My first pass at the NEMA 17 motor mount bracket used additive modeling, glomming together several blocks made from cube primitives:
The motor mounting plate, less five holes
Two side struts to stiffen the motor plate
The baseplate, minus two mounting holes
Makes perfect sense to me; perhaps I’m an additive kind of guy. That produced an OpenSCAD model with positive surfaces for the various parts and negative surfaces inside the holes:
NEMA 17 Mount – additive model
Compile that through CGAL, export as STL, inhale into RepG 25, and you (well, I) get what looks to be a fine object in the preview pane:
NEMA 17 RepG preview – additive
Then run it through Skeinforge 40, which emits a flurry of messages along these lines:
[19:11:08] Warning, the triangle mesh slice intersects itself in getLoopsFromCorrectMesh in triangle_mesh.
[19:11:08] Something will still be printed, but there is no guarantee that it will be the correct shape.
[19:11:08] Once the gcode is saved, you should check over the layer with a z of:
[19:11:09] 0.165
The usual searching suggested that sometimes Skeinforge has problems with coincident surfaces, such as between the motor mount plate and the struts and the base, or coincident edges where two blocks abut. Judging from the messages, the problem ran all the way to the top of the struts. Oddly, Skeinview didn’t show any problems, so the G-Code was (presumably) OK.
Error messages tend to make me twitchy, though. I modified the OpenSCAD code to extend the struts 0.1 mm inside the base and ran that model through the software stack, which produced not a single complaint about anything, anywhere.
Success!
However, painful experience has caused me to review the G-Code for every single object with the Skeinlayer plugin, which, right on cue, revealed this interesting anomaly:
NEMA 17 Mount – Skeinview – Bad gcode
That happened for every layer in the square motor mount plate: the lower right corner is fine, the upper left seems to be the negative of the actual solid model. The holes are filled, the plate is empty. The Skirt outline ignores the smaller holes, goes around the large one, and continues on its merry way.
I putzed around for a while and discovered that the failure seems acutely sensitive to the side strut thickness. Yeah, like that makes any sense.
Any variations along those lines that I tried generated either:
A flurry of mesh error messages, with seemingly good G-Code
No error messages whatsoever, with totally bogus G-Code
Running the STL files through netfabb Cloud Service produced the same diagnostic for both:
Number of holes: 3
Number of shells: 2
Mesh is not manifold and oriented.
We unfortunately have not yet enough experience with the occuring server loads, that we can securely enable shell merging at the moment.
However, the repaired STL files produce correct G-Code: evidently OpenSCAD spits out bogus STL data. The fact that RepG/SF treats the two files differently suggests improved diagnostics would be in order, but that’s in the nature of fine tuning.
So I junked the additive model and went subtractive, chewing the recesses out of one huge block:
NEMA 17 Stepper Mount – solid model
That worked:
Number of holes: 0
Number of shells: 1
Mesh is manifold and oriented.
I like processes that don’t emit error messages or result in mysterious failures, although it’s not obvious that subtractive modeling will always produce correct results. Heck, I’m not sure I can think in terms of negative volumes all that well.
The OpenSCAD code for the additive model, with a highlight on the conditional that will trigger the two errors:
OpenSCAD depends on CGAL for all the 3D heavy lifting, which puts any STL export problems further upstream. I suppose I could open Yet Another RepG ticket to get better diagnostics, but the others haven’t gotten much attention so far and I suppose it’s not really their problem anyway.
It looks about the same as before, only now it’s transparent gray. The 2-unit cube in the middle marks the “your object goes there” spot; the % prefix on the grid cubes causes OpenSCAD to ignore them.
OpenSCAD Build Surface Grid – revised
The OpenSCAD source code:
module ShowPegGrid(Space = 10.0,Size = 1.0) {
Range = floor(50 / Space);
for (x=[-Range:Range])
for (y=[-Range:Range])
translate([x*Space,y*Space,Size/2])
%cube(Size,center=true);
}
ShowPegGrid();
cube(2,center=true);
The Smell of Molten Projects in the Morning 