What Are Interrupts in PLC Programming?

Programmable Logic Controllers (PLCs) form the backbone of industrial automation, controlling everything from assembly lines to chemical processes. Their ability to respond immediately to critical events without scanning the entire program is made possible through interrupts. An interrupt is a hardware or software signal that pauses the normal cyclic execution of a PLC program to run a dedicated interrupt service routine (ISR). Once the ISR completes, the PLC resumes the main program from where it left off. This event-driven approach allows engineers to guarantee response times for safety-critical operations such as emergency stops, over-temperature alarms, or communication timeouts.

The standard PLC scan cycle reads inputs, executes the program logic, updates outputs, and performs housekeeping tasks. Without interrupts, a high-priority event might have to wait until the end of the current scan cycle, introducing an unacceptable delay. Interrupts bypass this cycle, inserting an immediate handling routine that runs asynchronously with respect to the main program. This mechanism is especially valuable in high-speed applications like packaging, bottling, or robotic cell control where timing windows are measured in microseconds.

Types of Interrupts in PLCs

PLCs support several categories of interrupts, each suited to different event types. The two primary classes are hardware interrupts and software interrupts, but modern PLCs also support timed interrupts and communication interrupts.

Hardware Interrupts

Hardware interrupts originate from external digital or analog signals. Common sources include limit switches, proximity sensors, pushbuttons, encoder zero-pulse signals, and safety devices. When the hardware input changes state (e.g., rising edge, falling edge, or level), the PLC’s hardware logic immediately triggers the corresponding ISR. For example, a conveyor system may use a hardware interrupt from a photo-eye to stop the motor instantly when a jam is detected.

Software Interrupts

Software interrupts are generated internally by the PLC program or operating system. They can be triggered by arithmetic errors (e.g., division by zero), overflow conditions, or when a timer reaches a specific value. Some PLC platforms allow the programmer to manually raise a software interrupt from any point in the code. This is useful for handling exceptions or implementing custom event-driven subroutines without relying on external wiring.

Timed Interrupts

Many PLCs provide periodic or one-shot timed interrupts that execute an ISR at precise intervals, independent of the main scan cycle. Timed interrupts are ideal for tasks that require consistent execution rates, such as PID loop calculations, encoder position tracking, or data logging. For instance, a timed interrupt every 10 ms can ensure a PID controller updates its output at a fixed frequency, even if the main program scan time varies.

Communication Interrupts

Modern PLCs with built-in Ethernet, Profibus, or Modbus interfaces often use interrupts to handle incoming messages without polling. When a data packet arrives, a communication interrupt pauses the main program to parse the message and update shared data buffers. This reduces latency and frees up CPU cycles for other tasks.

Implementing Interrupts for Event Handling

Implementing interrupts requires careful configuration in the PLC programming environment. Most platforms (e.g., Siemens TIA Portal, Rockwell Studio 5000, Schneider EcoStruxure) provide a dedicated interrupt configuration pane where the engineer selects the trigger source, assigns an ISR program, and sets priority levels. The ISR itself is typically written in the same language as the main program—Ladder Diagram, Structured Text, Function Block Diagram, etc.

When writing an ISR, keep the routine short and deterministic. The ISR should only handle the immediate event and set necessary flags or outputs, leaving higher-level logic for the main program. For example, an emergency stop interrupt might directly de-energize a safety relay output and set a "E-Stop Active" flag, but the logic to acknowledge the stop, reset alarms, and restart the process should reside in the main program.

One common pitfall is using instructions that take variable execution times (e.g., communication reads, file access) inside an ISR. Such operations can cause the ISR to exceed its allowed execution window, potentially corrupting data or causing the PLC to fault. Use only deterministic, fixed-time instructions inside the ISR.

Interrupt Latency and Priority Management

Interrupt latency is the time between the trigger event and the first instruction of the ISR. This delay depends on the PLC’s processor speed, the interrupt controller hardware, and whether other higher-priority interrupts are currently being serviced. In most industrial PLCs, worst-case latency is in the range of microseconds to a few milliseconds. For ultra-fast applications (e.g., servo drive positioning), some PLCs offer interrupt inputs directly wired to the motion controller core.

Priority levels allow engineers to decide which event gets serviced first when multiple interrupts occur simultaneously. Typically, a higher priority interrupt will preempt a lower priority one. For example, a safety-related interrupt (emergency stop) should have the highest priority, while a diagnostic event (low battery) can have a lower priority. Careful priority assignment prevents missed critical events while allowing lower-priority ISRs to eventually run.

Some PLCs support nested interrupts, where an ISR itself can be interrupted by an even higher-priority event. Engineers must weigh the benefits of nesting against the risk of stack overflow or unstable system behavior. In practice, many safety standards (e.g., IEC 61508) forbid nested interrupts in safety-related functions to maintain deterministic behavior.

Interrupts vs. Polling: When to Use Each

Polling is the traditional method of checking input states repeatedly during each scan cycle. While simple to implement, polling introduces a delay equal to the scan time. For events that occur infrequently or are not time-critical, polling is often sufficient. Interrupts, however, are necessary when:

  • The event requires a response faster than the minimum possible scan time.
  • The event is sporadic and waiting for a scan cycle would waste CPU resources.
  • The event has safety implications demanding immediate action.
  • Precise timing (e.g., capturing a pulse width) is required.

A typical hybrid approach uses interrupts for the most urgent events and polling for all other inputs. For instance, a packaging machine might use an interrupt for the cut knife position sensor (timing critical) but poll the operator panel buttons every scan cycle.

Common Use Cases for PLC Interrupts

Emergency Stop Systems

In safety-critical applications, a hardware interrupt from an emergency stop button should immediately halt all dangerous motion. The ISR typically writes a zero-speed command to drives and sets a safety relay reset latch. Many safety PLCs comply with standards like ISO 13849-1, requiring interrupt response times under 100 ms.

Encoder Zero-Pulse Alignment

For servo and stepper motor applications, an encoder’s zero-pulse (index) signal triggers an interrupt to reset a position counter. This ensures accurate home positioning without drift. The ISR might also initiate a calibration routine or toggle a "home found" flag.

Fast Counter/Timer Events

High-speed counters measuring pulses from flow meters, tachometers, or rotary encoders use interrupts to increment counts without missing pulses. The ISR updates a counter value in shared memory, which the main program reads periodically.

Communication Error Recovery

When a fieldbus detects a CRC error or loss of signal, a communication interrupt can activate a predefined safe state for outputs (e.g., set all analog outputs to 0%, close valves). This prevents erratic behavior during network disruptions.

Best Practices for Using Interrupts

  • Keep ISR routines short and deterministic – Avoid loops, variable-length operations, and subroutines that call other blocking functions. Aim for execution times well under 1 ms.
  • Prioritize interrupts based on importance – Assign highest priority to safety events, then fast machine control, then diagnostics. Document the priority scheme in the project manual.
  • Test interrupt handling thoroughly – Simulate worst-case scenarios where multiple interrupts fire simultaneously. Verify that the system returns to a known safe state after each event.
  • Document all interrupt routines clearly – Include the trigger condition, expected behavior, and any side effects (e.g., global variable modifications). Use comments inside the ISR for maintainability.
  • Use global variables to pass data between ISR and main program – Protect shared data with atomic access or semaphores if the PLC supports them. Some platforms automatically disable interrupts during data reads to prevent corruption.
  • Be cautious with interrupts in safety-related logic – Follow applicable safety standards (IEC 62061, ISO 13849) and use certified hardware that guarantees interrupt latency and error handling.

Programming Language Support for Interrupts

Interrupts are supported in all five IEC 61131-3 languages, though implementation details vary:

  • Ladder Diagram (LD) – ISR shown as a separate ladder routine with dedicated inputs/outputs. Often used for simple boolean-based interrupts.
  • Structured Text (ST) – More flexible for complex arithmetic and conditional logic inside the ISR. Preferred for high-performance interrupt handlers.
  • Function Block Diagram (FBD) – Can visually represent the ISR logic using blocks. Best for signal processing and mathematical operations.
  • Instruction List (IL) – Still available in legacy systems, though rarely used for new development.
  • Sequential Function Chart (SFC) – Can embed interrupt actions within steps, but not typically used for standalone ISR definitions.

When selecting a language, consider the team’s familiarity and the complexity of the event handler. For high-speed counters, Structured Text or LD with dedicated interrupt instructions is common. For communication interrupts, FBD may provide clearer signal flow.

Interrupts in Safety PLCs vs. Standard PLCs

Safety PLCs (e.g., Siemens F-series, Rockwell GuardLogix, Schneider M580 Safety) have stricter requirements for interrupt handling. They must detect any interrupt failure (e.g., missed event, delayed execution) and force a safe state. Safety-certified systems often use redundant interrupt controllers and diagnostic checks. In contrast, standard PLCs may allow more flexible programming but do not guarantee fail-safe behavior under fault conditions. Engineers must choose the appropriate PLC category based on the risk assessment of the application.

Real-World Example: Interrupt-Driven Bottle Filling Machine

Consider a high-speed bottle filling machine that must stop the conveyor exactly when a bottle reaches the filling nozzle. A photo-sensor triggers a hardware interrupt. The ISR immediately stops the conveyor drive (via a discrete output) and starts the fill timer. Meanwhile, the main program monitors fill level, controls the valve, and tracks total production count. Without the interrupt, the conveyor would stop only at the end of the current scan cycle, causing misalignment and spillage. This example demonstrates why interrupts are indispensable for precise event synchronization.

For further reading on interrupt configurations in specific PLC platforms, refer to: Siemens TIA Portal Interrupt Handling and Rockwell ControlLogix Event Tasks Guide.

Common Pitfalls and How to Avoid Them

  • Ignoring interrupt nesting limits – Stack overflows can crash the PLC. Configure a maximum interrupt depth and test it.
  • Using blocking calls inside ISR – Avoid RTC_GetTime or Mailbox_Send functions that may wait. Use non-blocking versions or schedule those tasks in the main loop.
  • Sharing variables without protection – If the main program reads a variable that the ISR modifies, use a volatile qualifier and consider disabling interrupts briefly during the read. Some compilers have built-in atomic instructions.
  • Overloading the interrupt controller – Too many high-frequency interrupts can saturate the CPU and degrade overall response. Use polling for low-priority events.

Conclusion

Mastering interrupts in PLC programming is a fundamental skill for industrial automation engineers. They enable millisecond-level responses to critical events, improve system reliability, and allow designs to meet strict safety standards. By understanding the types of interrupts, implementing short and deterministic ISR routines, and managing priorities carefully, engineers can build control systems that are both responsive and robust. As automation demands increase—driven by Industry 4.0 and real-time data processing—the proper use of interrupts will remain a cornerstone of effective PLC programming.

For additional insights on event-driven PLC design, the ISA’s PLC Programming Guide and the Automation World article on interrupts offer practical case studies.