Modicon gpm to bpd totalizer

tla_loc

Member
Join Date
Jan 2015
Location
California
Posts
3
Hello all,


I am working on a Modicon plc using Proworx32. What I am trying to accomplish is take a reading that is coming in gpm and convert it to bpd and then totalize it. I have tried several things but its not working.


Thanks in advance.
 
Woah, slow down. You can't just use random units!
Gallons per minute?
Barrels per day?
Is this for a US client or UK, where they use two very different definitions of the word gallon?
And what kind of barrels? Different industries and different products use different definitions. Beer barrels? Oil barrels?
Do you have 64bit math in your PLC?
So many questions!

Secretly hoping it's grapes per meter and barrels of wine!

Welcome to the forum! It's Sunday night here, so please don't take my post too harshly. Genuinely need to know those things.
 
Using Quantum 434, prom rev. 2.20, kernel rev. 0110. I have checked the instrument, communication path, values at the instrument and in the plc. They match. The equation being used:



US units, (Oil GPM*1440)/42=BPD, Sampled per second, if (BPD/86400)>0 add BPD/s to previous BPD/s, Move total value to day 1 at midnight and zero current day BPD/s.


Using

EMTH 20 to Multiply GPM*1440
EMTH 21 to Divide GPM/42
T1.0 at 1 sec and ONS to sample BPD
EMTH 21 to Divide BPD/86400
EMTH 18 to Add BPD/s + previous BPD/s = previous BPD/s
FTOI to convert previous BPD/s float to integer
SUB Block to move integer to current day
ONS to move totals to different days at a set time and clear current day and previous BPD


I have also tried to removing the GPM to BPD steps in the calculation above and just multiplied gpm by 0.0003968 barrels per second and by 34.2857 barrels per day not at the same time.


The moves and zeroing happen fine. The problem lies in the conversion/data handling. The totals at the end of the day are five to six times bigger than expected. I may be overlooking something obvious.




AustralIan you crack me up! Now im bummed because its not wine!
 
Last edited:
I'd try totalizing GPM in the same units as the instrument uses, get that right first, and then convert the units to BPD with the GPM totalization result.

You need to be sure that your one second interval is as close to one second as possible. There are issues with rounding off when using Floating Point math that can become a problem when you totalize large numbers, and that's been addressed in several existing threads. That doesn't seem to be your problem, or you'd be coming up short, which you apparently aren't.
 
Do you have multiple rows of maths instructions on the same network?

A while back i was trying to do some maths in proworx and could not get the result i was expecting.

I later remembered how proworx scans the networks : top to bottom, left to right.

I had placed 2 rows of instructions on the same network reading left to right. Occupying rows 1 to 3, 4 to 6.

As the plc scanned this it was completing the maths in the wrong order (to me, but in the correct scan order).

I later put the second row of maths instructions on a seperate network and proworx was then scanning the instructions in my correct order. I then go the result i was expecting.

Maybe your instruction order is different to the actual proworx scan order.
 
Assuming you want a "standard" 42-gallon barrel, 1 gallon per minute = 34.286 barrel per day. Multiply your flow meter reading by 34.286 (or whatever level of precision you need) to get the answer in preferred units. That should be one rung of ladder logic with one instruction.

These are simple algebra equations to convert units.
24hrs/day x 60 min/hour x 1 gal/42 barrels = 34.286

https://aoghs.org/transportation/history-of-the-42-gallon-oil-barrel/
 
Now I'm no MODICON proworx expert, but are you sure your timer is limiting the EMTH 18 to every second?
Some PLCs have the rung condition out of a timer equal to the rung condition in of the timer. You have to reference the timer.dn bit elsewhere in your code.
Is it definitely 1 second? Some PLCs ask for the time in decimal, but it is actually in tenths of a second.
Other thing is your gallons/min could be M3/hr or something. Can you confirm the gpm reading is what you expect?
Do you have a link to the instruction set reference manual for this specific PLC?

Also, your floating point totalizer is totally terrible! (Although not terrible enough to be out by x6)
A float has 6 digits of precision.
86400 is 5 Digits.
So you could be out by 10% when you get towards the end of the day.
What precision is your gpm? Let's assume 15bit.
86400 x 32767 = 2,831,068,800. This fits into a 32 bit unsigned integer without any loss of precision. I'd go with that over floats for totalizers. You the convert to float (and then correct units) only for display and at the end of the day.
(Note that 64bit floats have 15 digits of precision, so these can also be totalizers, but a bit harder to calculate)
 
I haven't looked over your math in too much detail, and other commenters have you covered on the limitations of floating points (and have suitably chastised you for not using the metric system), so I'll leave all those point aside and just throw out one piece of information that I learned that hard way about Modicon PLC's and Proworx 32, in case it's contributing to your problem.

The logic is solved vertically, not horizontally.

Yes, really.

Code:
|      +-------+      +-------+      +-------+      +-------+
|------|  ADD  |------|  ADD  |------|  ADD  |------|  ADD  |
|      |       |      |       |      |       |      |       |
|      |       |      |       |      |       |      |       |
|      +-------+      +-------+      +-------+      +-------+
|

|      +-------+      +-------+      +-------+      +-------+
|------|  SUB  |------|  SUB  |------|  SUB  |------|  SUB  |
|      |       |      |       |      |       |      |       |
|      |       |      |       |      |       |      |       |
|      +-------+      +-------+      +-------+      +-------+
|

|      +-------+      +-------+      +-------+      +-------+
|------|  MUL  |------|  MUL  |------|  MUL  |------|  MUL  |
|      |       |      |       |      |       |      |       |
|      |       |      |       |      |       |      |       |
|      +-------+      +-------+      +-------+      +-------+
If the above code were any other PLC, it would execute all four ADD instructions, then all four SUB instructions, then all four MUL instructions.

In a Modicon PLC, it'll execute the first ADD, then the first SUB, then the first MUL, then the second ADD, SUB, and MUL, and so on. This can completely mess up your calculations if you put your blocks in the wrong place on the screen. It gets even more complicated if you have regular conditional contacts in series, because they're still connected left-to-right as you'd expect. So once they're executed and determined to have a true or false output, the PLC trots off to the next line to see what else is happening, before returning to determine what to do with the aforementioned true-or-false condition that it worked out a couple of ticks ago.

Once I found out about this "feature", I started doing all my math like this:
Code:
|      +-------+      
|------|  ADD  |
|      |       |
|      |       |
|      +-------+
|
|                     +-------+
|---------------------|  SUB  |
|                     |       |
|                     |       |
|                     +-------+
|
|                                    +-------+
|------------------------------------|  MUL  |
|                                    |       |
|                                    |       |
|                                    +-------+
|
 
ASF said:
Once I found out about this "feature", I started doing all my math like this:
This doesn't make me cry at all.

Whelp, looks like with all the help our good new friend loc has received there should be a solution. Please come back and tell us what solved it in the end.
 
This doesn't make me cry at all.
I clearly remember the moment I worked it out. I just sagged in my chair staring blankly at the screen, wondering how in the name of all that is good and holy somebody thought that solving logic vertically was a good idea.

Another thing about the Modicon PLC's that definitely doesn't make me cry at all is that they don't use zero-based addressing. Their inputs go from 1-32, not 0-31. Definitely no tears when packing binary data into words for transmission to a different platform.
 
I clearly remember the moment I worked it out. I just sagged in my chair staring blankly at the screen, wondering how in the name of all that is good and holy somebody thought that solving logic vertically was a good idea.

LOL. I remember this moment as well only I buried my head I'm my hands thinking WTF.
 
Almost all flow meters that I have worked with have a "Pulse Output" and this can be programmed to be gal/barrels/liters whatever you need. Then just count the pulses for whatever time frame you work with.
 

Similar Topics

Hello All, Was hoping I could get a little help with Modicon ladder logic. This is the first time I have seen Modicon logic and currently trying...
Replies
6
Views
257
I have a 170AAO92100 card that I am interested in using as a 10 volt output. Is there setup that I have to do in order to change output or simply...
Replies
0
Views
84
Hi, Seeking consultation on an implementation matter, and have a question about Modicon Compact 984 communication through RS485: Three Modicon...
Replies
4
Views
210
After updating a panel, I inherited another PLC for my "learning lab". It's a Modicon TSX Micro. I've not worked with a Modicon PLC yet, so I...
Replies
1
Views
128
I have an old PLC (circa 2007) consisting of Telemecanique/Modicon/Schneider Electric devices. The system has developed errors and unfortunately...
Replies
2
Views
228
Back
Top Bottom