SO about a year ago I finished my senior project - a liquer dispensing machine and graduated college.
we got the thing working for exactly the demo and then it sat in my basement for the year. I'm contemplating redoing it but trying to figure out a pouring mechanism better than the original.
I attached the design review, page 17 has the pumps schematic, these were small 3v motors from battery powered fish tank air pumps, I would pump air into the bottles which would force liquid out. the system had its issues but was cheap and simple and worked.
All the problems could be tolerated except for 1. everything was powered by a pc power supply, capable of a couple hundred watts. When the pumps were activated they would turn the lcd display into garbage output, and recovering was impossible without restarting the machine. we found that running the motors off the power supply and powering the arduino and lcds off of a usb drive connected to a PC would work and we would be able to have multiple runs without problems (although occasionally the issue would be seen) our conclusion was that it was some sort of electromagnetic interference, but we had slacked off to long and slapped it together in the last days so we never solved the problem.
is there anyone out there that can hypothesize what the problem may be. My plan is to get the thing up and running again, the control system, and the UI were pretty solid, so I will reuse that, I would like to use the pouring mechanism but I'm willing to redesign that if I cant solve this(any redesign ideas also would be appreciated) its pretty hard to find parts unless I want to get booze dispensors and scrap them, but that gets expensive.
I suggest you follow Mike's suggestion first and see how that works out. I would recommend a separate power supply for the pumps and the control system for starters. I'd use a ULN2003A to keep the pumps and the chips happy. You could only use one output at a time if high amps is a concern - the ULN2003a can handle up to 500mA with the right heat sink.
I am also unsure why you need some of the multiplexing chips you're using. Use an analog input then give each switch a different resistor for the Arduino to measure in a voltage divider. One debounce setup, no multiplexer, etc.
Constantin:
Your power supply is totally undocumented.
yeaaa... sometimes I'm impressed and slightly scared that we were able to get Engineering degrees with this project... A lot of the documentation is plain wrong. Plus, we were mostly software guys so in the hardware spectrum we stuck with what we knew. I believe we did add some decoupling to the power supply but that did not solve the issue, I will retest once the thing is up and running again. I figured in the worst case, I could reset the lcds after each run(but I cant imagine we didn't think of that initially)
I do like your idea of the voltage divider... seems like that would simplify a lot of my input logic.
I will try to get to this soon, I'm hoping to have it working by holoweenish.
sassafrassquatch:
I believe we did add some decoupling to the power supply but that did not solve the issue, I will retest once the thing is up and running again. I figured in the worst case, I could reset the lcds after each run(but I cant imagine we didn't think of that initially)
If there was an initial attempt at decoupling, and it was done correctly, you could also try putting the the motors in a Faraday cage (with ports for the wires and hoses) and this will eleminate the possibility of induced EMI. Any grounded fine metal mesh should work, so if you have a hardware store that sells screen window/door material that will do.
Also by reset, you just mean sending commands to clear the LCDs right? If so, that would probably be the quickest solution. Although IMHO, if the motors are emitting that much EMI it's better to cage them and prevent possible interference issues with other nearby electronics.
sassafrassquatch:
I do like your idea of the voltage divider... seems like that would simplify a lot of my input logic.
The idea is to have a analog read circuit with a bunch of switches and resistors. Each switch has a resistor in parallel with its contacts. Once you close the switch, that resistance is removed. Every resistor should have a different resistance, and with the right analog setup you should be able to read multiple switches being used singularly or even in parallel (think of it like bits being toggled in a byte).
You need to have enough 'difference' for the resistance read so that the 10 bit ADC in the Atmel can reliably pick it up (i.e. you have 1023 steps to play with unless you go to decimation - and I'd stick to being able to pick up the differences with a 10-bit ADC). I'd start off with 10k pull-up resistor, then work out resistances on the other side of the voltage divider to give you the resolution you need while also being readily available (i.e. 100, 220, 470, 1k, 2.2k, 4.7k, 10k, 22k, 47k, 100k, etc.) Note how I staggered the values to allow no overlap even if all 'lower' values have been inactivated / activated.
I'd work it out ahead of time in Excel, especially if you need to allow for multiple keys being pushed at once. But even with this prep-work, I'd field measure the resistances put out by the various combinations and then use Progmem arrays to store the data in a flash (not SRAM) array. Give yourself some latitude re: measurements (i.e. a lower boundary and a upper boundary for each value) and your analog input may also benefit from a small cap (0.1uF) to GND to steady things a bit and remove EMI spikes.
) to