ControlLogix Timer accuracy

whumphrey

Lifetime Supporting Member
Join Date
Aug 2011
Location
Lincoln, NE
Posts
35
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 what it should be.

We did a test where we counted the .DN from the timer in a CTU block and compare this to system clock seconds (Datetime[5]).

Over time, Datetime[5] begins pulling away from counter .ACC.

These rungs were in a continuous task with a typical scan time of ~10ms. I tried the same test in a scheduled task and got the same result.

Is this a known issue of some kind? Could it be something we are doing wrong with our processor setup? We are using only a fraction of the availble memory.

Thanks,
Warren
 
I have a similar problem. Another programmer used timers and a subroutine for runtimes. And yes, they were about 75% too low. I ended up using the PLC clock second to trigger the needed one second pulses, and the accuracy improved a lot. It's still not where I want it, but there's absolutely nothing I can do to improve the speed. It's as accurate inside the PLC as it will ever be.

PLC clocking isn't a sure thing. This is something I learned way way back, and every once in a while it shows itself. Doing totals and runtime is where it will show failure. In the program, your timers are subject to the run time of the program. There are those who will disagree, but it does accumulate errors in accuracy.

Good luck.
 
So this isn't just a ControlLogix issue but rather AB PLCs in general?
We use CompactLogix quite a bit for this same appliation and I don't recall having this same problem...or at least not this magnitude.

Now I want to go back and check some other projects.

Thanks for the reply.

-Warren
 
A trick to help increase timer-only based accuracy:

Let's say you want a pulse every second. Set up a timer with a preset considerably longer, say 5 seconds. Have it run on an unconditioned rung.

Now a test, if the accumulated time is equal to or greater than 1 second (1000 in ControLogix) then increment your 'second counter' and subtract 1000 from the accumulator. Watch this over time. It will probably be a bit closer.
 
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 what it should be.

We did a test where we counted the .DN from the timer in a CTU block and compare this to system clock seconds (Datetime[5]).

Over time, Datetime[5] begins pulling away from counter .ACC.

These rungs were in a continuous task with a typical scan time of ~10ms. I tried the same test in a scheduled task and got the same result.

Is this a known issue of some kind? Could it be something we are doing wrong with our processor setup? We are using only a fraction of the availble memory.

Thanks,
Warren

tomalbright hinted on the inherent inaccuracy problems of timers, let's take it a step further....

Firstly let's get one thing out of the way and move on....

Timers in A-B PLCs are not Timers at all - they are instructions that perform a bit of maths and set some flags. The "timing" element of a timer is always referenced back to the system clock.

Here's how TON timers work, in sufficient detail to understand why I say they aren't timers - TOF and RTO work the same way - with the obvious differences...

When the rung evaluates as false, the timer accumulator is reset to zero, and the EN TT and DN flags are reset.

The first time the rung evaluates as true, the EN and TT flags are set, and the current system clock data is recorded in the unused bits in the Timer tag (no, you can't get at them).

The next time the timer rung is scanned (assume still true), the current system clock data is compared to the stored data, and a bit of maths works out how many milliseconds have elapsed since it was last scanned. These milliseconds are added on to the accumulator value, and the stored current system clock data is updated with the new time. Then the instruction compares the accumulator value to the preset value, and, if greater than or equal to, sets the DN bit, resets the TT bit. No further accumulation of time will happen once the DN bit is set (i.e. the timer freezes).

Go back one paragraph to see what happens on the next scan of the rung.

So, if your happy with that description, it's easy to see that a timer does not "count" milliseconds into its accumulator, it is simply "bumped up" by how many milliseconds have elapsed since the previous scan of the instruction. The number of milliseconds added is the time between scans, usually the same as the program scan time.

Consequences of this .....

1. A timer can (and will) "overshoot" the preset value. If you had a scan time of 50 mS, your 1000mS timer could easily "time-out" (i.e.set the DN bit), after 1049 mS.

2. Never attempt an EQU instruction on the accumulator value, it will invariably miss the target altogether, use GEQ or GRT to trigger whatever it is you want (with a one-shot if you need to).

Now what if you are using a self-resetting timer to generate a "time-period" trigger. Usually this is done with an XIO of the DN bit on the rung to reset the timer. Be aware that it will then take an additional 2 program scans before the timer starts timing again. The next scan after the DN bit gets set will reset the timer, thus resetting the DN bit, which will be picked up on the next scan to start it timing again.

All said and done, it is best not to use Timers where you need any accuracy, such as your case where you are using it to calculate a time-based parameter - flow totalisation.

If you want to do something every 1000mS, create a periodic task (scheduled 1000mS), and choose its priority level dependent on how accurate you want the task to run - highest priority has absolute control, and therefore, absolute precision.

I hope this explanation gives you food for thought, it is fundamental to good program design to understand the instructions, and the way the processor evaluates them.



Warren, can you post your test rungs ? (Zip the ACD file)

I could write a test routine myself easily, but I'm intrigued by your 75% error findings and want to know how you tested it.
 
I had a very similar application just recently (flow totaliser being inaccurate). An old, wise engineer taught me a good way around it.

What I had was a pulse-type flow meter that gave out something like 13.17 pulses per litre (or liter, if you're american ;) ). So I set up a timer, and a counter, and counted the number of pulses in one second, and from that calculated the flow rate.

BUT...as mentioned above, I used a 5 second timer and a GEQ instruction. Once the timer .PRE value is GEQ to 1000 (msec), on the next flow meter pulse, the logic multiplies the number of pulses by 1000 and then divides it by the .PRE value in the timer - effectively multiplying the number of pulses by the number of seconds (i.e. 1 and a little bit) to get an accurate figure. (and then resets the timer to zero)

If you have a little bit of time, you can create a function block to do the whole thing - I wrote one where you just feed in your pulse input, tell it your k factor (pulses per litre), give it a timebase for the output (i.e. litres per second/minute/hour), and it spits out a flow rate.

The only thing you have to be careful of is that depending on how you program it, if the flow stops, the figure may not reset to zero because the calculation executes on a flow meter pulse oneshot. The easy way around that (which I also included in the add-on instruction) is to have a free running TON of about 2 seconds, which is reset by a one shot from both the pulse ON and pulse OFF. If the timer times out, the output value was reset to zero.

Hope some of this is useful to you in your application :)
 

Similar Topics

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...
Replies
17
Views
5,216
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