I seem to remember a topic a while back which there was an S: bit in either a SLC of PLC-5 that toggled every second which was rather repeatable. Anyone remember the topic or what bit it was for that matter.

I am trying to add seconds using an add function, but a 1 sec. timer is just not accurate enough, it needs to accumulate for a few hours with better accuracy. The timer looses time, I though of adding a "Fudge" factor but would rather not if it is not needed. My scan time is around 50mS. I have the same problem in my PLC5's and SLC's so a solution for either is appreciated.

FYI... The same Logic in a CLX processor holds remarkably good time...

Anyone Remember??

Thanks

In the PLC5 the S:23 word is seconds (0-59).
if you use S:23/0 it is on for one second and off for 1 sec.

If you use a timer, try using a time base of .01 sec with a preset of 100
it still may not be accurate enough because it still effected by scan time.

If it doesn't have a RTC then the closest is S:4/6 - 1.280 seconds. Still scan time dependant

What is the duration of the timing? Perhaps log the start and stop and do the math?

Have you tried placing your add instruction inside an STI and interrupting at the 1 second interval. This should help with the scan issue drift you're seeing.

The problem sounds like "scan time jitter". Even if the controller's internal clock is absolutely perfect, your ability to catch a 1-second timer's .DN bit can only be as accurate as the PLC scan time. A worst-case 50 millisecond inaccuracy is 5% !

You mentioned wanting to accumulate seconds for hours at a time. That sounds like a job for a Retentive Timer (RTO) instruction. Any time the timer is enabled, it accumulates time based on the controller's internal clock, not on the scan time. You'll still have "scan time jitter" but the inaccuracies will be twice per measured interval, not once per second.

The RTO has a 15-bit preset like other SLC timers, so the maximum measured duration is 32767 seconds = 9 hours, 6 minutes, 7 seconds.

You have to play to the timer's strengths, not its weaknesses.
A timer's weakness is the PLC scan. As long as you remain dependent on the scan you are going to accumulate error in your time totalizer. AB PLCs use a rolling time stamp that is stored in the first 8 bits of word 0 of the timer element. Each time the timer is executed the current time is compared to the time stamp stored the last time the timer instruciton updated its ACC word. If a time period in excess of the time base (1 sec or .01 sec) has expired then the timer count (.ACC) is incremented, and a new time stamp is stored in the low order byte of word 0. Because the time stamp is a single byte you must execute a timer instruction at least once every 2.54 seconds.

So how do you take advantage of this without adding scan time into your time total? The answer is easier than you might think. You never let the timer reach its preset. You manipulate the value in the .ACC as you totalize your time.

For an example of how to do this see this download:
http://forums.mrplc.com/index.php?autocom=downloads&showfile=576
I'm blowing my own horn here, but I have used this to keep accurate time for durations of time that far exceed a timers max of 32767 and 327.67 seconds.
I have used variants of this basic routine many times and find that it works well with good accuracy. One variant is to subtract 3600 from a single .01 sec timer's ACC every 36 seconds and upcount a .01 hour register to track 1/100ths of an hour.


-------------------------------------------------------------------------------------------------------------------

Exercise question to ponder: What happens to timer T4:0 if the rung

XIC B3/0 TON T4:0 .01 1000 0

is programmed in two or more places in the same program? Why? and, Why would one program that rung multiple times in the same program?

Placing that rung in multiple locations in the program will update the timer more often and reduce the issues seen with the SC/PLC scan times and timers.