3 types of "software" relays commonly used in PLC
On this page
What are the main software relays used in PLC programs?
The three workhorses are the latch (set/reset), the timer (on-delay, off-delay, retentive) and the comparator (compare and limit instructions). The latch holds a state until explicitly reset, the timer delays or extends actions, and the comparator makes decisions on analog or counted values. The failure mode to design against is the same for all three: an element whose reset or boundary condition was never defined, which is exactly the kind of logic bug that looks like a hardware fault on the floor.
An earlier version of this page opened with a customer case and failure statistics attributed to field service. Those could not be verified and have been removed. The explanations below stand on how the elements behave, which is what you need at the desk.
Latch relay (set/reset)
A latch maintains state regardless of its input: once set, it stays set until a separate reset instruction fires. This is what makes it right for alarm latching, pump status retention and safety-circuit memory, and also what makes it dangerous when used carelessly, because a latched output ignores whatever else is going on until something clears it.
Before deploying a latch, answer two questions in writing: what happens if power is lost, and what happens if the reset condition never occurs? If either answer is "undefined", the latch is not ready. Retentive behaviour across power cycles is a controller configuration (battery-backed or supercapacitor-retained memory), not a default, and critical applications often add a hardware latching relay as the second layer.
Illustrative ladder pattern
Set bit when start condition fires: SET(start_sensor, pump_latch). Reset bit when stop condition fires: RESET(stop_or_fault, pump_latch). The drive logic then reads pump_latch alone. The pattern is illustrative; instruction names differ by platform, and the reset path should include the fault conditions alongside the operator stop button.
Timer relays (TON / TOF / RTO)
Timers provide time-delayed activation or deactivation and are the backbone of sequencing. The on-delay timer (TON) waits its preset before turning on; the off-delay timer (TOF) holds an output after its input drops; the retentive timer (RTO) accumulates time across interruptions instead of resetting. Typical uses: soft-start sequences, staging delays between equipment, pulse generation, and anything where two events must not overlap.
The classic timer mistake is the timer that never resets, so the second cycle behaves differently from the first. Give every timer a defined reset path and watch it through at least two full cycles in simulation or online monitoring before trusting it.
Comparator relay (CMP / LIM)
Comparators turn analog values into decisions: compare a temperature to its setpoint, check a level against a band, supervise a pressure. Compare instructions (greater than, less than, equal) drive one output; limit instructions (LIM) test whether a value sits inside or outside a range. They are how the program reacts to the continuous world rather than to on/off signals.
The design point that separates working comparators from chattering ones is hysteresis: a deadband between "on" and "off" thresholds so the output does not toggle when the value hovers at the setpoint. Define the deadband with the selection, not as a later fix.
Selection guide
| Type | Best for | Common mistake to prevent |
|---|---|---|
| Latch (SET/RESET) | Alarm hold, memory, toggle states | No reset condition defined; map the reset path before coding |
| Timer (TON/TOF/RTO) | Sequencing, delays, pulses | Timer never resets between cycles; verify with a separate reset bit |
| Comparator (CMP/LIM) | Limits and monitoring on analog values | Hysteresis ignored; define the deadband up front |
Scroll the table horizontally to view all columns.
Software versus hardware relays
Software relays have clear advantages: no contact wear, instant modification, complex logic in little space, and no spare-parts shelf. Their limits are equally real: they consume scan time, they lose state on power loss unless retention is configured, debugging is less tangible than probing a physical relay, they never switch real current, and logic bugs hide better than burnt contacts do. Hardware relays remain the choice for high-current switching and as an independent layer for safety memory.
Common questions
Why does my latch not reset after a power cycle?
By default, software elements clear when the controller powers down. If the state must survive, configure retentive memory for that address, or use a hardware latching relay for the critical states. For safety functions, keep the software latch and add a hardware layer; the software copy alone is not the safety mechanism.
Can more than one latch drive the same output?
Technically yes, and it creates conflicts that surface weeks later. Track multiple set conditions in separate bits, derive the output from one combining rung, and let a single bit own the output. The program becomes readable and the conflicts disappear.
How do I debug a suspected software relay problem?
Use online monitoring to watch the bit while triggering inputs, and trace the set and reset paths separately. Most platforms allow forcing bits for testing; remove the forces when done. If the fault only appears after hours of running, look first at the elements with time in them: timers and retentive latches.
Sourcing help
KOEED supplies PLC hardware across the major brands, from compact controllers to safety-rated CPUs. Send the platform and part numbers, or the application description if you are selecting hardware for new logic.
Need a quote for this part?
Send us the part number or article link — we will confirm price, availability and lead time.