Deph Control by Motorised Ball Valve

[wiifm]

In the random sketch, a new Setpoint is  created every 200ms and can be up to 500ms away from the previous Setpoint  This is arbitrary, but gives a vigorous test of the valve.  Effectively, the random setpoint makes the valve chase all over the place.

In your example, if the current position is 0 and the Setpoint is 124, the update function will cause the valve to open and start counting time.  Each time update is called, it checks to ensure at least 1ms has lapsed, then updates the current position based on elapsed time and compares to the  Setpoint.  if current position is less than set point, no further commands are issued. If current position equals set point, the motor is stopped.  If current position is greater than setpoint, the valve will be caused to close. Rinse and repeat.

You can change the setpoint in the loop and the update function will just take the new setpoint into consideration and act accordingly.

Overshoots will just depend on what else is happening in the loop and interrupts  A false interrupt could cause the motor to run for an extra 25ms minimum but a bunch of Serial commands might be a couple of ms.

[Eucyblues]

In your example, if the current position is 0 and the Setpoint is 124, the update function will cause the valve to open and start counting time.

Yep - I understand that

Each time update is called, it checks to ensure at least 1ms has lapsed, then updates the current position based on elapsed time and compares to the  Setpoint.

Yep - clear

if current position is less than set point, no further commands are issued.

Yes - but as per my example, as the update checking is only done @200m/s intervals, for a setpoint of less than the checking interval, surely the valve will always overshoot, then correct, then undershoot etc
 

[wiifm]

update() is called every time the loop goes around.

In the example below from the Random_Position example, the generateRandomOutput is called every 200ms, but the valve.update() fuction is called every time.

Code: [Select]

void loop ()
{

  doFunctionAtInterval(generateRandomOutput, &lastRandom, 200);
  valve.update();

}


[Eucyblues]

OK - yep - must be too many hours on the keyboard - So any over-runs will be governed by the timing of other loop() functions -

If you slowed the valve down to approx half speed You could instead conceivably use a callback function with a frequency of up to 60ms - that's about 1 degree tolerance  - a mere blip

[wiifm]

Absolutely you can change the timings.  My goal in this was to have as fine adjustment as possible.  After all we are using a ball valve.  If it turns out to be not necessary then all good.

[Eucyblues]

wiifm - here's a tidy solution for the constant checking - an interrupt timer on the valve motor - can be set to micro seconds - uses TimerOne library

working example below:

Code: [Select]

#include <TimerOne.h>
 #define pinA1  8
#define pinA2  9
void setup(){
  Serial.begin (9600);
  ValveOpenStep(62000);//  62 millis-input whatever you want (in micros) up to over 8 secs
}
 
void loop(){
  // Main code loop
  }
 
//***************
void ValveOpenStep (long step) {
  Timer1.initialize(step); // set a timer
  Timer1.attachInterrupt( ValveCoastISR ); // attach the service routine
 Serial.print("Valve Open @ ");
  Serial.print (millis());
  ValveOpen();
 }
void ValveOpen() {
 digitalWrite (pinA1, HIGH);
 digitalWrite (pinA2, LOW);
}
void ValveCoast() {
 digitalWrite (pinA1, LOW);
 digitalWrite (pinA2, LOW);
}
void ValveCoastISR() {
 ValveCoast();
  Serial.print("Valve Closed @ ");
  Serial.print (micros());
  Timer1.detachInterrupt();
}
The example works like a charm - needs to be tested with other interrupts to check if conflicts occur but seems likely to fix your hunting

Library attached

Here's the link to the playground article
http://playground.arduino.cc/Code/Timer1

Cheers
Eb

[inglishill]

Started having a read, although it may bit off topic here is a way to make counting pretty easy, self explanatory really

Deph Control by Motorised Ball Valve
Timing idea.jpg (1031.71 kB. 350x622 - viewed 928 times.)

[Eucyblues]

Hi inglishill

Hall effect sensors are readily available as well

However, these motorised valve are fully enclosed - you can't access any shafts without destroying them

[inglishill]

Hi inglishill

Hall effect sensors are readily available as well

However, these motorised valve are fully enclosed - you can't access any shafts without destroying them

I forgot all about hall sensors......

The idea behind the above was using a Stepper Motor and Needle Valve that already had exposed shafts, the three components could be integrated or separate and run with pulleys and belts. It would make sense to integrate the stepper motor and the counter.

Just a random thought that may help solve the problem mechanically rather than electronically.  All that would need to be done would to be to work out the steps/clicks/microswitch pulses from closed to open, obviously the more teeth you had the more control you could have (or you could use different sized pulleys to gear the outfit to be more precise). 

[wiifm]

My understanding of stepper motors is that they are able to hold position (within limits) so if you can count steps and have an accurate position.

I am not certain that we need to be perfectly accurate with the current position of the valve.  Ultimately, the PID algorithm will tell the valve to adjust its position in order to achieve the desired result.

[Eucyblues]

I am not certain that we need to be perfectly accurate with the current position of the valve.  Ultimately, the PID algorithm will tell the valve to adjust its position in order to achieve the desired result.

Yep - it's only really relevant to a manual control over-ride of the PID

[wiifm]

wiifm - here's a tidy solution for the constant checking - an interrupt timer on the valve motor - can be set to micro seconds - uses TimerOne library

working example below:

Code: [Select]

#include <TimerOne.h>
 #define pinA1  8
#define pinA2  9
void setup(){
  Serial.begin (9600);
  ValveOpenStep(62000);//  62 millis-input whatever you want (in micros) up to over 8 secs
}
 
void loop(){
  // Main code loop
  }
 
//***************
void ValveOpenStep (long step) {
  Timer1.initialize(step); // set a timer
  Timer1.attachInterrupt( ValveCoastISR ); // attach the service routine
 Serial.print("Valve Open @ ");
  Serial.print (millis());
  ValveOpen();
 }
void ValveOpen() {
 digitalWrite (pinA1, HIGH);
 digitalWrite (pinA2, LOW);
}
void ValveCoast() {
 digitalWrite (pinA1, LOW);
 digitalWrite (pinA2, LOW);
}
void ValveCoastISR() {
 ValveCoast();
  Serial.print("Valve Closed @ ");
  Serial.print (micros());
  Timer1.detachInterrupt();
}
The example works like a charm - needs to be tested with other interrupts to check if conflicts occur but seems likely to fix your hunting

Library attached

Here's the link to the playground article
http://playground.arduino.cc/Code/Timer1

Cheers
Eb

Thanks Eb. From what i can tell the timerone code is implemented by counting cpu cycles. It is just hidden in the class.  At the end of the day, there are no software interrupts in Arduino. 

What would you do if the target position changed mid-move? With the timer, it looks like you would be forced to complete the move, then look at the target position?

[inglishill]

My understanding of stepper motors is that they are able to hold position (within limits) so if you can count steps and have an accurate position.

I am not certain that we need to be perfectly accurate with the current position of the valve.  Ultimately, the PID algorithm will tell the valve to adjust its position in order to achieve the desired result.

Good call, in which case you could do away with the stepper motor and use the gear and a valve with reducing pulleys, counting clicks to set position.

As I said, just a random idea, and by and large off this topic so I will dispense with it.

Great stuff here guys, you are all doing a really good job on these boards

[Eucyblues]

Thanks Eb. From what i can tell the timerone code is implemented by counting cpu cycles. It is just hidden in the class.  At the end of the day, there are no software interrupts in Arduino. 

What would you do if the target position changed mid-move? With the timer, it looks like you would be forced to complete the move, then look at the target position?

I think you can detach the timer mid move and break it, but after stuffing around with it for the best part of a day, I can't find a satisfactory way to control consecutive events.

If you have a set of consecutive movements (like in initialisation/calibration), event 1 starts the event and the timer, but in returning to the main process, it obviously then tries to start the next_in_line event immediately.  I tried forcing it to return to loop() while the interrupt was active but it didn't work consistently

So if a locking function is required anyway, for my purposes at least (a valve mounted slave), the bad 'ol delay() works just fine.

I've wasted too much time on it 

 

[ShiFu]

When you guys finally give up on a ball valve with DC motor...

Maybe you will be interested in a needle valve with a stepper motor? 

[Eucyblues]

I think the ball will work OK but only time will tell ShiFu ........

[Eucyblues]

Another update:

One step forward - one back as i wrestled with the CR05 valve.  I also blew up 2 Nanos in the process (too many dangly jumpers and I plugged the wrong holes in the proto board) so did some re-writing for a Micro only to find that it doesn't like the interrupt library so I gave up on that - Fortunately new Nanos arrived the next day so I was back to it...

This valve is higher geared than the CR02 unit so open and close times are about 3 secs, and it won't accept PWM speed control (must be the motor controller type) - the CR02 unit was fine with this.

However on the plus side, the open/close ratios are basically the same - very minor differences in times probably due to backlash

This unit also has no obvious relay which is positive for longevity.

BUT - I also tore my hair out as per wiifm because in reverse, the interrupt would fire randomly and shut the whole sketch down (I had test print routines running but outside the interrupt routines)
 
Even though wiifm had this problem, it took some considerable time for me to eliminate other possibilities and reach the same conclusion - For a while i was convinced it was either a voltage issue or the valve sticking (it died in revs just before stopping - it literally groaned to a halt - quite weird).  A simple test sketch without interrupts proved the valve OK and I simply (but belatedly) removed the interrupts from the limit switches and it fixed it - the pin readings of the switches are fine so no more problems in this regard.

I have retained blocking functions for the valve movements as the unit is a slave device - and after initial setup, I'm not expecting constant lengthy movements to be necessary.

The CR05 is still the best for this job because the presence of the limit switches, although problematic for interrupts, allows calibration timing to be carried out - this is important because the speed of these devices is wholly dependent on the power supply voltage - so the timings can be checked and the step times reset on each startup

Because the ball openings are not linear, I delved into theoretical valve flow and came up with a flow equation which allows desired flows to be input and the ball will rotate to the corresponding position - It's not tested and may not be highly accurate but it's a better method than turning to an angle.  I also laboriously calculated the physical aperture areas across the range of openings and compared those to the theoretical results - they were in the ballpark but the flow is more constrained at low openings than is represented by simple aperture calcs because the flow turns through quite steep angles thereby increasing head loss.   

The required flow will ultimately be controlled** by the PID routine but it can be over-ridden manually if desired.

So I have the Nano sketch just about ready apart from tacking on the PID, and I have a transmission sketch on a Mega to be transplanted to the Distillator

The transmission test sketch allows flow percentages (0 to 100) to be entered via the serial monitor, or 'disengaged' by entering 255.  On disengagement, manual stepping open and shut can be done by both the master and the slave.  The slave sends back both the calculated flow and the ball angle to the Master.

My box arrived today also - and I've done a ShiFu  - the box is so big I can fit the whole ball valve AND my Bike in it - so I'll have to resort to a balsa or cardboard mockup before ordering another one.

Switches are ordered, brass fittings in hand - getting closer. 

** I have a recirculating coolant supply and I have some doubt that the PID routine will cope with it as the 'base' conditions will change as the water heats up, so the P and the I will be affected and the D will be confused - time will tell.

     

[Eucyblues]

YAPR - Yet Another Progress Report

Just about finished boxing - Photos attached - I'm waiting on:

1/ mini USB connectors M+F to allow 5 wire connection to the box for the valve

2/ digital flow meter (photo below) : http://www.ebay.com.au/itm/391453518776?_trksid=p2057872.m2749.l2649&ssPageName=STRK%3AMEBIDX%3AIT

3/ Slide switch for manual/auto control

The button label process I've posted in the new hints and tips section

I've made a short demo video - hopefully ShiFu will upload it

The flow meter will hook to the slave controller and I2C data back to the Distillator - Using this unit with 2 way comms will allow the Disti to control the actual flow versus the indirectly calculated flow I have at present - It will also be interesting to compare the actual flow with thos calcs

PS - to overcome my concern in the previous post: viz:

** I have a recirculating coolant supply and I have some doubt that the PID routine will cope with it as the 'base' conditions will change as the water heats up, so the P and the I will be affected and the D will be confused - time will tell.

I'm intending to use the deph temp readings to calculate an temperature-constant equivalent coolant flow - ie - use a base temp and assuming the cooling effect is directly related to the flow and water temp I can correct for rising coolant temps by proportionally increasing the flow

Sounds reasonable to me - here's hoping

[Edwin Croissant]

I'm intending to use the deph temp readings to calculate an temperature-constant equivalent coolant flow - ie - use a base temp and assuming the cooling effect is directly related to the flow and water temp I can correct for rising coolant temps by proportionally increasing the flow

Sounds reasonable to me - here's hoping

I think that will work. If you know the coolant flow through your dephlegmator and the temperature difference between inlet and outlet of your dephlegmator you know the amount of heat you extract from your distillation process. So if you have a constant heat supply and you keep the amount of heat extracted from your process constant you have a constant reflux ratio. During the run you gradually extract more heat to get a higher reflux ratio to compensate for the depletion of your charge.

[Eucyblues]

A PS on the Nov 14 post

Even though wiifm had this problem, it took some considerable time for me to eliminate other possibilities and reach the same conclusion - For a while i was convinced it was either a voltage issue or the valve sticking (it died in revs just before stopping - it literally groaned to a halt - quite weird). A simple test sketch without interrupts proved the valve OK and I simply (but belatedly) removed the interrupts from the limit switches and it fixed it - the pin readings of the switches are fine so no more problems in this regard.

It's happened again a few times in my boxed circuit on 'fullyopen' and fullyclose' where I'm probably running a slightly lower valve voltage than on the test board  - I've figured out what it is - the CR05 has both limit switches AND current sensing and sometimes (stiffness??) the valve groans to a halt JUST BEFORE the limit switch is tripped - ie - the load sensor overrides the limit switch - this effectively halts the sketch as it waits for the limit switch to trip - another blip on the button drives to the limit switch and all is well - I'll increase the voltage a nudge and see if that fixes it.  Strangely, it doesn't seem to affect the initialisation cycles which use the same routines

PS - FIXED (I think) - I added a timeout on the open and close cycles based on the calibration figures (also has an initial default)  - seems to be OK