Advertisements

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…

Advertisements

  1. #1 by bstott200 on 2011-12-26 - 10:53

    Thanks for your discription of the RepRap firmwares. I did not know how they related to MBI. Sounds like the logical process. I was also wandering about ScribbleJ’s firmware. Too bad my file server drive went south. I’m not in the mood for rebuilding, reconfiguring and all the tweaks. It was a Toshiba Magnia SG20. It sits beside – collecting dust. My household network after 19 years is a shambles with parts having antiquated, failed, upgraded, moved several times and I’m tired of the tweaking. I just last month did string a wire (Yes, wire – the wireless went out on the printer control/set-up laptop) to the Vista machine I inherited from the off to college daughter. Ack… Vista but, I don’t want to invest the time or money to upgrade!

    Ed, Hope the end of your year goes well and your beginning is GREAT! Best wishes to you and yours and that everyone does as they should. :-) Brian Stott – Pittsburgh.

    • #2 by Ed on 2011-12-26 - 20:01

      I’m not in the mood for rebuilding, reconfiguring and all the tweaks

      I know that feeling! The “file server” is a Foxconn Atom D520 with Xubuntu 11.10, so it’s not nearly as exotic as it sounds. Having everything stored there, with nightly backups, takes a load off configuring all the other systems. I must admit getting Samba working with the Token Windows Laptop tends to generate more steam around my collar than it really should, though.

      FWIW, our Larval Engineer just confessed to having snuck a CAT5 cable from her room into her closet, through the plumbing hatch behind the tub, down into the basement, neatly tucked around all the shop crap, and into the last remaining port on the network switch over the TOM & Sherline. Well done, sez I, even if it does enable her nocturnal lifestyle…

      Thanks for the good words: it’s been a fun year!

  2. #3 by c0derage on 2011-12-26 - 13:19

    Ed,
    Surprised you didn’t give SFACT a spin. Granted it’s only a modified version of Skeinforge but it does take a lot less effort to configure. Mad.e the switch a month or so ago, wish I had done it sooner.

    Regarding stepper controllers, reading how the allegro based devices fail on a regular bases I opted to use some ‘inexpensive’ controllers from keiling inc. Having to replace the drivers once would make up the difference in cost. From what I’ve read, the RAMPS drivers are not much different than the MBI drivers and doubt they have discernible difference in reliability. Admittedly, that is conjecture on my part.

    Looking forward to reading your findings, been too wary of the open source bleeding edge. That and my days are spent troubleshooting colicky babies as of late. No time for tinkering.

    • #4 by Ed on 2011-12-26 - 19:53

      it’s only a modified version of Skeinforge

      Therein lies the rub: SFACT comes bundled with its own version of Skeinforge, but it’s not clear which one and whether you can update SF to the version of the day. If I’m going to be using Skeinforge anyway, I’d like to have control over that one really big knob on the top!

      Dimension reduces the whole extrusion configuration to measuring the filament diameter, then putzing with the “filament packing density” knob, which is really just a way of tweaking the filament speed, until the right answer comes out right. Of course, then you (well, I) run into the nonlinearities involved with different speeds, but …

      the RAMPS drivers are not much different than the MBI drivers

      True, but as nearly as I can tell, any of the “all in one” boards costs about as much as any two MBI boards and some of them actually have replaceable parts. Getting rid of some clutter in the electronics bay would be a pleasant side effect…

      troubleshooting colicky babies

      Give ’em a few years and you’ll have a brace of Shop Assistants!

  3. #5 by benipk on 2011-12-26 - 21:01

    I’m using ScribbleJ’s firmware in a Thing-O-Matic, along with Kliments Printerface and everything is going pretty smoothly. Sadly ScribbleJ appears to have stopped updating and revising his firmware, but what’s there works like a charm now with the exception of support for an LCD display and control pad.The biggest headache to get it all working was to get all the python modules installed for both printrun and the firmware compiler, but once all that’s set up it’s straightforward to tweak the acceleration variables, upload it to the makerbot and get printing :)

    I’m a complete doofus when it comes to software/coding but I’m more than happy to share how I got my own setup working. I just can’t go back to stock standard RepG and the MBI firmware now as the bot will just start shaking itself to bits with speeds over 40mm/s without acceleration.

    • #6 by Ed on 2011-12-27 - 12:38

      ScribbleJ … [has] stopped updating and revising his firmware

      Ouch. I hope somebody will pick it up and run with it, although most likely it’ll fade away in favor of the Marlin branch. Which means I must eventually break down and buy one of those single-processor boards.

      speeds over 40mm/s without acceleration

      The acceleration numbers that went up today worked reasonably well. After a bit of adjusting (which I’ll get into in a few days), the thing can now run the Smooth Axis Motion test at 250 mm/s. Can’t print at that speed, but the thing isn’t losing its position or shaking off the shelf, either!

      A spectacular improvement, indeed!

      • #7 by bstott200 on 2011-12-27 - 17:47

        Ed,

        uh, you kinda like —- program? mmmm….. uh, well, uh, maybe like, you know….. You could pick up the OpenSource and clear some brush for the decrepit ignert of us?

        That is to say, Many of us are not conversant or understanding of any code, but you who have swam the oceans and tangled with the sharks could surely make a solid showing??? Would You?

        • #8 by Ed on 2011-12-27 - 22:04

          You could pick up the OpenSource

          And drop it on my toes. I’ve looked at that code: I’m not competent to carry his water bottle.

          If the truth be told, all I really want to do is print plastic widgets that I build into other things. All this printer improvement / development stuff is a distraction. [grin]

          Judging from ScribbleJ’s photo stream, he just moved into a new house. If my experience is any guide, that’s the end of his other activities for, oh, another two years… houses, even new houses, are trouble!

          • #9 by bstott200 on 2011-12-27 - 23:45

            Gotcha. I hadn’t looked at ScribbleJ’s doings since about Sept…. Houses, ah yeah. There is moldings, then crown moldings, hose bibs, fireplace appointments, wall hangings, yard trim, bushes, trees, garages, door knobs, lights, new furniture, changing colors, switch plates and electrical outlets, unpacking, re-packing, throwing out. Yada, yada, yada…. Too many things to tweak. He’s gone. ;-> Too Bad. I’m looking at RTOS and ‘C’ coding but, I’m already over my head with all the new electronics that I am just seeing chinese.