Difference in steam flow totalizer value, Fatek PLC vs Redlion PAXP

AB2005

Member
Join Date
Nov 2006
Location
Lahore
Posts
318
Hi;


We installed an orifice plate type steam flow transmitter which configured to give 4-20mA signal correspond to 0-9ton.
I given that signal to a Redlion brand PAXP meter, having built-in totalizer function, to create a steam flow totalizer. The same signal i also connected with Fatek PLC's analog input module. In PLC, first i converted 4-20mA signal to get ton/h data. Then created a totalizer to add this value after one second clock pulse.


Problem is that, in daily steam usage reading, there is 2-5ton difference in between PLC and Redlion. Redlion value is always high.

In PLC, I used 1sec high speed timer to calculate the 4-20mA signal into "ton" then add this value in register after divided by 3600 within same PLC's scan.
 
Last edited:
There are many possible issues. Some of them are scan time and converting to float. We need more data. Maybe you should post the program.
 
There are many possible issues. Some of them are scan time and converting to float. We need more data. Maybe you should post the program.


Hi;


Please find the attached PLC program and check the Sub Program "HSTA". I used 1sec interrupt of built-in high speed timer to calculate steam flow rate and adding the value in totalizer.
 
I cannot open you file, so I am assuming you have a self resetting timer. Timers take at least one scan to reset, so your timer is going to be 1 scan slow, every one second, over a period of time, these 1 scan delays add up.

It would be best to have the totalizer in a one second task, or interrupt, that does not rely on a timer.

You can also set it up, where the timer never resets, and you use compares for the timing, with a modification of the timer values.
 
Do the PLC and Redlion totalizer values maintain a constant ratio throughout the day?

What are the ratios throughout the day? E.g. Can you plot the two numbers every hour, or half hour?

What datatype is the raw value that is coming into the PLC and into the Redlion?

I see you mentioned that you are using a 1s interrupt in the PLC to run the totalizer; is that the best timing standard there? What is the timing standard in the Redlion?

Is there any way to compare the clocks' accuracies?
 
Of what magnitude is the 2-5 ton error ? Is the RedLion total 10tpd? 50 tpd? 100tpd? 1,000 tpd? 10000tpd?
 
As other posters have indicated, although the timing may be a problem if the total per day is always out by a similar percentage then added to the timing any difference in the accuracy between the PLC conversion & what the redlion does will give an accumulated difference for example over 1 hour the difference might be 0.5 ton but in 10 hours 0.5 x 10 is 5 ton difference (not likely that much but it all adds up), best thing to do is check every half hour & if the difference in percentage stays similar then one of the scalings is wrong, however, also, the float conversion errors could be different on the two platforms, adjusting the scaling on the PLC may pull it back within reasonable limits, after all, how do you know if it is truly x tons /hr unless calibrated using a calibrated source.
 
Of what magnitude is the 2-5 ton error ? Is the RedLion total 10tpd? 50 tpd? 100tpd? 1,000 tpd? 10000tpd?

From OP, the range max is 9 ton/h, so over 24h, the max total possible is 216, so 2-5 tons difference over a day is 1-2%+ at a minimum.

With that magnitude of difference, it is unlikely to be caused by a difference in clock rate, whether the PLC is using the 1s interrupt or a repeating TON. A 1% oscillator difference would be nearly a quarter hour per day.

Also, accumulated error over 86400 one-second periods in a day due to 32-bit floating-point roundoff is unlikely* to account for that much error in a day (assume Redlion is 64-bit floats).

So that leaves scaling, maybe a fat finger error, or something we have not thought of yet.

The simplest solution would be to pick one and use it in both places e.g. use the PLC value and read it into the Redlion.

* a day's worth of 1s samples is just over 16 bits, and a 32-bit float has 24 bits of mantissa, so 16 bits would be lost, worst case, when adding to the total near the end of the day, assume near constant flow rate. That leaves 8 bits of precision, or about a quarter percent, again that is worst case at the end of the day, so not enough to account for the observed difference.
 
What is the source of the "one second clock pulse" in the PLC totalizer? If it is an internal PLC bit that is supposed to represent one second, perhaps on for one half second then off for one half second, the actual elapsed time between pulses will always be longer than one second, due to the PLC scan mechanism. Given that, the error in totalizing will be cumulative. The OP needs a better way to measure actual elapsed time between each addition to the cumulative total. That method needs to have an equal likelihood of being less than one second or greater than one second. I've never worked with a Fatek PLC, so I can't offer any suggestions.
I also don't know what is going on 'under the hood' of the Red Lion unit, but it seems safe to assume their totalizer is as good as can be achieved with the hardware they're using, and almost certainly more accurate than what the OP has programmed in the PLC.
 
1. Steve Bailey: "I also don't know what is going on 'under the hood' of the Red Lion unit, but it seems safe to assume their totalizer is as good as can be achieved with the hardware they're using, and almost certainly more accurate than what the OP has programmed in the PLC."

I agree


2. Calibration of the AI on the PLC could easily be off by 1%:

Assuming a 12mA midscale value, 12mA * .01 = 120uA (0.12mA).

An offset of 0.12mA at the AI could cause this.

Or a difference of 0.5% in a positive direction in one device and 0.5% in the negative direction in the other device.
 
I cannot open you file, so I am assuming you have a self resetting timer. Timers take at least one scan to reset, so your timer is going to be 1 scan slow, every one second, over a period of time, these 1 scan delays add up.

It would be best to have the totalizer in a one second task, or interrupt, that does not rely on a timer.

You can also set it up, where the timer never resets, and you use compares for the timing, with a modification of the timer values.
As the program is for Fatek PLC, you need to install Winproladder software by Fatek which is free.
I have used 1sec Interrupt of high speed timer which time base is 1/10000.
 
Do the PLC and Redlion totalizer values maintain a constant ratio throughout the day?

What are the ratios throughout the day? E.g. Can you plot the two numbers every hour, or half hour?

What datatype is the raw value that is coming into the PLC and into the Redlion?

I see you mentioned that you are using a 1s interrupt in the PLC to run the totalizer; is that the best timing standard there? What is the timing standard in the Redlion?

Is there any way to compare the clocks' accuracies?
I have compared two days data, first day, Redlion value is 4ton > PLC and on second day, Redlion 4.47ton > PLC.



The data type in Redlion, i dont know. In Fatek PLC, 4-20mA = 3276 - 16383.


There is a built in high speed timer in PLC. I used it with 1/10000 time base to get 1sec interrupt.
 
What is the source of the "one second clock pulse" in the PLC totalizer? If it is an internal PLC bit that is supposed to represent one second, perhaps on for one half second then off for one half second, the actual elapsed time between pulses will always be longer than one second, due to the PLC scan mechanism. Given that, the error in totalizing will be cumulative. The OP needs a better way to measure actual elapsed time between each addition to the cumulative total. That method needs to have an equal likelihood of being less than one second or greater than one second. I've never worked with a Fatek PLC, so I can't offer any suggestions.
I also don't know what is going on 'under the hood' of the Red Lion unit, but it seems safe to assume their totalizer is as good as can be achieved with the hardware they're using, and almost certainly more accurate than what the OP has programmed in the PLC.
There is a built-in high speed timer in PLC which i used to run an interrupt after 1 sec. The time base is 1/10000. So its very accurate.
 
If we use a PLC-internal one-second pulse, like S:4 in MicroLogix/SLC, or like the changes in the seconds counter of an hours:minutes:seconds real time clock, and not a timer (TON), then even if we react to its edges in the continuous task, the average time between edges will be very close to 1s*, because any spill over into one second will be taken from the time to the next second.

And if the average sample time is 1s, then the accumulated error, due to things like scan time variability, on the totalizer will be negligible i.e. effectively zero, assuming gaussian noise characteristics.

* 1s as defined by the oscillator driving the PLC clock
 

Similar Topics

We have remote IO 1734-AENTR and all of them seem to be recognized in Logix except in, RIO-5000. When we look at the revision, all the ones that...
Replies
4
Views
746
From a FAT it appears that a struct containing bits/int/real can't be sent from a 1513 to a 1200. When using two 1513 there is no issue. Total...
Replies
5
Views
700
Hello, I have a problem with AO- and AA-Tags. When I use for example the tag AO_Test with the address 200 and type the value 1,2 in, the AA-Tag...
Replies
7
Views
1,415
As per the title. This might seem like a basic question to many, but I'm unclear about the difference between a coil ( ) and an application...
Replies
28
Views
4,046
Good Morning , I have 2 Frequency Drive panels to build and commission . It is for 2 pump systems . Just wondering , what is the...
Replies
4
Views
1,973
Back
Top Bottom