DIY Dosing Pump Controller Atmega128

I don't know about providing pre-flashed uC's... that involves time and money and this is not a commercial venture. Even if it was my intent, I could not talk about it here on RC due to the rules about commercial posts.

I can likely have boards made up at some point but would need a minimum number of interested people to keep the cost reasonable. This is not a cheap project. The Rotary encoders are $20, the uC is $20, The wiznet is $20 the LCD is $10, the EL driver (not needed if you have an LED backlight) is $10, the rest of the components are $30-$50 or so.

Yes, I order from digi-key and have a parts list with references from their part numbers. Their prices are very competative and they have a large stock.

This is by no means a down and dirty cheap project... it is just what I wanted to do :)
 
<a href=showthread.php?s=&postid=13747752#post13747752 target=_blank>Originally posted</a> by BeanAnimal

I .... would need a minimum number of interested people to keep the cost reasonable.
Count me in .... :D
 
:) Let me get the sucker finished first!

As I stated, I have my doubts about the ethernet capability. I am just not thrilled with the WIZNET board and have no desire (or ability) to bit bang TCP/IP with some of the other available tcp/ip offerings.
 
<a href=showthread.php?s=&postid=13748428#post13748428 target=_blank>Originally posted</a> by BeanAnimal
Let me get the sucker finished first!
Not to worry - I'm sure everyone is willing to allow you a reasonable amount of time ....:cool:
 
Bean,

"I had an ISR problem with the rotary encoders switch. I could not stop the random ISR calls "

Does the board support IRQ masks?

If so, when the ISR is called the first time, the ISR disables the interrupt ( by writing to the mask register) while it polls all the relevant input registers to detect which switch was pressed.
Once the routine determines which switch was pressed, it re-enables the interrupt mask and quits.

????? maybe

Stu
 
I tried to write directly to the IRQ register to clear it stu... the problem was that the switch is snap type and bounced BOTH on close and on open. So no matter how I tweaked the debounce wait states and register clears, I missed a bounce here or there.

In the end it was my failure in logic, not that of the AVR. That is, each press causes a high and low pulse, as does each release.

So here is how I corrected my logic.

INT5 = trigger on both rising and falling edge
PRESS SWITCH = FALLING edge with a few bounces rising and falling bounces.
RELEASE SWTICH = RISING edge with a few risong and falling bounces.

Code:
Encoderbutton_isr:
   Disable Int5
   Waitms 80
   If Flg_debounce = False Then
      Set Int5_triggered
       Flg_debounce = True
   Else
      Flg_debounce = False
   End If

   Set Eifr.5                                               'clear INT5 flags set by switch bounce
   Enable Int5
Return
 
Last edited:
In other words... I am throwing out every ISR call that happens withint 80 miliseconds of the initial INT call and then EVERY OTHER INT call that occurs outside of that 80ms range.

Hope that makes sense and helps people who have run into the same brain bender.
 
I see a few decently priced materflex heads on there. I have no use for the whole "pump" unit for this project. Though, the unit itself would make a nice doser for somebody who does not want to build a controller.

The #35 heads I have are too big for trace dosing, but would be great for continuous water change systems. My controller will have a water change mode for several of the outputs.

Pump Configuration Menu

Code:
Dosing Mode
  disabled
  1 shot
  2 internvals
  4 internvals
  8 intervals
  16 intervals
  32 intervals
  48 intervals
  trigger-on/trigger-off  
  nonstop (water change)
 
Dosing Window
  2 hours
  4 hours
  8 hours
  12 hours
  16 hours
  24 hours

Dosing Start Time
  time of day

Dosing Volume
  Total Volume in mL

Pump Label
  12 character pump label

Pump calibation
  mL per Minute
  ml per rev

Level Sensor awareness
  This float switch
  Any float switch
 
Pump Operation
  Timed
  Revs
 
For those looking for an update... I am slugging away at the menu code. I only get 1/2 hour or so a night to work on this project...

The menu side of the project runs off of a FINITE STATE MACHINE... aka a "state machine".

I have posted a PDF with the menu logic. Each square box represents a 4*20 LCD "screen". Red links are BUTTON presses and BLUE links are rotary encoder inputs.

With each pass of the "game loop" or "state loop" the menu state is checked with a "SELECT CASE" statement. If a button press or encoder rotation flag is detected, then the menu state and/or data displayed changes accordingly. SO in essence each state responds to BUTTON, LEFT or RIGHT with a new STATE and if applicable NEW DATA.

The PDF is 8.5x11 but the drawing is really D size. So print it in zoomed mode or zoom in using acrobat.

Enjoy
http://www.beananimal.com/media/6017/doselogix_state_machine_v2.4.pdf
 
I am an IT consultant....

Needless to when one of my clients asked about a 36" CANON plotter, I was happy to sell them one :) I have it mapped over the VPN too :)
 
also... don't beat me up too bad theatrus, I do this as a hobby and am self taught. My code is not pretty, or optimized... it just compiles :)
 
With peristaltic pump you know the amount dosed based rotation. It seems like you will give up a fair amount of accuracy only doing timed control. Sorry if this sounds critical, I dont mean it to be I wish I had the remotest clue how to build a circuit like that :)
 
There is no difference in accuracy between timed and counted revolutions, assuming that in timed mode, the motor provides a consistent RPM.
 
I think I should elaborate on the last answer for those who may not understand the logic.

AC motors are frequency based, That is, their rotational speed is dictated by the frequency of the electricity used to power them. Here in the United States, that frequency is 60Hz. So if an AC motor with sufficient torque is used, then the RPMs are fixed and will not changed. It follows that the ml/time will be an accurate measure of the pumps output.

DC motors are a different story, the rotational speed is dictated by by the voltage applied to the motor (ignoring DC motors with complex drivers). However, it is fairly trivial to build a constant voltage DC supply to drive the motors. A constant voltage will provide a predictable RPM as long as the motor has sufficient torque to drive the peristaltic head.

Counting RPMs is also a valid way to predict our control the flow of a peristaltic pump. As mentioned earlier, this was an option I kicked around. I have the hardware and have tested the functionality. However, the added complexity is simply not needed for our purposes.
 
Bean,

It would be trivial to use hall effect sensors for each head to measure rotations.
Just glue a magnet on the pump rotor & mount the sensor on the housing.

I saw that you were trying to use the encoders, but I think that's overkill

Stu
 
Stu,

I may have confused you by not explaining myself fully.


I have a bin full of different styles of hall effect sensors and have tested them out. They work as expected!

Some of the ismatec drives have builtin shaft encoders. I could easily incorporate them into the design as well, but my ismatec heads do not have encoded motors. Therefore, I did not bother even bother prototyping this option.

I AM using a rotary encoder (Grayhill optical with integrated momentary push-button) for the user interface. RIGHT, LEFT and BUTTON are the only user inputs to the device and control all menu navigation and data entry.

So back to the shaft encoders/hall sensors... Using "timed" dosing is universal. I have implemented a "calibration" feature to set the ml/min per each pump output. To use revolution based based dosing, I would need to use the same basic calibration routine, but also need to adapt each and every pump by adding 2 extra wires and mounting the sensor and magents. Not so universal as far as offering the design to other people to build. More troubleshooting and PMs to answer... if you follow.
 
I don't agree timing the motor while be as accurate, accurate enough for this application I suppose.

Also, feedback to a control system will increase reliability.
 
Back
Top