B&R X2X Link Protocol — Wire-Level Technical Reference

Scope: B&R (Bernecker + Rainer, now ABB) X2X Link and X2X+ backplane/remote-I/O bus systems used in the X20, X67, and Compact-S product families.

Date: July 2026 — Compiled from official B&R datasheets, system manuals, community posts, and third-party technical articles.

Table of Contents

1. Protocol Overview
2. Physical Layer
3. X2X Frame Format and Wire-Level Encoding
4. Timing, Bit Rate, and Synchronization
5. Node Addressing
6. Protocol Versions — X2X Link vs X2X+
7. Error Handling and Diagnostics
8. Sniffing / Tapping X2X Traffic
9. Decoding IO Card Sensor Data at the Protocol Level
10. Pinpointing Failing IO Modules / Channels from Captured Traffic
11. Tools for X2X Analysis
12. Component Reference Tables
13. Source URLs and References

1. Protocol Overview

X2X Link is B&R’s proprietary real-time deterministic bus protocol designed for:

• Backplane communication between I/O modules on the X20/X67 bus bases
• Remote I/O expansion up to 100 m from the controller
• Providing a single unified protocol for both local (backplane) and remote (cable) I/O, eliminating the need for separate fieldbus-to-I/O gateways

Key characteristics:

IMPORTANT CAVEAT: B&R has never publicly released a wire-level protocol specification for X2X Link. The frame structure, checksum algorithm, and bit-level encoding described below are reconstructed from official hardware documentation, system manuals, community knowledge, and reverse-engineering observations. Some details are necessarily incomplete or inferred.

2. Physical Layer

2.1 Backplane (X20 Local Bus)

On the X20 backplane, X2X Link is carried on the module-to-module bus connectors (8-pin keyed connectors at 12.5 mm pitch). The protocol runs at 12 Mbps over PCB traces directly between modules slotted onto the bus base.

• Each X20 module has an 8-pin bus connector on each side (left/right)
• Modules are physically clipped together onto a DIN-rail-mounted bus base
• The bus base carries: X2X data lines, +24 VDC, GND, and I/O power
• No external cabling is needed for local backplane communication

2.2 Remote X2X Link (Cable)

For remote I/O expansion, X2X Link uses a differential-pair serial link over shielded twisted-pair copper cable. The physical layer is electrically compatible with EIA-485 (RS-485) transceivers, but the protocol and data encoding are entirely proprietary — it is NOT standard UART/RS-485 framing.

2.2.1 Connector — M12, B-keyed, 5-pin

All X2X Link remote cable assemblies use B-keyed M12 circular connectors:

Critical note about pin 1 (Red wire / X2X+): Pin 1 carries both the X2X Link data signal AND the +24 VDC power supply for the remote X2X backplane. When connecting to devices with their own power supply (e.g., IF789 or LS189 interfaces), the red wire end must be insulated (heat-shrink) to prevent short circuits. For standard X2X remote stations (X20BR9300, X67 modules), pin 1 provides both data and power.

Source: X2X Link Cables Data Sheet V2.21

2.2.2 Cable Specifications

Standard pre-assembled cable lengths: 0.25 m, 1.0 m, 1.5 m, 2.0 m, 5.0 m, 10.0 m, 15.0 m, 25.0 m, 50.0 m. Bulk cable (X67CA0X99) available in 100 m and 500 m drums for custom assembly.

Cable part numbers:

• X67CA0X01.xxxx — Straight M12-to-M12 connection cables
• X67CA0X11.xxxx — Angled (90°) M12-to-M12 connection cables
• X67CA0X21.xxxx — Straight female-to-open attachment cables
• X67CA0X41.xxxx — Straight male-to-open open cables
• X67CA0X51.xxxx — Angled male-to-open open cables
• X20CA0X48.xxxx — X20 system attachment cables (open-ended one side)

2.2.3 Termination

• 120Ω termination resistors are required at both ends of each X2X Link segment
• B&R dedicated terminator: X20AT6100 (120Ω, 0.25W)
• DC resistance measured between X2X+ and X2X⊥ at bus ends should read ~60Ω (two 120Ω resistors in parallel when both terminators are installed)
• Some modules have built-in termination switches/jumpers

2.2.4 Topology

• Daisy-chain / multi-drop — modules are connected serially with an IN and OUT port
• Each X20BR9300 bus receiver has two X2X ports for daisy chaining
• Maximum of 100 m total cable length per segment
• The X2X Link bus is fed by the X20BR9300 bus receiver (or X20BT9100 transmitter)
• After approximately 30 modules on a single segment, a bus repeater (another X20BR9300/X20BT9100) is needed
• Shield must be grounded at both ends for best EMC immunity; ground the supply line as close as possible to the shield connection point

2.2.5 Physical Verification Checklist

1. Verify DC bus voltage: Should be 2.5V ±0.5V between X2X+ and X2X⊥ when idle
2. Verify DC resistance between A+ and B-: ~60Ω with both terminators installed
3. Check cable shield grounding: One-point grounding minimum, two-point preferred
4. Confirm segment length ≤ 100 m
5. Confirm terminator at first and last node
6. Check for ground potential differences between panels
7. Verify power supply sequencing: X2X modules stabilize before CPU initialization

3. X2X Frame Format and Wire-Level Encoding

3.1 What Is Known

B&R has not published the X2X Link wire-level protocol specification. The following is reconstructed from multiple sources:

3.2 Physical Signaling

• The X2X Link uses differential signaling over twisted pairs, electrically compatible with RS-485 transceivers
• The bus operates at 12 Mbps on the backplane; remote cable speed is determined by the transceiver and cable quality (B&R specifies up to 12 Mbps with their qualified cable over 100 m)
• The encoding is NOT standard UART/async serial (no start/stop bits in the conventional sense). The protocol uses a synchronous, clock-recovered NRZ-like encoding with its own frame delimiters and bit-stuffing
• The master provides the clock reference for all slaves on the bus

3.3 Inferred Frame Structure

Based on community observations and reverse-engineering efforts, X2X Link frames appear to follow this general structure:

┌──────────┬──────────┬──────────┬──────────────┬─────────┬──────────┐
│ Preamble │ Sync     │ Header   │ Payload Data │ CRC/FCS │ EOM      │
│ (edge    │ Pattern  │ (address │ (I/O data,   │ Checksum│ End of   │
│  training│ (unique  │ + ctrl + │ config,      │         │ Message  │
│  for PLL │ word for │ frame    │ diag)        │         │ marker)  │
│  lock)   │ framing) │ type)    │              │         │          │
└──────────┴──────────┴──────────┴──────────────┴─────────┴──────────┘

3.4 Frame Types (Inferred)

The X2X Link master cyclically transmits the following frame categories:

3.5 Cyclic Communication Model

The X2X Link operates on a master-slave polling model within each cycle:

1. Master broadcasts a poll frame containing the destination node address and output data
2. The addressed slave responds with input data and status information
3. Master polls the next slave in sequence
4. All slaves are polled once per cycle time
5. The cycle repeats deterministically

This means: Cycle time ≥ (number_of_slaves × per_slave_transaction_time) which is why the X2X cycle time must be at least as fast as the task class that reads/writes its I/O.

NOTE: The exact byte-level frame format, sync word values, CRC polynomial, and bit-level encoding remain proprietary. B&R has not released this information. Any attempt to fully decode X2X traffic from raw captures would require either (a) a leaked specification or (b) significant protocol reverse-engineering effort.

4. Timing, Bit Rate, and Synchronization

4.1 Bit Rate

Source: B&R System Overview I/O, Fieldbus, and Control Systems (2011/2012 edition) — X20IF1061 and X20IF1063 interface modules listed with “X2X Link, baudrate max. 12 Mbps”

4.2 Cycle Time

The X2X Link cycle time is user-configurable in Automation Studio:

The cycle time determines how fast I/O data is updated:

• At 2 ms cycle time: I/O is refreshed 500 times per second
• At 0.5 ms cycle time: I/O is refreshed 2000 times per second
• The X2X cycle time directly affects the cyclic task classes in Automation Studio; task classes must have cycle times that are multiples of the X2X cycle

4.3 Synchronization Mechanism

• The master node (CPU or bus controller) generates the timing reference for the entire X2X bus
• All slave nodes synchronize to the master’s clock via the X2X frame preamble and sync patterns
• When an ACOPOS drive (POWERLINK) is added to the configuration, the system timer configuration changes to “EPL/X2X Interface” mode, and the POWERLINK and X2X interfaces share the same timing base
• POWERLINK cycle time must be a multiple of 400 μs for motion control applications
• IO-Link cycle times can be synchronized to or explicitly specified independently from the X2X cycle time

4.4 Timing Constraints

• The X2X cycle time must match or be compatible with the task class cycle times that read/write the I/O mapped to that X2X bus
• If a stepper motor controller (e.g., X20SM1436) runs in a 4 ms task, the X2X bus must also run at ≤ 4 ms (typically the same value)
• Default X2X cycle: 2 ms; default POWERLINK cycle: 10 ms (but these can be changed independently in Automation Studio)

Source: Pedronf65 blog post on B&R task timing configuration

5. Node Addressing

5.1 Addressing Scheme

Each X2X Link node has a unique 1-byte address in the range 0x01 to 0xFD (1 to 253 decimal). Address 0x00 has a special meaning (automatic assignment).

5.2 How Nodes Get Addresses — Two Methods

Method 1: Manual Address via DIP Switches

Bus modules equipped with node number switches (e.g., X20BM05) allow manual address assignment:

• Two rotary/hex switches labeled ×16 and ×1 provide a range of 0x00 to 0xFF
• The actual address is: (×16 switch value × 16) + ×1 switch value
• Setting the switches to a value in range 0x01–0xFD sets the X2X Link address permanently for the bus base
• Setting 0x00 enables automatic address assignment (see below)
• Placing a node-number-switch module at the beginning of an X20 block ensures a unique address base; subsequent modules in the block are auto-numbered upward from that base

The switches are physically located on the bus module (bottom of the module), with symbols printed on the locking lever for external visibility.

Method 2: Automatic Address Assignment

• When a bus module’s node number switches are set to 0x00, the X2X Link address is automatically assigned by the master during initialization
• The master assigns addresses in ascending order starting from the last known address + 1
• Manual and automatic addressing can be combined: place one manually-set module to establish a unique base, then let subsequent modules auto-assign

5.3 Address Assignment Rules

• No two nodes on the same X2X segment may share the same address
• The master (CPU/bus controller) always has the lowest address (typically 0x01)
• Addresses must match the configuration in Automation Studio
• Changes to node number switches only take effect after a power cycle
• The X2X Link address is independent of the electronics module plugged into the slot — it depends only on the bus module’s switch setting

5.4 Addressing on X67 System

On X67 remote I/O blocks:

• The left node number switch sets the upper nibble (×16)
• The right node number switch sets the lower nibble (×1)
• Combined value forms the X2X Link address

6. Protocol Versions — X2X Link vs X2X+

6.1 X2X Link (Original)

6.2 X2X+ (Enhanced)

6.3 Key Differences

From B&R press release (Jan 30, 2023):

“X2X+ enables faster data transfer and up to four times faster response times. In combination with this higher bandwidth, large amounts of data can be handled quickly and easily.”

Source: B&R “Four times more performance” press release

6.4 Migration Notes

• Existing X20 I/O modules are compatible with both X2X Link and X2X+
• If X2X+ is selected in Automation Studio as the backplane bus, all local modules use X2X+; remote X2X Link segments require a separate X2X Link interface
• A separate X2X Link interface module is needed if you need to connect X2X Link remote stations to an X2X+ system

7. Error Handling and Diagnostics

7.1 CPU Operating Modes

7.2 Module-Specific LED Diagnostics

7.3 CPU Error Codes (7-Segment Display)

7.4 Common Failure Modes

7.5 X2X Bus Configuration Error Detection

• During initialization, the master sends configuration frames to each slave in sequence
• If a slave does not acknowledge configuration within the timeout period, that node is marked as not configured
• Address conflicts (duplicate addresses) will cause initialization failures for the conflicting nodes
• The X2X bus is completely inactive if the CPU is not in RUN mode — this is by design, as a safety measure

7.6 Power Supply Sequencing

• 24 VDC power to X2X modules must stabilize before CPU initialization
• Recommended sequence:
  1. Disconnect all 24 VDC power
  2. Wait 60 seconds for complete discharge
  3. Reapply power to X2X modules first, wait 2 seconds
  4. Apply power to CPU
  5. Observe LED sequences during boot

7.7 Reset Button Behavior

• Brief press: Warm restart — application program remains in memory
• Hold 3+ seconds then release: Warm restart with re-initialization attempt
• Hold 10+ seconds during power-on: Cold start — clears retain variables, forces complete re-initialization
• Cold start can also be triggered via Automation Studio command

8. Sniffing / Tapping X2X Traffic

8.1 Challenge Level: HIGH

X2X Link is a 12 Mbps differential serial protocol on a proprietary physical layer. There is no off-the-shelf Wireshark dissector or commercial protocol analyzer that natively supports X2X Link. Sniffing requires custom hardware and software.

8.2 Physical Tap Points

For the remote X2X Link cable, the tap point is straightforward — you have accessible M12 connectors. For the local backplane, you would need to either:

• Probe the PCB traces directly (requires opening the module housing)
• Tap into the bus connector pins using fine-pitch probe clips

8.3 Hardware Options

Option A: High-Speed Logic Analyzer

REQUIREMENT: At 12 Mbps, one bit period is ~83.3 ns. You need a minimum of 4-5 samples per bit (16-20 ns resolution), so the logic analyzer must sample at ≥ 48-60 MS/s per channel. A 100 MS/s or better analyzer is strongly recommended.

Option B: RS-485 Transceiver Tap Board

Build a simple passive tap:

                    ┌─────────────────────┐
  X2X Master ──────│ A (non-inverting)    │────── Logic Analyzer CH1
                    │ B (inverting)       │────── Logic Analyzer CH2
  X2X Slave ───────│ GND                 │────── Logic Analyzer GND
                    │                      │
                    │ 120Ω term (switchable)│
                    └─────────────────────┘

• Use a high-speed RS-485 transceiver rated for ≥ 20 Mbps (e.g., SN65HVD1782, MAX1487, ADM485)
• Add a switchable 120Ω termination resistor to avoid affecting bus operation when tapping mid-segment
• Power the tap board from an isolated supply to avoid ground loops
• Connect the transceiver output to the logic analyzer’s digital inputs

Option C: Differential Probe + Oscilloscope

• A differential probe (e.g., Tektronix P5200 or equivalent) connected to an oscilloscope can visually capture the X2X signal waveform
• Not suitable for long captures or automated decoding, but useful for verifying signal integrity and estimating baud rate

8.4 Capture Procedure

1. Identify tap point: Disconnect the X2X cable at a convenient junction (between master and first slave, or between two slaves)
2. Install passive tap: Insert the tap board inline. Ensure termination is correct (tap mid-segment: no termination; tap at end: enable termination)
3. Configure logic analyzer:
   • Sample rate: ≥ 100 MS/s (≥ 200 MS/s recommended)
   • Channels: CH1 = X2X+ (data+), CH2 = X2X⊥ (data-)
   • Trigger: Rising or falling edge on CH1
   • Capture duration: ≥ 2× X2X cycle time (4 ms at 2 ms cycle)
4. Start capture and observe:
   • You should see a periodic pattern corresponding to the X2X cycle
   • Each cycle contains multiple bursts (one per slave)
   • Idle periods between bursts show the bus in the recessive/idle state

8.5 Signal Characteristics to Expect

        ┌──┐  ┌──┐  ┌──┐  ┌─────┐           ┌──┐
   X2X+ ┘  └──┘  └──┘  └──┘     └───────────┘  └──
   X2X⊥ ────────────────────────────────────────────
           ← Frame 1 →         Idle    ← Frame 2 →

• Differential voltage swing: approximately 1.5–3.0 V (typical RS-485 levels)
• Idle/bus-free state: X2X+ ≈ X2X⊥ (both at common-mode voltage, ~2.5V)
• Active state: X2X+ and X2X⊥ diverge by ±1.5V differential

9. Decoding IO Card Sensor Data at the Protocol Level

9.1 What You Need to Know Before Decoding

To decode IO data from raw X2X traffic, you need:

1. The I/O mapping from the Automation Studio project (which node addresses map to which I/O modules, which channels, and data types)
2. The cyclic data layout for each node (how many bytes of input/output data per node per cycle)
3. The byte order (likely little-endian, consistent with x86 B&R CPUs)
4. The frame boundary markers (sync pattern) to segment the captured bitstream
5. The CRC/checksum algorithm (to validate decoded frames)

9.2 Data Mapping Architecture

In Automation Studio, the I/O mapping defines:

Node Address 0x01 (X20BR9300 - Panel 1):
  Slot 2: X20DI9372 (16-channel digital input)
    → Input bytes: 2 bytes (16 bits, one per channel)
    → Byte 0: Channels 1-8 (bit 0 = channel 1)
    → Byte 1: Channels 9-16 (bit 0 = channel 9)
  Slot 3: X20AO4622 (4-channel analog output, 16-bit)
    → Output bytes: 8 bytes (4 × 16-bit values)
    → Bytes 0-1: Channel 1 value (0 to 32767 = 0 to 10V)
    → Bytes 2-3: Channel 2 value
    → ...

Node Address 0x11 (X20BR9300 - Panel 2):
  Slot 2: X20AI4632 (4-channel analog input, 16-bit)
    → Input bytes: 8 bytes (4 × 16-bit values)
    → Bytes 0-1: Channel 1 value (0 to 32767 = 0-10V or 4-20mA)
    → ...

9.3 Digital Input Data Format (Inferred)

• Digital I/O is packed as bit-mapped bytes, 8 channels per byte
• Bit 0 of byte 0 = channel 1 (or channel 0, depending on B&R’s convention)
• Little-endian packing: LSB first
• Sink inputs read 1 = input active (current flowing)
• Source inputs read 1 = input active (voltage present)

9.4 Analog Data Format (Inferred)

• Analog values are typically 16-bit signed or unsigned integers
• Resolution depends on the specific module (12-bit or 16-bit ADC)
• Scaling from raw value to engineering units is done in the PLC program, not in the protocol
• Common analog ranges:
  • ±10V: raw 0–32767 (unsigned) or -32768–32767 (signed)
  • 0–10V: raw 0–32767
  • 4–20mA: raw 0–32767 (where 0 = 4mA, 32767 = 20mA)

9.5 Decoding Workflow (Without Official Specification)

1. Capture raw differential signal with logic analyzer
2. Convert differential signal to single-ended (X2X+ XOR X2X⊥)
3. Identify frame boundaries using sync patterns
4. Extract bitstream for each frame
5. Parse header to identify source/destination address
6. Extract payload based on known I/O mapping
7. Verify with CRC (algorithm unknown — trial and error with common CRC-16 polynomials: CRC-16-CCITT, CRC-16-IBM, CRC-16-MODBUS)

Practical reality: Without the official protocol spec, decoding X2X payload data requires significant reverse-engineering effort. The most practical approach is to use known I/O states as test patterns and correlate captured bits with expected values.

10. Pinpointing Failing IO Modules / Channels from Captured Traffic

10.1 Diagnostic Approach Using Captured Traffic

If you can capture and decode X2X traffic (even partially), you can identify failing modules/channels by:

Method 1: Address-Level Identification

1. Compare the list of responding node addresses in captured traffic against the expected configuration
2. A missing address in the cyclic polling sequence indicates a slave that is not responding (offline, cable fault, or module failure)
3. An unexpected address may indicate an address conflict or misconfigured node

Method 2: Status Word Analysis

Each slave’s response frame likely contains a status/diagnostic word. Look for:

• Error flag bits (which bit positions indicate which conditions is unknown without the spec)
• Watchdog timeout flags
• Module-specific error codes
• Per-channel diagnostic bits for digital modules (wire-break, short-circuit)

Method 3: Data Anomaly Detection

• Digital inputs stuck at 0 or 1 despite known physical state → channel fault or wiring issue
• Analog values pegged at 0, full-scale, or random noise → ADC failure, open wire, or signal conditioning fault
• Sudden data loss from a specific node → module failure, cable disconnect, or power loss to that station

Method 4: Timing Analysis

• Increased round-trip time for a specific slave → the slave is taking longer to respond, possibly due to internal retries or hardware degradation
• Missing response frames → slave timeouts, CRC failures, or physical layer errors

10.2 Practical Troubleshooting Without Protocol Decoding

Since full X2X decoding is impractical without the spec, the most effective approach is:

1. Use Automation Studio diagnostics: Configure X2X diagnostic information to be sent over EIP/POWERLINK to a central HMI or data logger
2. Monitor LED patterns: As described in Section 7.2, LED states provide immediate visual diagnostic information
3. Use the B&R “Network Analyzer” (X20ET8819): This is B&R’s own Ethernet/ POWERLINK analysis tool — it can capture POWERLINK traffic but does not directly decode X2X
4. Swap-and-test: Replace suspect modules or cables one at a time and observe which change restores communication
5. Resistance/continuity testing: Check cable resistance between X2X+ and X2X⊥ along the chain

10.3 Diagnostic Data Export

B&R Automation Studio can be configured to export X2X diagnostic data including:

• Slave online/offline status
• Per-module error counters
• Watchdog status
• Cycle time monitoring
• Configuration match/mismatch flags

This data is typically exported via:

• OPC UA (all SG4 controllers with Ethernet)
• Ethernet/IP tags (X20BC0088 bus controller)
• Modbus/TCP registers (X20BC0087 bus controller)
• POWERLINK process data

11. Tools for X2X Analysis

11.1 Official B&R Tools

11.2 Third-Party / Community Tools

11.3 Writing a Custom Wireshark Dissector for X2X

Since no native X2X dissector exists, you could write one using Wireshark’s Lua API:

-- Pseudo-code for a Wireshark Lua dissector for X2X Link
-- This is a skeleton — the actual frame format is proprietary and unknown

local x2x_proto = Proto("x2x_link", "B&R X2X Link Protocol")

local f_frame_type = ProtoField.uint8("x2x.frame_type", "Frame Type", base.HEX)
local f_src_addr   = ProtoField.uint8("x2x.src_addr", "Source Address", base.HEX)
local f_dst_addr   = ProtoField.uint8("x2x.dst_addr", "Dest Address", base.HEX)
local f_payload    = ProtoField.bytes("x2x.payload", "Payload")
local f_crc        = ProtoField.uint16("x2x.crc", "CRC", base.HEX)

x2x_proto.fields = {
    f_frame_type, f_src_addr, f_dst_addr, f_payload, f_crc
}

function x2x_proto.dissector(buffer, pinfo, tree)
    pinfo.cols.protocol = "X2X Link"
    local subtree = tree:add(x2x_proto, buffer())

    -- NOTE: Field offsets and sizes are UNKNOWN/INFERRED
    -- Actual implementation requires the official spec or RE
    subtree:add(f_frame_type, buffer(0, 1))
    subtree:add(f_src_addr,   buffer(1, 1))
    subtree:add(f_dst_addr,   buffer(2, 1))
    subtree:add(f_payload,    buffer(3, buffer:len() - 5))
    subtree:add(f_crc,        buffer(buffer:len() - 2, 2))
end

-- Register as a user DLT (Data Link Type) for raw capture import
local wtap_dissector_table = DissectorTable.get("wtap_encap")
wtap_dissector_table:add(wtap_dissector_table:get_free_id(), x2x_proto)

To use this:

1. Capture X2X traffic with a logic analyzer → export as raw binary/captured stream
2. Write a conversion script to import the raw data into a pcap-like format
3. Register the custom dissector to decode the frames

11.4 Recommended Hardware Setup for X2X Analysis

┌──────────────┐     X2X Cable      ┌──────────────┐     X2X Cable      ┌──────────────┐
│              │◄──────────────────►│              │◄──────────────────►│              │
│  CPU/Master  │   IN     OUT       │  X2X Tap     │   IN     OUT       │  Slave I/O   │
│  (X20CP...)  │                   │  Board       │                   │  (X20BR...)  │
│              │                   │              │                   │              │
└──────────────┘                   └──────┬───────┘                   └──────────────┘
                                          │
                                    ┌─────┴─────┐
                                    │ RS-485     │
                                    │ Transceiver│
                                    └─────┬─────┘
                                          │
                                    ┌─────┴─────┐
                                    │  Logic     │
                                    │  Analyzer  │──► PC (Saleae/sigrok)
                                    │  ≥100MS/s  │
                                    └───────────┘

12. Component Reference Tables

12.1 X2X Link Bus Controllers (X20)

12.2 X2X Link Bus Transmitters / Receivers (X20)

12.3 X67 Bus Controllers with X2X Link

12.4 Bus Modules with Node Number Switches

12.5 Termination and Accessories

13. Source URLs and References

Official B&R Documentation

Technical Articles and Community Posts

Troubleshooting and Diagnostics

System Overview / Reference

Reverse Engineering / Sniffing References

Cross-References

• powerlink-internals.md — ETHERNET Powerlink protocol details; X2X and POWERLINK timing interaction
• physical-layer-sniffing.md — Probing X2X signals at the physical wire level with oscilloscopes and logic analyzers
• io-card-hardware.md — IO module hardware internals; how sensor signals are conditioned before X2X transport
• memory-map.md — How IO data from X2X modules maps into the PLC address space
• network-architecture.md — X20 network topology, device discovery, and bus configuration
• cp1584-hardware-ref.md — CP1584 physical specifications, connectors, and X2X link power output
• io-sniffing.md — Higher-level IO sniffing methodology for diagnosing sensor issues
• analog-calibration.md — Analog signal quality analysis across the X2X transport path
• diagnostic-workstation.md — Logic analyzer and oscilloscope setup for X2X protocol analysis

Appendix A: X2X Quick Reference Card

┌──────────────────────────────────────────────────────────────────┐
│                    B&R X2X LINK QUICK REFERENCE                    │
├──────────────────────────────────────────────────────────────────┤
│ Bus Speed:        12 Mbps (X2X Link) / ~48 Mbps (X2X+)           │
│ Cycle Time:       0.5 ms – 10 ms (default 2 ms)                 │
│ Max Slaves:       62 per master                                  │
│ Max Cable:        100 m per segment                              │
│ Addresses:        0x01–0xFD (manual), 0x00 = auto               │
│ Termination:      120Ω at both ends (X20AT6100)                 │
│ Connector:        M12 B-keyed 5-pin (remote)                     │
│ Pin 1: X2X+ (Red) — Data+ AND +24V supply                      │
│ Pin 2: X2X (White) — Data reference                              │
│ Pin 3: X2X⊥ (Black) — Data- inverse                            │
│ Pin 4: X2X\ (Blue) — Data ground                                │
│ Pin 5: NC                                                      │
│ Shield: 360° via knurled screw (ground both ends)                │
│ Idle Voltage: ~2.5V between X2X+ and X2X⊥                       │
│ Terminated R:  ~60Ω between X2X+ and X2X⊥ (both ends)          │
├──────────────────────────────────────────────────────────────────┤
│ LED Patterns:                                                     │
│   R-LED steady green = Normal operation                         │
│   R-LED single flash = Reset/Stop mode                          │
│   R-LED double flash = Boot mode (don't interrupt)               │
│   X-LED steady orange = X2X communication active                │
│   X-LED off = No X2X communication                              │
├──────────────────────────────────────────────────────────────────┤
│ Default CPU IP (Boot mode): 192.168.1.1                          │
│ Config Tool: Automation Studio (B&R)                             │
├──────────────────────────────────────────────────────────────────┤
│ ⚠ X2X+ and X2X Link CANNOT be mixed in the same segment        │
└──────────────────────────────────────────────────────────────────┘

Appendix B: X2X LED Diagnostic Pattern Reference (Field Troubleshooting)

LED Types on X2X Modules

R-LED Patterns

X-LED Patterns

System-Level LED Interpretation Table

CPU Reset Mode Entry Conditions

The CPU enters reset/STOP mode when any of the following occur:

1. Hardware watchdog timeout (typically 500 ms – 2 s, configurable)
2. Critical memory access violation (page fault, illegal address)
3. Illegal instruction executed
4. Power-up with corrupted non-volatile memory
5. Manual reset via Automation Studio (warm restart)
6. Firmware update failure

In reset mode:

• CPU stops executing application code
• All X2X/POWERLINK fieldbus masters are disabled
• Digital outputs go to safe state (0V)
• All module R-LEDs flash at ~1 Hz
• Communication with Automation Studio may still be possible via service interface

Recovery Procedure for X2X Communication Failure

1. Disconnect all 24VDC power to CPU and X2X modules
2. Wait 60 seconds for complete discharge (capacitors)
3. Reapply power to X2X bus modules FIRST, wait 2 seconds for stabilization
4. Apply power to CPU
5. Observe LED sequences:
   - R-LED: single flash → double flash (init) → steady green (RUN)
   - X-LED on master: off → flashing orange → steady orange (X2X active)
   - Slave R-LEDs: single flash → steady green (initialized)
   - Slave X-LEDs: off → steady orange (communication established)

If LEDs do not progress past single flash:

• Check termination resistors (120Ω) at both bus ends
• Measure DC bus voltage between X2X+ and X2X⊥: should be 2.5V ±0.5V when idle
• Check for ground potential differences between panels
• Verify node address switches on X20BR9300 are unique and match configuration
• Try pressing CPU reset button (3-second hold) for warm restart

X2X Bus Components Quick Reference

Appendix C: X2X+ Backplane Bus (2023 Enhancement)

In January 2023, B&R introduced the X2X+ backplane bus as an option for X20 systems, delivering approximately 4× the bandwidth of X2X Link.

Key Differences: X2X Link vs X2X+

X2X+ Advantages for Condition Monitoring

The higher bandwidth and per-data timestamping make X2X+ particularly suited for:

• High-speed vibration monitoring and condition monitoring
• Higher sampling rates on analog channels
• Separate fast/slow cycle times: less time-critical data transported at slower rate to reduce CPU/network load
• Complex high-speed processes controlled with cost-effective standard hardware

Migration Note

All existing X20 I/O modules are compatible with X2X+. To upgrade, only the bus modules (the base/backplane modules) need to be replaced with X2X+-capable versions. The electronic modules (I/O slices) remain the same.

Source: B&R Press Room, “Four times more performance” (2023-01-30) — https://www.br-automation.com/en/about-us/press-room/four-times-more-performance-30-01-2023/

Appendix D: Glossary

Key Findings

1. X2X Link is B&R’s proprietary master-slave deterministic serial bus running at 12 Mbps over RS-485 differential signaling. The wire protocol specification has never been publicly released by B&R. Frame format, sync words, CRC polynomial, and bit-level encoding are reconstructed/inferred from hardware documentation and reverse-engineering observations.

2. Physical layer: remote cable uses M12 B-keyed 5-pin connectors with a critical pin 1 dual-function – the red wire (X2X+) carries both differential data AND +24 VDC power for the remote backplane. When connecting to self-powered devices (IF789, LS189), the red wire must be insulated to prevent short circuits. Termination is 120 ohm at both ends (X20AT6100); measured DC resistance across X2X+/X2X perpendicular should read approximately 60 ohm.

3. Cycle time is user-configurable from 0.5 ms to 10 ms (default 2 ms). Cycle time must be compatible with task class cycle times (multiples or divisors). At 2 ms cycle, IO refreshes 500 times/second; at 0.5 ms, 2000 times/second. X2X+ (introduced 2023) provides approximately 4x bandwidth (estimated 48 Mbps backplane) but is not compatible with X2X Link in the same segment.

4. Up to 62 slave nodes per master (X20BT9100 transmitter / X20BR9300 receiver), with a maximum segment length of 100 m. After approximately 30 modules on a single segment, a bus repeater is required. Topology is daisy-chain/multi-drop. Node addressing is via hex rotary DIP switches (0x01-0xFD manual, 0x00 auto-assigned).

5. Sniffing X2X requires a logic analyzer sampling at >= 100 MS/s (200 MS/s recommended) – at 12 Mbps, one bit period is ~83.3 ns, requiring 4-5 samples per bit minimum. A Saleae Logic 2 Pro 16 (1 GS/s, 83 samples/bit) is adequate; cheaper sigrok clones at 24-100 MS/s are insufficient. Build a passive RS-485 tap board using a high-speed transceiver (SN65HVD1782, MAX1487) with switchable 120 ohm termination.

6. IO data decoding from raw traffic requires: the Automation Studio IO mapping (node addresses to module types to channel data types), the byte order (little-endian, consistent with x86 B&R CPUs), frame boundary sync patterns, and the CRC algorithm (unknown – trial with CRC-16-CCITT, CRC-16-IBM, CRC-16-MODBUS). Digital IO is bit-packed (8 channels per byte, LSB first); analog values are 16-bit signed/unsigned integers.

7. LED diagnostic patterns: R-LED steady green = normal operation, single flash = reset/stop mode, double flash = boot mode (do not power off during firmware update), X-LED steady orange = X2X communication active, X-LED off = no X2X communication. Default CPU IP in boot mode is 192.168.1.1.

8. Idle bus voltage between X2X+ and X2X perpendicular is approximately 2.5 V. When actively transmitting, the differential voltage swing is approximately 1.5-3.0 V (standard RS-485 levels). Shield should be grounded at both ends for best EMC immunity.

This document is compiled from publicly available sources. The X2X Link wire protocol is proprietary to B&R Industrial Automation (ABB). Some protocol details are inferred or reconstructed and should be verified against official documentation if available. No confidential or proprietary protocol specifications were accessed in creating this document.