ControLogix Flow Totaliser

tgoulding

Member
Join Date
Jan 2005
Posts
84
We have an L61 Contrologix processor communicating with a PLC5 remote rack via a DHRIO card. The remote rack has some 1771-IFE analog cards taking mA signals from various flow meters. We are trying to integrate some of the flow signals as pulse outputs are not available, see code below;

Clogix_Tot.gif


This code is based on code from a thread posted previously on this site. We are having two problems, a) there is a 7-8% approx error when compared to local totaliser even when using a constant input, b) the total values seem to stop when they get to 132,000 approx.

The totalisers are in array tags of real type, floating point. Has anybody tried to totalise analog signals in ControlLogix before and if so have they had similar problems. Is there a flaw in the way we are trying to achieve total values. Any suggestions would be appreciated.
 
I think, since you are considering the Scan time in your calculation for the totalised flow, it shall never match with the local Indicator. The reason behind this is the scan time and accuracy of CLX can not be compared with the local indicator. If still you want to match the values, then you need to go through the User Manual of the Local Indicator device to see its minimum update time (For scan rate) and also see the frequency of its update. It may possible that the local indicator calculates the flow from it's internal pulses based on time, so you need to match the sampling time in CLX program as well.
I hope, this helps as I have also faced similar problems at so many places and eventually sorted out by matching the scan times.
 
Use the totalizer function block placed in a periodic task. It works very well. Using a periodic task assures that the function is executed at a specific interval not affected by scan time.

If you must use ladder, use an intermediate register to total up to 1000 kg, then add 1000 to the main totalizer and subtract 1000 from the intermediate. I haven't tested floating point in ControlLogix, but in the PLC5 and SLC500, adding a very small floating point number to a large floating point number doesn't work as you might expect.
 
I have a couple of comments.

First, are you positive the local totalizer is right? Is it based on a pulse output, or is it totalizing from the analog signal you are using? Is the analog signal shared directly or is there a signal conditioner or such that may induce an error? Does the analog data in the PLC agree dead nuts with the analog indicator on the flow transmitter? Is the flow signal rock solid or is there drift, process fluctuations, or signal noise involved? Are you looking at mass flow or volumetric flow, and are there pressure and temperature fluctuations that can skew the relationship between them? Is there any filtering on the analog card that could impact instantaneous flow readings.

As Dave pointed out, the chances of having two different displays achieved by two different devices agree exactly range between poor and insignificant.

How important is accuracy? Is there custody transfer or regulatory compliance involved? Is this info only data provided so an opeator can compare performance one day to the next?

In many of the totalizer schemes here the scan time is used for totalizing. In your case, since the steam flow is going to be reasonably stable, I would suggest that you follow Alaric's suggestion and perform the totalization on a fixed periodic basis, say once every second or two. Most process fluctuations will cancel out. (In other words, the peak you miss between one set of calculations will undoubtedly be offset by a valley you miss in another set.) You have to judge how often to make the calculations based on your obeservation of the severity and frequency of flow rate changes.

Keep the task and objectives in perspective. After all, the cumulative error of meters, signal conditioners, displays, etc. is likely going to be approaching ±1%. 7% error seems a bit much, but don't expect to get exact answers.
 
OK I'll admit it, I was bit by this very same thing.

danny.michael is on the right track. If you use a floating point to hold your totalizer, at some point you will start to get inaccurate totals. If you keep on totalizing, you will eventually get to a point where the total stops increasing at all. This is due to floating point round off. The amount you are adding is so small relative to the large total, that the rounding off causes the total to increment erratically.

If you need to add very small amounts to a very large total, Danny's solution will work just fine. Basically it solves the problem by never letting the float that you add your just measured increment to get big enough to have a problem. You will have to determine how big that is for your situation.

However, I am surprised that you ran into this with a total at 132,000. You must be adding a VERY small amount each scan. I was adding a few gallons every .5 sec and I didn't run into trouble until I had over a million gallons accumulated (that took a long time). I solved my problem by just resetting the totalizer every time I used it instead of letting it run (bad idea on my part). That may work for you as well.

I definitely second what everyone else said about putting this into a periodic task. For all the reasons mentioned. It will also have the side effect of giving you larger and more regular increments to add than you are now using.

Also, since you are integrating a 4-20ma signal, I wouldn't expect much better than 1%.

Good luck,
 
When adding small values to floating point numbers you have a resolution limit to the float. For example, when adding 1.0 to a float, you can accurately add up to 16,277,215 (2^24). When adding 0.1 to a float, you can accurately add up to 2097152 (2^21), and when adding .01, you can add up to 262144 (2^18), and when adding .001, the limit is 32768 (2^15). If you want to count by millionths, you can count to 2^5, or just 32 (You should see the pattern here as long as you keep thinking in base 2).

This condition exists on all computers that use the IEEE 754 floating point format (which is most every computer on the planet) - so you will see it in the ControlLogix PLC as well. Computers using 64 bit IEEE 754 double floats even exhibit the same kind of behavior, although the resolution problem does not appear until you have much larger numbers.

(For more fun, try getting the exact number 0.010 in your PLC - it can not be done,the closest you can get is 9.9999998e-3 - Your display may round it, but that is the closest you really are - But thats another exercise although the cause is related to this issue)

If you run into problems of this nature when totalizing, I suggest you choose a different unit of measure. If measuring liters, then try cubic meters, if pounds, then try tons.

The reason for using a periodic task has been covered.
 
Last edited:
some more comments

How is the IFE module set up?
  • It can have optional on-board filtering
  • it can be set up for real-time sampling - not sure how this functions in CLX
  • how often are you executing the block tansfer?
  • minimum conversion time of the IFE is 25 msec (as I recall)
  • what is the span of the flow transmitter?
  • what is the operating range of flow vs span?
 
Last edited:
The nature of any totaliser is that it will always integrate minor errors so there will always be a discrepancy between the total on the instrument and the calculated total. The only way I have found to prevent this is to abandon the 4-20mA signal and use a pulse from the instrument as the PLC input. It is as easy to derive the rate from a pulse as it is to build a total from the analogue signal. Having said that I have found that the Logix 5000 totaliser function block seems to work much better than a "roll your own" solution. I am not sure why this should be but I suspect that that they use a more accurate timing method.

Andybr
 
Hi Tom,

Just to answer some of your questions. The local totaliser is on the flow transmitter we are taking the mA signal from. Hard to say if the analog data in the PLC agrees dead nuts with the analog indicator on the flow transmitter, but we are sure that they are a lot closer than the 7-8% error suggests. The flow signal is not rock solid, there are process fluctuations as this is on the main steam feed to a plant. There is no noise as all cables are well shielded and run seperately to power cables etc. filtering on the card is set to minimum.
It is not a custody transfer or regulatory compliance so 1-2% would be more than acceptable. This info will be used with other info to look and energy and other usage to specific areas of plant. If we can get reasonable consistant accuracy then it will remove the need to buy additional hardware, i.e. new flow transmitters, plc pulse cards.
Finally, as advised previously we used a fixed mA source input to analog card to test accuracy and found the same 7-8% error. This would lead me suspect the rounding issue as suggested by others in this post.
Again thanks for youe suggestions and help on this.
 
The TOT block is part of the L5K instruction set. However it is not supported in ladder - its only available in ST and FB - so if you only have Logix5000 standard you will need to get the extensions to support the additional languages. If you have the FB and ST extensions then create a new FB routine and drop a TOT block on it and give it a tag. If you are more comfortable with ladder then you can execute the actual TOT instruction stand alone in an FB subroutine but do all of the mainpulation of the TOT tag in a ladder that calls the FB routine with a JSR.
 
tgoulding said:
Hi Andybr,

You mentioned a Logix 5000 totaliser function block, where can one get their hands on this.


Create a new periodic task as mentioned above. Within that task create a new routine, in the type field select "function block diagram". If FBD is not an option you will need to upgrade your Logix5000 software. It looks like the lite, full, and pro editions support FBDs.
 

Similar Topics

Can someone tell me if this math function is correct to totalize analog flow in a 30 Milsec peridoc task...
Replies
3
Views
1,717
Can anyone confirm that using contrologix 5580 controller is not possible to work with powerflex 527? It's been a couple of days now that i am...
Replies
8
Views
1,145
Hello, I have a flow control PID that keeps locking up. It seems to control fine but after a while the output no longer moves. For instance...
Replies
4
Views
940
Hi everyone, I can't add any modules to the Controllogix backplane and it doesn't matter online or offline. Both is not working. Please see the...
Replies
13
Views
2,927
Hello, I have a question regarding the possibility of using messages instructions to communicate between: PLC5/80E Series D - CE Water Mark...
Replies
12
Views
3,024
Back
Top Bottom