Thing-O-Matic LCD Temperature Readout by ScribbleJ

Last crawled date: 2 years, 11 months ago

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 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:http://www.sparkfun.com/products/709
This should also apply to the following (at least):http://www.sparkfun.com/products/255http://www.sparkfun.com/products/791http://www.sparkfun.com/products/790http://www.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.