Hi esantos

I'm not surprised with what you observe and the reason is probably twofold:

1. You are using an S5 Timer. It's accuracy depends on the time base which is of course obscured from view when S5 Timers are used in an S7 and in your 1 second time set point case will be 10ms
   
2. You say "This Timer was implemented to auto-reset" Without knowing how you do this, you may easily end up with an "empty scan" of the S5 Timer so that the timer can see a rising edge again and start again afterwards (this will cost you a cool 100ms every second if called from within your OB34)
   

esantos

Analyzing what you say in the item 2 that's reffering to time cost for edge transition on Timer restart, I simulated this on Excel to check how much time per hour we get as error and this matchs with what I observe in CPU. By example: my OB1 average scan has 15 msec, then it cause arround 1 minute per hour of delay. And if I put it on OB34 (100 msec) I get a still worse behavior.

Please How can I workaround this for a future needs?

You could call the timer right away a second time so that it sees an RLO of 0 and is ready to started again in the next scan (or OB34 call).

This won't help you with the S5 Timer inaccuracy itself though and the million $ question is: What is it that are you actually trying to achieve?

Using the CPU 's clock bits or reading out the system time via SFC1 READ_CLK or using SFC64 TIME_TCK etc. are all based on the internal real time clock and will be far more accurate (although the CPU's real time clock drifts too as per CPU spec).

IF a 100ms OB34 is already there, you could of course also simply add up an INT by 1 on every call and check when it reaches 10 to get a 1 second indicator.

Back to the million $ question is: What is it that are you actually trying to achieve?  (or why do you think you need an S5 Timer to achieve it)