Probably get attacked because of scan time and I should use 59 instead of 60 etc. Lol! I also remember reading something here about how much out it is after a day. I'm always up for suggestive improvements...
The reason you are off at the end of the day is because you use a conditional rung for your timer. If your PLC has a 20 millisecond scan time and you are resetting it conditionally, then every time its reset you loose up to 40 milliseconds of time between when the timer actually times out, when its reset on the next scan, and then when its restarted on the scan after that. 40 millisceonds dosen't sound like much, but do that once a minute and at the end of a day your time totalizer is off by more than a minute. If you're totalziing time by 100ths of an hour you'll be off by almost two minutes at the end of the day.
When a timer rung first goes true the timer instruction get the current system time reference word and stores the least significant 8 bits in the low order byte of word T4:x.0. The second time the timer instruction is scanned true the system gets the current system time again, subtracts the value in the low byte of T4:x.0, and if the result is greater than the timebase, the accumulator is incremented by the appropriate amount. Then the amount the accumulator is incremented by is also added to the time reference in the low order byte of T4:x.0. The timer keeps accurate time this way. Remember that a timer is a computer instruction that operates on an area of memory, it is not a device, so the actual time period being timed almost always elapses while the processor is doing something else besides running the timer. That means that the amount of actual time elapsed is always slightly longer than the amount of time timed. When the processor gets around to executing the timer instruction again it sees that the time (and then some) has elapsed, so it sets the /DN bit. If you program a self resetting timer, now you will have a full scan elapse before the rung is scanned as false, which resets the timer, and then another full scan elapses at which point the processor sees the timer rung as true again and it restarts the timer. It wont be until the third scan after the timer timed out that it starts comparing elapsed time to the new time reference value stored in in T4:x.0 again.
If you prevent the timer from ever timing out however by directly manipulating the ACC value instead of resetting the timer, you preserve the time base reference value in T4:x.0 and you don't loose the time of two scans from resetting the timer.
See my previous post for the link showing one way to avoid the scan time issue.