About this 3D model

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 ( http://www.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 ( http://www.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 t