Giving Up on Linear Bearings

I’ve officially given up on linear bearings. Two weeks ago I installed the linear bearings in my MakerBot, but didn’t like the initial noise results. Today I finished removing them and putting the old copper bushings back.

The linear bearings were amazingly smooth. If you put on one a rod and started tilting it, it would roll off the rod very quickly. There was almost no friction. In contrast, the copper bushings hold on for at least 5 to 10 degrees more before they start to move, and they have enough drag that they don’t pick up nearly as much speed.

But the noise drove me nuts. When I asked about noise solutions on the MakerBot google group they gave me some ideas, but I just couldn’t solve it. I got some white lithium grease, but putting that in the bearings made almost no difference (works nice on the bushings though). Everyone recommended PTFE based grease but I couldn’t find it locally and didn’t care enough to order it and wait.

If I owned a house where I could put the Thing-o-Matic a few rooms away, I would probably leave the linear bearings in. But in my one room apartment, I have to live right next to the noise and it was far too loud.

As long as my bot is open, I’ve been doing a few other upgrades. I installed M_G’s tensioning pieces, which worked great. When I reassembled my X axis is was pretty cool to be able to turn one bolt and have the slack in the belt pulled up. It’s so much easier than loosening four bolts, pulling the motor, and trying to hold that while tightening things back up.

I added Campbell’s Y-axis idler and I plan to install Joakim’s X follower. I made both when I first got my printer, but things weren’t calibrated well enough at that point so neither fit (nor worked) very well. Now that I know what I’m doing I know I can do much better. The Y idler should help with the tension (and hopefully reduce noise), while the X follower should make the X axis much smoother since it cuts the number of bushings in half. I also saw a reference to epideth’s Z axis bearings which I’d also like to. I don’t like how close the bushings on the Z axis are, the make it possible for the whole thing to wobble because it can’t support it’s own weight very well. Once the weight of the giant MK6 motor was gone, I was amazed how far the end of the Z platform could bounce if I pushed it with my finger. Having those long supports should help.

Last I finally got around to installing static drain lines which I’ve been meaning to do for over a year. When the air gets dry this time of year I start to get zapped by everything in my apartment, so I get really worried that I’m going to damage my MakerBot. I also used up a ton of 1/4″ kapton tape (mine came from MakerBot) to tie up some of the loose wires in the base, which really cleaned things up. I don’t know why I didn’t think of it before.  I cut pieces just a few inches long and wrapped them around the groups of wires every few inches.

After that I’d just like to get back to printing little things and painting them. That was quite a but of fun but I haven’t been able to try it in a long time. After all my tinkering it’s clear I’m pushing the Thing-o-Matic a bit, I’m wondering when I should give up and decide to buy a new printer. I’m not sure which model I’d want though. Make’s 3D printer guide was a fun read, but didn’t give me a clear winner.

Ultimakers have always looked nice, and I like that they’ve moved to cartridge heaters, but the lack of a heated bed means printing ABS parts would have to be small. I also really like Sailfish and have no experience with the Marlin firmware.

The Replicator 2 looks nice, and I’ve had great experiences with Makerbot. But I’m not sure about Makerware and would be happy to get away from Skeinforge. I hear so many great things about Slic3r, I think I’d be happy to move to it. While the Replicator 2 is much closer to an appliance (which is a good thing at this point), it doesn’t do ABS (the Replicator 2X will). The biggest con is that those printers are very expensive.

All of this is rather academic, as I’m not that interested in spending the money right now. But I keep thinking about it.

Don’t use FileMerge with 25mb files


How long does it take to use OS X’s FileMerge on a pair of 25mb files? Somewhere between 20m and 2 hours. I left my computer after 20m since it wasn’t done, but it was when I came back. At this point, I’m convinced I don’t need to worry about using PyPy with Skeinforge, so I can start saving time. Now if I could only quadruple the speed of my ToM…

Differences in PyPy generated gcode (Updated!)

Comparison of CPython and PyPy fill patterns

As I said in my last post, the gcode generated when using PyPy instead of CPython can differ, so I’ve been trying to find out when. I already knew that the standard 20mm calibration cube had no differences, and the same seems to be true about a simple cylinder generated with OpenSCAD. So next, I generated a cylinder intersected a box and the differences appeared. It’s in the picture below, but here is the code:

$fn = 25; # So the cylinder is reasonably smooth

union() {
	cylinder(30, 12, 12);

	translate([5, -5, 25]) {
		rotate([0, 30, 30]) {
			cube([35, 35, 5], true);

So what’s different?

The first thing I noticed when running a diff between the files is that the bounding boxes for layers can be defined in a slightly different order. For example while CPython will generate this:

(<boundaryPoint> X26.813 Y-12.614 Z16.375 </boundaryPoint>)
(<boundaryPoint> X9.313 Y17.697 Z16.375 </boundaryPoint>)
(<boundaryPoint> X5.232 Y15.341 Z16.375 </boundaryPoint>)
(<boundaryPoint> X22.732 Y-14.969 Z16.375 </boundaryPoint>)

PyPy will put the first line as the fourth. It’s the same bounding box, but it shows up in a diff. More importantly, it also makes different decisions when it comes to fill. My profile is set to a 20% fill, and you can see the differences in the image above. Neither implementation’s output seems to be actually suffer. In the case above (a few layers after the intersection starts), PyPy uses fewer straight lines. But further up on the object CPython put more angles in. Things are never too different though, they are kind of close. Maybe this isn’t something to worry too much about.  I’ll have to spot check one of the more complicated objects to see if an obvious problem occurs.


After posting this I received this email from Carl Friedrich Bolz, one of the PyPy developers:

[I] wanted to point out two of the most likely sources of differences (I’m a PyPy developer):

– dictionary order is not guaranteed between implementations
– CPython probably uses x87 floating point math, whereas PyPy uses SSE2. those two have slightly different rounding behavior, so if the algorithms are not numerically stable, you can get diverging results.

if you find out that it’s not one of those too, it might be a bug in PyPy.

The SSE issue was actually one of my theories for what was going on. Rounding on floating point numbers would explain what Skeinforge is doing. On my example layer above, PyPy must have thought it was a hair under on plastic so it added some extra kinks in the fill lines to make up the difference. The dictionary ordering explains the outline coordinates.

I haven’t gotten around to spot checking the larger object, but between my results above and confirmation that PyPy handles floating point number differently… I think I’m going to start using it permanently with Skeinforge. The 4x speedup is really wonderful.

Trying PyPy with ReplicatorG

PyPy + ReplicatorG

While I’ve been having a ton of fun with my MakerBot Thing-O-Matic, generating the gcode to run the machine takes an amazingly long. Despite having a quad-core Core2Duo running a hair over 2.5GHz, Skeinforge is not efficient. Python isn’t fast at that much number crunching, and the process that turns the 3D model into a series of 2D layers is almost totally serial.

I’ve been using a program called Pleasent3D to look at the gcode Skeinforge makes to look for errors. While reading about the software, I found a blog entry by the author describing how he got tired of waiting on Skeinforge and then ported the gcode gene ration algorithms to Objective-C and ended up with a massive speedup (up to 230x in one module).

Now I don’t want to get away from the official MakerBot way of doing things yet, I’m not that confident. The easiest way to speed up Skeinforge would be to speed up Python. People used to recommend Psycho, but it is no longer updated and doesn’t run in 64-bit mode (like Python does on my Mac). I finally got around to playing with PyPy, which grew out of Psyscho, to see just how much of a difference it made. I’d seen references to other people doing this, so I knew all the libraries had to be there.

Installing PyPy & TkInter

Installing PyPy was as easy as downloading a pre-built binary distribution and unzipping it. The problem is that to use PyPy with Skeinforge (and therefor ReplicatorG), you need to have TkInter installed. I found a great set of steps to follow in a PyPy blog entry about using the IDLE IDE. The only problem was the TkInter package for PyPy is looking for Tk8.4, but OS X Lion has 8.5. Luckily since it’s a point release I figured I could just swap them out and it worked out fine. I updated the files in the tkinter-pypy install file and it worked fine (updated zip for download). Making ReplicatorG use PyPy is as easy as selecting it in the preferences window.


So I ran some benchmarks by running a couple of models through with both CPython and PyPy with my normal profile, no support:

Model CPython PyPy Speed
20mm calibration cube 19s 13s 1.46x
Vica illusion sculpture 5m 36s 1m 48s 3.11x
V8 cam shafts 6m 37s 1m 18s 5.09x
Tank! 2h 45m 29s 38m 45s 4.27x

As you can see, PyPy can be dramatically faster. I chose the Tank! model (which unmodified is about 4x the max print area on my ToM) to see just how big the difference would be on very complex models. Getting a 4x speedup is a great result, but there is just one minor problem: the gcode is different. Generating gcode should be deterministic. Given the same profile, the same model, and the same version of Skeinforge you should always get the same output.

In the case of the 20mm calibration cube, the gcode is identical. But for every other model, it’s different. The F parameters on the move commands are different, and sometimes the points seem different. I haven’t looked at it too hard yet. It seems like it might be due to floating point differences, but PyPy is supposed to be a drop in replacement for most Python programs so I doubt this should be happening.

I’m going to have to look into it further.