Industry Online Support
Technical Forum
Navigation
Rating 
Thanks 1
3 Entries
| 11/28/2010 12:29 PM | |
Joined: 10/7/2005 Last visit: 11/6/2024 Posts: 3026 Rating:
|
Hello leq1890 first of all good on you for wanting to understand why the "strange" Timer behaviour is as it is. Secondly,what you observedcan actually be expected and is "normal" Timer in an S5 (the same applies too for using S5 Timers in an S7 by the way). The reason is that Timers are updated asynchronously by the Operating system as per their time base. What this means in your case is this: T87 is loaded with theTime Setpoint and "started" when I97.2 goes from 0->1value at the moment in time when NW15 in PB59 is executed. Therafter the Operating system takes over and will count down the time every 100 ms irrespective if NW15 in PB59 is continued to be executed in subsequent scans or not (you can for example start an On Delay timer in a startup OB and it will time out as per time setpoint sometime after the CPU restart). Let's assume the 5 seconds are almost up and T87 value is down to its last 100 ms. If the Operating systemnow does it countdownof the last 100ms after NW 15 but before NW 39in PB59, T87 will be declared as "done" there and then and the oberserved "strange" (albeit logical) behaviour will take place (F80.1 gets set, but F203.4 will only get set in the next scan). In most cases this does not matter, but there can be situations where it may cause problems. To avoid that timers can cause this "strange"behaviour, you do what already implemented (only question thetimer for expiry once somewhere in the logic andassign its status to a bit which you then use multiple times thoughout the program). I hope the above explanation makes sense and helps |
|
Cheers |
|
| 11/29/2010 11:08 AM | |
|
Posts: 24 Rating:
|
Thank you for explanation. |
This contribution was helpful to
|
|
Follow us on