Practice with timers - major discrepancies

Hello all,
I'm a recent beginner in the PLC world. I'm working on a set of exercises handed down to me from a friend to help get comfortable with programming AB PLCs.

Background to my setup for testing is that I've got the RSLogix Emulate 5000 running with RSLinx Classic, RSLogix 5000, and FactoryTalk View Studio. I've emulated a full setup of PLC & HMI.

I've created a program that is testing the timer against the system clock. I have a pushbutton on the HMI that starts the timer and grabs the initial system time. When the timer is done, I get a final system time. Now I'm trying to time 25 seconds and using a 0.25 second timer and a counter to increment up to 100 timer ticks.

When I examine my actual system time at start and stop I'm consistently 3 seconds or so off. If I change the 0.25 second timer I get varying error, but always fairly significantly off...

I'm wondering if I'm simply doing something wrong or my emulation setup is hampering accuracy?

Please take a look at the attached PDF printout of the routine.

Thanks,
Bill

I don't see any major errors in your PLC logic. There are some things you could simplify though.

I would expect that the error lies with the emulator. I have not used Emulate 5000, but I use Emulate 500 quite a bit and one of my first complaints was the fact the the scan time of the emulated PLC was kinda goofy, and that debug files scan times were weird as well.

Paul

I've never played with the emulator before so I don't know what level of performance it is capable of. But with what you are doing you are losing somewhere between 0 and a full scan worth of time every time the timer reaches it's preset. It may be even more than that depending on how the timer reacts to a reset.

Take the worst case. You just scanned the timer instuction and you were 1 microsecond short of the preset. You need to go through a full scan and scan the timer again before you get the done bit. So now you are at 0.25 seconds plus one scan of time. When you reset the timer that time over 0.25 seconds is tossed on the scrap heap. It is lost and you can never get it back. The closer your scan time is to your timer preset the worse the errors will be from a percentage standpoint.

Instead of 0.25 seconds, set you timer to 2.5 seconds and count 10 events and see what your error is. Then set it up to time for 25 seconds and run one event and see what your error is.

You just came across the point ofd the exercise, by the way.

Keith

When ever you couple a timer and the timer DN bit to increment a counter you can get significant timing errors due to the fact that scan time is also totalized into the count.

TON is a software instruction that operates on a memory location, not a device. For PLC/5, SLC500, MLX and CLX processors, when the TON is first enabled a time reference is stored in the LSB of the timer word 0. Each time the TON instruction is executed after that the value stored in the LSB is compared to the current system time reference. As soon as the system time reference minus the value stored in the word 0 LSB is greater than the time base then the accumulator is incremented. Then the reference time in the word 0 LSB is updated to reflect the system time reference + any excess left over when the ACC was updated. This way the timer keeps accurate time. But when the ACC >= PRE then the DN bit will be set. This time value is always equal to the preset value plus any elapsed scan time between when the time period actually elapsed and when the timer instruction was next executed. In a controllogix system it also includes the task update time (eg a 5 second timer DN bit in a 1 second task will be set anywhere from 5 to 6 seconds plus the scan time after the timer is enabled.) Now in your logic, you then reset the timer. That clears, among other things, the reference value stored in the word 0 LSB. So all the extra microseconds that kept from when the ACC was last updated are lost. A few micronseconds aren't much, but do that a few hundred times and it starts to make a difference.

In your program you have added in the program scan time plus the task execution rate 100 times into your accumulated timer value. To illustrate this make a comparison between the logic you used with the counter and just a straight 25 second timer where the preset is 25000.

Here are some other threads where this same issue has been discussed:
http://www.plctalk.net/qanda/showthread.php?t=44471
http://www.plctalk.net/qanda/showthread.php?t=21110
http://www.plctalk.net/qanda/showthread.php?t=29287

There are some things that can be done to maintain accuracy over very long time periods but it requires some knowledge of how the TON instruction works inside. In a CLX for really long time periods (> 596 hours) I would use the TOT instruction instead.

Thanks for the replies! I read through some of your links Alaric and implemented some changes which have brought me down to 25.4-25.8 seconds difference in system time on my 0.25 second timer base tied to my 100 tick timer. I did as suggested and did not reset but simply subtracted 250 from my timer's ACC value. I did have to manually unlatch the DN bit in order to get the timer to continue timing which I did not see in your example.

I also tried to clean up the code for simplification.

Aside from modifying the timer to a larger increment, is there anything else that I can do to increase the accuracy or other general coding tips on this beyond what I've done?

I've attached my new code as PDF.

Thanks,
Bill

That timer is still going to stop counting when the ACC reaches 250. The reason for the improved accuracy is that you at least aren't clearing the residual reference time in the LSB of timer word 0, but you're still summing scan time into the total. One way to improve this is to never let the timer complete by setting the PRE to some very large value that is much greater than the expected count interval, say 1000 for example, and then use a comparrison instead of the DN bit. Just increasing the PRE of the Lab6_Timer to 1000 will improve the accuracy - I hope that while we are doing this you are starting to understand the inner workings of the TON instruction, otherwise there isn't much point in it. By the way, a TON or RTO works, the RTO used in one of the linked examples was for totalizing motor run hours in 1/10th hour increment so it needed to be retentive when the motor stops, but your app can use a TON instruction.

How does using only a timer with a 25000 preset compare? For all time periods that are less than 2^31 milliseconds (about 596 hours) it doesn't make much sense to use anything except a simple stand alone timer. That approach is generally the best because it is the simplest for another person viewing the program to understand what you are doing, and it will be more accurate than any other approach.

BTW, I second what Keith said, you have come across the point of the exercise, to demonstrate that using a timer + counter combination to time long time periods has accuracy problems due to repeatedly summing the very small timing errors introduced by the scan time until the sum become significant. Its not nearly as much of a problem in the ControlLogix processor because it uses a 32 bit timer, but other processors that use a 16 bit timer can see some sizable time discrepancies if the programmer is not very careful in timing long time periods. A 16 bit timer can't even time a whole day so you encounter the problem a lot more often on those platforms than on the CLX platform.

Another exercise for the CLX would be to create a task that executes once ever 250 milliseconds. A program in this task adds 1 to a tag. Use the ADD instruction and a DINT tag, not a counter because a counter must see a false to true transition to increment. When the tag reaches 100 check the elapsed time. It should be right at 25 seconds +/- just a couple of milliseconds.

Alaric,
Thanks for the reply again.

I tried your suggestion of setting the PRE value higher than 250 and the elapsed time is now 25.01 which is much better.

I understand that this is not the "best" way overall - a direct timer is of course going to be less complex and more robust anyway.

Glad to see this forum is very helpful! So far I'm pretty much just self teaching myself this stuff, and good to have a decent resource at hand. I'll have to give the reoccurring task idea a shot too.

Thanks,
Bill

I hope that this helped you get a better understanding of the inner workings of the timer instructions.

BTW, welcome to the forum. We hope to see more of you around here, and even though you are a beginner, feel free to participate - I can't think of a better way to learn.