Replacing Hardware Interrupts with B&R X20DS and reACTION Modules

Overview: Deterministic Runtime and the Missing User ISR

The B&R Automation Runtime executes every task class inside a deterministic scheduler. Unlike a general-purpose operating system where a user-defined interrupt service routine (ISR) can preempt the main thread, Automation Runtime deliberately hides hardware interrupt vectors from the application. This design protects cycle-time guarantees: a runaway ISR or a priority inversion cannot be allowed to starve the PLC, motion, or CNC classes that share the controller.

Engineers who search for a "hardware interrupt" equivalent on a B&R X20 system are usually trying to solve one of these problems:

• Capture the exact arrival time of a digital edge with microsecond accuracy.
• Measure pulse width, period, frequency, or duty cycle on a fast or noisy signal.
• React to an edge with a latency well below the PLC task cycle.
• Generate a deterministic output in response to an event, independent of the application cycle.

Every one of these can be solved inside the B&R ecosystem by moving the time-critical work out of the CPU and onto a dedicated module. This reference covers the four families B&R ships for that purpose and the configuration patterns that replace a traditional hardware ISR.

Why Automation Runtime Excludes User-Defined ISRs

The scheduler in Automation Runtime reserves the interrupt subsystem for internal services such as the X2X cycle, POWERLINK, and Ethernet/IP communication. If an application register an ISR, it could:

• Exceed the worst-case execution time (WCET) budget of the active task class.
• Cause jitter in the bus cycle, breaking deterministic communication.
• Block higher-priority system handlers required for motion or safety.

Consequently, the B&R runtime exposes edges, counters, and timestamps as cyclical data points, not as asynchronous callbacks. The cycle time you set on the I/O mapping or the PLC task becomes the implicit "interrupt period," and the module becomes the ISR. The X2X backplane preserves determinism because every cycle has a fixed maximum duration; the module captures the edge locally and the PLC reads the result on the next cycle boundary.

Alternative Approaches for Time-Critical Digital Input Capture

There are four practical replacements, ordered from simplest to most capable:

1. Cyclic poll on a standard X20DI module – adequate when the signal is slow (tens of Hz) and the cycle time of the smallest PLC task is shorter than the shortest pulse.
2. Digital counter module (X20DCxxxx) – off-loads pulse counting, frequency, and duty-cycle calculation to module firmware.
3. Digital signal processing module (X20DSxxxx) with edge detection – captures rising and falling edges together with a 64-bit NetTime timestamp.
4. reACTION module (X20RTxxxx) – executes application-defined logic on the module itself, independent of the PLC cycle.

Each approach is presented below with the relevant register layout, performance bounds, and programming pattern.

Cyclic Polling with Deterministic Cycle Times

For slow signals (typically below 50 Hz), the simplest solution is to map the digital input to a Boolean tag and read it from a fast cyclic task. B&R Automation Studio lets you assign any input to any task class, and the minimum achievable cycle time depends on the controller:

Sub-millisecond cyclic tasks are achievable on many controllers but are not available on every CPU variant. Confirm the limit on the controller's data sheet in B&R PLC product overview before assuming a 500 µs loop is possible.

X20DS Modules: Digital Signal Processing Overview

The DS suffix denotes digital signal processing. X20DS modules are designed for high-speed digital inputs that need timestamping, pulse-width measurement, or edge-rate counting that an ordinary X20DI module cannot deliver.

The X20DS1319 is the canonical example called out in B&R field guidance: it stores the time at which each rising and falling edge occurred in module-local memory and exposes the values as cyclical data on the X2X frame. The PLC reads the most recent edge timestamps during its normal I/O update without any ISR or callback.

X20DS1319 Edge Detection and NetTime Timestamping

The X20DS1319 captures edges on four inputs and timestamps each transition with the controller's NetTime value. NetTime is a 64-bit time base synchronized across all B&R devices on the same POWERLINK or X2X network, with the lower bits incrementing in module-internal increments as fine as 20 ns.

Register layout (per channel, simplifyed):

EdgeTimeLast        : DINT;   // NetTime low, last edge
EdgeCounterRising   : UDINT;  // count of rising edges
EdgeCounterFalling  : UDINT;  // count of falling edges
Status              : UINT;   // edge buffer level + module status

On every X2X cycle the module updates the timestamp register with the most recent edge and increments the matching counter. The PLC simply reads the registers in its cyclic task and computes:

// Structured Text example
IF bNewEdgeRising THEN
    // NetTime is split into high (sec) and low (ns) parts
    dwEdgeTimeLow := X20DS1319.Ch0.EdgeTimeLow;
    // difference from previous edge
    dwPeriod_ns := dwEdgeTimeLow - dwLastEdgeTimeLow;
    fFrequency_Hz := 1.0E9 / DWORD_TO_REAL(dwPeriod_ns);
END_IF;

The minimum two-edges-apart period that the X20DS1319 can resolve is dictated by the input filter. With the standard 1 µs filter disabled in Module Configuration > Filter, edges 50 ns apart can be distinguished, well below any 20 Hz signal encountered in practice. For slow signals the filter can be raised to 100 µs or 1 ms to debounce noisy mechanical contacts.

reACTION Technology: Module-Local Fast Logic

reACTION moves the fast logic out of the CPU entirely. A reACTION module (e.g. X20RT8001 or X20RT8381) executes a small ladder or C program on the module itself with response times as low as 1 µs. The module behaves like a coprocessor: digital inputs come in, the on-module logic runs, and digital outputs or status bits go out without ever crossing the X2X bus.

Typical use cases that map directly to "hardware interrupt" requirements:

• Trigger a fast output within 2 µs of an edge.
• Latch the last input state with deterministic timing.
• Run a PID or PWM loop with cycle times down to 50 µs.

Programming is performed in Automation Studio under Tools > reACTION Configurator, and the generated code is downloaded once. After commissioning the reACTION module operates without PLC intervention, freeing the PLC to handle slower application logic. See the B&R product downloads portal for the matching reACTION firmware manuals that document each module's I/O wiring and function block library.

X20DC Counter Modules for Frequency/Duty-Cycle Measurement

The DC family is purpose-built for counter, frequency, and duty-cycle measurement. Modules such as the X20DC2396, X20DC4395, and X20DC1196 provide increment counters, AB quadrature decoding, and configurable measurement modes. Many expose a direct frequency or duty-cycle register in Hz or percent, eliminating the need to derive the value in the PLC.

For a 20 Hz signal that must be monitored for frequency stability, an X20DC2396 in Frequency Measurement mode produces a fresh value every measurement window (configurable from 1 ms to 60 s). The PLC reads the Hz value directly without performing any timing math, which is the cleanest replacement for a polling-frequency ISR loop.

Selecting the Right Module: Decision Matrix

General rule of thumb: if the period of the signal is shorter than the smallest achievable PLC cycle, you need a DS, DC, or RT module. Otherwise a normal DI plus a fast task is sufficient.

Configuration and Programming Pattern

The following end-to-end pattern captures the period of a digital signal with the X20DS1319. It mirrors the standard procedure documented in the B&R Help portal for the module.

1. In Automation Studio > Logical View, add the X20DS1319 under the X2X bus node.
2. Open Module Configuration, disable the input filter, and enable Edge Detection for channel 0.
3. Map the four status registers to a user-defined structure (EdgeTimeLow, EdgeCounterRising, Status).
4. Create a cyclic task with a 1 ms cycle time and declare the structure as a global variable.
5. In the program body, copy EdgeTimeLow on each rising-edge flag and compute the delta against the previous value.
6. Convert the delta (in ns) to seconds, then to Hz. Apply a moving average if the signal has jitter.
7. Read the Status register bit Buffer Overflow once per cycle to detect missed edges; if set, shorten the cycle or move to an X20DC counter module.

Verification Checklist

• Inspect Online > Module Diagnostics and confirm no X2X errors and the bus cycle time matches the configuration.
• Force a 1 kHz square wave into channel 0 and confirm EdgeCounterRising increments by 1000 within 1 s of expected windowing.
• Toggle frequency from 10 Hz to 100 kHz and confirm Buffer Overflow stays at zero on the smallest acceptable X20DS1319 cycle.
• Trace the calculated Hz value against an external counter to confirm accuracy within the chosen resolution.

Troubleshooting Matrix

When the Cyclic Approach Is Enough

For a 20 Hz signal with no sub-millisecond accuracy requirement, the cyclic poll on an X20DI module is genuinely the right answer. The response is deterministic, the cost is the lowest in the catalog, and the configuration effort is essentially zero. Choosing DS, DC, or RT modules for slow signals burns money on capability that the application does not need.

Frequently Asked Questions