Timers are a staple of any PLC program, it’s extremely unlikely that any sizable project does not have a use case for a timer of any sort. This post takes us through some examples of how Timers work, use cases and also some insights into other less known areas.

What’s In This Post?

General Information

There are 3 types of timer that all have the same base type (IEC Timer), but behave slightly differently as to how they control their output.

All 3 types of Timer all share the same interface, consisting of the following:

• IN – Input – Bool – The input that starts the timer
• PT – Preset Time – Time – The length of time the timer will run for
• Q – Output – Bool – The result of the timer
• ET – Elapsed Time – Time – The current elapsed time of the timer

TON – Timer On Delay

The most common type of Timer is the TON, as shown in #R1.0.

This timers output value adheres to the following logic rules:

IF IN is True AND ET is Less Than Or Equal To PT THEN Q is True
Else Q is False

📝Note
If IN is False, ET = PT
If IN is True, ET is incremented towards the PT value

This is demonstrated in the following image, lifted from Siemens TIA Portal’s help system

TOF – Timer Off Delay

A TOF timer works the opposite way round to the TON timer, meaning the output is kept True whilst the timer is idle and not timing, but only after IN is set to True. It is on the transition to False that the timer starts.

Once started, it is not until the ET = PT that the Q value is set to False.

The output of a TOF timer adheres to the following rules:

IF IN is False AND ET is Less Than Or Equal To PT THEN Q is False
Else Q is True

Whilst the above statement is correct, it’s important to understand that the IN must have been True at some point in order for the Q to be True. The Q output will not be true on PLC start if the IN is not True

The below diagram, lifted from Siemens TIA Portal’s help system demonstrates this:

TP – Time Period

A TP timer will always complete its PT duration on the rising edge of IN. Even if IN falls to False, the timer will continue to time. During the execution of the PT duration, whilst PT <= ET, the Q is True.

The output of the TP timer adheres to the following rules

IF IN transitions from False to True THEN Q is True UNTIL ET >= PT

Even if IN becomes False whilst ET < PT, the Q output is remains True

Even if IN remains True whilst ET >= PT, the Q output returns to False

The following diagram, lifted from Siemens TIA Portal’s Help System demonstrates the above logic:

Preset Time

Each timer has a PT input, which sets the duration of the Timer. In order to set the PT value, the Time data type is used.

A 20 second period, represented as Time would look like T#20s when hard-coded on the interface of the Timer (See #R1.4 for example)

The PT input will also accept millisecond representations of time, for example 2000 would be T#2s. This is because the Time data type is represented in milliseconds as the base value, but visually shown as a “nice” T#2s value to keep things simple.

📝 Note
The value 7882000 as milliseconds is difficult for us to quickly work out as a time based value, so the Time data type serves as an easy way to visually read that. In this case it would be T#2H_11M_22s, which doesn’t need any further explanation

Changing The PT Value

Siemens handle IEC Timers a little differently to most other PLC vendors, opting for the rule that PT values can only be changed when Timers are NOT running. The example below demonstrates that despite the Timer’s PT value being changed from T#30s to T#15s, the Timer rolls through the 15s period, and all the way to 30s before the variable Complete is set to True

This is something that is important to understand, especially if the Timer is vital to a control function, or the PT value is dynamically assigned / calculated.

This does have an easy fix, but it is something that needs to be added for each Timer that is placed in your project.

There is a special Coil called a PT Coil. The purpose of this coil is to tell an instance of an IEC Timer to re-calculate the End Timestamp that the ET is expected to reach the PT. When the PT Coil is set to True, the instance of the Timer used will be updated and the timer will behave as expected.

The below example now behaves as we’d expect, stopping at T#15s now there is a PT Coil in use

📝 Note
Notice that in example #R1.7, when changing the PT value from T#30s to T#15s, the Timer stopped at T#15s as we’d expect. Also notice that once the Timer completed, setting the PT value back to T#30s, before 30s had elapsed since IN became True did not set Q back to False. This is because once Q is set to True, the Timer is unable to load a new PT value until the IN transitions back to False

TON_Time, TOF_Time and TP_Time Data Types

Each Timer type has its own instance data type, as shown above. This means that TON uses TON_Time, TOF uses TOF_Time and TP uses TP_Time.

However, a not-so-well-known secret of TIA Portal is that all of these timer instance data types are actually an alias for the data type IEC_Timer. You can actually mix and match all of the Timer types with any of the data types, and the project will compile and operate without issue.

The above image shows that a TON timer has an instance declaration as a TP_Time data type, yet is operating as a TON still. If it were to behave as a TP, we’d expect to see the Complete variable as True.

Do & Grow – Creating a Multi-Ability Timer

Because of this, we can exploit the fact that all timer types can use the TON_Time data type to create a 1 Timer Fits All super Timer.

This timer will be capable of the following functionality:

• No need for a PT coil – PT values will update the expected ET output every single time
• Mode Input – The timer can be configured as TP, TOF or TON on the interface of the block, or even programmatically
• RT output – Remaining Time output, a backwards countdown version of the ET
• Formatted time output – An easy to view and pass to SCADA version of the ET or RT

Self Restarting Timers

Sometimes you may need to restart a Timer the instant it has finished (or on the next scan at least), so that Q is only active for 1 scan before the Timer restarts.

The above video demonstrates how this can be achieved.

By using the inverse of Complete as the connection to the IN interface, whenever the Complete variable is True, on the next scan, the IN of the TON is False because the Complete is True.

This means the Timer resets, and sets the Q to False, which, on the next scan, starts the timer again.

We can see that the Complete is True for 1 scan because the INC (increment) function only executes once every 5 seconds. If Q was True for more than 1 scan, we’d see the Complete_Count value increase at a faster rate.

⚠️ Important
There is a bug in TIA Portal, which has been there since TIA V13 at least, where by using Instance Data of the Timer’s Q value to perform the same logic can result in erratic behaviour. It is always best to write Q to a Static variable and use that instead.

Using The ET Value For Time-Based Logic

You can use the ET value and a high fixed PT value to create time logic.

The above shows an example of using the ET value to drive logic through comparators. It also encompasses the same “Self Restarting” logic approach as the previous example.

Using the ET is a powerful way to control multiple outputs with a single timer. In basic logic, you may expect Output_A, Output_B and Output_C to have their own timers, with different Bool signals starting their respective timers… Which approach is actually more simple though?

Key Takeaways…

• PT Coils are important! Make sure you are including them in your logic if you want to be able to change the PT value whilst the timer is running!
• TON, TOF and TP timers all derive from the same base structure
• You can create your own timer that encompasses all of the other Timer types, giving you a 1-stop block to rule them all!

Check Out Another Post

General

Optimized / Non-Optimized – What’s The Difference?

by Liam (Site Owner)

September 18, 2022

Difference between Non-Optimized and Optimized Data Since TIA Portal came along, there’s been an argument between whether or not you…

Read More

• LinkedIn
• Facebook
• YouTube
• Twitter