Deph Control by Motorised Ball Valve

[ShiFu]

Thanks wiifm,
I looked again at the motorized ball valve on page 2.
I have several of those but they are all "spring loaded" or something, they are made to quickly close when the power is removed.
Looking at them now, they probably are not useful in this application as they are 220 VAC.
Haven't taken one apart yet. Maybe I should?

[wiifm]

Thanks wiifm,
I looked again at the motorized ball valve on page 2.
I have several of those but they are all "spring loaded" or something, they are made to quickly close when the power is removed.
Looking at them now, they probably are not useful in this application as they are 220 VAC.
Haven't taken one apart yet. Maybe I should?

I think this is why everyone else has always excluded them along with the difficult experience of running an RC manually with a ball valve.

Have made slow progress and found there is no way with code to use the valve fully closed and opened signals as an interrupt. A 1 degree turn of the valve requires a pulse for around 35ms. The noise of the pulse in the close direction triggers the interrupt on every pulse.

On the bright side, as soon as the motor is stopped, doing a digital read of the pins provides true data, so I can pulse move the valve, stop, then read the signal state to see if we are fully opened or closed.  In the grand scheme of things, waiting up to 35ms for the pulse to finish to find out if we have reached a limit is no problem and the internal brain of the valve prevents movement beyond the range of the valve.

Maybe I have a faulty unit, since the interrupt on the fully opened side works perfectly, but i figure if i have a faulty unit, it may be common and i would rather not go through the process of adding a hardware debouncing circuit.

[wiifm]

I really had trouble trusting the limit switches on the Chinese 2 way ball valves also.  I don't have enough knowledge to wire up a hardware denounce circuit or two and read a heap about software debounce, then read some advice, which said an undebounced switch should not be used as an interrupt.

At least the limit switches on these things prevent the motor opening or closing past the limits without external action, so we can afford to not rely upon them.

My end decision, after two days of pulling my hair out, was to stop movement, wait 20ms for the noise to go away, then check the limit switch pin state.  This provides a reliable answer, but obviously makes the processor wait 20ms every time we want to check. 

To calculate the valve position, I wrote a calibrate function, which calls upon a binary search function to work out the time it takes to fully open the valve and fully close the valve and compare.  There may be something wrong with my code, but I have not found a difference between fully opening time and fully closing time during a calibration yet.  The time varies from calibration to calibration but the opening and closing time are the same on each calibration 

Once I know the time in ms to fully open the valve, I can fully close the valve, then from there, count all the time spent opening the valve and all the time closing the valve.  Total opening time minus total closing time = current position on the scale.

PS.  ShiFu, I hope you don't mind me continuing to post here.  Let me know if it is not useful.

[wiifm]

I edited my original post to include my sketch.

Now that you have a working debounce, I may take a look at your approach! 

[Eucyblues]

I edited my original post to include my sketch.

Now that you have a working debounce, I may take a look at your approach! 

By all means - you're welcome 

[Eucyblues]

Thought this was worthy of it's own topic so i've moved related posts from the needle valve topic to here

[Eucyblues]

Update on progress

1/ The eBay supplier has acknowledged that the wrong valve was sent (CR02) and will send another (CR05) - Now I just have to receive it

2/ In the meantime, I've been examining the CR02 and the L298N driver board

I had trouble initially with the driver boards (I have 2)  - thought I'd blown them on a number of occasions..

I tried them with first with an old transformer type 12v regulator which worked with the motor but wouldn't work when hooked to the driver boards

Then tried a switch mode 12v unit - same result

When I checked the open circuit output voltage it was only showing 6.5v for both regulators !?!

I googled and found a number of posts relating to low output voltage on these items and I was just about to hit the keyboard on eBay to say they were u/s when I tried out a larger multi V reg on 15v - Bingo - open circuit 15v showing on both boards - weird!!.

I hooked up the motor and away it went on 15v - Step 1 complete.

I thought I'd attach a buck converter before the driver board for 2 reasons..
a/ I didn't want to blow the 5v regulator on the board
b/ the speed of the DC motor is governed by the drive voltage so I wanted to select the output voltage on the driver board

I plugged it all in and set the driver board output voltage to 12.5v while the motor was running - the corresponding input voltage was about 13.5v - so only 1v lost through the board. - Step 2 complete

I wrote a sketch to cycle through speed ranges and found that the controller and motor combination won't work below about half speed - Full speed (255) open/close is about 4 secs -  step 3 complete

By much trial and error I determined that the ball travels through 12 degrees from fully closed to 'just-closed'.  This gave me a ball diameter of 24mm for a 15mm bore. This left 78 degrees of travel from 'just-closed' to fully open. - Step 4 complete

More trial and error and I had established a best low speed of 145 and a corresponding step time to achieve 1 degree movement increments.  - Major step 5 complete.

Tried various dance routines and noticed that when moving forward and backwards the same amounts, the ball stopped in different locations.  More investigation led me to conclude that the forward gears have a different ratio to the reverse!!.  Minor glitch overcome by changing the closesteptime.

Also noticed that the braking function will not work on this valve motor - obviously the controller interferes with it - won't accept HIGHs on both leads.  More checking required on this.

Because of inertia on 'coast' - stopping of large step angles was not precise - ie - 9 lots of 10 degrees overran the 90 degrees total.  The solution was to repeatedly step @ 1 degree intervals with a small pause in between. - Step 6 completed

Moved on from the test sketch and wrote one with interupts for Open and Close - stepping @ 1 degree intervals - works fine - The precision of steps is limited to integer values so it's a matter of juggling motor speed with steptimes to get the best fit.

Step 7 complete with the caveat that I'm not sure of the life of the relay in the motor using this approach - time will tell.  I could also halve the steptimes and jump in 1/2 degree steps but that's more load on the motor relay.  (It sounds like a mechanical relay).

So what happens now with the sketch:

1/ Power up, the valve does a full speed open and close, pauses, changes to low speed and then  opens to the 12 degree 'Just-Closed' mark. (note that with the CR02, there are no limit switches but a current sensing circuit, so to get a full open/close I just drive the motor long enough each way to ensure it's done, the circuit cuts the power at both ends)

2/  Interrupt waits for an open/close signal

In use, the degree control could be replaced by a small variable time step as the required opening will be governed by a PID routine and the inertia etc probably won't matter as the logic control will involve movements damped by the PID logic.

Anyway- that's future stuff - suffice to say that at this point the CR02 is a working option.

Next some maths to find out some proportional step openings and see how practical it would be to step by aperture proportion.  Probably won't correspond to proportional flow anyway as the pressure drop will vary.  Again in the end, with PID control we don't care what opening is chosen as long as the temp control can be achieved - too imprecise however and the PID might 'hunt' too much.

That's enough for now (some may say way too much  )   

I attach the sketch for those who are interested.

Cheers
Eb

[ShiFu]

I'd like to follow along with this.
Can't seem to find the valve cheaply here, the best that pops out is about $33.
Is this the right one?

[Eucyblues]

Glad to have you on-board ShiFu 

I bought this S/S one.  NB - BSP thread - not NPT

I ordered the CR05 wiring and received the CR02 - I think the CR05 is a CR02 with an added pair of limit switches but I'm not sure. 

wiifm has the CR05 and has been trying to use the limit switches with mixed success, but my reading of the blurb indicates that the CR05 will stop at open/close without using the limit switches which tells me they're probably the same current limit controller.  (wiifm please comment)

As I mentioned above - a replacement CR05 is (supposedly) being sent but the limit switches are not really necessary.

I'm thinking that what I'll do is hook the valve to a Nano powered from the driver board and use I2C to connect to the Disti.  It could be run as a one-way system (Disti->valve) or 2 way with valve position data being sent back.

The PID routine would be run by the Nano - so ABV and Head temp data is sent to the valve, and the PID does its stuff and controls the valve opening.   

[ShiFu]

No luck finding the CR05 and Aliexpress and Alibaba are not available to folks inside China, for some strange reason 
We can sometimes get around that by sending an email and asking them to list the item on Taobao  (Chinese eBay, kind of) but that doesn't always work.
Maybe Tan can ask the CR02 folks if they can source a CR05.
Heading out soon to see The Big Man Himself. Yep, Mickey Mouse at Hong Kong Disneyland. We have a business meeting in HK and while there we'll take in some sites.

See y'all again in a couple days.
And you behave while I'm gone. 

[wiifm]

wiifm has the CR05 and has been trying to use the limit switches with mixed success, but my reading of the blurb indicates that the CR05 will stop at open/close without using the limit switches which tells me they're probably the same current limit controller.  (wiifm please comment)

yes it will stop at open close limits without external control

[law-of-ohms]

I love the direction we are going in this hobby.

Making what was once sky high priced industrial solutions for a nano of the price.

And the experimenting that go's with it

[Eucyblues]

Speaking of Nanos.....

More pleasing progress to report....

I now have 2 working test sketches :

1/ I2C valve control on a Nano
2/ I2C TX "remote" control on a Mega

The Nano has the full valve control workings, including local interrupts for:
a/ Initialise valve (fully open/fully close/ advance to 'just closed')
b/ Fully close valve (fully close/ advance to 'just closed')
b/ Fully open valve
c/ step close @ 1 degree inc
d/ step open @ 1 degree inc

The Mega can send the same interrupts remotely, as well as uploading deph temp and ABV floats to the Nano for independent processing via a PID routine (yet to be done).  The Mega stuff is intended to be incorporated into the Distillator.

So the intention is to have a box (120x120x90-ordered-hope it's big enough ) attached to the valve.  The box will house the following:
1/ Nano (powered from the driver board)
2/ Driver board
3/ Buck converter
Fitted to the box will be:
1/ Power supply socket
2/ Power switch
3/ I2C (3 wire) plug (extra wire for common earth)
4/ Slider switch (manual/PID control)
5/ 4x momentary push buttons (if they all fit) for manual step control (O/C), fully close, fully open.

Now have to grapple with sending valve position back to the Mega

PS - My Nano runs exceedingly hot!!!  - I'll have to solder up another to check if it's normal..

     

[wiifm]

This MAY be of interest to you.  On another project i used a shield to gather data and they implemented serial over i2c.  there is some documentation and code here

[Eucyblues]

Thanks wiifm - I'll go thru the code

[wiifm]

I have made good progress over the past 24 hours.

I've now got a GitHub repository of a working Two way motorised ball valve class with some examples.  https://github.com/wiifm74/TwoWayMotorisedBallValve/

This allows us to create a TwoWayMotorisedBallValve object, tell it what variable to look at for it's set-point, along with pins for motor control and limit switches.

The begin() function calls a calibration routine (among other things) which fully opens and closes the valve several times and measures the time taken to do so.  From the averages of the times in each direction, it slows down the motor speed in the direction that is fastest, so that theoretically it should take the same time to fully open and fully close the valve.  It then uses the longer average as the full cycle time and gives a range of positions to target between 0 and cycleTime.

Limit switches work as interrupts (thanks to EB for his technique). It is a little messy since callback functions inside classes don't work the way some of might expect.  The trick is to use static functions and variables and the variables need to be declared in the sketch.

I am super happy with this as we can get fine resolution of the valve down to moving for 1ms in either direction.  Just in case the calculated position is out a little due to lots of movements, the limit switches reset the position to 0 at fully closed and cycleTime at fully opened.

There are no delay() s in the code except for limit switch debouncing so the processor is able to get on with things whilst the motor does it's job.

[Eucyblues]

Nice work wiifm  - very tidy code indeed

A different approach to mine - many ways to skin a cat, and I don't have limit switches (yet).

I hope you don't mind but i have a few questions/comments...
1/
When you say "There are no delay() s in the code except for limit switch debouncing so the processor is able to get on with things whilst the motor does it's job."... Looking at your random position sketch, it seems that you're constantly looping though the valve.update() function checking for elapsed time, so the processor can only get on and do other things provided it/they take less time than the setpoint time..
2/
And the fully open/ fully close functions have while loops which block until the limit switches are tripped 

Or am I missing something ?? ..It only matters if the routines are built into an eParrot which definitely will be busy on other things.

3/ in the FullyOpen/FullyClose loops, you're constantly running through motor(CLOSING)/(OPENING) which detaches/attaches interrupts, and sets the drive pins 
eg

Code: [Select]

long fullyClose() {

      unsigned long startTime, endTime;
      startTime = millis();

      while (!closeLimitReached) motor(CLOSING);

      endTime = millis();
      motor(STOPPED);

      return (long) (endTime - startTime);

    }

Because closeLimitReached and openLimitReached are volatile, the processor must constantly check the values so I think a null while loop may work (without a volatile variable, I think a null loop gets optimised out unless you have a delay(1) included)
eg:

Code: [Select]

long fullyClose() {

      unsigned long startTime, endTime;
      startTime = millis();
      motor(CLOSING);
      while (!closeLimitReached){}
      endTime = millis();
      motor(STOPPED);

      return (long) (endTime - startTime);

    }

The above will take the motor start operation out of the looping - still blocking though.

Cheers
Eb

[wiifm]

When you say "There are no delay() s in the code except for limit switch debouncing so the processor is able to get on with things whilst the motor does it's job."... Looking at your random position sketch, it seems that you're constantly looping though the valve.update() function checking for elapsed time, so the processor can only get on and do other things provided it/they take less time than the setpoint time..

This is just the class implementing it's own version of doFunctionAtInterval() with the interval set at 1ms.  Once it gets inside the check, if the conditions checked by the update function are the same as last time, it performs as few commands as possible, then gives control back to the loop of the sketch and waits it's turn in the loop queue. 

If the elapsed time of the processor doing other things causes the valve to overshoot the target position, the currentPosition calculation will cause the valve to reverse direction, then wait it's turn in the queue again. 

Even if you don't have a valve, or have a valve with no limit switches, replace the calibrate call in begin() with 'cycleTime = MAX_CYCLE;', then uncomment the Serial.print...  line around 130.  Start the Random example sketch and open up Serial Plotter. You can see at times, the valve overshoots the target position due to elapsed time in the loop and reverses.

When I say delay() s, I am specifically referring to the command delay(LENGTH_OF_DELAY); which does not give control back to the processor.

2/ And the fully open/ fully close functions have while loops which block until the limit switches are tripped  Or am I missing something ?? ..It only matters if the routines are built into an eParrot which definitely will be busy on other things.

I only wrote those two functions to be utilised outside the loop of the sketch (for the calibration obviously).  Let's say you wanted to do something different in the setup function of the sketch.  If they are used inside loop(), I would not use the update() function of the class (as in the Repeat_Full_Cycle example).
 

3/ in the FullyOpen/FullyClose loops, you're constantly running through motor(CLOSING)/(OPENING) which detaches/attaches interrupts, and sets the drive pins 
eg

Code: [Select]

long fullyClose() {

      unsigned long startTime, endTime;
      startTime = millis();

      while (!closeLimitReached) motor(CLOSING);

      endTime = millis();
      motor(STOPPED);

      return (long) (endTime - startTime);

    }

Because closeLimitReached and openLimitReached are volatile, the processor must constantly check the values so I think a null while loop may work (without a volatile variable, I think a null loop gets optimised out unless you have a delay(1) included)
eg:

Code: [Select]

long fullyClose() {

      unsigned long startTime, endTime;
      startTime = millis();
      motor(CLOSING);
      while (!closeLimitReached){}
      endTime = millis();
      motor(STOPPED);

      return (long) (endTime - startTime);

    }

The above will take the motor start operation out of the looping - still blocking though.

Thanks for looking through so closely.  I will change those functions. I didn't pay too much attention to the implications of calling motor() in a loop.  Your solution is better.  Thanks!

[wiifm]

By the way, all the detachInterrupt and attachInterrupt calls are because the close limit switch on my valve is SO BLOODY NOISY!  By detaching the interrupt, I only have to deal with the noise in the direction that is important.

[Eucyblues]

OK - So is this correct: (I haven't tried the actual sketch yet - just looking at the logic)

If you only want to move say 124ms (that's 2 degrees on mine) - the following happens

1/setpoint changed
2/callback calls update @ max 200m/s (your setting) (assume setpoint set @ the start of the 3/callback timing for this example and assuming zero time taken on calls)
4/update sets motor going and returns to loop()
5/valve motor passes setpoint by 76m/s before callback calls update again
6/update reverses the motor to attempt to get to the setpoint and returns to loop
7/motor passes the setpoint by 134m/s in reverse direction before update called again
8/update forwards the motor again and returns to loop
9/motor passes setpoint by 66ms
10/etc etc

The same would presumably happen for longer periods on the 'remnant' overflow ??, and the overshoot will depend on the callback period