Ton Timer

Rick Densing said:

I am a little suprised no one here really knows the correct answer.(At least for AB) It is just something that I took for granted. Wondered about, the shook my head an went on to the next real problem.

Click to expand...

I have wondered too, and it's certainly an advanced topic (the inner workings of a TON). And it is amusing that one of the most fundenmental principles of PLC programming (taught right after coils and contacts) can generate this much discussion, even by us "experts".

But it is a real problem (or at least has real application).

I brought it up because, last week, my boss and I were discussing indirect addressing of timers (via the technique I posted above), and not being please with the results. (I don't remember the specifics of why I wasn't pleased - just that I wasn't. He had a similar experience).

But if I know exactly how they work, perhaps I can devise code to make it do what I want.

Currently, the way I'm doing "indirect timers" is to use a 1 second pulse, and an ADD function:

      IS TIMING             TIMER IS

      CONDITION TRUE        ENABLED

    N40:[N10:15]/0       T44:[N10:15]/EN

----------| |------------------( )-



     TIMER IS

     ENABLED                

   T44:[N10:15]/EN        +---------- CLR ---+

---------|/|--------------| T44:[N10:15].ACC |

                          +------------------+



      TIMER IS

      ENABLED         1 SEC    +---------- ADD ---+

   T44:[N10:15]/EN    PULSE    | T44:[N10:15].ACC |

---------| |-----------| |-----|                1 |

                               | T44:[N10:15].ACC |

                               +------------------+







    +----------- GEQ ---+    T44:[N10:15]/DN

----|  T44:[N10:15].ACC |--------( )

    |  T44:[N10:15].PRE |

    +-------------------+







   T44:[N10:15]/EN    T44:[N10:15].DN    T44:[N10:15].TT

---------| |----------------|/|---------------( )

.
In this case, there really isn't any difference between timers and counters!

There's no TON, either, but that's OK - I "rolled my own".

Do I need to use Timer registers to do the above? No, but someone looking at the data tables labelled "Alarm Timers" and seeing the bits going on, the .ACCs increment, and so on, will certainly find it a lot easier to understand what's going on than if I just used integer registers.

The attached SLC-5/04 program file (TON_FUN.RSS) demonstrates and confirms the concepts that I set forth in my previous post #15. A step-by-step description of the program's operation is given below.
-----------------------------------------------------------
The processor is placed in program mode.
T4:1 is manually reset (all bits off; zero in accumulator).
T4:2 is manually reset (all bits off; zero in accumulator).
T4:3 is manually reset (all bits off; zero in accumulator).
The processor is then placed in run mode.
-----------------------------------------------------------
An FLL (fill file) instruction places bogus data into the data tables. This will make any “zero” data readings more obvious.
Timer T4:1 is “serviced” by executing a TON.
Timer T4:2 is “serviced” by executing a TON.
Timer T4:3 is NOT “serviced” - (no TON).
The accumulated value of T4:1 is stored in N7:11. ( 0)
The accumulated value of T4:2 is stored in N7:21. ( 0)
The accumulated value of T4:3 is stored in N7:31. ( 0)
The low byte of T4:1’s first word is stored in N7:41. ( 1)
The low byte of T4:2’s first word is stored in N7:51. ( 1)
The low byte of T4:3’s first word is stored in N7:61. ( 0)
The scan is "paused" in a loop for 0.07 seconds.
-----------------------------------------------------------
Timer T4:1 is NOT “serviced” - (no TON).
Timer T4:2 is “serviced” by executing a TON.
Timer T4:3 is NOT “serviced” - (no TON).
The accumulated value of T4:1 is stored in N7:12. ( 0)
The accumulated value of T4:2 is stored in N7:22. ( 7)
The accumulated value of T4:3 is stored in N7:32. ( 0)
The low byte of T4:1’s first word is stored in N7:42. ( 1)
The low byte of T4:2’s first word is stored in N7:52. ( 8)
The low byte of T4:3’s first word is stored in N7:62. ( 0)
The scan is "paused" in a loop for 0.07 seconds.
-----------------------------------------------------------
Timer T4:1 is NOT “serviced” - (no TON).
Timer T4:2 is “serviced” by executing a TON.
Timer T4:3 is “serviced” by executing a TON.
The accumulated value of T4:1 is stored in N7:13. ( 0)
The accumulated value of T4:2 is stored in N7:23. (14)
The accumulated value of T4:3 is stored in N7:33. ( 0)
The low byte of T4:1’s first word is stored in N7:43. ( 1)
The low byte of T4:2’s first word is stored in N7:53. (15)
The low byte of T4:3’s first word is stored in N7:63. (15)
The scan is "paused" in a loop for 0.07 seconds.
-----------------------------------------------------------
Timer T4:1 is NOT “serviced” - (no TON).
Timer T4:2 is “serviced” by executing a TON.
Timer T4:3 is NOT “serviced” - (no TON).
The accumulated value of T4:1 is stored in N7:14. ( 0)
The accumulated value of T4:2 is stored in N7:24. (21)
The accumulated value of T4:3 is stored in N7:34. ( 0)
The low byte of T4:1’s first word is stored in N7:44. ( 1)
The low byte of T4:2’s first word is stored in N7:54. (22)
The low byte of T4:3’s first word is stored in N7:64. (15)
The scan is "paused" in a loop for 0.07 seconds.
-----------------------------------------------------------
Timer T4:1 is “serviced” by executing a TON.
Timer T4:2 is “serviced” by executing a TON.
Timer T4:3 is NOT “serviced” - (no TON).
The accumulated value of T4:1 is stored in N7:15. (28)
The accumulated value of T4:2 is stored in N7:25. (28)
The accumulated value of T4:3 is stored in N7:35. ( 0)
The low byte of T4:1’s first word is stored in N7:45. (29)
The low byte of T4:2’s first word is stored in N7:55. (29)
The low byte of T4:3’s first word is stored in N7:65. (15)
-----------------------------------------------------------
The processor is intentionally faulted after one scan to
freeze the timers and the data values in place.
-----------------------------------------------------------
Analyzing the data values shows that timers T4:1 and T4:2 both kept the correct time (0.28 seconds) - even though one timer (T4:1) was “serviced” twice during the scan - while the other timer (T4:2) was “serviced” a total of five times during the same scan. Notice also that timer T4:3 was only “serviced” once - about halfway through the scan. This timer’s accumulated value did NOT advance during this “one-scan” program.

The values from the low byte of each timer’s first word were also recorded at each step in the scan. Analyzing these values indicates that the processor was using these low bytes as “notes” to keep track of the reading from the processor’s “internal clock” each time a TON required the “servicing” of a timer. This explains why timer T4:3’s accumulator did not advance. This value WOULD have advanced if the timer’s TON instruction had been executed again on a subsequent scan. Notice, however, that the processor DID “note” its internal clock reading (15) in the low byte of timer T4:3’s first word - once the timer’s TON had been executed about halfway through the scan.

This demonstration confirms my assertion that the TON is NOT a timer. Rather the TON is an INSTRUCTION which causes the processor to “service” the timer. The TIMER is actually the 3-word structure in the data table file.

I am convinced that I now “understand” how the Allen-Bradley SLC-5/04 handles the TON timer instruction. I trust that by reading my earlier post #15 in this thread, and by carefully considering the logic of this demonstration program, others may follow in my glorious path toward enlightenment. My work here is done.

I think the following little exercises will absolutely determine if the timers are "Serviced on a Call-Basis" as Ron described.

Create a Sub-Routine.

• Rung-1: SET "Was Called"
• Rung-2: Use "Was Called" to drive (turn ON) T-X. (1-mSec Timer, with a 32-Sec Preset).
• Rung-3: Return.

Now, in the Main Ladder,

• Rung-1: If NOT "Was Called", then "Call Sub-Routine"
• Rung-2: Show T-X Acc.

When started, since "Was Called" is FALSE, the main Ladder "calls" for the Sub-Routine.
The Sub-Routine SETS "Was Called" (this prevents subsequent calls to the Sub-Routine.).
The Sub-Routine uses "Was Called" to turn ON Timer-X.
The Sub-Routine RETURNS to the Main Ladder.

Now, use what ever means to, display the current T-X Accumulator Value.

If the value remains the same, whatever it is, then the timer is indeed "Serviced" on a "Call-Basis".

Otherwise, the value of T-X Acc is "Serviced" on a "Scan-Basis".


What do you see?

TON TIMER

THANKS TO ALL OF YOU!!!!!!!

For proprietary reasons I can not post the program.

Here is what we did so far and the problem has not occurred again.

The original timer in question was the first timer in the memory;

we used a different one ( the 4th one ). We are not using the first

and second timer at all. This was a way to go around it; but the

question remains unanswered.

Thanks to all again.

We're all just dying to know. Does this system use an EEPROM (memory module)? Most of us think that the program in the EEPROM had the "incorrect" timer settings burned in - and that these settings were being downloaded to the processor each time the EEPROM reloaded its copy of the program to the processor. If you could at least tell us what settings (if any) are/were enabled on the "Mem Module" tab under "Processor Status", we'd all be able to sleep a little easier tonight. Thanks.

No takers on the Sub-Routine scheme?

Since this thread keeps growing I have question that may throw things on a different perspective.


In the ab slc500 there is a bit for the average scan time (s:23 )
From the Instruction Set Reference manual it appears that the proc stores the last 7 or 8 scans to calculate this.
If the proc already stores 7 or 8 scan times does it use this info for the timers as well.

For example does it say; Set a marker,count Number of scans then when equal to X add those stored times to increment the accum.?

Or possibly does it use this info to help keep the timer accurate?

Just a thought but sitting here watching the discussion the thought came to mind and it hasn't come up yet.


Thanks
Drewcrew6

HELLO ???? Anyone there ???

Is my question so foolish that it doesn't deserve an answer ???

I'm asking if anyone has tried using the Sub-Routine scheme I suggested to determine if the Timer is indeed "Service-Driven" as Ron described.

With respect to AB, I don't know if it is, or not. Do you ???

I have tried a conditional jump over a timer.

If wrote a demo program where I a conditional jump to a label. I had a timer between the jump and the label. Therefore this timer was most of the time. I noticed that the timer counted up very slowly when enable. I could see that it was only adding the current scan time when ever the timer was enabled and wasn't skipped. To fix this, I moved the timer behind the label so it could work properly scan.

The results backed up my theory of how timers worked. See my post above.

I have not tried conditionally executing a timer in a subroutine, but I would bet the results would be the same as conditionally skipping or jumping over the timer to a label.

This was done on a SLC 5/03 or SLC5/04.

Sorry Terry
I dont have the time right now to try the prog you suggested. I certainly didn't mean to get you angry by my post.

Everything I know about programming is self taught and I don't deal with programs on a daily basis. I deal with them as needed to get the machines up and running, and as my experience grows with each machine I find I need to view the programming less and less. Partly because I understand the sequence for the machines and what sensors should be where and what they do. And that just makes me want to learn more in depth but don't have the opportunity to "play" with programming a whole lot. Yes I can "play" at home with it but with 3 year old triplets running around there just isn't quite time.

Sorry again Terry

Drewcrew6

Drew,

You don't owe me an apology - no one does. I'm not and wasn't angry.

Using bold print and a lot of question marks doesn't mean I'm angry.

I'm a Technical Writer as well and can't help throwing in a little formatting to spice things up. It's a Terry-thing!

Not a big deal at all.

I read Peter's post. Now, I'm just wondering what anyone else found.

As far as your question about the Average Scan Time... I don't know.

I really learned a lot in this post....As Ron indicated, I've always been curious about the scan time/timer issue but have been too busy with real world issues......Terry, I like the subroutine test, if I have time this weekend at home I'll give it a shot and post the results here. I know this post is a couple years old, just curious if anyone has made any further discoveries.

Greg