Ed Nisley's Blog: Shop notes, electronics, firmware, machinery, 3D printing, laser cuttery, and curiosities. Contents: 100% human thinking, 0% AI slop.
As the writing says, printed at 20 & 100 mm/s, 0.33 mm thickness, 0.66 mm width, and bridge speed at 1.0 to 1.3 times the usual.
I tried a few variations and got decent results with the bars set to 3 threads wide (the pix show 4 × bars). Making it fairly tall (11 × thread thickness, IIRC) helps get enough clearance below the sagging bridges between the vertical pegs. I’m amazed it works as well as it does.
Dropping to a width of 2 threads doesn’t work: the vertical pegs simply disappear from the G-Code! Turning the pegs into cylinders might help.
A pair of flush-cutting wire nippers applied to the top of the pegs along one edge allows you to lace a pair of sheets together. Apply a micro-drop of plastic cement to each cut, put a roll of duct tape on the joint overnight, and it’s all good.
My Shop Assistant has some interesting ideas for this, although I was mostly interested in its build-ability. It’s wonderful to see the printer lay down a sheet of tiny vertical pegs, five layers tall, and clear the top of every one, every time, on its way back and forth.
It had a bit of trouble with overhang under the ears, but I figure rabbits are soft and fluffy there anyway, so I’ll define this as a feature rather than a bug:
Stanford Bunny – ear overhang
What’s nice: all I did was slice the STL and build the rabbit. No muss, no fuss: It. Just. Works.
If you look very closely, you can see early Reversal suckouts just to the left of the zit marking the start of the thread. This was the object that prompted me to turn off early Reversal action, but I still haven’t figured out how to get rid of the zits:
Stanford Bunny – Reversal suckouts and zits
(Is it just me or does that not look like part of a rabbit?)
All in all, though, this bunny marks the end of the Intense Thing-O-Matic Hackage era. The printer now works dependably, prints parts accurately, and doesn’t require a lot of babysitting. I’ll present some test pieces over the next few days that explore some variations.
This one didn’t work out at all and, after a few attempts, I gave up:
Failed Heart Gears objects
It turns out that the myriad gear teeth curl up slightly as they cool. At some point, one of them will snag the nozzle and, even with good steppers in full effect, yank the XY stage to a dead stop. The missed steps cause that ledge a few millimeters up from the plate and, of course, the gears don’t mesh at all.
I watched it happen and stopped the print as soon as I could, but I didn’t catch exactly which tooth did the damage. Then I extracted just the bottom few layers by importing the STL into OpenSCAD, subtracting a block from the top, exporting what’s left as another STL, then built just that chunk.
Of course, that worked perfectly:
Heart Gears – curling gear teeth
Printing each object separately should eliminate the problem: the nozzle would remain within the outline at all times and, with a smaller part, the plastic would stay bendy.
Never negotiate a biz deal with a stranger using email
In the course of half a dozen volleys, the two of you will wedge each other into corners from which there is no possible retreat or compromise.
Even if you both think the venture would be a Good Idea and even if you both think it’d be fun & interesting, you’ll find perfectly valid reasons to call it off.
One evening I noticed that the kitchen faucet handle was skewed far off to one side and didn’t rotate to the other side as it should. I took the thing apart and found the whole pedestal was rotated:
Rotated kitchen faucet – top
It turns out that the screws on the clamping ring below the sink had worked loose over the last decade or so, allowing the pedestal to rotate just a wee bit as we swung the spout from basin to basin.
Kitchen faucet clamping ring
Of course it only rotated a little bit in one direction and never the other way…
I epoxied that aluminum plate when I installed the faucet, because the stainless steel sink top seemed too flexy. The plate stiffened it right up and it’s been fine ever since.
A 3×3 array of dodecahedra printed at 50 mm/s with 100 mm/s moves:
Dodecahedra – 50 mm per sec
You can clearly see the axis oscillation near the left edges.
What’s nice: the total lack of threads between the parts: snap ’em off the platform and they’re done!
After they built halfway up the top facets, I dropped a ball bearing in each one. They rattled around something fierce, but didn’t quite hop out.
Building a single dodecahedron at 20 mm/s showed that the oscillation problem really is due to the speed. More accurately, the problem is the abrupt change in velocity as the axes change direction without any deceleration / acceleration in the middle.
Here, the single line near the edge matches up with the internal fill, so it’s not an oscillation:
Dodecahedron – 20 mm per sec
The small ripples come from a mechanical resonance in the geared stepper mount pumped by its full-step drive at 1.28 rev/min. I’m using a failed MBI stepper driver board that can only do full stepping, so trying 1/2 stepping won’t happen until I build a 4-axis space transformer for those tiny Pololu stepper boards.
As you’ve probably noticed, I’ve gone back to Kapton tape on the build platform, rather than the ABS I’d been using. AFAICT, the Kapton didn’t work well on my earlier attempts because I didn’t have good control over the first-layer thickness and was probably printing too fast for conditions.
The Z-min switch solves the layer thickness problem and printing at 10 to 15 mm/s for the first layer glues the thread in place. So far, so good!
As it turned out, though, that part wasn’t the first attempt.
Caliper part – heavy blobbing
Even switching to red filament didn’t help:
Extrusion blob – top view
That, in fact, was when the light dawned: it always failed at exactly the same point for a given set of G-Code.
Come to find out that, for some parts printed with certain options, the Skeinforge Reversal plugin dependably produces huge blobs of plastic after a move. The extruder reverses properly, the XY stages move, then the extruder starts running forward at the Reversal speed while the XY stages move at whatever rate they’re supposed to for the next thread, producing a prodigious blob.
Extrusion blob – side view
Most parts have much more interior than they do exterior and, with any luck, the blobs vanish inside. However, this little bitty thing has no room to hide a blob. Several parts went down the drain, but at least it had a countable number of layers!
You need that program, because ordinary grep only searches within a single line. In this case, the G-Code pattern extends over several lines. The pcre stands for Perl Compatible Regular Expressions and the -M turns on multi-line matching.
You can count the number of blobs with the -cl options.
Having found the blobs, edit the file, jump to the indicated lines, copy the nearest preceding forward extruder move, including the speed setting, and paste it in front of the M101 that starts the extruder. If my sed-fu were stronger, I could automate that process.
Unleashing pcregrep on my collection of G-Code files shows a bunch of ’em with blobs and a few without. Note that this has nothing to do with the firmware running on the printer, because the G-Code has the error.
What happens, I think, is that Reversal emits a correct reverse at the end of a thread, does a fast move to the start of the next thread, notices that (at least) the first G1 of the new thread falls below the length threshold that would activate the un-reversal action, and incorrectly assumes that it need not run the extruder forward to restore working pressure. The to-be-printed G1 commands all seem to be very short in the failing G-Code files I’ve examined.
Setting the reversal threshold to 0.0 should avoid triggering this error. I’ve verified that it produces correct G-Code for two parts that didn’t work before, but that’s not conclusive proof.
I’ve looked into reversal.py and fixing (heck, finding) this error lies beyond my abilities.
The Smell of Molten Projects in the Morning 