The Hell Ya Beller Fun with hot, pointy, sharp, and caustic stuff.



Failure is natural.  Nothing to be ashamed of...usually.   It's what you learn from it that counts.  That and the lols.

I'm really happy to see a repository of FAIL like this.  I started looking for it a long time ago.


Tagged as: , 1 Comment

Things I’ve learned about Teacup and Sprinter Firmwares

Sprinter (formerly Klimentkip formerly Tonokip) and Teacup are the two leading firmware options right now.  They both support retraction, acceleration, heated beds, thermocouples, etc.  They're both in active development and things change fast.  As I've worked to get my mendel reliable, I've bounced back and forth.  Hence, I've learned a few lessons about each and the differences I need to make in my config to make each work.  All this is just from my experience.  If I got anything wrong, shoot me a comment and I'll fix it up.



  • M103 / M101  are deprecated codes but Teacup uses them to trigger the firmware based retraction.  Don't remove them through replace.csv
  • Firmware retraction is enabled by entering a non-zero number for E_STARTSTOP_STEPS.  I use 16X microstepping and about 700 steps = 1mm of feedstock.  I wanted to retract about 3mm so 2000 is a reasonable number.
  • Teacup Firmware retraction and Skeinforge retraction don't play well together.  Disable SF by entering '0' in the mm to retract setting in the Dimension plugin.


  • Sprinter doesn't do retraction in firmware but handles the Skeinforge retraction well.
  • You must have your maximum feedrate for the E axis quite high.  In fact, you have to set it much higher than you can actually extrude.



  • Teacup uses G161 and G162 for homing.  The firmware doesn't pay attention to the switches at all during any other move so manually seeking the switches with a G1 or G0 move will fail.
  • When searching, Teacup will run at the axis maximum feedrate until it hits the switch.   Then it backs off, and searches a second time at the SEARCH_FEEDRATE.  This can be a little unnerving.


  • To home a single axis you try to move the axis in the direction of the switch farther than it could possibly go.  Something like G1 X-200 F1000 It will stop at the switch.  Then you do a G92 to set the position.
  • You can also use G28 to home all the axis, X, then Y, Then Z.   G28 doesn't take an axis parameter and must home all axis.  This doesn't work for me be cause I like to home my Z slightly below the bed height and then do a G92 with the offset to set the correct position.  The dump location where I can move the nozzle below the bed height isn't at X=0 Y=0, so I need to home X and Y, then move to the dump location and home Z.


  • Teacup wants distances in relative terms.  Set this on both the 'preface' and 'dimension' pages.
  • Sprinter seems to want to work in absolute numbers.

Other things

I haven't tried all these but noted them when I read them.  Might be useful to someone


  • A 10 uF capacitor across the thermistor contacts may help smooth out any noise.
  • Settings in the configuration.h file are intentionally conservative.  VERY conservative.  The expectation is that a person will change them and not that some base config will ALMOST work for everyone.  For example,  the acceleration default value is 10.  I ended up using 6000.  Like I said, VERY conservative.
  • If the result of STEPS_PER_MM_Z*MICROSTEPPING_Z is greater than 1000 then Teacup will ignore the MAXIMUM_FEEDRATE_Z setting.  This can Z to do things you don't want or to just stall.
  • you can change the pid factors stored in the eeprom using M130-M134, read source for details
  • M200 prints the status of the available endstops.






Daily moment of ‘Duh’.

I started seeing missed steps in my prints.  I haven't had this problem for a long time so I went through the basics of tuning up, lubricating moving parts, etc.  The problem remained.  I started printing test blocks and noticed the problem looked very regular.

This made me think it must be in the software tool chain and I spent a couple days trying to narrow it down.   Nothing.

Finally, I took another look at hardware, even going so far as to disassemble things that have been working reliably for a while. Lo and behold, I found this:

Part of the gear has delaminated.  The missing tooth doesn't cause a problem all the time, but during certain rapid movements, or during rapid start/stops, it slips.

These were some old gears that I printed when my quality was still pretty rough.  I should have reprinted them a long time ago, but I forgot when they seemed to be reliable.

After you figure out a problem, it always seems so obvious.



A really great article on configuring skeinforge.

Dave Durant has helped me out from time to time on the Makerbot  Google group.  He's got an excellent article on configuring skeinforge.

Tagged as: No Comments

Offerings to the god of print.

I really like the movie Worlds Fastest Indian.  It's based on a true story and if the main character isn't a 'hacker' in his own way, I don't know what he is.

In the opening scenes, the camera pans through his workshop across a shelf full of blown pistons.   Clearly this guy has obtained his knowledge and skill at the expense of many failed experiments.

After I got my makerbot working, I tried to find the internet equivalent of that shelf.  I figured somebody must have collected pictures of common printing problems, possible causes, and recommended solutions.   The forums are full of descriptions and the community, like all communities is evolving its own vocabulary.  Raft, tower, splodge, ooze, and shells are a few of the new words in my life.  It's daunting for newbies.

But it's been surprisingly difficult to find that kind of information in any organized form.  So, I'm starting to collect what I find and what I learn here. I'm adding a new category of 'common print problems' and a tag 'offerings'   Hope someone finds it useful.

To start things off:  The best collection of images and descriptions I managed to find.  Thanks Tony!

Tony's list