Yoda Bust

I don't know why Thingiverse puts the descriptions in this order and makes you read through my extreme verbosity just to get to some instructions...



Cupcake users have been rigging up LCDs for a while, but as far as I (and the Firmware, and the RepG code) know, no one has done it on a Thing-O-Matic. I guess the latest RepG monitors temperatures, so that's nice, but I had this LCD in a box and I thought finally - something to use it on.

Yes, this has no keypad, but even if you have /nothing/ in your workshop, the total project cost for this is < $20.

It turned out to be a bit of a slog, since there was literally nothing written for it in the Thing-O-Matic firmware. But worse than that, since I personally have two extruders, and I hope others will follow ( thingiverse.com/thing:6632 ) ... it didn't make sense to hook it to the extruder controller as is traditional. It made sense to hook it to the motherboard.

This brings in a whole raft of problems. The motherboard firmware has never known the toolhead temperature. It doesn't really have any way to know. So I had to add one. Because the only way to get the temperatures is a round-trip comm with the extruder, this is a little costly; but I think in the latest version I've managed to completely eliminate any delays.



IMPORTANT NOTES FOR YOU!
* I didn't bother to separate out the code for my estop ( thingiverse.com/thing:6704 ) from the below, so if you use the .patch file or firmware as-is you get both, but if there's nothing wired up to your estop it doesn't matter anyhow.
* It's always best if you can use the .patch file to compile your own firmware. The .hex file attached is hardcoded to assume 1 toolhead, and prints "THING-O-MATIC" in the extra space. It also assumes you're using a 16x2 display with Hitachi addressing, so something like the black/white one from Sparkfun and NOT like my green Newhaven.
* Any news below about delays is old news. What's published here is the final version and works brilliantly in all my tests.
* The .STL files below are for my Newhaven display and are much too big for the Sparkfun displays. It'll probably be down to someone else to design a nice case for this.
* If you are using your X-MAX endstop (you probably are using X-MIN, not X-MAX) the published .hex file will disable it. Use the .patch file and re-enable it or... well, no or really. You're on your own here. :) I don't think this will actually be an issue for anyone, I've never heard of anyone using X-MAX.
* This also disables the debug LED on the motherboard.


UPDATE: (2011-03-01)

It does introduce delays. By splitting things up so that it doesn't try to do everything at once, the delays are vastly reduced, but not, I think, eliminated. However, there may be more I can do, and suggestions are welcome. I'll be uploading a new patch later tonight after I do some more work that will solve at least most of the problem.

Patch still pending; I've uploaded a plan for a LCD Case, which so far I've printed the smaller half of and it fits great. I've got a plan for fixing the delay completely; it turns out the LCD library form Arduino is stupid and sits and waits after each character for 100us. Assuming this adds up pretty quickly, but the LCD actually does require almost 100us to process a command, the sane thing to do is to pulse the line on, go on and do something else, and come back after about 100us to turn it off. This is easy to accomplish and when I upload the patch it'll have this change, but it may not be for several hours as I'm knee-deep in my day job right now.

-- new patch and firmware uploaded. These make a huuuuuuge improvement in how the LCD Library works, so there's fundamentally no delay there. But the querying of the extruders does still sometimes introduce a delay I still need to solve. I'm not sure how (or if - haven't used it myself) RepG is able to query for the temp during a print without causing minor interruptions...

But I'm imagining the solution is something like putting a check temperature command into the queue instead of just /doing/ it like I am now... since that'll make it fundamentally equivalent to whatever RepG is accomplishing.

So that'll be my next step... another pretty big one probably.

UPDATE: (2011-03-04)

Sorry for the delays on this one; my day job has been just killer lately and I've had to fit in ToM development where I can.

I got the LCD display I linked below from Sparkfun, and it turns out some of the assumptions I made about how these things work generally, extrapolated from the one I was using, were incorrect. It's not any major thing; the one wire I hooked up 'even though it's not used' turns out to be an analog contrast adjustment pin on most of these LCDs, so should be attached to a pot to make an easy contrast knob; or maybe PWM'd from the pin it's on now would work? Not sure; I'll probably go with the pot...

And a reason for that is I've recieved the $3 keypad mentioned in the comments. It needs 7 pins to drive. If you're keeping score at home, that makes 23 pins total used between the keypad and LCD, and the ToM expansion port only has 22 pins. If I take out the LCD contrast pin and run it through a pot, that frees up the final needed pin. However, I'm not doing that right now; I'm stealing the unused pin out of the x-max endstop.

There will be an updated firmware up sometime today that shows the beginnings of keypad support and HOPEFULLY clears up the last of the delays from polling the tools.

Incidentally, I looked over the cupcake LCD code by Revar to see how it was done there, and it seems to be on an unmaintained, outdated version of the code, sadly. (If I'm wrong, correct me!) It's too bad the stuff I'm putting together here is not likely to work for cupcake users without some modification. I did find some inspiration there for how to approach things overall, but not a lot, as that architecture is very different... not just that old firmware, but also his design -- it costs so much more to put together his because is uses i2c; it only needs a few pins to drive everything. Here the total cost is < $20 in dollars but about 22 in pins. Still, what ELSE are you going to use all those pins for?

No beginnings of keypad support in the code /as such/ but you will find the firmware below now clears up all delays... so it works perfectly as advertised.

UPDATE: (2011-03-05)

Tested with 16x2 display from Sparkfun:
sparkfun.com/products/709

This should also apply to the following (at least):
sparkfun.com/products/255
sparkfun.com/products/791
sparkfun.com/products/790
sparkfun.com/products/256 4 lines!

I needed to tweak the firmware just the tiniest amount to fix up the support for the Hitachi standard, as the 20x2 Newhaven I had been using has some odd quirks. Now the patch should support either one, but the firmware below is compiled for the 16x2 from Sparkfun -- oops, and two toolheads. I'll recompile and upload it again shortly. As always, it's best if you can use the patch and compile your own!

I've uploaded some comparison photos.

The case I made for the sparkfun LCD failed to take into account the extended length of the backlighting, and so does not fit. I don't need to upload it; it's the same code as the other case just with the measurements changed.

I do still owe you all a new firmware, and I'll upload it tomorrow. I've got the keypad (linked below in the comments) up and running and I expect Big Things for tomorrow!

UPDATE: (2011-03-06)

I'm putting a DONE stamp on this. As a temperature readout for the Thing-O-Matic, it's complete and there are no issues I am aware of remaining. The published version of the firmware below is compiled with the patch labeled "finalprobably," which is just what it says.

Felt a very urgent need to get this out there once I saw this xkcd:
xkcd.com/743/

As much fun as having a tiny violin might be, I'm really hoping we'll eventually have a real violin, or at the very least ample violin accessories here.

This free model comes with MeshLab, the open-source stl viewer and editor. I cleaned it up a bunch in Blender, then exported to stl and sliced it up with SkeinFox/Skeinforge. Gcode included below (high-res for printing all the fine details -- 0.25 mm/layer).

I've included the source Blender files and also the Blender render environment I used to make the marble pic.

The original model was scanned by the ISTI-CNR and was released under the CC-SA license. More details can be found at: vcg.isti.cnr.it/downloads/3dgallery/form_laurana.htm

Better Living with MakerBot, Episode 2
You probably all know this situation:
You're supposed to ref a soccer game in less than 1/2 an hour and you cannot find your whistle. You're screwed!

But from now on you're out of trouble: Fire up your trusty MakerBot and print a new whistle in 26 minutes!

This object prints the pea right inside the whistle. Since the pea is connected to the rest of the object only at one tiny point, it's quite easy to break it loose after printing with a small screw driver or tweezers.

I probably pushing luck a little bit with bridging the top layer. So far I printed the whistle twice without problems.

As always, I added the object as .obj file (wavefront), which can be imported into AOI and Blender.

The gcode file is the one I used to print the whistle on the image. The gcode file contains an experimental raft with additional "blobs" on the second (interface) layer.
You might want to generate your own gcode file with skeinforge settings, tested with your MakerBot. Be sure to setup Skeinforge to create an (almost) watertight object, since the whistle won't whistle if it's full of holes...

[Update]
I added a second version of the whistle. "Whistle_v2" is an attempt to fine tune the object a little bit. My brother (he's a pipe organ builder) gave me some tips how to optimize the whistles mouth. Whistle v2 should start whistle with less airflow than v1 and thus be (somewhat) less loud. I also downsized the pea a little bit and changed the shape of the lanyard loop.

Whistle v1 is still available for reference and also since it's more "tested"...

Since you blow the whistle with your mouth, be aware of possible problems concerning "food safety" of printed plastic. See the blog post "For foodies out there" ( blog.thingiverse.com/2009/09/13/for-foodies-out-there/ ) for more information.

This is an STL file decribing a Utah Teapot, based on data created by Martin Newell.
en.wikipedia.org/wiki/Utah_teapot

This is a pretty poor model for printing; it's been refined by Unfold since:
thingiverse.com/thing:918

This is the design we used for the first batch of MakerBots. These are the lasercut design files you will need to make your own if you have access to a laser cutter.

A regular polyhedron with twelve pentagonal faces. This one is about about 25mm high and is hollow. See hydraraptor.blogspot.com/2008/11/dodecahedron.html.

This is a "radiolaria" sculpture roughly modeled on the drawings of Ernst Haeckel. It has simple icosahedral symmetry, with thirty "spines" radiating from the edges.

This is the design for the X-Y stage used in the prototype of the Cupcake CNC robot.

This is my first cut at a printable linear bearing for M8 rod. It's intended to be printed by a Cupcake CNC with a plastruder. It will probably take a bit of tweaking before it's ready to go, so don't throw away your precision-machined bearings just yet.

It's a geared calling card! Two slots in the top layer display different information as you turn the smaller gear, and a little window lets you watch the gears mesh.

This is a layout for making a 170mm high single digit LED display. I use these to create the digits for my wall clocks. 10 standard 5mm (T1 3/4) LEDs are used for each segments (a total of 80 LEDs per digit).

I've also included a design for a small single-sided board that you can use to easily wire up your individual segments.