As noted before, I hadn’t figured out how to get Skeinforge to run on a current computer, after losing my previous Skeinforge installation to the crashes of both my personal desktop and laptop computers, on which I had all of the data and none of the software or configurations backed up. (I’m wiser now.)

I struggled figuring out how to get Skeinforge running again now, in part because I think the instructions that come with it never got updated as its capabilities did. No, I am not going to copy the STL into the system executable directory every time I want to slice something and then move the resulting G-code back out. It turns out that any version of Skeinforge that I might actually want to run has a file browser and remembers where you browsed the last time you used it; so it’s pretty easy to get along with.

And as to which version I actually want to run, one of the files I did have backed up was my detailed notes on fine-tuning Skeinforge settings for my CupCake, which (naturally) included the fact that I was running Skeinforge 0035. So there we go.

With slicing working, that just leaves calibration, and I’ve done that now too.

Last weekend … the weekend before? (Time flies / Doesn’t seem a minute) … I used my favorite calibration set, coasterman’s Essential Calibration set, to (re)calibrate Skeinforge to my CupCake.

The first thin-wall box (upper left) is printed with Skeinforge’s default settings, which aren’t even for a CupCake, and was extruding way too much plastic. The second is printed after clicking in all of MakerBot’s published CupCake defaults, and was good enough for me.

The 20-mm infill boxes test the Infill Solidity setting, which I always mix up and take in the wrong direction before going the right direction. 1.7 gives a beautiful, smooth upper surface to my infill.

Bridging (lower left) is … something I’m not going to try too hard to adjust right now. It works-ish. The perimeter-width calibration objects fit together on the first try. The Oozebane tuning to reduce stringing as the nozzle moves from one print area to another … does nothing for me, and never has.

And then I was ready to print, so print I did!

The first non-calibration object I printed was this bracket I designed for 2020 aluminum extrusion (left). It doesn’t look so great. Let me tell you what’s wrong with it: … No, let me take the shorter approach of telling you what’s right with it: The two-hour print completed with no hitches. That is one hideous print.

I reprinted it with the Comb module activated (right), so that when it needs to move the nozzle from one area to another, it takes a path over the printed area instead of over open space, completely eliminating stringing. From the print areas. Comb completely eliminates stringing from the print areas. But Comb is executed (in the current toolchain configuration) before Raft; and Raft is the module that generates the support material that I was trying out in Skeinforge for my first time evar; so you still get stringing to and from the support material (and not even optimized for the shortest hop across open air). That’s handy.

And that support structure (front right) is … not what we’re used to in 2020. It’s actually not too bad — it uses material pretty efficiently; it generally is only generated where needed; and it generally detaches pretty easily. But it looks very different.

Also you can see how blobby and irregular the print is. Because the CupCake is horrible and incapable of printing smoothly? What if this is the best I can ever get?? All this effort … !!! … !!!

But I didn’t believe that. I’ve made smooth prints before; what’s the difference? The difference is that this object requires hopping the nozzle from area to area a lot; and rapidly stopping and restarting extrusion during nozzle hops are what a DC gearmotor extruder is worst at. With a stepper extruder, this part would be glorious!

Prove it!, you say. Fine; I’ll CAD up a part in which each layer has all smooth curves and no jumps, and we’ll see how gloriously it comes out.

There you go. The strands on the top layer are where the Y axis snagged and skipped steps and everything went poo; but otherwise, that’s a smooth print, photographed with the camera handheld in order to cause enough blur that you can’t prove otherwise.

It does, however, have very noticeable shrinkage from about 2 mm ≤ Z ≤ 4 mm. That, my dear friends, corresponds to when I opened the door to the garage to go work on something while still listening to the printer in case of problems. The blast of cold air from the garage shrank the ABS immediately — and more on the front of the print than the back.

Here’s a reprint with the dimensions reduced slightly to avoid the previous snagging when the build platform is at the absolute extremes of its range of travel, and with the entire build chamber enclosed by cardboard and plexiglass. There’s still some irregular shrinkage that I’m going to have to figure out, and just a bit more stringing that wasn’t completely eliminated. But this is not too bad.

The CupCake’s extruder mounts on a Z stage that lowers down to the build platform. The Z axis is run by a stepper mounted inside the frame at the front, with the central black pulley on the motor shaft driving the belt that connects the four black pulleys on threaded rods protruding down into the machine to raise and lower the Z stage by its corners.

As I was testing in 2018, and again this spring, what should have been continuous movement of the Z axis getting down to the platform to start a print would once in a great while pause and resume. I didn’t hear the characteristic clack/clonk of a stepper motor skipping steps, but it was hard to be sure. But whatever the cause, if the Z motor wasn’t running completely reliably before a print, there’s a fair chance that it could misbehave during a print. Plus a printer with neither Z probe nor Z endstop makes it hard enough to set first layer height already; I don’t need to play this game in Nightmare mode.

Part of the challenge was replicating the problem. In the first run at Cort’s house, everything worked initially, then finally misbehaved many minutes into a print. After restarting the print, again it took many minutes before the next failure, suggesting that we were going to have a dickens of a time watching the problem on a scope and reinforcing my decision to take it to his house where we could use his digital scope with triggered capture.

However, after some fiddling, we discovered that if I used the ReplicatorG control panel to continually jog the Z up and down, at least after the printer was warmed up, it would occasionally pause, which we could hear as well as see. That in turn led to an even more interesting discovery.

All of the steppers on the CupCake are powered by Zach’s RepRap stepper motor driver 2.3 boards. In the orientation shown, power connects on the lower edge, the stepper on the left, communications on top, and optional endstops on the right. Immediately above and below the motor connector on the left are LEDs that light as the two coils of the bipolar stepper are each driven in their positive and negative directions — and what we noticed was that when the motor stalled, the LEDs were briefly off.

Hang on; that’s not your usual stepper motor failure! The most common failure of a stepper motor is when it tries to drive a load that (in general or for a moment) requires more torque than the motor can provide. Instead of moving forward one step, it will jerk back three steps, causing the clack or clonk I mentioned earlier. (The second most common failure of a stepper motor is when it’s driven faster than it can run and just goes bonkers.) But in both of these cases, the driver will still be trying to move the motor, and mine wasn’t.

We could choose to probe the situation with test equipment or we could swap parts and see where the problem followed. With a lower psychological barrier to entry, we elected to swap parts.

I swapped the communications and motor cables between the Y (good) and Z (bad) axes. The problem remained with the Z axis, suggesting that the driver board wasn’t the problem and making us wonder about a motherboard issue like a stall in the main execution loop. I put the motor back on the Z board where the Y communication was still connected and told the ReplicatorG control panel to move the Y to in reality move the Z … and the Z still stuttered, suggesting that the motherboard and communications weren’t the problem. I swapped in a spare CupCake stepper driver board for another data point; the Z still stuttered. The only thing in common with all the test cases was the Z motor.

I began preparing to swap the Z motor but couldn’t get the pulley off of this one without a puller that I didn’t have along, so we had to stop replacing parts and start using our brains. Manual movement of all three axes on the CupCake seems to take more force than on other printers … and well it might, as the Z-axis threaded rods aren’t commercial lead screws and the X and Y axes travel on bushings instead of bearings. But more importantly, the Z axis in particular seems to take more torque to move than it did when it was new, which could be caused by the motor being gunked up from age and the upper and lower bearings getting gunked as well.

Each stepper driver board has a reference potentiometer to set the motor coil current … and the one for the Z stepper was already at maximum with no option to turn it up to 11. If the motor was drawing more than the 2 A that the A3982 could provide, perhaps it would go into shutdown and stop driving the outputs, which would explain the blanking of the stepper coil LEDs. And if the ravages of time caused the one stepper on the oddball axis to go from originally using just a little less current than the driver could provide to now needing just a little more, then what to do next?

In the dual interests of troubleshooting the Z axis and of resuming Z operation to be able to troubleshoot the extruder problem, the answer was to use an external stepper driver that could provide more current. I had already purchased this guy for fiddling with on the bench; so on the next visit, I brought it along; we hooked it up to drive the Z; and nothing. Didn’t even light the activity LED inside. A bad unit!

On the subsequent visit — and mind you, these visits are about a month apart, so I’m exercising some patience and restraint here — I took a new stepper driver module that I’d purchased and it also did nothing, which was incontheivable. Turns out that the external module’s ENA input is really a /ENA input and Cort and I were both too punch-drunk on the first attempt to think of that possibility.

The driver module is actually quite pleasant to wire, because having pins for both ends of the optoisolators on each signal input mean you can feed it either active-low or active-high inputs by choosing whether to connect signal and 5V or signal and ground. I mean, if you stop to think about what logic style each signal is using.

Not having a spare connector for the motor plug, Cort soldered the wires to heavy pins salvaged from some piece of equipment and I drew up a housing, which we printed in “galaxy blue” one of Cort’s printers. The pins are a tight friction fit in the housing and a looser fit in the motor plug, so it worked well.

Cort fiddled together some jumper wires for the appropriate signal lines out of the Z-axis jack on the motherboard, and the whole thing Just Works.

With the stepper module DIP switches set for 1.5 A, the Z stepper loses steps in the traditional way. Set for 2 A, it hasn’t failed yet, not in subsequent testing nor in my actual use this past weekend. That reinforces my notion that the Z stepper’s current demand has just barely climbed up over the capacity of the original Allegro driver — and got me past the Z problem and able to diagnose the extruder problem.

When it’s not posing for a glamour photo, the stepper module tucks nicely into the bay next to the printer’s power supply.

Back in January of 2015, I had got my CupCake tuned up for pretty prints and then the extruder stopped working. Two years ago when I documented that experience, I got the CupCake set back up to troubleshoot that extruder problem and I had a new problem with the Z motor skipping steps, which I had to solve before I could figure out why the extruder stopped working 40+ minutes into a print.

I figured that troubleshooting the two problems would be easier with a fancier scope than I have; so a few times this spring, carefully observing COVID-19 precautions, I made couple-hour visits to my friend Cort and his basement workshop. Over the course of those visits, we were able to identify and address the Z-axis problem (which I’ll write up later) and make some observations about the extruder that ultimately led to a successful workaround this weekend.

In our testing, Cort and I noted that — even just being driven by the ReplicatorG control panel — the extruder motor stalled fairly easily; it was fairly certain to stall with any PWM value below 240. Because yes, the CupCake shipped with a DC gearmotor.

Cort and I were suspicious of the 8P8C cabling that delivers both communications and power from the motherboard to the extruder daughterboard, and Cort cleaned the plugs and jacks with DeoxIt. We also figured that after the hours of service that the motor experienced back in the day, it was probably starting to wear and draw more current to maintain the same speed. That would exacerbate the voltage drop from crusty cabling; so between the two, we figured that cleaning the contacts provided at least a modest chance of it working again with no further intervention. (Foreshadowing: nope.) After that troubleshooting session, I brought the printer back home to try out before the next time we were going to be able to get back together.

First Attempt: Mechanical Problems

Yesterday I cleared space on my workbench, set up the CupCake, and resumed trying to persuade it to do that same print from 2014. I still happen to have the G-code file that was generated back then, so I’m using that same object and that same G-code in order to introduce as few variables as possible.

The first print failed impressively, twice. The jog in the middle was from the X axis binding when both of the back bushings popped out of the Y carriage, nothing to see here, move along. But then later it just stopped printing, much earlier than it had in 2014 or while testing at Cort’s house, which was discouraging.

Oh hai! What are you??

I stepped back into my workroom and saw this bearing sitting on the power supplies. ??? How did it get there? Did it fall off a shelf? Did someone break into my workroom during the two minutes that I was away and set a bearing on my bench?

Oh. That bearing. You know, the one on the end of the motor shaft that keeps it from deflecting away from the filament and losing its grip. It just friction-fits into the hole in the laser-cut acrylic and it worked its way out, fell down, bounced off the Z stage, rolled out of the printer, landed on the power supplies, and stopped there instead of, you know, rolling under the washing machine and I’d be looking at the CupCake parts manifest to order a new one.

Okay, you happy now? Good.

Second Attempt: Filament Problem

I noticed that the first print, purportedly at the same temperature I’ve always used in the past to get natural-colored prints, had a toasty marshmallow glow about it. I found the MakerBot G-code reference that lists which codes were implemented and how they were interpreted and found that M104 Snnn sets the nozzle temperature. Accordingly, I edited my 2014 G-code file, found the two M104 codes and edited them to lower the temperature, and started the print again.

It failed early, due to <ahem> another mechanical problem. My original MakerBot ABS filament was shipped in a coil because spools hadn’t been invented yet, and pulling filament out of a coil is prone to snagging. If I get distracted watching Adam Savage YouTube videos and don’t pay enough attention to feeding filament off the coil, the extruder starts to climb up the filament into the sky like the Lorax, then plop itself back down dramatically and make a blob, at which point you may as well cancel the rest of the print.

Third Attempt: Extruder Problem Returns!

Still toasty marshmallow, so I edited the G-code and lowered the temperature again.

At last, we’re back to the original failure mode! About 30 to 40 minutes into the print, the extruder motor stalled and just stopped pushing filament.

I put my meter onto the motor leads and read 9.92 VDC, which would be an alarming drop from 12 VDC if it were true. I halted the print, started the ReplicatorG control panel, set the extruder motor PWM to 255, and read 11.78 VDC at the motor with the motor running, which was more like what I expected. I played around with different PWM values and found (A) that my meter low-pass-filters out the PWM and reads the average DC value (okay); and (B) that it reads about 10 VDC around a PWM of 239 to 240. That is, when the motor stalled, it was probably running at a PWM of 240.

This led to some control-panel-based testing of how low the extruder-motor PWM value can be set and still push filament at different nozzle temperatures on this CupCake at this age in this condition in this workroom. The reliability values above are estimated, but they tell a pretty clear story that this CupCake extruder — as it sits today — really ought not to be driven at less than full DC nor with the nozzle at less than 220°C.

Fourth Attempt: Success

With that empirical <cough — anecdotal> information at hand, I referenced the MakerBot document again to determine that the only G-codes pertaining to the extruder motor were:

• M101 turn extruder on, forward (CW)
• M102 turn extruder on, reverse (CCW)
• M103 turn extruder off
• M108 extruder speed (Snnn)

I searched my 2014 G-code file for M108 extruder speed commands and found only two, both setting it to a PWM of 240.

240? Whyyyyyyy? However much a PWM of 240 slows down that DC gearmotor from straight 12 VDC — and I assure you no one on this planet knows — why would you want to push filament slower, when the filament speed is the bottleneck on printing and the X and Y axes can comfortably go faster than the extruder can keep up with? Le sigh.

Anyway, I made another pass at hand-editing the G-code file, to raise the nozzle temperature back to 220°C and raise the extruder motor PWM from 240 to 255; and it was then ready to run without the likelihood of stalling due to too low a PWM and too low a temperature.

As this was going to push more filament into the print than the previous G-code … which doesn’t matter on the narrow walls that constitute most of this print because they’ll just get squished wider, but there is some infill that will build up … I babysat the print and live-adjusted the Z every few layers to make them taller, accommodating the volumetric increase.

And it worked. This print, which I no longer need and about which I care only as a canary, completed for the first time evar.

Next Steps

With a dataset of one completed print, I am declaring success.

More seriously, of course it may fail again, either because the combination of PWM and filament viscosity wasn’t the only issue or because the motor is aging enough that it’ll soon be stalling at PWM 255 on the 12 V power supply. One could likely perk it up nicely with an external 15 VDC power supply, but that would require hacking (or duplicating) the extruder PCB to get a higher voltage to the A3949 motor driver ICs or hacking an interface off of the H-bridge outputs to use an external H-bridge driver, neither of which particularly appeals.

I know that back in the day, people figured out how to upgrade their extruder DC gearmotor to a stepper-motor drive, “Wade’s Geared Extruder” being the most-evolved example. I’d love to upgrade to stepper drive — I already have the parts for a Wade’s geared extruder — but I can no longer find any notes online about how to drive that using an external stepper driver (which one wants), only a description of how to use the two onboard H-bridge drivers to drive a stepper and a forum post on how badly that works. It’s always been my plan to do that upgrade, but it’s tough finding the documentation about nascent DIY upgrades ten years of noise later.

Independent of making sure I have a working extruder motor, I have to figure out a working slicer and redetermine slicer settings. I’d be perfectly content still using Skeinforge; but when I install apparently the same version I was using in 2014 onto my current laptop, it looks and behaves completely different, so that’s a puzzle. I’ve created and lightly tweaked a CupCake printer profile in PrusaSlicer; but Slic3r (and PrusaSlicer by extension) do not have a G-code flavor for the CupCake (their MakerBot G-code flavor appears to be for a much later model) and I don’t think that G-code is going to run successfully. (I tried, and it did some odd things.) Nor can I find any documentation on how to create or edit Slic3r G-code flavors, which I’d be totally willing to do. So that’s a bit of a puzzle.

That means, of course, that although I can successfully complete old prints, I can’t yet start new ones.

Finally (for now), why is my ABS coming out toasted darker when it used to print at the same color as the raw filament? My best guess is that ten years of sitting have degraded the filament, but that’s outside my area of expertise. As shown at the top of this post, though, even lowering the nozzle temperature to 210°C doesn’t keep it from darkening and looking scorched.

It should come as no surprise that at times I’ve had a surplus of CRT monitors (surplus of CRTs is redundant, I guess?), many not working. I pulled their PCBs and salvaged their components, put out the metal for recycling, and … cut up the ABS cases into flat chunks and stored them. Did the same with dead inkjet printers people kept giving me — I think they must come in the bottom of cereal boxes.

In tangentially-related news, I’m doing some OpenSCAD design work and a friend is printing the parts for me, as my CupCake has not rehabilitated itself yet. The parts are supposed to friction fit and he has only PLA and I think it’s too brittle for a good fit — if the parts fit at all, they slide too easily. I think they need a little give to slide together, stick in place, and slide apart, so I want to try ABS. I have 3-mm ABS filament but his printer of course uses 1.75-mm filament. I could buy some 1.75-mm ABS filament, but I have all this bulk ABS sitting around …

So last night I dug out my bins and color-matched my project to the medium grey ABS and scrubbed it in the kitchen sink with soapy water and let it dry.

Still hadn’t figured out how I was going to chew it up into pellets. There are plastic shredders, even DIY ones, but they seem frightfully expensive especially once you include the motive power.

I pondered misusing all my different power tools, bearing in mind that my goal was to get pellets somewhere in the size range of rice to peas. ABS dust would probably be fine for re-forming into filament — but much more difficult to capture/collect without impurities like wood dust from other use of the power tools. Tablesaw, sander — dust. Bandsaw, rotary rasp — coarse dust. Drill press — interesting idea but would probably produce spirals that would have to be re-cut; plus any type of bit would be prone to grabbing the plastic and having to clamp it down in each position would take time.

Router table with router set to lowest speed and taking shallow passes — very promising, and very finger-scary. Jointer — definitely the right size chips, and more finger-scary. Lathe — hilarious!

And remembered my hand-operated sheet-metal nibbler.

This morning I produced a good tablespoon of pellets (shown at top) in ten minutes of hand-work as a proof of concept and today I ordered a Filastruder.

I’m still pondering … but I do have a pneumatic nibbler somewhere and I’m thinking about a table design whereby I could feed the plastic to the nibbler. That should be pretty safe, as the nibbler’s up/down action won’t be nearly as prone to grabbing the workpiece and sucking in my fingers.

Although I am going to want some red ABS for this project …

I’ve always had astoundingly good luck with kapton tape since nophead’s serendipitous discovery, probably because I (still) prefer to print in ABS. When the build platform is warm, my prints stick to it absolutely with no raft or mouse ears and once it has cooled, they release easily. That’s a pretty compelling combination.

So my first step was replacing the scraped-up kapton that I gouged the last time the printer was on. I bought a 4″ roll way back when and I keep a strip of unsticky tucked under the end so I don’t have to peel it up with fingernails and get fingerprints on the stickum.

In the past I’ve always replaced the tape by sticking down the end and using a credit card to “squeegee” it onto the surface, and it can be tough to avoid getting bubbles. Yesterday I unrolled enough tape to cover the platform and when I had it stretched out, it was easy to align the front edge of the tape with the front edge of the platform, at which point I squeegeed it down with my thumb with no bubbles at all. Huh, well, I guess I’ll remember that.

I heat my build platform with the rackmount laboratory-grade power supply the CupCake is sitting on. From my 2010 blog post about making the heated build platform (gosh, this blog thing is handy), I see that I ran the power supply around 24V to heat the build platform to the neighborhood of 180-200C, then backed it off to 12V. This is a definite opportunity to control via software in the future; but for now, I’ll keep doing it with a manual control the way the pilgrims did.

Setting Nozzle Height by Extruding Onto the Platform

I’ve never got the Z-axis endstops integrated into my build process — if someone knows how to implement that (some G-code preface), I’d love to hear about it — and getting the right nozzle height has always been one of my biggest recurring challenges with this machine. So I decided to take a different approach and set the extruder to run while jogging the build platform under numerical control and lowering the nozzle until the extrusions stuck well but didn’t flatten badly.

I got a blob every time it stopped between jog steps, but the process worked pretty well — I got the height tuned to stick the extrusion down to the build platform without squishing it badly out of shape.

Removed from the printer, you can see that the ABS was starting to scorch. I’d been running the nozzle at 228C based on my 2012 post; but somewhere I found that I’d backed down to 220C, and that does seem to work better.

First Print (from Saved Gcode)

I don’t have my machine’s calibration parameters loaded into Skeinforge yet, in part because I can’t find Skeinforge (which is supposed to be integrated into ReplicatorG, but I don’t find that to be the case); so I can’t slice and print an STL file. But I have G-code files that I’d generated for this printer, and it should work to print those.

This clip didn’t turn out so well. The G-code was generated to print at 228C and the printer stopped extruding partway through, I think because the ABS was overheated. I could update the G-code to run at 220C instead; but I’m going to want to get Skeinforge running to slice new models anyway. So this was a fine proof of concept.

Thermistor Is Calibrated

I found (and subsequently remembered) that a few settings are saved in the printer’s NVRAM, including the thermistor coefficients. They’re accessible in the Machine / Toolhead Onboard Preferences... dialog:

So it really was running at 228C when it said it was.

Remaining Issues

• After positioning the nozzle at the build platform’s origin, I raised it high out of the way. When I told it to return to home, the Z action paused about once a second on the way down and stopped about 13 mm above the build platform instead of running smoothly back to its original position. For goodness sake, you should be able to get the basics right.
  
  I haven’t checked whether the motherboard was signaling the stepper driver and it was skipping steps (doubt it) or whether the motherboard was malfunctioning, so I should do that yet.
  
  I’ll never be able to automate nozzle positioning if the CupCake can’t reliably move the nozzle into position.
• Skeinforge doesn’t seem to be integrated. I can install it separately, but I wonder why it’s not there.
• I need to recover all of my calibration settings from the hard drives of my crashed computer and put them into Skeinforge that doesn’t exist. And then add that location to my backup system.
• ReplicatorG shows the preview of the STL when I’m clicking on a file to open but doesn’t have a preview window after loading where one can rotate and reposition the object. I thought that was available even before the Skeinforge integration, but I could be misremembering.

It went surprisingly well, with the only real snag being my misremembering the installation process, leaving me stuck in NotConnectedLand for a while.

What Software

A lot has happened in the world of hobbyist 3D printing since the last time I had the CupCake powered up and both new firmware and new driver software are available. I’m interested in upgrading both as I have time; but for a first boot, I want to change as few variables as possible. That means leaving the firmware that’s on the CupCake and matching a legacy version of ReplicatorG to what’s on it. And I had no idea what was on it.

Fortunately I have a blog and on that blog I write some things.

I went to my own blog’s MakerBot CupCake blog category and quickly found the January 2012 post on rebuilding the heater in which I had written:

… I upgraded ReplicatorG from 0024 to 0029r2, and let it upgrade my firmware from v2.4 (I think) to v3.0, and lo! lost communication between ReplicatorG and the CupCake…

This is apparently a known problem …

Anyway, downgrading ReplicatorG to 0026 restored my connectivity …

So there you have it: I need ReplicatorG version 0026 to connect to the 3.0 firmware currently on my CupCake.

Happily, the ReplicatorG web site is still online in spite of MakerBot’s acquisition by Stratasys (though I note there have been no code updates since the acquisition). The download page has dowload links for only the last version (0040) but also has links to the Google Code archive, which on p3 has that 0026 for the Mac that I’m looking for.

Running ReplicatorG

I downloaded ReplicatorG 0026 and tried running it from the disk image before actually installing it on my laptop. I got the standard security warning:

and had to look up to right-click and Open rather than double-click and change security preferences. After much playing around yesterday, I see that OS X Sierra does not remember approval I’ve given to run software on a disk image but does remember approval I’ve given to run software once it’s installed.

Once I got past that, I got a Java version error:

Shockingly, clicking More Info... in that dialog does something useful — it takes me to Apple’s JRE download page for that version. After regaining consciousness, I installed that software and ReplicatorG starts up like a champ.

Can’t Connect to the CupCake (Because I Installed ReplicatorG Wrong)

It doesn’t appear to see the CupCake, though,

giving the error:

Could not load machine 'null' no machineNode found
could not load machine 'null' please check Driver-> <Machine Name>


It does see my FTDI USB-serial cable under Machine / Serial Port. It does not have anything listed under Machine / Driver and it does not bring up anything when I select Machine / Machine Information…

I don’t find much online about this. A Thingiverse Sailfish firmware comment sounds as though I simply have the wrong machine type selected, but I can’t even select a machine type. The tail end of a ReplicatorG comment thread sounds as though it can’t see USB-serial ports on current OS X versions, but it does see it. A much older MakerBot forum post mentions success after reseating the FTDI cable; but I don’t even know whether that’s the same issue and reseating mine didn’t help.

Installing ReplicatorG Correctly

It seemed obviously wrong that I couldn’t bring up the Machine Information… dialog, and I hunched that something was wrong there. Researching about the machine type, I saw that the ReplicatorG machine configuration page mentions a machines.xml file, which I didn’t have. But that sparked a memory — the ReplicatorG disk image had a machines folder in it and … oh, yeah.

The ReplicatorG Mac installation page clearly says to create a ReplicatorG folder under Applications and drag the entire contents of the ReplicatorG disk image into it. Which I hadn’t. I’d just dragged the app because in spite of remembering and knowing better, I’d just dragged the app.

I deleted the app from Applications, created the folder, dragged the contents, started ReplicatorG by right-clicking and choosing Open, and boom. Connected to the CupCake.

First Extrusion

I went back to my same blog post and found the nozzle temperature that works well for my CupCake, then set that and ran the extruder:

I don’t have any of my CupCake’s calibration settings loaded in yet, in particular my thermistor coefficients, so this temperature is only an estimate; but it worked well enough.

First squeeze! Software installed; connected to and controlling the machine.

A Brief Aside About the FTDI USB-Serial Driver

When first I ran the ReplicatorG software, I wondered whether I had the FTDI USB-Serial driver already loaded on my MacBook from working with Arduino or whether the driver was missing and was the cause of the problem. ReplicatorG did find a USB-Serial under the Serial Port list, but I still questioned.

A bit of research shows that the driver’s presence or absence can be seen by running System Information and looking under Software / Installations. I didn’t see it there and I found that it can also be checked by running pkgutil --pkgs | grep -i ftdi . Didn’t see it there either.

The FTDI driver version supplied with ReplicatorG was of course quite old and I didn’t know how well it’d work on a newer OS X release. I went to FTDI’s Virtual Com Port (VCP) driver page, downloaded and installed version 2.4.2, and found that it made no changes to what I was experiencing. I’m wondering whether the FTDI driver is by now supplied as part of OS X or whether it silently installed when I installed the Arduino software on this MacBook.

Foreshadowing: It turned out as a pessimist might suspect rather than as an optimist might plan.

The first step in getting the CupCake running was powering it up and connecting it to a computer. I went out to the utility and

AAAAAAAAAUGH.

After spending all of Wednesday sorting and packing, I could see that I had only about an hour left of cleaning my workbench before I had room to even think about powering on the CupCake. (BTW, watch out for those breadboars. They will gore you if you’re carrying bread through the forest.)

Which leads to scheduling a vacation day today to devote to getting my CupCake 3D printer running again (and for relaxation and recovery as well — I prefer to live by a maxim attributed to Ben Franklin and was out later than usual last night seeing Ocean’s 8).

After spending another hour sorting and packing, I could see that I needed to clean my workbench before I felt like powering on the CupCake, so I did a little scrubbing and was then ready to go.

Testing the Power Supply

Out of an abundance of caution, I unplugged the power supply from the printer and tested it before powering up the printer. It’s a PC power supply; they do go bad; they tend to fail dark rather than bright; but having the power supply smoke CupCake parts would really set back this process.

Looks fine, though I’m puzzled why the -5V light isn’t on. <shrug>

With the power supply reconnected, the CupCake powers up successfully and its motherboard power switch does turn the power supply on and off. First milestone reached.

Then I was trying to print a draft of a pocket holder for a tube of moustache wax and comb and when I came back, I found that something had gone wrong after about 40 minutes of printing. I forget the order in which these occurred, but through the original attempt and two retries it:

• kept running the filament while printing so the model snagged and the X-Y build platform skipped steps and lost its place; then when the print finished, kept the extruder on forever, creating a thumb-sized fungal growth of plastic
• kept moving the X-Y build platform but stopped extruding
• kept moving the X-Y build platform but shut off the nozzle heater, chewing a divot through the filament

The second try, I ran another print of the same model; the third try, I made a tiny dimensional change to the model or Skeinforge settings in case the extruder controller was glitching on some particular G code; but that doesn’t seem to have been the case. I got different bad behaviors and it seemed as though the extruder controller stopped taking instructions and kept doing exactly what it was doing at that moment.

I don’t know whether it’s a firmware bug, a power supply problem, a wiring problem, an extruder board problem, or something I haven’t thought of yet. I have (recently) found reference to a few of the DC extruder motor windings shorting, reducing the coil resistance and increasing the load, to the point that the extruder controller FETs burn out. But these weren’t burned out — they worked again immediately (for another 40 minutes).

And then before I could muster the motivation to troubleshoot it, both my laptop SSD and my workstation motherboard crashed, leaving me no working computer with 3D-printing software installed and no working computer with my CupCake’s calibration settings on it. And then time passed; OSes were upgraded; ReplicatorG versions increased; the barrier to reentry increased substantially; and I simply have not touched it since early 2014.

This shall change.

In the four and a half years I’ve owned my MakerBot CupCake 3D printer, I’ve never had it working well enough to use for more than a week or two at a time. My real frustration has been a lack of understanding what has failed and how to fix it, so much so that it’s been almost two years since I most recently gave up and put it away. [Written in December 2013, and I haven't used it since January 2014.] I know there are newer, more reliable printers on the market; but it sure seems like it should be possible to get the CupCake to work reliably, if I’m willing to upgrade critical parts.

In the intervening time [meaning 2011 to 2013], my friend Joel has run some prints for me on his Thing-O-Matic. Recently while chatting over a print in progress and checking whether the filament was jammed (solution: his build platform’s aluminum heat spreader was bolted tightly around all the edges, expanding when hot, bulging up in the middle progressively over an afternoon of attempted printing, and blocking the nozzle which was enough to jam things up), he mentioned that his nozzle had jammed to the point that he couldn’t even push filament through by hand with pliers (yes, my problem exactly) and that he had solved it (oh???).

Dust.

Joel had disassembled his extruder and lightly drilled most of the filament out of his clogged nozzle with an undersized bit, as I had in the past; then soaked out the rest of the plastic with acetone, as I had also. But when removing the clogged filament, Joel noticed it was quite dirty and made the mental connection with dust on the filament. When he reassembled, he added a toothbrush to wipe dust off the filament on its way in and has also made a point to keep his supply bagged and/or boxed. Since then (and until the expanding heat spreader), he’s had no further troubles with clogging.

This is not a new issue, but I had never heard anyone indicate it had so completely jammed their nozzles that their extruder wouldn’t extrude.

And it fixed my CupCake. Mostly. For a while.

Here ended the text of my 2013 draft, with photographs already lined up for me to narrate the rest of the story. I’ll do the best I can to fill in the details five years later.

The toothbrush had worked well for Joel but I was leery of it only cleaning two sides of the filament, so I wanted to run the filament through a hole or slot in a sponge.

I designed a sponge holder in OpenSCAD that would sit on top of the CupCake extruder. It’s not fastened in place — the legs keep it sitting on top; the filament keeps it from sliding side to side; and the filament pulls it down onto the extruder. The occasional filament reversals never push it far upward.

Since my extruder nozzle was at that moment passing filament, I was able to print the part myself. From the first picture in this post and the string at the bottom of this one, you can see that I printed it in the opposite orientation from the photo — printed in the orientation in which it’s used — because my printer has always been reasonably good at bridging, so I wasn’t worried about it. Still probably would have been smarter to print it upside-down anyway.

In this picture, you can see foreshadowing of a future post — the sponge holder’s legs are warped inward. That occurred because the first layers of the body cooled so rapidly that they shrank while the remainder of the body was still being printed — the same issue that causes corners and edges of people’s bases to pull away from build platforms that aren’t super-sticky.

I had an unused carwash sponge on hand, so I sliced it with a sharp knife, then cut a cube to fit inside the holder. I think I poked a hole through the center with an awl, but it’s possible I sliced in from the edge to provide a path to load the filament.

And I’ve had no further problems with nozzle clogs since then! Which sounds sarcastic since I only used it another month before not touching it for five years … but really, this did solve my clogging problem, and it was evident that it had done so during the remaining time I was actually using it. I’d had frequent mini-clogs and occasional maxi-clogs prior to the filament cleaner, and none since.

When I say stopped extruding, I mean the motor actually ground to a halt. Usually it chews a divot into the filament, but this time it stopped. And I was pretty sure — don’t remember whether I actually checked the on-screen display or not — that the nozzle temperature had dropped and the filament wasn’t melting any more.

I know people talk about extruding ABS at temperatures as low as 200°C, and I don’t find that to be the case in my CupCake. Mine is calibrated, and mine doesn’t like temperatures that it thinks are lower than 220°C, and mine doesn’t really like temperatures that it thinks are below 225°C. So it really doesn’t take much to make it unhappy.

I had just rebuilt and rewound my heater at the time, and I knew that I had crimped the nichrome to the teflon-coated lead wires with silver crimp beads. I had a suspicion that the joints had become oxidized under the crimps, and the 7.3Ω resistance across my heater wires seemed high for my CupCake.

A couple of weeks ago I disassembled the heater and found that one of the two connections was indeed quite scorched and oxidized.

After cutting away the crimp tubes, cleaning the end of the nichrome wire with fine sandpaper, cutting back the lead wire, and recrimping, I tinned both lead wires with solder. Solder doesn’t stick to nichrome; but being coated with solder, the joint (which already had a solid mechanical connection from crimping) should be much less prone to oxidation.

After the rebuild, the heater measured 6.8Ω. Half an ohm difference doesn’t sound like that much until you’re trying to get to 225°C. Since power P = V² / R, at 7.3Ω, P = (12V)² / 7.3Ω ≈ 19.7W; and at 6.8Ω, P = (12V)² / 6.8Ω ≈ 21.2W; so maybe that could be enough to make the difference at the high end of the extruder’s temperature range.

Aaaand … after reconnecting things, I still couldn’t get the temperature above 222-223°C, even though it now had some 7% more power. That doesn’t seem quite right.

When in doubt, scope it out. Yeah, after almost a full minute of failing to hold the temperature at the set point, the software PWM in the extruder controller was still running the heater at about a 50% duty cycle. That definitely doesn’t seem quite right.

And isn’t something I can easily fix, either. The ReplicatorG version I was running didn’t have a control panel for the heater PID settings, so (even assuming I was smart enough to fiddle them into shape) I would have had to recompile the code each time I wanted to make a tweak, which wasn’t palatable.

Firmware Upgrade

But I thought I’d heard that newer ReplicatorG versions did bring the PID coefficients into the machine control panel, so I upgraded ReplicatorG from 0024 to 0029r2, and let it upgrade my firmware from v2.4 (I think) to v3.0, and lo! lost communication between ReplicatorG and the CupCake. It said it had a connection but all the menu options to talk to the CupCake were greyed out.

Great.

This is apparently a known problem claimed to have something to do with the Mac’s localization settings for the string representation of “,” and “.” in numbers. Srsly? And the suggested tweaks didn’t fix it for me, so I’ll just wait for the next ReplicatorG release. And since the Mac package of ReplicatorG continues to be a DMG file of all the pieces you have to drag into /Applications/ReplicatorG, rather than a ReplicatorG folder that one could conveniently drag into /Applications like everyone else provides … I guess I should feel lucky to have a Mac version at all, and I’m not holding my breath for a fix on this problem.

Anyway, downgrading ReplicatorG to 0026 restored my connectivity and got me a look at those sweet, sweet PID coefficients.

Which I no longer need, ’cause with the upgraded CupCake firmware, the PID algorithm seems to work right. Reaching for the knobs was obviously an attempt at a workaround, and the real fix is oh so much better.

The stringing on this diffusing filter holder is my fault, not my machine’s — I have a 0° (or 90°) overhang on a concave curve, so there’s no way it was going to come out clean. I still wanted to see what it would do, and it performed admirably under the circumstances of an impossible model.

And then stopped working again.

Filament drive motor locked up against the filament. A-gain. (Yay, great grip on the drive pulley, and nozzle retaining washer not breaking!) Temperature claims to be steady where set.

My utility is fairly cold these days. I’ll try enclosing the build chamber again in hopes that although the nozzle is hot enough, the teflon tube is too cold — but I bet I end up disassembling and drilling out the inside of the tube and nozzle again.

Should have been designed with a quick-release.