ControlLogix Timer Accuracy

Austin1985

Member
Join Date
Mar 2016
Location
Indiana
Posts
20
Hello!

How accurate would someone say a timer is in a L71 PLC?

I'm tasked with displaying a total water pumped using a flow meter over X time. The unit in GPM, if I capture the flow every one second and add each value until the end of the flow time, then divide by 60, that should be my total water pumped.

If I want to be more accurate, maybe I could capture the flow value every 500ms with a little more math. This would net me double the resolution. What if I went every 50ms?!? The scan of the program is going to limit me at some point..

I hope this interest anyone... Thanks!
 
The PLC timers are very accurate 1 sec or 500ms should work fine for you.
but don't surprised if the accrual time may be a little longer than the preset 1 or 2 ms
due to program execution time - scan time but with scan times in nano sec range the difference would not be noticeable.
 
Here's how I would probably approach this. Most of the Flow meters that I work with have a build in pulse per gallon(this is programmable). So I may have this flow meter setup to pulse ever 1000 gallons or 100 gallons or even 10,000 gallons. I then just count the pulses over a set period of time let's say 1 hour, so if I get 37 pulses over that hour and I have the flow meter set at 1 pulse equals 100 gallons I would times 37 by 100 and that would give 3700 gallon over that hour.

Thats how we would probably do it.
 
Hello!

How accurate would someone say a timer is in a L71 PLC?

I'm tasked with displaying a total water pumped using a flow meter over X time. The unit in GPM, if I capture the flow every one second and add each value until the end of the flow time, then divide by 60, that should be my total water pumped.

If I want to be more accurate, maybe I could capture the flow value every 500ms with a little more math. This would net me double the resolution. What if I went every 50ms?!? The scan of the program is going to limit me at some point..

I hope this interest anyone... Thanks!

If you want to be more accurate, then bypass the inherent inaccuracy of scanned timers by putting your accumulation code in a periodic task, no timers needed.

Periodic Task execution is not dependent upon the scan time of the Continuous Task, and will be "fired off" at the pre-defined periodic interval.

If you already have other periodic tasks, then you can achieve maximum accuracy by giving the accumulating task the highest "priority" (lowest number). This will have an impact on the tasks with lower priority, so you do need to check what those other periodic tasks are used for. Tasks with equal priority are "time-sliced", so the tasks appear to run concurrently.
 
Here's how I would probably approach this. Most of the Flow meters that I work with have a build in pulse per gallon(this is programmable). So I may have this flow meter setup to pulse ever 1000 gallons or 100 gallons or even 10,000 gallons. I then just count the pulses over a set period of time let's say 1 hour, so if I get 37 pulses over that hour and I have the flow meter set at 1 pulse equals 100 gallons I would times 37 by 100 and that would give 3700 gallon over that hour.

Thats how we would probably do it.

Depending on the flowmeter, it can be an additional cost to get the pulse signal. But this is the way to go... even better is if you have a frequency counter input in your plc in which case you don't have to worry about missing a pulse or anything like that.
 
Hello!

How accurate would someone say a timer is in a L71 PLC?

If I want to be more accurate, maybe I could capture the flow value every 500ms with a little more math. This would net me double the resolution. What if I went every 50ms?!? The scan of the program is going to limit me at some point..

Timers aren't very accurate if you let them run, time out, trigger your calculation, then reset them and start over. The time between the reset and restarting is 'lost', and can add up, especially if you are trying to run it every 50 ms. The better way is to use periodic tasks as others have indicated.

As far as your totalizing, you need to be careful that your totalizer does not overflow, or that the totalizer value does not get to big and then the addition value be too small to increase the total. There is a built in totalizer for function blocks that uses double precision floats that helps prevent this problem.
 
Timers within the continuous task drift, and more noticeably so as the task becomes populated with more complex programs (leading higher scan times, generally). Accessing the controller’s real-time clock in a periodic task is my approach.
 
While the OP question was about the accuracy of timing capability of the L71 processor, it is in the context of accurately totalizing (integrating) a sampled input signal. I would say that the error contribution of the software technique to the totalized result is negligible compared to instrumentation, wiring, analog/digital conversion, filtering, etc.

Using a totalizer pulse avoids some of these error contributions, though accuracy still depends on the instrument capability to accurately generate pulses. So, as pointed out, this is a preferred method if it is available and the continuous signal is not needed. Or use both as inputs to the PLC if desired.

If going down the route of totalizing an analog input, you will want to consider how that signal is filtered by the instrument and/or PLC input in determining the timer/task period. There is not much point in sampling at 50 ms if there is a filter time constant of 5 seconds, unless you need the totalized value to update that often. Likewise, a really slow sample period on a noisy input could produce less stable result.
 
While the OP question was about the accuracy of timing capability of the L71 processor, it is in the context of accurately totalizing (integrating) a sampled input signal. I would say that the error contribution of the software technique to the totalized result is negligible compared to instrumentation, wiring, analog/digital conversion, filtering, etc.

Using a totalizer pulse avoids some of these error contributions, though accuracy still depends on the instrument capability to accurately generate pulses. So, as pointed out, this is a preferred method if it is available and the continuous signal is not needed. Or use both as inputs to the PLC if desired.

If going down the route of totalizing an analog input, you will want to consider how that signal is filtered by the instrument and/or PLC input in determining the timer/task period. There is not much point in sampling at 50 ms if there is a filter time constant of 5 seconds, unless you need the totalized value to update that often. Likewise, a really slow sample period on a noisy input could produce less stable result.

I think your comment is assuming that the analog signal isn't changing. Not considering filtering, if the signal barely changes, then the integration error will be near zero. If the signal is changing constantly, the integration error may very well be worse than all the contributors combined.
 
I think your comment is assuming that the analog signal isn't changing. Not considering filtering, if the signal barely changes, then the integration error will be near zero. If the signal is changing constantly, the integration error may very well be worse than all the contributors combined.

This is true with respect to part about favoring a totalizer pulse over integrating a sampled analog input. But the main point I was trying to make is error related to measuring the physical process (i.e., liquid flow through a pipe) will likely be much greater than error from the final computation of rate to volume. This will be significantly impacted by flowmeter technology and attention to detail in the measurement. And there could be a case where the process conditions and instrumentation technology are so good as to elevate integration error to significance.
 
Counting pulses from a flowmeter is always going to give you the best accuracy, as it is solely dependant upon 1 thing, the flowmeter itself. No other factors can cause any errors.

But if a flowmeter volumetric pulse is not available, then you must eliminate any areas of uncertainty, which would lead to an incorrect totalisation.

The worst of these potential errors is a noisy analog signal. These can often be filtered by the analog input card itself, sometimes external filtering eg. a large value capacitor across the input, or by internal filtering, using any one of a number of filtering algorithms.

One method I have used on numerous occasions is to sample the analog reading into a "shift register" periodically. As each reading is "shifted in", the oldest is lost. Then the software copies the shift register array to another, sorts it ascending value order, then the average is taken of the sorted array, excluding the lowest (first) and highest (last) values. How many values you exclude at each end determines the aggressiveness of the filtering, but I have never used more than 2 at each end. Typically the shift register for storing the readings is 20 readings.
 
Lots of input here. Thanks everyone!

The flow meter does not have any output pulse that can be utilized. The system is all built, and I don't wish to add a periodic task, but I may have to. Noise over wires could be a problem. I'll build what I can and I'll see what it does.

Also, this is a quench, so I'm only looking at the signal for about 10 seconds. The first second of that is crazy noisy because the water shifts from a bypass valve into the tool, and it takes a bit to settle down. It sounds to me like the current meters and mechanical setup may not be well fitted for totaling.

Again, Thanks!
 
My preferences for flow totals:
1) protocol. Read the totalizer right out of the meter. they always will match. It is more complicated to set up, but you can usually get more diagnostic info from the flowmeter and a real time flow rate too.
2) pulse. Count pulses and scale if needed. This will match the meter as long as no pulses are missed and the starting values are set to match
3) analog with timed interrupt (periodic task or STI). This method will always accumulate error, but if it is all you can get, make the most of it by being very precise with your set up and wiring.
 
My preferences for flow totals:
1) protocol. Read the totalizer right out of the meter. they always will match. It is more complicated to set up, but you can usually get more diagnostic info from the flowmeter and a real time flow rate too.
2) pulse. Count pulses and scale if needed. This will match the meter as long as no pulses are missed and the starting values are set to match
3) analog with timed interrupt (periodic task or STI). This method will always accumulate error, but if it is all you can get, make the most of it by being very precise with your set up and wiring.

It will only "accumulate error" that exists on the analog signal. As far as timing goes, Periodic task is the way to go.
 

Similar Topics

I have some 1000ms TON instructions in a ControLogix L62 than on .DN totalize a flow reading. We noticed that the result is only about 75% of...
Replies
5
Views
5,459
I have an array of UDTs in which is located a timer. I have made a page where I wish for the timer preset to be adjusted. There's just zeroes on...
Replies
0
Views
1,068
I have 2 transfer cars that need a horn and light installed for when they are moving. With teh Slc5/03 processors I usually put the light and...
Replies
7
Views
1,600
Good day all, I was hoping the forum could help me with something I've been wondering (I looked through the Forum's Search function but did not...
Replies
9
Views
2,113
In addition to the typical status bits of EN, TT, and DN, the Logix5000 Timer Tag shows additional status bits when viewed in Tag area. Has...
Replies
8
Views
4,714
Back
Top Bottom