Category Archives:

M2 update

This post is a follow-up on my previous post, We have a MakerGear M2. We’ve spent a fair amount of time tuning the print settings and experimenting with different printing and design techniques.

We started printing gear cubes pretty early on (, not sure if that’s the exact model we’ve been using); we’ve printed about 3 at this point. As far as difficulty, they aren’t very intricate, but the overhang occasionally causes problems. These are probably the coolest things we’ve printed; they’re a lot of fun to pick up and fiddle with.



This particular version prints the gears with the pins already attached. We’ve found that the versions that have separate pins tend to work better, if only because the pins are easier to replace when you break them trying to assemble the thing.


Of course, we have run into a number of problems, most of them small. The above picture shows two things. First, these are the separate pins I mentioned. Second, the head occasionally catches the model it’s printing and we end up with a pile of goop (this happens very rarely). Now that I think about, third, we’re printing on painter’s tape. The models adhere to the tape better than the glass or to kapton tape. We usually only use the blue tape for smaller models though, as models with a large surface area end up bonding really, really well.

doorstopProbably the most useful thing that we’ve printed is a doorstop. We like to keep the lab open, but the door has an automatic closer on it, so we need a doorstop. Getting a doorstop wasn’t really a problem, but the carpet in our lab is slick enough that the door pretty often would push the doorstop across the carpet until it was half closed. We designed and printed a doorstop with spikes and solved the problem (

If you’ve been following, then you’re likely familiar with MOG and our maze. We’ve printed lots of these mazes at various scales. We printed some small ones, inserted ball bearings, and sealed some plastic over the top. They made pretty good handouts for the College of Engineering’s E-Day.




(Credit to Paul Eberhart on these photos)

The above is a picture of the bottom of one of the mazes. We’ve developed a cool debossing technique that allows us to print images and letters on the bottom faces of objects.

A large part of the reason (excuse?) for buying this printer is that we can use it to print camera parts. To do that, our advisor needs to be able to print very thin layers with great detail. As a test, he started printing owls (again, not sure whether that’s the exact model). The owls are some of the most impressive items that we’ve printed. The owl in the picture below isn’t more than 2 inches tall; the detail is good enough that if you look from the right angle, you can see the nostrils clearly.



In general, we’ve not had much trouble with the printer. We’re always tweaking the settings and we have to go through the optimization process every time we try a new filament, but our print quality has been steadily improving. We’ve had the print head jam once; cleaning that out apparently involved a small torch.

This is probably my last update on the M2, as I’ve graduated and I’m not hanging around the lab anymore. If you want to hear more about it and see more pictures, you can take a look at this Google+ album. Also, our advisor is posting some of his designs on thingiverse.

3D printers still aren’t ready for use by the general public. We’ve got ours working rather well, but keep in mind that it’s in a lab full of engineers who like to tinker. High quality printing takes a lot of time and tuning. That said, the process isn’t complex, and the default settings that MakerGear distributes are workable in most situations. I’m interested to see how 3D printing changes as it moves into the mainstream.

I’m finished

The last month and a half has been pretty intense. I wrote the majority of my masters thesis while at the same time TAing CS115 and working on several other miscellaneous things. I successfully defended my thesis on April 19 and the graduate school officially accepted my thesis this afternoon. I’m finished with my degree and with school in general, at least for the time being. I should actually have time now to post here regularly.

I’ve got an internship this summer with SDGblue. I’m not sure precisely what I’ll be doing, but SDGblue provides IT and other services with a strength/focus in security and compliance. I think this work will be interesting and I’m looking forward to it. In my spare time, I will continue work on NodeScape and the web front-end I’ve been working on as part of my masters thesis.

KOAP 20130205

In an effort to sustain momentum going into the semester, I was tentatively scheduled to give a talk about KOAP for our research group Tuesday afternoon. KAOP is my tool for developing OpenCL applications using the C host API. I took the opportunity yesterday afternoon to change a few of the things that were bugging me about KOAP.

First, a little bit about how KOAP works internally (well, how it worked until Tuesday). KOAP takes an input file containing C code, OpenCL code, and KOAP directives as input. KOAP expands the directives into OpenCL API calls and combines all of the OpenCL code into a string for compilation at runtime. KOAP does not use formal parsing methods. The parsing takes place over multiple passes and is very ad-hoc. KOAP reads the input into a single string. KOAP processes comments and KOAP includes (like C preprocessor includes) in this first step. KOAP then separates the OpenCL source from the C source and breaks the source strings into double-ended queues (STL deque) of strings, using newline characters as delimiters. KOAP expands directives one line at a time, building a deque of output lines as it goes.

Why STL deques you ask? At one point, that was the only STL container that supported the methods I needed (or thought I needed). My first modification Tuesday was to replace all deques with STL vectors. Vectors support all of the needed operations, and are better suited to the problem (I’m mostly using the element access operator [] and the push_back method). KOAP has been released for over two years now, and I’ve spent two years thinking it was dumb that KOAP used double-ended queues. That’s not bugging me anymore.

My other modification is actually user visible. KOAP understands a handful of arguments for things like setting the flags passed to the OpenCL compiler, setting the device type to be used (OpenCL works on CPUs, GPUs, and other accelerators), and a few other things. All of the command line arguments came in pairs (-argname argument). I had written a very dumb bit of code to parse the command line arugments and set the necessary internal flags. My old parser required that the KOAP file for processing be the last argument, and would only process one KOAP file. I’ve rewritten the argument parser to be more general. The new parser is smarter about how it parses the arguments and accepts as many KOAP input files as you wish to give it.

The queues and the argument parser were the two things that bugged me the most about KOAP. Now that they’re fixed, I’m reasonably satisfied with how KOAP is structured internally. I’m not quite to the point of being proud of the codebase, but at least now there’s nothing in KOAP that I find embarrassing.

We have a MakerGear M2


The research group I work with ordered a MakerGear M2 back in November, and it finally arrived yesterday. My lab-mates and I took the afternoon to pull it out of the box and become acquainted with it. We ordered the pre-assembled package, so this was mostly a plug-and-play operation.

I arrived in the lab shortly after the unboxing, so I can’t describe the packaging in great detail. I’m told that the box was covered in “fragile” labels, and that the zip ties on the printer were color coded; red for ties that should come off and black for those that are permanent. MakerGear uses high-end chocolates are for packing inspection tokens. I can say from experience that those are very good. Before shipping the assembled printer, the folks at MakerGear printed two test patterns, a bracelet and a gorilla head; both were shipped with the printer.

bracelet bigfoot

We started by fiddling with the motion on the head and the bed. Before printing anything, we brought the head and the bed up to printing temps (185 C and 60 C respectively, for PLA) and ran some filament to clean the head. Finding the right calibration settings took three or four attempts at printing something. Somewhere in the process of learning how to manipulate the machine, we managed to move the bed to the positive limit in Y and the power/sensor cables snagged on the frame. The power connector simply unplugged. Unfortunately, the sensor wire snapped at the solder connection inside its connector. After half an hour of negotiating with the connector housing, we were able to extract the metal contact and re-solder the connection. One more round of leveling and we began printing a Companion Cube. We’ve apparently got some issues with our configuration for the skirt, and I think we probably need to adjust the head clearance, but our first printing looks pretty reasonable.

printing cube

I’m certain I’ll have more to say about our printer in the coming days/weeks. It’s an interesting device, and I expect it to be a good toy (or distraction).