Digital In: Paddlewheel Flow Sensor, Total & GPM

[Mark 0]

Any sample code or guidance is appreciated. Micrologix 1100 (1763-L16BWA) GF Signet Model #3-2536-P1 Flow rate sensor The sensor is to have a square wave output allowing connection to a 24VDC discrete input. The sensor is wired as open collector with a 10K ohm pull up resistor to I:0\0. Interested in GPM and TOTAL FLOW. Thanks. -mark Edited 28 Aug 2007 by Mark

[TimWilborne 108]

Which inputs are you using? 0 and 1 are you HSC inputs. How fast will the pulses be coming from the paddle wheel?

[Bob O 8]

I know this isn't you model but thought it maybe be of some help. I am using the 2540 Signet flow switch to an ML1100 and wire Blk 24VDC, Silver 0VDC and red to my input I/0. I am not using any pullup resistor and have had no problems. I would post my .rss but I am cleaning up the office and have past all this along since I am starting a new job on Monday. Hope this helps, Bob

[finfin 0]

It looks like 15 Hz per ft/s nominal at up to 20 ft./s .... That comes to 300 cycles per second. What are the HSC inputs good to, TWControls? Edited 23 Aug 2007 by finfin

[Bob O 8]

Here is a page out of the manual... HSC_info_for_ML1100.pdf

[Mark 0]

How do you make these conversions? My application are for two paddle flow meters. One is a 8" pipe to meet a specification of 800 GPM. Second is a 6" pipe to meet a specification of 450 GPM. I found conversions online that tell me the above GPM's come out to 5 Feet\Second. What I am missing is how many pulses is the input going to see at these rates? I'll call the vendor, GF Signet, as they gave me an example for a 1" pipe = 50 GPM = 20ft\sec. ...actually, just looking at the spec. sheet it says "Frequency: 15 Hz per ft/s nominal" So, with the conversions this is 5 ft\sec x 15 ft\sec = 75 pulses every second. The ML1100 (1763L16BWA) has four high-speed inputs with an operating frequency of 0 Hz...20kHz; this should work. Edited 28 Aug 2007 by Mark

[Mark 0]

Is there a way to change the title of this post? I think it may be better to read Digital In: vice Analog In: I am trying to break this task down into small parts and build by starting with counting the pulses from the flow meter and putting them in one long integer file. Please comment on the attached. Will it work? Flow_Pulse_Counting.RSS Edited 28 Aug 2007 by Mark

[TimWilborne 108]

This code will do the same thing and is much cleaner. I don't quite understand the thread title you requested but I changed it also FLOW_PULSE_COUNTING.RSS

[Mark 0]

holy cow, I've got lots to learn...simple and clean code is the goal the title I am proposing is "Digital In: Paddlewheel Flow Sensor, Total & GPM

[TimWilborne 108]

What is the ultimate goal of your paddle wheel? Are you trying to adjust certain parameters based off of flow or are you trying to pump X amount of a substance through the paddle wheel? Also, changed the title again

[Mark 0]

1. Display Total Volume of water passed for maintenance. 2. Display water Flow in GPM. 3. If water flow greater than 450 GPM, turn valves on for a second tank. Working with GF Signet I discovered: 'A' Factor x Frequency = GPM or GPM/'A' Factor= Frequency (# of pulses) 'A' Factor = 60 / 'K' Factor 'K' Factor = 8.325 (this is the value for a 6" Schedule 80 pipe; I have no idea where to get this value for an 8" pipe) so...60 / 8.325 = 7.207 example: 100 GPM / 7.207 = 13.87 Hz What's next I think is to how much time has passed for the number of pulses received. I read somewhere that tracking the scan time would be most accurate. For algorithms: # pulses x 7.207 = Total Gallons Total Gallons / Total Scan Time (minutes) = GPM Edited 29 Aug 2007 by Mark

[TimWilborne 108]

Where did you get the 8.325? http://www.gfsignet.com/products/pdf/2540eng.pdf Going off of plastic schedule 80 pipe I'm getting that 6"=11.041 and 8" = 6.2877 60/11.041=5.43 A Factor for 6" pipe 60/6.2877=9.54 A Factor for 8" pipe Maximum Frequency of 6" pipe = 450/5.43 = 82.87 hz Maximum Frequency of 8" pipe = 800/9.54 = 83.86 hz This is where my concern comes in. You method is scan time dependent. and a pulse will be coming in at a maximum rate of roughly 12ms for both the 6" and 8" pipe. While this is doable with this ladder method is is on the edge depending on the scan time of your program Let's revisit an earlier question Can you verify the maximum frequency of pulses coming from the paddle wheels?

[Mark 0]

Don't the calculations above show the max. pulses coming in at roughly 56-58 Hz? Wouldn't that be around every 18 mSec? GF_Signet_2536eng.pdf Edited 29 Aug 2007 by Mark

[TConnolly 13]

Mark, Tim, I noticed that neither one of your programs had done this: For best results open the IO configuration, double click on the PLC base unit, Select the Embedded IO configuraiton tab, and configure the paddlwheel input as a rising edge latch. This way you won't miss pulses and you also won't need any one shots. See the instruction set reference manual section on latching inputs under IO configuraiton for more information.

[TimWilborne 108]

Never used that before Alaric. Good point, I will have to play with that

[TimWilborne 108]

BTW, I did forget to insert an ONS in my program. If you don't us Alaric's method then it will need an ONS. 18ms is doable with this method if your program isn't too large

[Mark 0]

Thanks for pointing that out Alaric, seems like you've had experience where this was helpful. Looks like the 'K' and 'A' factors are set. Here are my adjusted algorithms: (6" Pipe) # pulses x 7.979 = Total Gallons (8" Pipe) # pulses x 13.825 = Total Gallons Total Gallons / Total Scan Time (minutes) = GPM Calculating Flow per Second is the reference I mentioned earlier. It's understood being from an analog input. Ladder Logic attached: Any concerns in algorithm or using all Long Integers? For testing: would a (18mSec) timer instruction work? FLOW_PULSE_COUNTING.RSS Edited 29 Aug 2007 by Mark

[TimWilborne 108]

You need to use floating numbers to do your GPM calcuations. That is causing your error in rung 1 and you are loosing accuracy. Take L16:0 and MOV it to F8:0 then use F8:X in place of L16:X the rest of the way. I don't think the scan time method is going to work unless your are looking for the average GPM through the day. Not much time to explain right now but I would just take the current L16:0 and MOV it to another L number every X time increments. Then subtract the two values during every time interval and divid by the time constant. I'll try to post later or maybe someone else can pick this up.

[TConnolly 13]

I see another potential issue looming here - its probably not really a problem for the process, but its something you should be aware of. While your PLC can represent some very large numbers using floating point numbers, it does not repreent them very precisely. Try adding 1.0 to 16,777,216 Your PLC is going to give you 16,777,216 as the answer, not 16,777,217. Thats because values greater than 2^24 must loose resolution in the one's column.. As your number gets even bigger you loose resolution in the ten column, and the hundreds column, etc. This is because of the way the computer has to store floating point numbers. 32 bit long integers can help solve this problem because you can count by ones to over 2 billion. But that isn't still going to help you too much here. At your maximum frequency you gave above (~58hz) you will count a little over five millionn pulses a day. No problem there with a long integer. But when you multiply that by 7.979 then you get a number that is close to 40 million. That means that your tens column is the limit of significan digits. IE, you can't say that you delivered 39,984,346.8 gallons of product in a day, the best you can say is that it was 39,984,340 gallons. And if you try to multiply your long by 7979 then you will get integer overflow in the 32 bit long. So if resolution becomes an issue then you will need to reset your values more often than daily or use some unit other than gallons such as cubic feet or cubic meters. And none of this takes into account the overall accuracy of your paddle wheel yet. 99% of the time it doesn't matter, but you should still be aware of the potential issues.

[TConnolly 13]

Mark, I took a look at the last code you posted and I see a few problems. First, you aren't totalizing scan times. S:3 is the watchdog time setting in 10 millisecond units. S:35 is the time from the last scan in 100 microsecond units. Second, the value in S:35 isn't the exact scan time, its rounded up to the next 100 micro-second unit. If you are totalzing this every scan then after just a couple of minutes you will be significantly off, totalizing more time than has actually passed. Third, L16:11 will always be greater than L16:1 because L16:1 can at most increase by one count per scan, while L16:11 will increase by multiple counts per scan depending on what your real scan time is in 100 microsecond units. Since you are doing integer division the result in L16:20 can only be a 1 (when rounding up) or 0 (which will be the case almost all of the time) Take a look at the attached for a different way to do it. I see you configured the input to latch short pulses. Thats good. It will help as long as your scan time is faster than your pulse rate, preferably more than twice the pulse rate. Are you sure you are supposed to multiply by 7.979 as opposed to dividing.? Multiplying means each pulse represent almost 8 gallons, and that doesn't seem right for a six inch pipe. At the 58hz you mentioned earlier that means over 460 gallons per second - I find that very hard to believe. In the attached I followed through with the multiplication, but I don't think its right. Recheck. EDIT: I have amended the program to divide instead of multiply. See post # 22 in this same thread. FLOW_PULSE_COUNTING_4.RSS Edited 29 Aug 2007 by Alaric

[Ken Moore 23]

I agree with Alaric, your numbers don't seem right. Looking back through the thread, I think you might have use 450gpm and 800 gpm. So these valves are in gallons per minute, while Hertz is per second. So...I think your calculations are off by a factor of 60, if so these should be closer: Maximum Frequency of 6" pipe = (450/60)/7.98 = 0.93985 Hz Maximum Frequency of 8" pipe = (800/60)/13.82 = 0.96479 Hz

[TConnolly 13]

From the data sheet you attached: So you need to divide. I recommend you write this thing out on a sheet of paper with the units involved so that you can keep track of pulses, gallons, and minutes and seconds. When converting from one unit to the next if all units except the one you want in your answer don't cancel out then you don't have it set up right.

[Mark 0]

The file: FLOW_PULSE_COUNTING_4.RSS when verified comes up with the ERROR: Operand sizes do not match! Apparently it doesn't like to go from a Long Integer to a Floating Point. Looking on the Knowledge base I found tech note 19396 but it takes two integer values...looking for more info EDIT: I see that adding the MOV instruction will work before the DIV instruction. Also reversed L16:0 and L16:1 to avoid negative numbers. Edited 13 Sep 2007 by Mark

[TConnolly 13]

That's odd, a MOV works but a DIV doesn't. I'll bet there is some kind of functional issue with the compiler, because if it can type cast with a MOV instruction it should be able to type cast with a DIV. I'll wager that its somthing they missed adding to the compiler when they added the L data type. Other than that, how does it seem to be working? Edited 13 Sep 2007 by Alaric

[Mark 0]

It's working pretty good so far. I am moving onto stepping through the mode sequence portion now and will get back to this later. thanx for your help