The Smell of Molten Projects in the Morning

Ed Nisley's Blog: Shop notes, electronics, firmware, machinery, 3D printing, laser cuttery, and curiosities. Contents: 100% human thinking, 0% AI slop.

Category: Machine Shop

Mechanical widgetry

  • Thing-O-Matic: Software Shuffling

    Having installed the 0.4 mm nozzle, being desirous of turning on Skeinforge’s Dimension plugin, and being therefore faced with recalibrating everything, I figured I might as well update all the software to the current versions before commencing. While this adventure turned out well in the end, it required fitting together a large number of moving parts; this is an overview / core dump of how I picked the pieces.

    Note: I’ve certainly gotten something wrong in this mess, perhaps drastically so. Let me know, but consider the entire assembly before suggesting a different part.

    ReplicatorG is the default Thing-O-Matic printer interface and consists of two parts: the Java-based Arduino-IDE-oid program on the PC and the firmware inside the printer (which is, itself, in two parts divided: Motherboard and Extruder Controller). Their mutual interfaces have become sufficiently tangled that they must upgrade in lockstep, as no versions have backwards or forwards compatibility.

    RepG 29 bundles Skeinforge 35 as its default STL-to-G-Code converter, with 40 and 41 as experimental (i.e., largely unsupported) options. Skeinforge 35 is now ten full clicks behind the current version, came out on 6 November 2010, and has a number of fairly well-known problems. Although I understand the need for upstream stability, SF35 long ago fell off the thick edge of the wedge and even SF41 is 8 months old.

    I have been using RepG with SF40 for much of the last year, having figured out the parameters essentially from scratch to suit my admittedly oddball configuration & preferences. Regressing to SF35 lacks appeal and, frankly, going just one click up to slightly less obsolescent SF41 isn’t in the cards, either. I have no particular aversion to using bone-stock Skeinforge, fetching the most current version as needed, and controlling the update process myself.

    RepG manages Skeinforge profiles that collect its myriad parameters into named groups that can be selected for a particular build. RepG also includes a Print-O-Matic function that pre-sets / computes key SF parameters based on desired extrusion parameters within a given profile, but (apparently) only for SF35. Given that I want a single printer configuration that produces known-good results, putzing around with multiple profiles isn’t of interest and I’m unwilling to use an obsolete version of Skeinforge to sidestep them.

    FWIW, I eventually figured out that having one master set of start.gcode, end.gcode, and alterations.csv files with symlinks from the profiles helps keeps the clutter under control, which is particularly important given the complexity of my homing routine. RepG doesn’t create symlinks in new profiles, but after you’re used to it, you just create a profile, blow away the copies, and install the symlinks.

    So RepG really doesn’t provide what the B-school gurus called a compelling value proposition for my use case. The STL models I cook up using OpenSCAD emerge properly scaled, properly located, properly oriented, and ready to build. All I need is a way to convert those STL models to G-Code, then send G-Code to the printer. Everything else RepG does simply gets in the way.

    The dealbreaker, however, was having RepG 28 occasionally freeze up solid, to the extent of requiring a killall java in a console window to dispose of the corpse. RepG 29 misbehaved the same way and both failed on two different machines with two different versions of Ubuntu. The hole may have been in my end of the boat, but I didn’t devote much time to diagnosing / reporting the problem, given the attention given to the last batch of tickets I opened.

    Freed from the confines of RepG, Skeinforge turns out to be not nearly so intimidating as one might be led to believe. Admittedly, a bit of option pruning helps, but after that you’re left with knobs controlling those things that need controlling.

    Slic3r seems to be the up-and-coming alternative G-Code generator. The key problem, at least for the objects I create, is the lack of an equivalent to the Skeinforge Cool setting that enforces a minimum time for each layer. Printing exactly one of those caliper repair parts at 15 seconds per layer worked perfectly: no fans, no slumping, no hysteria. One could, I suppose, slow the motion throughout the entire object to make the top come out right, but that’s not appropriate for large parts with small towers. Slic3r is under heavy development, so who knows what the New Year will bring?

    Incidentally, my experience with those earlier caliper parts explains why I’m unwilling to regress Skeinforge just to use RepG.

    Kliment’s Printrun wins, hands down, as the RepRap UI that does what I need and very little else. The pronterface GUI presents a reasonably clean, single window printer interface. Even better, from my perspective, is the pronsole command-line interface; I generally do everything except actually print while sitting upstairs in the Comfy Chair, so being able to drive the printer with a command-line interface through a simple SSH session (shared keys, an oddball port, no root logins) is wonderful.

    The pronterface G-Code preview pane has its origin at the lower-left corner, presumably from its RepRap lineage, while RepG puts (0,0) at the build platform’s dead center. Centering the origin avoids baking the platform dimensions into the G-Code and greatly simplifies the overall alignment, but the mismatch is not insuperable: I can ignore the preview and the printer will be perfectly happy.

    However, MBI firmware expects to receive a binary version of the G-Code file, known as S3G and documented there, from the PC through the UI. As nearly as I can tell, nobody else does it that way and none of the other UIs do S3G translation / compilation. Not using RepG means ditching the MBI firmware inside the printer in order to use any other UI.

    The current state-of-the-art open-source 3D printing firmware seems to be the Marlin branch of the Sprinter family tree. Its main appeal, at least for me, is motion control with acceleration limiting, which should resolve most of the problems with the MBI stock firmware and greatly enhance the printer’s performance & print quality. For more details on that topic, search herein for acceleration. Alas, Marlin runs on “single processor electronics” controllers, categorically excluding MBI’s Motherboard + Extruder Controller configuration.

    While I could junk the entire contents of the Thing-O-Matic’s electronics bay and pop in a RepRap RAMPS 1.4,  Generation 6, or Generation 7 electronics package just to use Marlin, that bears a strong resemblance to bad craziness, even by my relaxed standards (although, should another MBI stepper driver board go toes-up, it’ll make considerable economic sense). That comparison of various electronics packages may be helpful. The temperature sense hardware for most of those boards uses thermistors, which means tearing apart the Thermal Core to replace a thermocouple that delivers perfectly accurate results with a thermistor requiring fiddly calibration, which I’d be willing to do, but …

    As it turns out, ScribbleJ’s SJFW firmware runs on both RepRap and MBI electronics, includes acceleration limiting, features automagic endstop position settings for both min & max positions, and seems reasonably stable. It has some quirks (no G0 rapid motion, no G28 homing, weird G-Code parsing assumptions / failures), but on the whole it does what’s needed.

    So the software stack, from the top down, consists of:

    • OpenSCAD
    • Skeinforge
    • Printrun UI — pronsole / pronterface
    • SJFW Motherboard firmware
    • Bone-stock MBI Extruder Controller firmware

    Everything requires configuration / tweaking before plastic starts oozing out of the nozzle. Then I can begin retuning the printing process.

    The overall workflow looks like this:

    • Edit/save OpenSCAD program in external editor on right-hand portrait monitor
    • Watch/examine OpenSCAD 3D rendering on left-hand landscape monitor, iterate
    • Export to STL on file server
    • Convert to G-Code using Skeinforge on PC at printer via SSH
    • Examine proposed G-Code paths with Skeinlayer (set to auto-display), iterate
    • Load/print with pronsole / pronterface via SSH/VNC
    • Trot downstairs to watch the show

    For the relatively simple models I build, CPU load generally isn’t a big deal. I’ll move the Skeinforge config from ~/.skeinforge to the server and add symlinks to it from both PCs, so as to run SF from either PC with the same settings and eliminate synchronization hassles.

    I’ll be writing up my scattered notes over the next week or so…

  • Sony NP-FS11 Batteries: After the Aftermarket

    The batteries I rebuilt for our much-beloved Sony DSC-F505V camera back in early 2010 have faded away with constant use. Having already sawed the cases open, rebuilding three of them didn’t pose much of a challenge; this time I added a short tab of Kapton tape to help extract them from the camera socket.

    Rebuilt NP-FS11 batteries
    Rebuilt NP-FS11 batteries

    Three batteries seems to be about the minimax for ordinary use:

    • One in the camera
    • One in the carrying case
    • One in the charger

    You (well, we) can’t keep track of more than three: it always seems one battery gets overused and another gets lost in the dark. We’ll see how three works in practice; there’s a set of six more raw cells lying in wait.

    The new batteries produced these results on their first two charge-discharge cycles:

    Sony NP-FS11 2011 Packs - First Charges
    Sony NP-FS11 2011 Packs – First Charges

    One battery didn’t come up to speed on the first charge, but after that they’re all pretty close.

  • Skeinforge: Simplified Plugin Selection Page

    The Skeinforge Craft window presents a formidable array of buttons, one for each possible plugin:

    Skeinforge standard
    Skeinforge standard

    I’ve disabled many of those plugins because, for example, limiting Z-axis speed isn’t relevant on my printer. If you’re sure you won’t use some of the plugins, remove them by editing /where-it's-installed/skeinforge_application/skeinforge_plugins/profile_plugins/extrusion.py thusly…

    In getCraftSequence(), located at about the midpoint of that file, duplicate the line that lists the plugins and add an octothorpe (OK, a hash) to make one line a Python comment, then remove the plugins you don’t care about from the other line:

    def getCraftSequence():
	'Get the extrusion craft sequence.'
#	return 'carve scale bottom preface widen inset fill multiply speed temperature raft skirt chamber tower jitter clip smooth stretch skin comb cool hop wipe oozebane splodge home lash fillet limit unpause dimension alteration export'.split()
	return 'carve scale preface inset fill multiply speed temperature raft skirt jitter clip smooth skin cool dimension alteration export'.split()

    This being Python, do not change the indentation. If you get overenthusiastic and toss something useful overboard or just pine for the Good Old Days, swap the octothorpe to your modified line to restore the original plugin assortment.

    Save the result and you’ll see only the useful buttons:

    Skeinforge simplified
    Skeinforge simplified

    There, now, wasn’t that easy?

  • Enabling Remote Desktop Sharing in Xubuntu

    I set up Xubuntu 11.10 on the Dell 531S driving the Thing-O-Matic, as the Unity UI seems surprisingly like crippleware: every feature that isn’t mandatory is prohibited. However, Xubuntu’s XFCE UI also has a long list of things that should be easy and aren’t, such as enabling remote desktop sharing. Gotta have that so I can fire up the printer and monitor progress from upstairs.

    It turns out that the Vino server is installed, but not enabled, so you must start by firing up vino-preferences in a terminal to set some preferences:

    This is a local machine behind a firewall, so a moderately secure password with no confirmation will suffice. Your paranoia may vary.

    Then drill down through the menu from Settings → Settings Manager → Session and Startup to the Application Autostart tab, then Add the Vino VNC Server to the list: /usr/lib/vino/vino-server. You can start it manually if you have the hots for immediate sharing.

    This seems to be impossible in Unity, trivially easy in GNOME, and unduly mysterious in XFCE.

  • Thing-O-Matic: Filament Melt Zone

    The 0.5 mm nozzle came off the hot end with surprisingly little effort; the high-temperature lube did its job! I dismantled the tensioner, clipped the filament at the top of the drive wheel, and extracted it (with the red PTFE insulation / guide tube) through the bottom of the Thermal Core. Getting the filament out of the tube required the gentle suasion of a pin punch, but eventually I found this:

    Filament melt zone - overview
    Filament melt zone – overview

    Although you can’t tell from the picture, the filament seems completely melted for about 20 mm, well-softened for another 20 mm, and soft for about 10 mm. Here’s a detail of the transition from well-softened to soft to hard:

    Filament melt zone - detail
    Filament melt zone – detail

    Notice how the notches from the drive wheel gradually fade out over about 10 mm, whereupon the filament expands to fill the PTFE tube. You can’t see the shallow depression from an air pocket offscreen at about 30 mm, but it suggests the filament isn’t quite molten from 20 mm onward. Given that the distance from the nozzle tip to the top of the Thermal Core is about 40 mm, all this makes sense, particularly when you figure the filament was stationary as the Core cooled off after the last print: the melted-to-melty sections are inside the Core and the softened section is just above the Core.

    In round numbers, the Thermal Core supplies enough heat through the PTFE tube to fully melt the filament for about 20 mm above the nozzle when printing at 2 rev/min. The effective drive diameter is 9.6 mm, so 1 rev = 9.6 π = 30 mm and the Core must melt 60 mm/min = 1 mm/s. This is obviously a grossly nonlinear situation, but if you get only 20 mm of molten filament at 1 mm/s, the maximum speed can’t be much more than 4 mm/s or so.

    The rest of the Thing-O-Matic’s mechanics set an upper limit for, say, printed octopi at 80 mm/s and 4 rev/min = 2 mm/s, but the extruder will definitely be the limiting factor for speeds over, say, 150 mm/s. Not much risk of that happening here, I’d say.

    I’ve settled on Reversal for 125 ms at 25 rev/min, so the retraction distance is:

    1.6 mm = (30 mm/rev) (0.125 s) (25 rev/min) / (60 s/min)

    That’s somewhat smaller than the 3 mm of pushback I’ve seen when swapping filaments in mid-print, but it’s in the right ballpark.

    Now, to install the 0.4 mm nozzle and recalibrate the software yet again…

  • RCA Alarm Clock Dimming

    Mary prefers dim digits on the bedroom alarm clock, far below what the usual DIM switch setting provides. I’d slipped a two-stop neutral density filter in front of our old clock’s VFD tube, but the new one has nice green LED digits that ought to have a tweakable current-setting resistor behind the switch. Indeed, a bit of surgery revealed the switch & resistors:

    RCA clock - DIM switch and resistors
    RCA clock – DIM switch and resistors

    It turns out that the 220 Ω resistors set the DIM current, with the 100 Ω resistors in parallel to set the BRIGHT current. Weirdly, the display operates in two halves: one resistor for the lower and middle segments, the other for the top segments. The resistor numbers give a hint of what the schematic might look like:

    RCA clock - LED current-set resistors
    RCA clock – LED current-set resistors

    The current control isn’t all that good, because the brightness varies with the number of active segments. With 470 Ω resistors (yes, from that assortment) in place, the variation became much more obvious; the LEDs are operating far down on their exponential I-vs-V curve. We defined the result to be Good Enough for the purpose.

    Four short screws hold the circuit board in place, but one of them arrived loosely held in a pre-stripped hole. I cut eight lengths of black Skirt filament, anointed them with solvent adhesive, dropped two apiece into each screw hole, and ran the screws back in place. I likely won’t be back in there, so it should be a lifetime fix:

    RCA clock - ABS filament in screw hole
    RCA clock – ABS filament in screw hole

    Done!

    As with all the trade names you remember from back in the Old Days, the present incarnation of “RCA” has nothing whatosever to do with the original Radio Corporation of America:

    RCA clock - data plate
    RCA clock – data plate

  • Brita Pitcher Lid Hinge

    This pitiful excuse for a hinge actually lasted far longer than I expected:

    Brita pitcher lid hinge pins
    Brita pitcher lid hinge pins

    Also much to my surprise, the plastic solvent-bonded to itself, although I doubt either of those pins will survive another four years.

    The yellow discoloration seems to be most prominent on the inside of the lid, which suggests the water is nastier than they’d have you believe. The disinfection additive has switched from chlorine to chloramine and back to chlorine over the last few years, which may have something to do with it.