B&R Serial Communication Diagnostics — Complete Reference

Serial communication (RS232 and RS485) remains pervasive on legacy B&R machines, connecting the PLC to drives, scales, barcode readers, operator terminals, and other devices. When serial communication fails, the symptoms can range from intermittent data corruption to complete device unresponsiveness — and the original device specifications are almost never available. This document covers how to sniff serial traffic between the PLC and serial-connected devices, common B&R serial protocol patterns, how to decode the data streams, and how to replace or reconfigure serial connections when the original setup is unknown. Cross-references: cp1584-hardware-ref.md for RS232/RS485 hardware details, io-sniffing.md for general sniffing techniques, and modbus-gateway.md for Modbus serial gateway configuration.

Table of Contents

1. Overview of B&R Serial Communication
2. B&R Hardware Platforms and Serial Capabilities
3. Serial Interface Modules: System 2003 / 2005
4. Serial Interface Modules: X20 System
5. Wiring and Pinouts for RS232 and RS485
6. Baud Rate, Parity, and Stop Bit Configuration
7. Flow Control and Handshake Issues
8. B&R Software Libraries for Serial Communication
9. How to Sniff Serial Traffic Between PLC and Serial-Connected Devices
10. Tools for Serial Sniffing
11. How to Decode Serial Data
12. Protocol Analysis: MODBUS RTU Over Serial
13. Protocol Analysis: Custom ASCII and Binary Protocols
14. Reconfiguring or Replacing Serial Connections When Specs Are Unknown
15. Serial-to-Ethernet Conversion Options
16. Common Serial Communication Failures and Debugging
17. Troubleshooting Matrices
18. References and Further Reading

1. Overview of B&R Serial Communication

B&R Automation (Bernecker + Rainer) industrial controllers use serial communication (RS232, RS485, RS422) extensively for connecting to third-party devices — sensors, drives, HMIs, barcode readers, weigh scales, temperature controllers, and more. Understanding how to diagnose, sniff, and decode serial traffic is critical when commissioning systems, troubleshooting intermittent failures, or reverse-engineering undocumented connections.

B&R serial communication spans three major hardware families:

• System 2003 — compact DIN-rail controllers with integrated or plug-in serial modules
• System 2005 — modular rack-based controllers with interface modules (IF260, IF671, IF622, etc.)
• X20 System — modular I/O with base modules providing integrated serial, plus dedicated communication interface modules (X20CS1020, X20IF1030, X20IF1082, etc.)

On the software side, two primary libraries handle serial I/O:

• DV_Frame — general-purpose raw serial frame I/O (user-defined protocols, ASCII, binary)
• DRV_mbus — Modbus RTU master/slave with automatic CRC and function code handling

2. B&R Hardware Platforms and Serial Capabilities

2.1 X20CP1584 / X20CP1585 / X20CP1586

The X20CP158x series are compact X20 CPUs with integrated serial and Ethernet:

IF1 RS232 Pinout on X20TB12 terminal block:

The RS232 interface is not electrically isolated from the PLC logic on most X20CP158x models. Use shielded cable with shield bonded at one end only to prevent ground loops.

2.2 X20CP1484 / X20CP1485 / X20CP1486

Similar to the 158x series but with Ethernet limited to 10/100 Mbit/s on IF2. IF1 is RS232 via the same X20TB12 terminal block pinout.

2.3 X20CP0482 / X20CP0484

Entry-level X20 CPUs. The serial interface is provided by the base module (X20BB52) and exposed on the power supply module’s (X20PS9600) terminal block. IF1 = RS232 at up to 115.2 kbit/s.

2.4 CP476 (System 2003)

Compact controller with integrated serial port. Uses DB9 connector for RS232:

• Pin 2: TXD (Transmit)
• Pin 3: RXD (Receive)
• Pin 5: GND (Signal Ground)

Supports both RS232 and RS485 depending on model variant. Programmed using the DV_Frame library.

2.5 Base Modules with Integrated Serial (X20 System)

A critical architectural detail: on the X20 system, the integrated serial interface lives on the base module, not on the power supply module:

The X20PS9600 power supply module passes the RS232 signals from the base module to its terminal block. A second X20PS9600 will not provide a second serial port — each X20 segment allows exactly one PS module.

3. Serial Interface Modules: System 2003 / 2005

3.1 IF260 — Programmable Interface Module

The IF260 (3IF260.60-1) is a System 2005 interface module that can function as either a CPU or as a programmable interface processor. The module auto-detects its operating mode from the slot position:

• Slot 0 — operates as a CPU
• Other slots — operates as a programmable interface processor

This allows the IF260 to offload serial communication processing from the main CPU. It runs its own Automation Basic program and can handle multiple serial protocols independently.

3.2 IF622 — Triple Serial Interface (1×RS232, 2×RS485/RS422)

The IF622 (3IF622.9) provides:

• IF1: 1× RS232 interface
• IF2, IF3: 2× RS485/RS422 interfaces

All interfaces are electrically isolated. Used in System 2005 racks for expanding serial connectivity beyond what the CPU provides natively.

3.3 IF671 — Triple Communication Module (RS232, RS485/RS422, CAN)

The IF671 (3IF671.9) provides three isolated communication interfaces on a single module:

• IF1: RS232
• IF2: RS485/RS422
• IF3: CAN bus

This is the most versatile serial interface module for System 2005, covering RS232 point-to-point, RS485 multi-drop, and CAN bus in one card.

3.4 IF261 / IF262 / IF3xx Series

• IF261 — CPU module variant for System 2003/2005
• IF262 — Interface processor for serial protocols
• IF3xx series — Various interface modules for specific fieldbus protocols (Profibus DP, CANopen, DeviceNet) with optional serial sub-interfaces

3.5 CP260 — Serial + CAN Interface Module

The CP260 (3CP260.60-1) provides:

• 1× RS485/RS422 interface
• 1× CAN interface

Used as a compact interface processor or standalone communication node.

4. Serial Interface Modules: X20 System

4.1 X20CS1020 — RS232/RS422/RS485 Communication Module

Device name in Automation Studio: CS1020_IF1

This is the standard choice for adding a second serial port to an X20 controller when the base module’s integrated port is already in use.

4.2 X20IF1030 — RS232 Interface Module

Designed for point-to-point RS232 serial connections. Note: The X20IF1030 is RS232 only — do not confuse it with the X20IF1031 (RS422/RS485) or X20IF1041 (RS422/RS485 isolated). For multi-drop RS485 networks, use X20IF1031 or X20IF1041. See modbus-gateway.md for the complete serial module comparison.

4.3 X20IF1082 — Configurable RS232/RS485

Single configurable channel supporting either RS232 or RS485 communication. Software-configurable interface standard.

4.4 X20IF1072 — RS485 Interface Module

Dedicated RS485 interface for the X20 system. Used for serial remote connection of complex devices.

4.5 X20PS9600 — Power Supply (Serial Pass-Through)

Not a serial module itself — the X20PS9600 passes RS232 signals from the base module (e.g., X20BB52) to its terminal block:

5. Wiring and Pinouts for RS232 and RS485

5.1 RS232 DB9 Standard Pinout (Male Connector, DTE Side)

5.2 RS232 Wiring: Straight-Through vs Null-Modem

Straight-through cable (PC/PLC to modem/peripheral):

DTE (PLC)          DCE (Device)
Pin 3 (TXD)  →   Pin 2 (RXD)
Pin 2 (RXD)  ←   Pin 3 (TXD)
Pin 5 (GND)  —   Pin 5 (GND)

Null-modem cable (PLC to PLC, or PLC to PC configured as DTE):

Device A            Device B
Pin 3 (TXD)  →   Pin 2 (RXD)    (crossed)
Pin 2 (RXD)  ←   Pin 3 (TXD)    (crossed)
Pin 5 (GND)  —   Pin 5 (GND)    (straight)
Pin 7 (RTS)  →   Pin 8 (CTS)    (crossed)
Pin 8 (CTS)  ←   Pin 7 (RTS)    (crossed)

5.3 RS485 Wiring

RS485 uses differential signaling (A/B or +/−) and supports multi-drop (up to 32 devices on a single bus):

                    120Ω
Master ──── A ───────────────── A ──── Slave 1
         │                             │
         └──── B ───────────────── B ─┘
               │                     │
              GND                   GND
                                           120Ω (at far end)

RS485 connection rules:

• Use twisted pair cable (e.g., 1 pair of Cat5e or dedicated RS485 cable)
• 120 Ω termination resistors at both ends of the bus
• Common ground connection recommended but keep ground currents minimized
• Maximum cable length depends on baud rate (EIA-485 standard, twisted-pair cable, 120 Ω termination):
  • 115.2 kbit/s → max ~200 m (conservative: 100 m in noisy environments)
  • 19.2 kbit/s → max ~1000 m
  • 9600 baud → max ~1200 m

5.4 B&R X20 Terminal Block Serial Wiring

For X20CP1584 and similar CPUs using X20TB12:

• TxD connects to terminal 9
• RxD connects to terminal 10
• GND connects to terminal 11
• Shield connects to terminal 12 (FE)

Use shielded twisted pair cable (LiYCY 3×2×0.14 mm²). Bond shield to FE at the cabinet entry only — do not ground both ends.

5.5 RJ45 to DB9 RS232 Adapter (Common for B&R Field Wiring)

Some B&R installations use RJ45 connectors for serial field wiring. A common mapping:

Note: RJ45-to-serial pinout varies by manufacturer. Always verify with a multimeter before connecting.

6. Baud Rate, Parity, and Stop Bit Configuration

6.1 Standard Configuration Parameters

6.2 Common Configurations

6.3 Configuring in B&R Automation Studio

In the IO Configuration view, set the serial port properties:

In code (DV_Frame):

openInfo.baudrate   := 9600;
openInfo.dataBits   := 8;
openInfo.parity     := dvPARITY_EVEN;
openInfo.stopBits   := 1;
openInfo.handshake  := dvHANDSHAKE_NONE;

In code (DRV_mbus for Modbus RTU):

openInfo.baudrate   := 9600;
openInfo.parity     := dvPARITY_EVEN;   (* Modbus RTU commonly uses Even parity *)

6.4 Maximum Baud Rates by B&R Hardware

7. Flow Control and Handshake Issues

7.1 Types of Flow Control

7.2 Common Handshake Problems

7.3 B&R-Specific Flow Control Notes

• X20BB52 base module exposes RTS and CTS on the PS9600 terminal block (check exact pin assignment in datasheet)
• X20CS1020 supports RTS/CTS and XON/XOFF in RS232 mode
• For Modbus RTU over RS485, flow control is typically None — the protocol handles framing via 3.5 character silent intervals
• When using DV_Frame with dvHANDSHAKE_RTSCTS, the library manages RTS automatically

8. B&R Software Libraries for Serial Communication

8.1 DV_Frame Library

The DV_Frame library is the primary general-purpose serial communication library for B&R controllers. It provides raw frame-level access to serial ports.

Key Functions:

Modes:

• dvFRAME_MODE_RAW — raw byte I/O, no protocol framing
• Terminator options: dvFRAME_TERMINATOR_CRLF, dvFRAME_TERMINATOR_LF, custom delimiter

Example — Opening a Serial Port:

VAR
    fbFrame   : DV_FrameOpen_Type;
    openInfo  : DV_FrameOpen_Info_Type;
    rxBuffer  : ARRAY[0..63] OF USINT;
    rxLen     : UDINT;
    handle    : UDINT;
END_VAR

openInfo.deviceName   := 'IF1';
openInfo.mode          := dvFRAME_MODE_RAW;
openInfo.baudrate      := 9600;
openInfo.dataBits      := 8;
openInfo.parity        := dvPARITY_NONE;
openInfo.stopBits      := 1;
openInfo.handshake     := dvHANDSHAKE_NONE;
openInfo.rxBufferSize  := SIZEOF(rxBuffer);
openInfo.rxBuffer      := ADR(rxBuffer);

DV_FrameOpen(fbFrame, openInfo);
IF fbFrame.status = 0 THEN
    handle := fbFrame.handle;
END_IF

Example — Sending a Query:

VAR
    fbWrite   : DV_FrameWrite_Type;
    query     : USINT := 16#52;  (* 'R' = ASCII 0x52 *)
END_VAR

DV_FrameWrite(fbWrite, handle, ADR(query), 1);

Example — Reading a CRLF-Terminated Response:

VAR
    fbRead : DV_FrameRead_Type;
END_VAR

DV_FrameRead(fbRead, handle, ADR(rxBuffer), SIZEOF(rxBuffer), rxLen,
             dvFRAME_TERMINATOR_CRLF);
IF fbRead.status = 0 THEN
    (* rxBuffer[0..rxLen-1] contains the response *)
END_IF

8.2 DRV_mbus Library (Modbus RTU)

The DRV_mbus library provides Modbus RTU master and slave functionality with automatic CRC-16 handling.

Key Functions:

Example — Modbus RTU Master:

VAR
    fbMbus   : DRV_mbusOpen_Type;
    fbRead   : DRV_mbusReadReg_Type;
    openInfo : DRV_mbusOpen_Info_Type;
    regValue : UINT;
END_VAR

openInfo.deviceName := 'IF1';
openInfo.mode       := dvMBUS_MODE_RTU_MASTER;
openInfo.baudrate   := 9600;
openInfo.parity     := dvPARITY_EVEN;
openInfo.timeout    := 500;  (* ms *)

DRV_mbusOpen(fbMbus, openInfo);
IF fbMbus.status = 0 THEN
    DRV_mbusReadReg(fbRead, fbMbus.handle,
                    slaveAddr := 1,
                    funcCode  := dvMBUS_FC04_INPUT,
                    regAddr   := 16#0001,
                    regQty    := 1,
                    pData     := ADR(regValue),
                    dataLen   := SIZEOF(regValue));
END_IF

8.3 Choosing Between DV_Frame and DRV_mbus

9. How to Sniff Serial Traffic Between PLC and Serial-Connected Devices

9.1 Why Sniff Serial Traffic?

• Determine unknown protocol parameters (baud rate, parity, framing)
• Capture request/response patterns for reverse engineering
• Debug intermittent communication failures
• Verify PLC program behavior against expected protocol
• Identify timing issues, bus contention, or signal integrity problems

9.2 Methods for Sniffing

Method 1: Hardware Tap (Non-Intrusive — RS232 Only)

For RS232 point-to-point connections, insert a Y-cable or hardware tap between the PLC and the device:

PLC TXD ────────────────────── Device RXD
          │
          └──── Sniffer RXD

PLC RXD ────────────────────── Device TXD
          │
          └──── Sniffer TXD

Hardware needed:

• Passive RS232 monitor Y-cable (3-plug DB9)
• Or build one: connect sniffer’s RXD to both TXD lines (with diodes for isolation)

Limitations: RS232 only (voltage levels must be compatible). Cannot easily tap RS485 mid-bus without disturbing differential signaling.

Method 2: RS485 Tap (Intrusive but Low-Impact)

For RS485 multi-drop buses:

• Connect the sniffer as an additional node on the bus with a high-impedance RS485 transceiver
• The sniffer listens only (never transmits) to avoid disturbing bus traffic
• Ensure proper 120 Ω termination is maintained

Method 3: Oscilloscope / Logic Analyzer (Non-Intrusive)

Connect probes to the TXD/RXD (RS232) or A/B (RS485) lines. This is the best method because:

• No electrical loading of the bus
• Captures exact timing and signal integrity
• Can detect electrical noise, reflections, and voltage levels
• Works for both RS232 and RS485

Method 4: Software Sniffer (Windows PC)

If the serial traffic passes through a PC (e.g., USB-to-serial adapter):

• Install a serial port monitor driver that intercepts IOCTL calls
• Tools: HHD Serial Port Monitor, COM Sniffer, Serial Port Monitor (eltima)
• These capture all read/write operations at the driver level
• Non-intrusive to the application but requires the traffic to pass through the monitored PC

9.3 Sniffing B&R PLC Serial Traffic

B&R PLCs run their own real-time OS, so software-based sniffing directly on the PLC is not possible with standard tools. To sniff traffic from a B&R controller:

1. Hardware approach (recommended): Use a logic analyzer or oscilloscope on the serial lines
2. Y-cable approach (RS232): Insert a passive tap between PLC and device, connect to a PC running serial terminal software
3. B&R diagnostic approach: Add logging in the PLC program using DV_Frame to echo both TX and RX data to a second serial port or to Ethernet
4. Modbus diagnostic: Use DRV_mbus built-in error counters to track CRC errors, timeouts, and exception codes

10. Tools for Serial Sniffing

10.1 Software Tools

10.2 Hardware Tools

10.3 Saleae Logic Analyzer for Serial Protocol Decode

Saleae Logic analyzers (Logic 4, Logic 8, Logic Pro 8/16) can read and decode RS232, RS485, and RS422 signals up to ±25V:

Setup steps:

1. Connect ground probe to circuit ground
2. Connect channel probes to TXD and RXD (RS232) or A and B (RS485 differential pair)
3. For RS232: Use the “Async Serial” analyzer with correct baud rate, parity, stop bits
4. For RS485: May require RS485-to-TTL receiver chip to convert differential to logic levels
5. Set up “Modbus RTU” analyzer on top of the async serial decode for Modbus devices

What you get:

• Decoded hex/ASCII data in real time
• Timing measurements between frames
• Protocol-level decode (Modbus function codes, register addresses, CRC)
• Export to CSV, JSON, or screenshot for documentation

11. How to Decode Serial Data

11.1 Step-by-Step Decode Process

Step 1: Capture Raw Data

Use a logic analyzer or serial sniffer to capture the raw bitstream. Record:

• All bytes in hex format
• Timestamps between bytes
• Direction (TX vs RX)

Step 2: Determine Baud Rate

If baud rate is unknown:

1. Measure bit duration with oscilloscope: Connect to TXD line, trigger on falling edge, measure one bit width. Baud rate = 1 / bit_width_seconds.
2. Common baud rates to try: 300, 1200, 2400, 4800, 9600, 19200, 38400, 57600, 115200
3. Auto-detect approach: Set logic analyzer to each common baud rate and see which produces valid ASCII or consistent framing
4. Bit-width reference table:

Step 3: Determine Frame Format

Standard UART frame: [Start bit (0)] [5-9 data bits] [Parity bit (optional)] [1-2 Stop bits (1)]

If the data looks garbled, try:

• 8-N-1 (most likely)
• 8-E-1 (common for Modbus RTU)
• 7-E-1 (legacy devices)
• 8-O-1, 7-N-2

Step 4: Identify Protocol Type

Step 5: Analyze Message Structure

For each captured message:

1. Identify the master request (PLC sends) and slave response (device replies)
2. Look for fixed patterns in the first few bytes (address, command)
3. Look for repeating structures in the data payload
4. Look for the last 1-2 bytes — often a checksum (CRC-16, LRC, sum)
5. Note timing between request and response

Step 6: Verify Checksums

Common checksum algorithms:

• CRC-16 (Modbus): Polynomial 0x8005, init 0xFFFF — used in Modbus RTU
• LRC (Longitudinal Redundancy Check): XOR of all bytes — used in Modbus ASCII
• Sum checksum: Add all bytes, take lower byte
• CRC-CCITT (0x1021): Used in various industrial protocols

Use an online CRC calculator or embedded code to verify.

11.2 Example: Decoding a Custom ASCII Protocol

Captured hex dump (PLC → Sensor):

52 0D 0A

Decoded: R\r\n (ASCII “R” + CRLF) — this is a read request.

Captured hex dump (Sensor → PLC):

2B 32 33 2E 34 35 20 43 0D 0A

Decoded: +23.45 C\r\n — temperature reading in ASCII.

11.3 Example: Decoding a Binary Protocol

Captured hex dump (PLC → Device):

01 03 00 00 00 0A C5 CD

Decoded as Modbus RTU:

• 01 = Slave address (1)
• 03 = Function code (Read Holding Registers)
• 00 00 = Starting register address (0x0000)
• 00 0A = Quantity of registers (10)
• C5 CD = CRC-16 (Modbus)

12. Protocol Analysis: MODBUS RTU Over Serial

12.1 Modbus RTU Frame Structure

┌──────────┬──────────┬──────────┬──────────┬──────────┬──────────┐
│ Address  │ Function │  Data    │  Data    │ CRC Low  │ CRC High │
│ (1 byte) │ (1 byte) │ (N bytes)│ (N bytes)│ (1 byte) │ (1 byte) │
└──────────┴──────────┴──────────┴──────────┴──────────┴──────────┘

• Address: Slave device address (1–247)
• Function code: Operation type (01–06, 15–16 most common)
• Data: Register address, quantity, write values
• CRC-16: CRC-16/Modbus (polynomial 0x8005, initial value 0xFFFF)

12.2 Common Function Codes

12.3 Modbus RTU Timing

The end of a Modbus RTU frame is defined by a 3.5 character silent interval on the bus:

The inter-frame delay must be at least this long. The inter-character delay must be less than 1.5 character times or the frame is considered incomplete.

12.4 Modbus Exception Response

If a slave cannot process a request, it returns an exception response:

┌──────────┬──────────┬──────────┬──────────┬──────────┐
│ Address  │ FC + 0x80│Exception │ CRC Low  │ CRC High │
│ (1 byte) │ (1 byte) │  Code    │ (1 byte) │ (1 byte) │
└──────────┴──────────┴──────────┴──────────┴──────────┘

Common exception codes:

12.5 Analyzing Modbus RTU with B&R DRV_mbus

When using DRV_mbus, the library handles CRC and framing automatically. To debug:

1. Monitor fbRead.status after each DRV_mbusReadReg call
2. Check for CRC errors: dvMBUS_ERR_CRC indicates electrical noise or baud rate mismatch
3. Check for timeouts: dvMBUS_ERR_TIMEOUT means the slave didn’t respond
4. Check for exception codes: Non-zero slave response with error code indicates addressing or register problems
5. Log all reads/writes: Echo the request parameters and responses to a log file or HMI for pattern analysis

12.6 Tools for Modbus RTU Analysis

13. Protocol Analysis: Custom ASCII and Binary Protocols

13.1 ASCII Protocols

Many industrial sensors use simple ASCII request/response patterns:

Pattern 1: Command-Response (read request)

PLC sends:  "R\r\n"        (request reading)
Device:     "+23.45 C\r\n" (response with value)

Pattern 2: Addressed Multi-Drop

PLC sends:  "$01RD\r\n"   (address 01, read command)
Device 01: "!01+23.45\r\n" (addressed response)

Pattern 3: Set-Command

PLC sends:  "SET 100\r\n"  (set value to 100)
Device:     "OK\r\n"        (acknowledgment)

Analysis approach for ASCII:

1. Capture traffic and view as ASCII text
2. Identify request vs response by direction
3. Look for delimiters (CR, LF, CRLF, semicolon, comma)
4. Identify data format (decimal, hex, scientific notation)
5. Map command set by observing different PLC operations

13.2 Binary Protocols

Binary protocols use structured byte sequences with headers, addresses, commands, data, and checksums:

Typical structure:

┌───────┬───────┬───────┬───────┬───────┬──────────┐
│ STX   │ ADDR  │ CMD   │ LEN   │ DATA  │ CHECKSUM │
│ 0x02  │ (1B)  │ (1B)  │ (1B)  │ (nB)  │ (1-2B)  │
└───────┴───────┴───────┴───────┴───────┴──────────┘

Analysis approach for binary:

1. Capture multiple transactions and align them by frame boundaries
2. Look for fixed byte values in position 0 (start marker: 0x02, 0xAA, 0x55)
3. Look for the length field — count data bytes to confirm
4. Verify the checksum against candidate algorithms
5. Correlate known values (e.g., if you know a sensor reads 25.3°C, find 0x0199 or 0x9919 in the data)
6. Determine byte order (big-endian vs little-endian) by comparing known values

13.3 Mixed Protocols

Some devices use a mix of ASCII commands and binary data (e.g., text headers with binary payloads). Look for transitions between printable and non-printable byte ranges.

14. Reconfiguring or Replacing Serial Connections When Specs Are Unknown

14.1 Systematic Approach to Unknown Serial Connections

When you inherit a system with undocumented serial connections:

Phase 1: Physical Investigation

1. Identify the hardware: Locate the serial module (IF1, CS1020, IF622, etc.)
2. Trace the wiring: Follow cables from the PLC serial port to the connected device
3. Identify the connector type: DB9, terminal block, RJ45
4. Note the cable type: Shielded/unshielded, twisted pair count
5. Check for RS485 termination: Look for 120 Ω resistors on the bus ends

Phase 2: Capture Traffic

1. Use a logic analyzer to capture raw serial data
2. Determine baud rate by measuring bit width (see Section 11)
3. Determine frame format (8-N-1, 8-E-1, etc.)
4. Save hex dumps of multiple request/response cycles

Phase 3: Protocol Identification

1. Check if the traffic matches Modbus RTU (address + FC + data + CRC pattern)
2. Check for ASCII patterns (readable text, CR/LF delimiters)
3. Check for known vendor protocols (Mitsubishi MC Protocol, Siemens S7, Omron Host Link, Allen-Bradley DF1)
4. Search online for the connected device’s protocol documentation

Phase 4: Replication

1. Once the protocol is understood, implement it in B&R using DV_Frame (custom) or DRV_mbus (Modbus)
2. Test with the captured device to verify matching behavior
3. Document the protocol for future maintenance

14.2 Common Vendor Serial Protocols Found in B&R Installations

14.3 Practical Tips for Unknown Protocol Reverse Engineering

1. Start with the defaults: Try 9600-8-N-1 first (covers ~80% of industrial devices)
2. Leverage the device manual: Even partial documentation helps identify the protocol family
3. Correlate with known I/O: If you know what the PLC is controlling (e.g., a drive speed), look for that value in the captured data
4. Use pattern matching: Many binary protocols use fixed headers or sync bytes (0x55AA, 0x0243, etc.)
5. Test with a Bus Pirate: Send known bytes and observe the device response to build a command set
6. Check B&R source code: If you have the Automation Studio project, search for DV_Frame or DRV_mbus calls to understand the current implementation

14.4 Migrating from Serial to Ethernet

When replacing a serial connection:

1. Keep the serial link operational during migration
2. Install serial-to-Ethernet converters (see Section 15)
3. Configure the converter for the exact serial parameters (baud, parity, etc.)
4. Test Ethernet-side connectivity before cutting over
5. Update the B&R PLC program to use TCP/UDP or Modbus TCP instead of serial

15. Serial-to-Ethernet Conversion Options

15.1 Why Convert Serial to Ethernet?

• Extend serial device reach beyond 1200 m (RS485) or 15 m (RS232)
• Centralize serial devices on an Ethernet network for SCADA/PC access
• Replace aging serial infrastructure while keeping legacy devices
• Enable remote monitoring of serial traffic over IP
• Add redundancy and easier troubleshooting via network tools

15.2 Serial-to-Ethernet Device Servers

Moxa NPort Series (Industry Standard)

Operating modes:

• Virtual COM mode: Presents serial ports as virtual COM ports on a remote PC — transparent to existing software
• TCP Server mode: Device server listens for TCP connections — PLC or PC initiates connection
• TCP Client mode: Device server initiates TCP connection to a specified IP:port
• UDP mode: Connectionless datagram mode for low-latency applications
• Pair connection: Two device servers form a transparent serial tunnel

Other Manufacturers

15.3 B&R-Specific Integration

B&R X20 controllers can communicate with serial-to-Ethernet converters using:

15.4 Serial-to-Serial Conversion

When the PLC has the wrong serial type:

15.5 Configuration Considerations

When setting up serial-to-Ethernet converters:

1. Match serial parameters exactly: Baud rate, parity, data bits, stop bits, flow control must match the device
2. Set TCP timeouts: Configure idle timeout, connection retry, and reconnection behavior
3. Latency: Add inter-character delay if the converter sends too fast for the serial device
4. Buffering: Configure FIFO size for burst data
5. Termination: If converting RS485, maintain proper 120 Ω bus termination
6. Network redundancy: Use dual-NIC converters (e.g., Moxa NPort 6000 series) for redundant Ethernet

16. Common Serial Communication Failures and Debugging

16.1 Physical Layer Problems

16.2 Protocol Layer Problems

16.3 Configuration Problems

16.4 Environmental Problems

17. Troubleshooting Matrices

17.1 Quick Diagnostic Flowchart

Serial Communication Failure
│
├─ No data at all?
│   ├─ Probe TXD with oscilloscope → No signal?
│   │   ├─ Check DV_FrameOpen / DRV_mbusOpen status
│   │   ├─ Verify device name (IF1 vs CS1020_IF1)
│   │   └─ Check if port is already open by another task
│   │
│   └─ TXD active but no response?
│       ├─ Verify RXD wiring (swap TXD/RXD)
│       ├─ Check device power
│       ├─ Verify slave address (Modbus)
│       └─ Check signal ground connection
│
├─ Garbled/wrong data?
│   ├─ Try 9600-8-N-1 (most common)
│   ├─ Try 9600-8-E-1 (Modbus RTU)
│   ├─ Try 19200-8-N-1
│   ├─ Measure bit width with oscilloscope for exact baud rate
│   └─ Check parity on both sides
│
├─ Intermittent failures?
│   ├─ Check RS485 termination (120 Ω at both ends)
│   ├─ Check for ground loops (shield grounded at both ends)
│   ├─ Inspect connectors for looseness
│   ├─ Measure cable length vs baud rate limits
│   └─ Check for EMI sources near cable run
│
└─ CRC / framing errors?
    ├─ Verify parity matches on both sides
    ├─ Reduce baud rate
    ├─ Replace cable with shielded twisted pair
    ├─ Add RS485 termination if missing
    └─ Check for signal reflections with oscilloscope

17.2 B&R-Specific Troubleshooting Matrix

17.3 Field Commissioning Checklist

18. References and Further Reading

B&R Documentation

• B&R Automation Help Portal: https://help.br-automation.com — DV_Frame library reference, DRV_mbus library reference, X20 system manuals
• X20CP158x / X20CP358x Datasheet: Available from br-automation.com — IF1/IF2 interface specifications and pinouts
• X20 System User’s Manual: Comprehensive X20 hardware and configuration guide
• B&R Automation Studio Online Help: Integrated in IDE; covers IO configuration, serial port setup, library functions
• System 2005 User’s Manual: Covers IF260, IF622, IF671 interface modules

Serial Communication References

• TIA-232-F (RS-232) Standard: Official electrical specification
• TIA-485 (RS-485) Standard: Differential multi-point serial specification
• Modbus Protocol Specification: https://www.modbus.org — Free download of Modbus RTU/TCP specification
• Saleae Logic Analyzer Documentation: Protocol decode guides, async serial analyzer setup
• PicoScope Modbus Decoding Guide: https://www.picotech.com/library/knowledge-bases/oscilloscopes/modbus-serial-protocol-decoding

Tools and Software

• HHD Serial Port Monitor: https://hhdsoftware.com/serial-port-monitor
• Saleae Logic Analyzer: https://www.saleae.com
• COM Sniffer: https://comsniffer.com
• Moxa NPort Configuration Guide: https://www.moxa.com
• QModMaster (free Modbus tool): Available on SourceForge
• RealTerm (serial terminal): https://realterm.sourceforge.io
• PuTTY (terminal emulator): https://www.putty.org

Community Resources

• B&R Community Forum: https://community.br-automation.com — Search for serial communication topics
• PLCtalk.net: https://www.plctalk.net — Industrial automation forums with B&R discussions
• EEVblog Forum: https://www.eevblog.com/forum — Reverse engineering and protocol analysis discussions
• Stack Overflow / Electronics Stack Exchange: Serial protocol debugging Q&A

Cross-References

• io-sniffing.md – general IO traffic sniffing approaches
• physical-layer-sniffing.md – RS-485 physical layer probing
• cp1584-forensics.md – first-contact diagnostic procedures
• modbus-gateway.md – Modbus RTU communication (serial-based)
• config-file-formats.md – serial port configuration files
• diagnostic-workstation.md – serial tap hardware and RS-232/485 adapters
• plc-to-plc.md – inter-PLC serial communication discovery
• grounding-emc.md – serial cable shielding and EMC considerations
• program-reverse-engineering.md – understanding serial protocol implementations

Document covers B&R serial communication diagnostics for System 2003, System 2005, and X20 platforms. Compiled from B&R official documentation, community forums, and industrial automation reference materials.

Key Findings

1. B&R serial interfaces (IF1030/IF1041/IF1051) are standard RS232/RS485 — any serial sniffer or protocol analyzer can capture the traffic. The challenge is decoding the application-layer protocol, not the physical layer.
2. The RS232 interface (IF1) factory default is 57600 bps, not 115200 bps — always try 57600 first when connecting to an unknown PLC. The baud rate can be configured higher but the default must be assumed.
3. Non-invasive serial tapping requires a Y-cable or tap adapter — never break the serial connection on a running machine. Use a 3-port RS232/RS485 tap that monitors traffic passively. See diagnostic-workstation.md for hardware recommendations.
4. B&R has no proprietary serial protocol documentation for serial-connected devices — the protocol implementation is in the PLC program (which you don’t have). Reverse-engineer the protocol by capturing traffic and correlating with known device behavior.
5. Serial baud rate auto-detection is feasible using statistical analysis — capture raw byte traffic at a high sample rate and use Python to identify the most likely baud rate by analyzing inter-byte timing patterns.
6. Modbus RTU over RS485 is the most common serial protocol on B&R systems — if the OEM used Modbus RTU, standard Modbus tools can decode the traffic immediately. See modbus-gateway.md for details.