Archive for the ‘msp430’ Category

standalone heated bed controller

June 21, 2016

Back in the day when I was at college we had a RapMan 3d printer.  Do not buy this printer.  The version we had was flat-pack, made entirely of acrylic sheets sandwiching smooth rods for construction.  Staying up all night to get the first print got us a small ABS plastic cup and a rain of nuts, washers, and bolts.  If you tighten anything down enough to not shake itself apart you shatter the acrylic, and the controller is proprietary, so there’s not much you can do to it from that front.  We spent the first few weeks designing and printing replacement parts for the printer out of ABS because the acrylic was garbage.  The extruders were nice, but used a custom machined razor sharp worm gear that would just chew up material if it was too soft.  On top of all that, it didn’t have a heated bed.  If you’ve ever 3d printed something you’ll know that a heated bed is quite nice and helpful to get good looking parts.  Since we couldn’t interface with the damn proprietary controller we just built a stand-alone one.

We built this in one night, and to my knowledge it never got changed.  This is both a blessing and a curse.  If you half-ass something and it works ‘well enough’ people are not motivated to make a better one, this could mean even more time before you have a reasonable solution to the problem.  If the solution is truly good enough then it’s not an issue, but there’s a spectrum… The other thing worth noting is if someone decided to take a ‘good enough’ solution out of order and replace it with an un-finished ‘right way’ solution taking the functionality from 60% straight down to 0%.  These sorts of ‘fixes’ are the hardest to come back from because it involves either finishing someone else’s project, starting over, or putting back the first solution.  I would tend to lean toward the latter of these options, but that’s not always possible if the parts have been cannibalized in the course of making the whole system non-functional.

Being built in one night it used what we had lying around, in this case an original msp430 launchpad.  These had a bunch of features, plenty of reasons to like them, and most importantly an arduino abstraction layer ported to them.  Arduino may have a bad IDE with very few features and a convoluted system of adding boards and other support, but the important part is that it’s easy enough to get working fast and has enough of a community that making your first few projects work is super easy.  At the time when I documented projects it was on the IEEE Lab Wiki, considering that’s who it was built for and where people would look for documentation on how to use it.  These days I’m going through my google photos looking for something to document, not to bulk out the number of blog entries I have, but just to put together a repository of my knowledge.  I’m not planning on getting hit by a bus soon, but I bought my own house and am already not that healthy of a person.  Here is the excerpt from the wiki article I wrote:

Overview

The heated bed was purchased to increase the quality of 3d prints on the Rap Man. It is constructed from a bed from RepRapDiscount, borosilicate glass from Lulzbot and our own custom controller built from an MSP430g2553.

Specifications

Maximum Build Dimensions

  • X: 214mm (~8.5″)
  • Y: 200mm (~8″)
  • Max Temperature: 110°C (230°F)
  • Power Requirements: 12V @ 8.5A

Design

We wanted to use one of our launchpad MSP430s, but we wanted to do it fast, so rather than learn how to use TI’s IDE (we tried, there were major problems that varied between chips) we used Energia. Using some KEM-5161BR (common anode) 7-segments driven by 2 74HC595N shift registers. To conserve pins we configured the 8th bit on the second shift register to control the third 7-segment as either blank or display a “1”. We have the POT being read on one pin and the thermistor set up as a voltage divider on another pin. The FET (2 in parallel since we needed more current) hooked up to a digital output. The code is [[1]here].

Future Modifications

  • Replace the thermistor table with a function
  • Replace the on/off functionality with a PID controlled PWM
  • Move the FETs to a separate board (or further away from the pot
  • Replace the FETs with one rated for the current
  • Print a PCB

 

I’m actually not going to elaborate on that because I don’t remember anything else about the design, construction, or functionality. Looking back, my favorite part of the code is the comment “fitted graphically”, I think I’ll use that at work some time as justification for data.  On the subject of ‘future modifications’ I’m pretty sure none of that ever happened, although at least one person got burned by the FET (that really should have been a relay, way higher power with basically no heat).  This article’s ‘value add’ can be my story and perspective on the whole situation I guess.

pictures are hosted here

code (and an unbuilt board design?) is here

original wiki article for the lab is here

Billy mouth billy bass hacking

June 15, 2013

Well, here’s a classic: hacking the old Billy M0uth Billy Bass!  This is an absolute classic, it seems like everyone and their tin dog has done this one.  I picked this thing up at a garage sale, the only intention I ever had was to hack it (who really wants this thing wailing at them?).  Well, let’s get to it.

First things first, the mouth was broken… unacceptable! Let me tell you this thing is a pain to get open, the plaque is fine, but the fish itself… they must have heat sealed it on or something, it looks like a ship in a bottle, like it was assembled inside the skin.  To finally free the mechanics from the skin I put a slit down the back of the tail about 2 or 3 inches long.  Once I got it open it was obvious the plastic had just sheared, lacking patience for 3d printers I decided to just superglue it back together.

Once I got that glued together I shaved some plastic to get it to fit (I had glued it a bit too tight) and installed it.

stuck some paper to it with glue…

That pretty much fixed the mouth.  When it breaks again (and it will) I’ll model and print another couple brackets.  Now that that’s done, let’s examine the ASIC.  ASIC stands for Application Specific Integrated Circuit, that means someone designed a specific chip to do this exact job.  In very small runs these are usually FPGAs (Field Programmable Gate Arrays) because of the cost involved in creating an ASIC.  In small runs they are usually like this, what we in the biz call “epoxy blobs”, they just bonded the silicon wafer to the PCB then covered it with epoxy.  In larger runs they are made into standard package ICs.  Epoxy blobs cause such a headache for hackers because the only way you can identify what’s under there is by dissolving the epoxy around the silicon wafer and just looking at.  The more reasonable and down to earth way of identifying what’s in the chip is known as “black boxing” it.  That involves looking at what the chip does, how it reacts to inputs and when it gives certain outputs.  By using a bit of logic you can determine basically what a chip does (while it’s still in the circuit preferably) without needing to know exactly how it does it.

This is the ASIC in question, helpfully it’s on its own PCB mounted perpendicular to the main PCB.  My solution for figuring this one out was to mount the ASIC on 0.1″ headers and stick it on a breadboard, run a ribbon cable and another 0.1″ header and jumper all of them together.  After testing that it behaved the same, I started changing things.  First I verified where ground was (by tracing it out).  Once I had a reference I found (what I assume to be) a relatively stable/regulated 3.3v source.  The next thing was watching what the lines did when the various motors triggered.  That was the single longest time I listened to the built in audio… and I never will again.  The button and CDS cell each seemed to generate analog voltages on two of the pins… kinda.  I say analog voltages, but they’re probably supposed to be digital, but there’s some variance in them, so I use them as analog.  The audio line I left off since I have yet to try to implement this.  Two of the lines I haven’t figured out what they do, but they don’t seem to matter.

Before taking on a project like this I usually say to myself “which will be easier, strategically modifying existing circuitry to suit my needs, or ripping it out and putting in my own?  I usually come to the conclusion that I could certainly build my own controller with a digital input, analog imput, l298d for the motors, but all that work is done for me here.  There is even a nice sorta regulated voltage I can run off of.  In this specific case it was easier for me to ignore how the circuit works (because it’s a mess of resistors, caps, diodes, and bjts) and just try to emulate the ASIC than design a circuit to do this job.  The main reason was that I didn’t want to spend a motor driver IC on this project if I didn’t have to.

The next thing is the brain.  The microcontroller is a key decision, the part that pushed my decision on this one was the voltage, the circuit seemed to run on about 3.5v so that meant I could use an arduino, but only if it was running at 8Mhz (which I didn’t have set up) or I could use an msp430 from one of the launchpads I had kicking around.  I’m not familiar with programming for the msp430, but luckily there is a project to program the launchpads with wiring code (what the arduino uses): Energia.  Slapping the msp430 on it I quickly built this small sketch to showcase all the inputs and outputs.  My eventual plan with this is to get a serial link working so it’s just another peripheral you can interface to with whatever program you want (maybe an ROS module? but that’s an idea for a future project bleeding in).  All images can be found here.