Three Considerations for Programming a Control System Timer

This week, several of us tackled programming solutions where timers were the linchpin.  On one project, a timer was extending cycle time, which caused a huge production back up.  Changing the length of the timer restored smooth production.  On another, we were testing a change to a robotic system. To reduce the risk of damaging equipment, we were running the robot slower than normal. There were many timers that did not cause any issues if the robot was at 100%, but if we ran too slowly, the timers would trip and cause excessive nuisance faults greatly increasing the time it took us to test the system.

This got us thinking:  What do we, as programmers, need to consider when choosing to use a timer in a control system?

Sensor vs. Timer

The first consideration is whether you should use a timer at all.  The downside of using a timer is that the motion of a part could actually change over time for a number of reasons. Mechanical wear or settings being adjusted (speed of equipment, air pressure, communication time) can affect timing of a system.  This could cause issues down the road, such as excessive cycle time or incorrect operation of the machine.

Therefore, before you decide to use a timer, consider using a sensor.  Instead of assuming that something happened based off a time duration, is there a sensor you could use to positively tell that it happened?  One example would be if cylinders had advanced all the way.  In that case, it might be better to add a sensor that detects the cylinder, rather than assuming how much time it would take for the cylinder to advance.

Types of Timers

Retentive vs. Non-Retentive Timers

There are many types of timers to use.  One choice a programmer must make is between retentive and non-retentive timers.  A retentive timer continues recording the total amount of time until it is reset.  This is even retained when the system is powered off.  A non-retentive timer uses event specific timing.  It is reset every time the particular motion or event occurs.

Debounce Timers

Debounce timers can be a wonderful tool, but occasionally, we have seen them used too frequently.  Two questions to consider before adding a debounce timer are:

• Does the input or signal actually bounce?
• If so, how long does it bounce for?

Having a debounce timer that lasts too long could adversely affect cycle time.  An extra second or two on a cycle may not seem like much time, but it adds up!

Length of Timer

Deciding on the length of a timer is highly dependent upon what it will be used for.

If a timer is used to detect a fault condition, if the time is set too short, it could cause nuisance faults (faults that occur when there isn’t actually an issue). For example, if you have a pallet that is supposed to move from station to station within 10 seconds, you might want to set a fault to indicate that the pallet hasn’t arrived in time. If you set the time period right at 10 seconds, you might have an excessive amount of faults. You might want to set your fault time to 15 seconds or so.

Precision of a timer is also a factor to consider. Within PLCs, timers are only as accurate as the cycle time of the PLC.  If precision required for your time-based event is tighter than the cycle time of the PLC, or if you do not want the time to vary at all, such as when using a PID controller, you might want to look into time-based interrupts rather than using timers within your standard logic.

What factors do you consider when programming a timer?