Makerbot Troubleshooting

Here are some of the things I have done while troubleshooting my makerbot.

Extruder Slipping Issues:

Ever since I assembled the machine, I've had some problems with the extruder slipping mid-build. The filament was not being pressed firmly enough by the idler wheel, and nothing would come out. Pushing on the filament would restart it, but sometimes I wouldn't notice and would end up with models which skipped a few layers mid-way through.

To make matters worse, the problem didn't occur with every revolution of the idler wheel. I suspect this has to do with the diameter of the idler wheel and the diameter of the metal gear wheel being relatively co-prime. Hence, just like Alan Turing's bicycle the problem would only occur when the position of both wheels happened to coincide.

Looking back through my notes, I see that I've had to strip down and reassemble the extruder 9 times and tighten it many more times. In the process I managed to crack one of the acrylic panels, (but some superglue fixed it nicely).

Filing down the slot in the housing helped a little, since the wheel was closer and applying more force to the filament, but it didn't solve the problem. It seems like the cause was unevenness in the diameter of the idler wheel causing uneven pressure on the filament.

Some things I tried, which may have contributed to the eventual stable solution:
  • Filing down the idler wheel slot (twice). I believe the new batch of Makerbots has a modified slot geometry so this may not be necessary anymore
  • Playing with number of washers above and below the idler wheel to align it as perfectly as possible
  • Remounting the metal gear-wheel with the two grub screws gripping the round, not flat, parts of the shaft (I think this improves the concentric nature, but I may be fooling myself)
  • Carefully filing down the 'bump' in the laser-cut idler wheel where the laser finishes off the circle

Machining a new idler wheel:

Eventually I gave up and decided it was time to machine a perfectly round idler wheel. Kean from Robots and Dinosaurs kindly agreed to let me use his lathe on short notice.

We used Delrin as the material for the wheel. It machines very nicely and isn't quite as hard as aluminium or steel. On the first attempt we made a wheel twice as thick as the original in order to prevent the filament from slipping to the side of the idler wheel.
Unfortunately I didn't measure the metal gear-wheel beforehand and when I got home I found it didn't fit.

To compensate, we reduced the thickness of the wheel using a fly-cutter on the milling machine. Some double-sided tape was used to hold the piece to the milling table. Damn this is strong stuff.

It was the first time I've seen a fly-cutter used, and I was surprised at the good surface finish.

Once the milling was complete, I added the skate bearing and superglued on an encoder pattern to both sides. This mostly for humans now, but I may add a photo-sensor to the extruder later to check for stalls.

The new idler wheel is  a smidgen thicker than the original, but still fits nicely 'inside' the metal gear wheel.

I reassembled the extruder and ran a piece of filament through. Not only was the force nice and strong, but the depth of cut of the teeth onto the filament was nice and constant over the whole length.

Verdict: Success!

Although I am wary about declaring victory yet, the extruder seems to be working quite nicely. It's given me a solid 2 days of printing at the first weekend get together of the Sydney Hackspace (a.k.a. Robots and Dinosaurs) without any hiccups. Some photos of the event are here.

Squaring the wheel: Crazy enough to work?

During the many extruder rebuilds I did, I noticed something odd. One time I had assembled the extruder with a new washer to change the spacing, but the washer was too wide and pressed on both the stationary and moving parts of the bearing. Consequently the friction was too high to allow the idler to turn reliably.

However, even though the idler wheel had 'stalled' the filament was still being gripped and the extruder was running perfectly. Apparently the friction of the stationary acrylic wasn't enough to stop the filament.

This raises an important point. I solved my extruder problems by using a lathe to ensure the wheel was perfectly circular. However in the RepRap design it is important to minamize 'Vitamin' components which require specialized machining.

If the extruder can work with a stationary wheel, then this is advantageous since the diameter remains constant and the wheel is once tightened-always-tightened. With a moving non-circular wheel it is possible to be tight in one position and loose in another.

A simple design would be to use a flat or curved stationary surface to press against the filament, and be adjustable for tension. Something like a square wheel would be a nice start since it doesn't require any extra machining.

Software Crashing Issue:

I have had some issues with the software for the makerbot. Occasionally it will stop mid-way through a build. Often the extruder will keep running, sometimes the Z-axis will continue to move up. This doesn't happen often, but it's frustrating. So far, I've gotten an entire plastic takeaway container filled with all the failed prints.

Here's an interrupted build of 4 topcaps. You can see the stalagmite formed where the extruder keeps running.

After looking at it closely it seems that the temperature control still works after a crash, so the problem isn't on the extruder controller board. I wasn't sure if the problem is on the host PC software (ReplicatorG) or the motherboard firmware.

Although there is a debug LED on the motherboard, it is used to indicate the successful interpretation of a command from the PC. When a crash occurs, I wasn't getting any flashes, but that didn't tell me which end the problem was on.

Adding a Heartbeat LED to the Makerbot Motherboard:

Rather than reprogram the existing red LED, I decided to add a new one to the board, to give a heartbeat signal in addition to the packet processing signal already in place.
After reviewing the circuit diagram for the motherboard, it appeared as though pin D1 was not used for anything. I wired up a small LED and resistor and connected the anode to pin D1, and the end of the resistor to ground.

The LED in place. You can also see the generation 1 stepper motor drivers on a separate board to the right.

I added some code to the loop() function in the Arduino motherboard firmware sketch, as well as creating a persistent variable outside the function:

//GS -- Added for debugging operation to help diagnose motherboard crashes.
unsigned long int debug_led_loop_time = 0;
//GS -- END

//handle various things we're required to do.
void loop()
  //check for and handle any packets that come in.
  if (Serial.available())

  //our basic handling for each loop.
  if (commandMode == COMMAND_MODE_IDLE)
  else if (commandMode == COMMAND_MODE_WAIT_FOR_TOOL)
  //GS -- Added for debugging operation to help diagnose motherboard crashes. 
  #define GS_DEBUG_LED 1
  if ( (millis() - debug_led_loop_time) > 1000) {
    digitalWrite(GS_DEBUG_LED, !digitalRead(GS_DEBUG_LED)); 
    debug_led_loop_time = millis();
  //GS -- END.
This worked very nicely. I could now see the motherboard status just by looking.

The next time it crashed, I looked at the LED, and no heartbeat could be seen. Hence it was the motherboard firmware, not the ReplicatorG host software that caused the crash.

I still don't know what actually caused it, but I'm closer than I was before.