Ed Nisley's Blog: Shop notes, electronics, firmware, machinery, 3D printing, laser cuttery, and curiosities. Contents: 100% human thinking, 0% AI slop.
Although those pink clamp platesworked well enough, they did not provide, shall we say, a completely satisfactory user experience. I reprinted new sets in red while varying the extruder speed by 0.1 rev/min, with small tweaks to the overlap between the infill and the loop threads.
First, the big pictures with details scrawled on the back of the lower plate…
At 3.2 rpm, which is only slightly too fast:
Fairing Plate – 3.2 rpm
At 3.3 rpm, a bit overstuffed:
Fairing Plate – 3.3 rpm
At 3.4 rpm, there’s obviously too much plastic:
Fairing Plate – 3.4 rpm
Some closeups, in the same order…
At 3.2 rpm with 0.20 overlap, it looks OK:
Fairing Plate – 3.2 rpm detail
At 3.3 rpm with 0.25 overlap, which pretty much devours the inner loop thread:
Fairing Plate – 3.3 rpm detail
At 3.4 rpm with 0.25 overlap there’s serious overfill:
Fairing Plate – 3.4 rpm detail
In all cases, the extruder left a track while exiting upward from near the middle of the images. Even at 3. 2 rpm there’s slightly too much plastic.
My ladies don’t care about the fine details. They prefer red to pink and the clamps hold the fairings firmly in place…
A miniature version of the Swig Cup came out reasonably well. It’s supposed to be a platform-filling monster; at only 25 mm tall, it’s cute:
Miniature Swig Cup
There’s a bit of trouble with the overhangs at the bottom and top of the handle and the spouts at the top look a bit lumpy. What you can’t tell from that crappy picture is that the panels don’t quite seal to the cylinders: it’s not watertight.
You’ll also have trouble seeing the fine hairs connecting all the spouts. The Reversal plugin in combination with 100 mm/s moves makes the ooze hairs easily removable, although I tend to leave them in place for show-n-tells.
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.
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 