totalizer to GPM

[hotwires]

Community,

I'm experimenting with a program where I need to convert a pulsed flow meter signal into GPM. No big deal, right?! Here's the catch: the turbine style flowmeter is calibrated at 1 pulse per gallon. The well flows right around 60 GPM 24/7. There is a self contained totalizer at the site now that is "jittery" in it's GPM indications. I already know all the ways I could count pulse or measure frequency and factor my way to GPM. With a range of 0 to 100 GPM at  1 pulse/gallon what is the best way? The shorter the sampling period the higher the multiplication factor and the poorer the instantaneous resolution becomes. A 1000mS sampling with about a pulse per second has a resolution of nearly plus/minus 60 GPM ? which is not so useful. Doubt that changing the flow meter to a unit with pulsed and 4 to 20 mA is in the cards. I have a feeling I have answered my own question already with the laws of physics. Any comments, ideas, or remarks are welcome.

Sincerely,

-HW

[Ausman]

Hi Hot,

could you add some more "lobes" to the turbine?  Might be simpler than you think.  Is it Hall or something else?

If I've read you right, are you doing the maths backwards?  Think laterally and set it up based on a quick counter that has the count stored and reset to 0 each pulse.  Then do the instantaneous maths on the stored count, and that is either close to/exactly current rate.  Don't compare it to a fixed time.   I've mentioned before that I think counters are an under-utilised item.  Often they outperform timers in a myriad of ways.

cheers,

Aus

[hotwires]

i believe what you are suggesting paralells my idea of measuring the "period" (time between pulses) and using math to equate to flow rate. the most instantaneous and accurate possible measurement is the time between two pulses, which would vary proportionately from 0 ms (0 GPM) to 1000mS at 60 GPM.  haven't had the flowmeter cap detached yet. 1 PPS is great for a totalizer but not so great for instantaneous flow rate. I started in the frequency counter mindset, count pulses for defined sample interval. that leads me to a 60 second sample being required to get 1.0 gallon resolution. frequency i'm trying to measure is to low for that approach. 

using the counter method: wouldn't the scan time be a factor in the rate of incrementation? one PTC would latch a contact to a counter and the next would release it, then store that counters value, and reset it? I'm assuming (perhaps incorrectely) that the pulse duration is constant, only the time between pulses changes with flow rate. But the more I think about it: if it's a magnet on a rotating disc then velocity would affect pulse ON time duration. Haven't examined the mechanics of the meter.... so not sure.  read the help (and hardware installation diagrams) on the vision HSC. For some reason I'm not making the connection on how I use the in0 and in1 as a reset when I only have one pulsing line from meter. 

[Ausman]

Unless the turbine is a very big diameter and the sense is minute in it's arc, I don't think you will have problems using normal DIs on such a slow Hz rate.  I wouldn't be bothering with HSC, but the only way to know for sure is to try it using the plc to measure On time, which wouldn't be that hard to set up.  (But my impression of you is I'd bet you have an oscilloscope handy!)  The following paragraph is helpful for this, too.

As for the counter, have a squiz at the 1.25 & 2.5mS Interrupt Routine descriptions, found in Interrupt in Index.  This should easily give you enough accuracy for what I was suggesting.

And the number of "lobes"/"magnets"/"little men shouting "OYYY" as they go past" increase??      "Haven't examined the mechanics"??    Huh!  What have you been doing all this time?  All things relating to the forum must be acted on immediately!  Cara said so.

cheers,

Aus

[hotwires]

A Tektronix 422, how ever did you know! Very compact scope back in it's day. Still works great.

Never used interrupts on a PLC, kudos for the inspiration!

I'll have to go spend some time in a pumphouse to examine the flowmeter, I don't have it's twin on my office desk  Just did a walk thru a few days ago to see what all client had to work with and wanted to see in an automation solution

[Ausman]

And you don't need the counter to be run via a latch.  Have it just banging away all the time the flowmeter is meant to be running.  You then have upper and lower limits on the count that are your alarm points.  In some instances, I also build in X numbers of self-correction, in case of a gliche.  ie it goes outside the alarm points, alarm counter gets one addition, counter gets reset to 0, process repeats X times.  If it turns out to be a temporary thing, I store the error date/time and reset the X error count to 0.  If it goes over X, it is a real issue and a stop/warning is needed.  There are myriad variations on this concept to suit the particular job.

It all comes under the guise of you initially write a program in the logical way, then look at it later and realise you can simplify/improve things all over the place!  Many, many times I have uttered words like "why didn't I do that in the first place....what a dummy!"

cheers, Aus

[hotwires]

thinking about how it will need to handle a zero flow condition. the count would just keep running depending on where the disc stops and in what state. that's where limit setpoints come in. not exactly simple, but as the saying goes: "if it was easy anyone could do it!"

[Joe Tauser]

You should be using positive transitionals to sense your pulses (even in an interrupt) so it doesn't matter if zero flow occurs.

Joe t.

[hotwires]

i use ptc for totalizer counters. I'm new to the pulse to gpm conversion with (relatively) real time updates. I took the freq counter logical approach but quickly found anything less than a 60 sec sample wasn't gonna be accurate down to the gallon. I seen in one of the examples where they use an output on plc to simulate pulses. I'll have to try that out. don't think my analog function generator will go low enough, 1 Hz would be 60 gpm. i've got a plc on my bench to play with but not the meter. i'm pre planning this project, no trigger pull on it yet. anytime I learn something new it's not time wasted. all prior flow meters I've worked with have had a 4-20mA gpm scaled output and programmable pulse:gallon ratio (and pulse duration).

[Ausman]

So you don't have a way of knowing if the flow is meant to be going or not?  The turbine is the only thing?  In that case you would still have a high limit on the count that if exceeded still got reset to 0, and your result would read "currently less than .01 GPM" or whatever that high limit = minimum flow maths result is.  The main method is still the same, when the turbine's pulse goes high the count is stored and then reset to 0.  By applying correct maths on the stored count you get the correct current GPM  if it trips over before the maximum count/minimum flow rate is reached.

cheers,

Aus

[hotwires]

The pump runs 24/7. So demand bit wouldn't be a useful zero signaling bit. Zero flow would only occur during power failure (which could be detected) or: pump failure, pump sucking air, discharge side occlusion, flow meter failure, unauthorized valve closure  between disharge side and meter input flange.  I'm sure there are a few possible conditions I've missed. My approach for testing logic is to present every possible set of conditions and then observe results, then ask: Is this what I wanted to happened? 

[Ausman]

So is the pump centrifugal , or positive displacement?  If you have a centrifugal running at zero flow you've got a problem regardless...say goodbye to the seal in no time.  If they're running dry it's quickly ta ta, but if they are running full without output then they get cooked.  Positive displacement not so much.  For all the other things you want to monitor, it can still all come back to whether the pump is being called for and what the flow is.  You say it is normally 60gpm, so the real question is what causes the variations from this normal rate, and how much does it normally vary.   Those are the crucial questions and answers.  Anything outside those amounts is an error.

And further to the use of the interrupt, I was meaning for it only to be used to advance the counter by 1 every interrupt cycle.  It is doing nothing else, the normal program does the rest of the calculations.  You could likely get more accuracy by involving IO immediate updates in the main program as well, but it may not make that much of a difference.  The program looks simple so isn't going to be too big and hence a long scan time.

cheers,

Aus

[Joe Tauser]

Don't get hung up on a 1000 ms sample rate or even trying to use an interrupt.

Your pulses are only coming once every second at your normal flow rate.  This is going to limit your update time; your screen update is going to be slow.  It would be much better if you could get 10 pulses per gallon, which is not unusual.  

You need to create a sliding time window where you totalize the pulses coming in for a time - say 10 seconds, and multiply the count by 6 to project the GPM based on that time.   I think you're having a hard time wrapping your head around this because you're trying to get instantaneous analog-style indication from a pulse train, which at best is going to be choppy..

The closest you will be able to get is your idea of measuring the period between pulses, which will give you an approximate 1 second update.  If you don't see a pulse for some time period then force it to zero and have your code wait until pulses start coming in again.

If you want to simulate the input to your code use a self-resetting timer with the preset on the display to generate the pulses.  Then you can easily play with pulse occurrence rates and how your code responds to them.  Stop theorizing and start playing.

Joe T.

[Ausman]

To clarify things that are being misinterpreted, I experimented and have my example of how to do it.  This was run on a V130 with the latest firmware.  It is the basics of everything you would need, and really is very simple once I got there.  It gives the "immediate" flow rate between the last sense and the one before that, like I have previously suggested.  I used the 2.5ms count for simplicity and the ability to run on older units.  Edit: oops, wrong number in the vlp, changed it to correct.

cheers,    Aus

 

Pumpexample2.vlp

[hotwires]

11 hours ago, Ausman said:

To clarify things that are being misinterpreted, I experimented and have my example of how to do it.  This was run on a V130 with the latest firmware.  It is the basics of everything you would need, and really is very simple once I got there.  It gives the "immediate" flow rate between the last sense and the one before that, like I have previously suggested.  I used the 2.5ms count for simplicity and the ability to run on older units.  Edit: oops, wrong number in the vlp, changed it to correct.

cheers,    Aus

 

Pumpexample2.vlp

Aus,

 

Thank you for the .vlp, I'll try it in my "R&D" Samba 4.3"

This may be a silly question: Does the subroutine: "_Interrupt 2.5 mS" have to be called in the main routine? Or does the _ make it run irregardless? The project optimizer flags it however after reading the help section it appears the name makes it run without a call.

Looks like the theoretical resolution would be 0.15 GPM    That will be more than sufficient!

Is an SM43-J considered an enhanced Vision on NOT?

Love the simplicity of your program!!! I'll be honest, my conceptual approach was a bit more complicated. Simple is good.

Thanks,

HW

 

Edited March 27, 2017 by hotwires

[Ausman]

Well, compile returns no errors at my end, under 9.8.31.  And I suggest you actually run it to learn the capabilities.  The layout should remain as is, see the help files previously mentioned.  As far as I know, anything with a colour screen is Enhanced.

cheers,

Aus

[hotwires]

correct, no comilper error. Just project optimizer. Hope to try it tonight live in the OPLC. 

[Ausman]

Re optimise, don't know why that shows.  Bug--Saragini?

cheers,

Aus

[hotwires]

It's doesn't prevent download, just states that the subroutine is not called, optimizer logic is not recognizing that the _interrupt is "self called". Program works. I added a comparator to zeroize stored count if 2.5mS counter exceeds 24,000 (less than 1 GPM). The update time and flow rate are directly proportional. cruises along nicely near 60 GPM. 2 GPM update time 30 sec, 1 GPM: 60 sec. that's the laws mathematics at work. Works better than counting pulses for a 60 sec interval for every sample. Thanks All

[Cara Bereck Levy]

On 3/27/2017 at 6:46 PM, hotwires said:

Is an SM43-J considered an enhanced Vision on NOT?

Yes- absolutely. I double-checked with the appropriate real-time guru (guru-ette? ) regarding interrupts. and yes, Enhanced indeed!

This is a fascinating thread! If you have direct questions/requests for me, please, please tag me or something -  I'm not following threads as closely as I like because the upcoming version release and elevendy other things are keeping me very busy.

[Cara Bereck Levy]

Someone mentioned a bug--I didn't follow. Can you please describe it for me so I can pass it on?

 

[AlexUT]

Hi all,

Just remark on Interrupt routines.

Newer call it from Ladder.

1.25 mSec and 2.5 mSec interrupt routines are activated from OS.

HSI interrupt routines activated, if HSI is configured as HSC with reload, when reload enabled, and when counter being reloaded (reached target).

B.R.

[Ausman]

Hi Alex, I'm a bit confused now.  Have you looked at my pumpexample2.vlp above?  The interrupt is done as specced by the Help files, and works fine.  Is there another way they should be done?

cheers,

Aus

[hotwires]

Program works in SM43. I'm NOT calling the interrupt subroutine. I'm just saying that the project optimizer is not "self aware" that "_interrupt" doesn't need to be called. No harm done. It could be a source of confusion for someone who always runs the project optimizer and follow it's advice. 

[AlexUT]

Hi,

Ausman, I not criticized your example.

I mentioned that Interrupt Routines should be defined/created to use it.

But do not required to call it from any Ladder code..

B.R.