PLC-to-PLC Communication on B&R Systems: Discovery, Interception, and Reverse Engineering Without Project Files

Overview

You have inherited a machine built by a now-defunct OEM. It has multiple B&R CP1584 PLCs, zero documentation, and no Automation Studio project files. The PLCs are clearly talking to each other — production halts when one goes down, and fault codes propagate across stations — but you have no idea how they communicate or what data they share.

This guide covers every practical method for discovering, tapping into, and understanding inter-PLC communication on B&R Automation systems when you are starting from scratch. It assumes familiarity with basic PLC concepts but no prior B&R-specific knowledge.

Related files in this repository:

Communication Mechanisms Between B&R PLCs

B&R PLCs can exchange data through at least six distinct mechanisms. On a multi-PLC machine, more than one may be active simultaneously. Your first job is to figure out which ones are in use.

Summary of Inter-PLC Communication Paths

Method 1: POWERLINK-Based Communication

POWERLINK How It Works

POWERLINK is B&R’s native real-time Ethernet protocol. It uses a Managing Node (MN) / Controlled Node (CN) architecture. For PLC-to-PLC communication, one PLC acts as the MN and the others as CNs, or all PLCs operate as CNs with a dedicated MN device.

There are two POWERLINK patterns for inter-PLC data exchange:

1. MN-mediated exchange: The MN collects data from all CNs and redistributes it. PLC-A sends its data to the MN in its PRes frame, the MN copies relevant data into PLC-B’s PReq, and PLC-B receives it. This is the simplest and most common pattern.

2. CN-to-CN direct cross-traffic: PRes frames are multicast. PLC-B can directly read PLC-A’s PRes payload without going through the MN. This requires explicit configuration in Automation Studio (both PLCs must be in the same project or referenced together) and the receiving CN must support cross-traffic (B&R iCNs do; third-party CNs may not).

What You’ll See on the Wire

POWERLINK uses ethertype 0x88AB. A typical cycle looks like:

[MN SoC] → [PReq to CN1] → [CN1 PRes] → [PReq to CN2] → [CN2 PRes] → [SoA] → [ASnd...]

• SoC (Start of Cyclic): MN initiates the isochronous phase
• PReq (Poll Request): MN polls a specific CN by NodeID
• PRes (Poll Response): CN responds with its process data (PDOs)
• SoA (Start of Asynchronous): Opens the async phase
• ASnd (Asynchronous Send): Non-real-time data (SDO, NMT commands)

Wireshark Capture

# Capture POWERLINK traffic on interface eth0
wireshark -i eth0 -f "ether proto 0x88AB"

# Or use BPF filter
tcpdump -i eth0 -w powerlink.pcap "ether[12:2] = 0x88AB"

Useful Wireshark display filters:

epl.src == 1          # All packets from NodeID 1 (typically the MN)
epl.dest == 3         # All packets addressed to NodeID 3
epl.type == 0x0001    # SoC frames only
epl.type == 0x0013    # PReq frames only
epl.type == 0x0014    # PRes frames only
epl.type == 0x0016    # SoA frames only
epl.type == 0x0017    # ASnd frames only

Identifying Which PLCs Are POWERLINK Nodes

1. Connect a PC to the POWERLINK network (any tap point works — see physical-layer-sniffing.md for methods)
2. Capture traffic for 5–10 seconds
3. In Wireshark, look at the epl.src and epl.dest fields
4. NodeID 0 is broadcast, NodeID 240 (0xF0) is the MN by convention
5. Other NodeIDs (1–239) are CNs — each is a PLC or drive

Understanding the PDO Payload

The PRes frame payload contains the mapped process data objects (PDOs). Without the project file, you won’t know the data layout, but you can:

• Count the payload bytes in each PRes frame to determine the data width per CN
• Create a custom column in Wireshark: right-click a PRes payload field → “Apply as Column” → rename to “PRes-Payload”
• Watch for patterns: If a payload has a section that changes only when a specific physical event occurs (e.g., a conveyor starts), you can correlate it

For detailed PDO mapping internals, see powerlink-internals.md Section 8.

Determining MN vs CN Role for Each PLC

• The MN sends SoC, PReq, and SoA frames. It never sends PRes.
• CNs only send PRes and ASnd frames.
• If you see a PLC sending SoC frames, it is the MN.
• If PLCs are using an X20ET8819 network analysis module or similar dedicated MN hardware, none of the PLCs will be the MN.

Method 2: OPC-UA Server/Client Communication

OPC-UA How It Works

OPC-UA is the most “modern” and most accessible inter-PLC mechanism. One PLC runs an OPC-UA server (exposing its variables), and other PLCs run OPC-UA client components (OpcUa_Any hardware object in Automation Studio) that subscribe to those variables.

B&R supports both:

• Configuration-only OPC-UA (no code required): Using the OpcUa_Any hardware object in Physical View
• Code-based OPC-UA: Using AsOpcUac library or the community EasyUaClnt wrapper for complex types (strings, structs, methods)

Discovering OPC-UA Communication

This is the one mechanism you can fully discover without any project files:

Step 1: Find the servers

# Scan for OPC-UA discovery servers on the control network
nmap -p 4840 --open 192.168.1.0/24

# Or use opcua-commander if available
# python3 -m opcua  opc.tcp://192.168.1.50:4840

The default OPC-UA port is 4840. If a PLC has OPC-UA enabled, it will respond.

Step 2: Browse the namespace with UAExpert

1. Download UAExpert (Unified Automation) — free client
2. Add a new server: opc.tcp://<PLC-IP>:4840
3. If security is configured, you may need certificates. Try “None” security first.
4. Browse the address space tree

B&R OPC-UA namespace structure:

Objects
└── PLC
    ├── Modules
    │   ├── Default
    │   │   ├── <TaskName>
    │   │   │   ├── Variable1 (BOOL)
    │   │   │   ├── Variable2 (REAL)
    │   │   │   └── Variable3 (DINT)
    │   │   └── <OtherTask>
    │   └── Global PV
    │       ├── gVar1 (USINT)
    │       └── gVar2 (BOOL)
    └── Server
        └── (diagnostic info)

Step 3: Identify inter-PLC variables

Look for variables whose names suggest inter-PLC data exchange. Common naming patterns from OEMs:

• StationX_... / CellX_... — station/cell identifiers
• From_PLC1_... / To_PLC1_...
• Handshake_... / HS_...
• Command_... / Status_...
• Interlock_... / Safety_...
• Recipe_... / Setpoint_...
• Heartbeat_... / Watchdog_...

Step 4: Monitor values in real-time

In UAExpert, subscribe to suspected inter-PLC variables. Watch how they change when you:

• Cycle the machine through different states
• Trigger faults on one station
• Change recipes or product types

Critical Limitation: Variables Must Be Explicitly Enabled

OPC-UA does not automatically expose all variables. Each variable must be explicitly marked as an OPC-UA tag by the OEM in the OpcUaMap configuration. If the OEM didn’t enable a variable, it won’t appear in the namespace — even if it exists in the running PLC program. See opcua.md for details on the enable/disable mechanism.

OPC-UA Browse Path Syntax (B&R to B&R)

When configuring a B&R OPC-UA client to connect to a B&R OPC-UA server, the browse path syntax is:

# Local variables (inside a specific task):
/0:Root/0:Objects/4:PLC/6:Modules/6:&:&:/6:/6:

# Global variables (PV scope):
/0:Root/0:Objects/4:PLC/6:Modules/6:&:&:/6:Global PV/6:

If the server uses Information Models (PV 2.00), replace 6:Modules with 4:Modules.

Checking if a PLC Is an OPC-UA Client

You cannot directly determine from outside whether a PLC is running an OPC-UA client. Indirect evidence:

• Port scan shows TCP connections to port 4840 on other PLCs
• The PLC has an OpcUa_Any object in its configuration (requires project file to confirm)
• OPC-UA server logs on the target PLC show active sessions from the suspect PLC’s IP

Method 3: Modbus TCP

Modbus TCP How It Works

Modbus TCP is widely supported on B&R SG4 controllers via the AsMbTCP (master) and AsMbTCPS (slave) libraries. It runs on standard Ethernet (not POWERLINK). Any PLC with an Ethernet port can act as a Modbus master or slave.

Discovering Modbus TCP

# Modbus TCP uses TCP port 502 by default
nmap -p 502 --open 192.168.1.0/24

# Attempt to read holding registers from a suspected slave
# (requires modbus client tool like mbpoll or pymodbus)
mbpoll -m tcp -t 3 -1 192.168.1.50

# Scan a range of register addresses
pymodbus.console -m tcp --host 192.168.1.50 --port 502
> client.read_holding_registers(0, 100)
> client.read_input_registers(0, 100)
> client.read_coils(0, 100)
> client.read_discrete_inputs(0, 100)

Identifying Register Maps

Without the project, you’ll need to brute-force the register space:

import modbus_tk.modbus_tcp as modbus_tcp
import modbus_tk.defines as defines

master = modbus_tcp.TcpMaster(host='192.168.1.50', port=502)
master.set_timeout(5.0)

# Scan holding registers in blocks
for base in range(0, 10000, 100):
    try:
        result = master.execute(1, defines.READ_HOLDING_REGISTERS, base, 100)
        if any(v != 0 for v in result):
            print(f"Active registers at {base}: {result}")
    except:
        pass

Watch which registers change when you manipulate different parts of the machine.

Method 4: Ethernet/IP (CIP)

Ethernet/IP How It Works

B&R controllers support EtherNet/IP via the AsEthIP library. This is common when integrating with Rockwell/Allen-Bradley equipment, but B&R-to-B&R communication over EIP is also possible.

Discovering EtherNet/IP

# EIP discovery uses TCP port 44818 and UDP port 44818
nmap -p 44818 -sU -sS --open 192.168.1.0/24

# EIP explicit messaging uses TCP 44818
nmap -p 44818 --open 192.168.1.0/24

Method 5: PVI/INA2000 (Legacy Proprietary)

PVI/INA2000 How It Works

PVI (Process Visualization Interface) is B&R’s proprietary middleware. The INA2000 protocol runs on TCP port 11160 by default. Every B&R controller running Automation Runtime has a PVIServer that responds to INA2000 connections.

This is not typically used for PLC-to-PLC data exchange in production, but it IS used for:

• HMI panels connecting to PLCs
• SCADA systems via the PVI OPC bridge
• Automation Studio online connections

Discovering PVI/INA2000

# Scan for INA2000/PVI servers
nmap -p 11160 --open 192.168.1.0/24

If a PLC responds on port 11160, you can connect using:

• Automation Studio (Connection → Set Target)
• PVI Browser (part of PVI installation)
• Custom PVI client (see pvi-api.md)

Browsing Variables via PVI

Using the PVI API from a PC, you can enumerate variables on a running PLC without project files:

# Pseudo-code using PVI .NET API
# See pvi-api.md for full examples
line = PviConnection("TCP", "192.168.1.50", 11160)
cpu = line.CPU("PLC")
variables = cpu.Variables.Browse()  # Lists all PV variables
for v in variables:
    print(f"{v.Name}: {v.Read()}")

For complete PVI reference, see pvi-api.md.

Method 6: Raw TCP/UDP Sockets

Raw TCP/UDP How It Works

OEMs sometimes implement custom inter-PLC communication using B&R’s AsTcp library (part of the AsEth family). This gives complete flexibility but is the hardest to reverse-engineer because there is no standard protocol — the data format is entirely up to the programmer.

Discovering Custom TCP Communication

# Comprehensive TCP port scan
nmap -sS -p- --open 192.168.1.0/24

# After identifying open ports, capture traffic:
tcpdump -i eth0 -w custom-tcp.pcap "host 192.168.1.50 and host 192.168.1.51"

Analyzing Custom Protocols

1. Capture traffic while the machine runs through different states
2. Look for periodic traffic with consistent message sizes (likely cyclic data exchange)
3. Look for request/response patterns (likely command/status)
4. Check if payloads are ASCII (text-based protocol) or binary
5. Correlate payload changes with physical machine events

Common patterns you might encounter:

• Fixed-size binary frames with a header byte, data payload, and checksum
• ASCII-based protocols using delimiter characters (CR/LF, semicolons)
• Length-prefixed messages with a 2-byte or 4-byte length header

Step-by-Step Discovery Procedure

When you are starting with zero knowledge, follow this systematic approach:

Phase 1: Physical Network Mapping

1. Trace cables from each PLC’s Ethernet ports (IF1, IF2, IF3)
   • IF1 / IF2: Standard Ethernet (TCP/IP, OPC-UA, Modbus, etc.)
   • IF3: POWERLINK (or configurable as Ethernet)
2. Note which PLCs share switches/hubs
3. Draw a physical topology map showing every PLC, switch, and cable

See network-architecture.md for detailed enumeration procedures.

Phase 2: Network Scanning

# Discover all B&R devices on the network
# B&R controllers respond to SNMP on UDP port 161 (if enabled)
nmap -sU -p 161 --open 192.168.1.0/24

# Scan for all common B&R service ports
nmap -p 80,443,11160,4840,502,44818,4000-4100 --open 192.168.1.0/24

Phase 3: Protocol Identification

For each pair of PLCs that you suspect communicate:

# Monitor all traffic between two specific PLCs
tcpdump -i eth0 -w plc-pair.pcap "host 192.168.1.50 and host 192.168.1.51"

# Run for 60 seconds during normal operation, then review in Wireshark

In Wireshark, check:

• Ethertype 0x88AB → POWERLINK traffic (if on shared PLK segment)
• TCP to port 4840 → OPC-UA
• TCP to port 502 → Modbus TCP
• TCP to port 11160 → PVI/INA2000
• TCP to other ports → Custom socket communication
• UDP traffic → Could be POWERLINK async or custom UDP

Phase 4: POWERLINK Deep Dive

If POWERLINK is present:

# Capture POWERLINK frames
tcpdump -i eth0 -w powerlink-dump.pcap "ether proto 0x88AB"

In Wireshark:

1. Identify the MN: Look for SoC frames (type 0x0001). The source is the MN.
2. List all CNs: Every unique NodeID in PRes frames is a CN (PLC or drive).
3. Map the cycle: Sort by time to see the polling sequence.
4. Extract PRes payloads: Create a custom column for the payload data.
5. Identify which CNs are PLCs vs drives: Drives typically have larger payloads with motion-related data patterns.

Phase 5: OPC-UA Namespace Mining

For each PLC with port 4840 open:

1. Connect UAExpert to opc.tcp://<IP>:4840
2. Browse the full namespace tree
3. Export the variable list (UAExpert: File → Export → CSV)
4. Compare exported lists between PLCs — overlapping variable names suggest shared data
5. Subscribe to variables and monitor value changes during machine operation
6. Document every variable with: name, data type, observed value range, what machine event changes it

Identifying What Data Is Being Shared

Once you know how the PLCs communicate, you need to figure out what they’re exchanging. This is the hardest part without documentation.

Approach 1: OPC-UA Variable Mining (Best Case)

If OPC-UA is enabled and the OEM exposed inter-PLC variables, this is straightforward:

1. Export the full namespace from each PLC
2. Sort variables by name patterns
3. Create a correlation matrix

PLC-1 Variable          PLC-2 Variable           Relationship
------------------      ------------------        -----------
Station1_Ready          Station2_StartReq         Handshake
Conv1_Speed_Setpoint    Conv1_Speed_Actual        Setpoint/Feedback
Heartbeat_Timer         Heartbeat_Watchdog        Liveness check
Recipe_Number           Recipe_Active             Recipe propagation

Approach 2: POWERLINK Payload Correlation

Without OPC-UA visibility into the mapped variables:

1. Capture POWERLINK traffic during a controlled test sequence
2. Force specific machine states one at a time
3. For each state, compare PRes payloads to identify which bytes change
4. Build a byte-level map of each CN’s payload

Practical procedure:

Test Sequence:
1. Machine idle (all stations stopped)
2. Station 1 running alone
3. Station 2 running alone
4. Both stations running
5. Fault on Station 1
6. Fault on Station 2
7. E-stop
8. Recipe change

For each test: capture 10 seconds of PRes data
Compare payloads between tests to isolate station-specific data regions

Approach 3: TCP Payload Pattern Analysis

For Modbus TCP or custom socket communication:

1. Capture all traffic between PLC pairs during a full production cycle
2. Use Wireshark’s “Follow TCP Stream” feature
3. Look for repeating patterns in payload data
4. Try common industrial data encoding:
   • Big-endian or little-endian 16/32-bit integers
   • IEEE 754 floating point
   • BCD-encoded values
   • Packed bits (bit 0 = status1, bit 1 = status2, etc.)

Approach 4: SDM Web Interface (Limited)

B&R’s SDM (Service and Diagnosis Management) web interface (port 80/443) provides:

• System Overview: Running tasks, CPU load, memory usage
• I/O Status: Digital and analog I/O states
• POWERLINK status: Node states, error counters
• File browser: CF card contents (can reveal configuration files)

Access via: http://<PLC-IP> in a web browser.

Configuration files on the CF card that may contain communication setup:

/System/
  OpcUa.Config.xml          # OPC-UA server configuration
  PLC_Configuration.xml    # Hardware and software configuration
  AR_Config.xml            # Runtime configuration
  /Powerlink/
    mn_config.xml          # MN configuration with node list
    cn_config.xml          # CN configuration

Approach 5: Firmware Object Dictionary SDO Read

If you can access a PLC via SDO (Service Data Object) over POWERLINK or CANopen, you can read the object dictionary to discover communication parameters:

• Object 0x1A00–0x1AFF: TPDO (Transmit PDO) mapping — what this node sends
• Object 0x1600–0x16FF: RPDO (Receive PDO) mapping — what this node receives
• Object 0x1400–0x14FF: TPDO communication parameters — timing and destination
• Object 0x1400–0x14FF: RPDO communication parameters

SDO access is available through:

• Automation Studio’s “Object Configurator” online mode
• B&R PVI API with POWERLINK line
• Custom tools using the POWERLINK SDO protocol

Building an Inter-PLC Communication Map

After completing discovery, document your findings in a structured format:

Template

INTER-PLC COMMUNICATION MAP
Machine: [Machine Name]
Date: [Date]
Engineer: [Your Name]

=== PLC INVENTORY ===
PLC-1: X20CP1584 @ 192.168.1.50, NodeID=240 (MN), Role: Main Controller
PLC-2: X20CP1584 @ 192.168.1.51, NodeID=1 (CN), Role: Station 2 Controller
PLC-3: X20CP1584 @ 192.168.1.52, NodeID=2 (CN), Role: Station 3 Controller

=== COMMUNICATION CHANNELS ===
Channel 1: PLC-1 ↔ PLC-2
  Protocol: POWERLINK (MN-mediated)
  Direction: Bidirectional
  Cycle: 2 ms
  Data: [Describe payload bytes and what they mean]
  Payload size: 64 bytes TX / 64 bytes RX

Channel 2: PLC-1 ↔ PLC-3
  Protocol: OPC-UA (PLC-1 server, PLC-3 client)
  Endpoint: opc.tcp://192.168.1.50:4840
  Variables:
    - PLC-1.gConv_Speed_Setpoint → PLC-3.localConvSpeed (REAL, 100ms)
    - PLC-3.gStation_Status → PLC-1.gStation3Status (UDINT, 50ms)

Channel 3: PLC-2 ↔ PLC-3
  Protocol: Modbus TCP (PLC-2 master, PLC-3 slave)
  Port: 502
  Registers:
    - Holding Register 0-9: PLC-2 → PLC-3 (command/status)
    - Holding Register 100-109: PLC-3 → PLC-2 (feedback)

Tapping Into Existing Communication (Read-Only)

Monitoring Without Disruption

The safest approach to understanding inter-PLC data is passive monitoring:

POWERLINK:

• Use a hub (not a switch) to tap into the POWERLINK segment — hubs broadcast all frames to all ports
• Or use a managed switch with port mirroring (SPAN) configured
• The B&R X20ET8819 network analysis tool provides hardware-timestamped captures with nanosecond accuracy
• Important: POWERLINK V1 used half-duplex, but POWERLINK V2 (the version supported by CP1584) uses full-duplex. When monitoring a V2 segment, set your NIC to auto-negotiate or 100 Mbit/s full-duplex. Only use half-duplex if you know the segment is running V1 (rare on CP1584 systems). See network-architecture.md for details.
• Recommended NIC settings: 100 Mbit/s, auto-negotiate (or full-duplex for V2), auto-crossover

OPC-UA:

• Connect UAExpert as an additional client — OPC-UA servers support multiple simultaneous sessions
• Set a high sampling interval (1000 ms) to minimize server load
• Never write to a variable you don’t understand

Modbus TCP:

• Capture traffic with tcpdump — Modbus requests and responses are plaintext
• Use a protocol-aware switch to mirror traffic without disrupting timing

Custom TCP:

• tcpdump with full payload capture: tcpdump -i eth0 -s 0 -w full-capture.pcap

Adding Your Own Monitoring Point

If you need ongoing visibility, consider adding a sniffer PLC or OPC-UA aggregation point:

Option A: OPC-UA Client on a Raspberry Pi

import asyncio
from asyncua import Client

servers = [
    "opc.tcp://192.168.1.50:4840",
    "opc.tcp://192.168.1.51:4840",
    "opc.tcp://192.168.1.52:4840",
]

async def browse_plc(server_url):
    async with Client(url=server_url) as client:
        root = client.get_root_node()
        children = await root.get_children()
        for child in children:
            print(f"  {await child.get_browse_name()}")

async def main():
    for url in servers:
        try:
            await browse_plc(url)
        except Exception as e:
            print(f"Failed to connect to {url}: {e}")

asyncio.run(main())

Option B: Wireshark + tshark Continuous Capture

# Capture all inter-PLC traffic to PCAP files with rotation
tshark -i eth0 -w /captures/inter-plc-%H%M%S.pcap \
       -f "ether proto 0x88AB or port 4840 or port 502" \
       -b duration:300 -b files:10

Common Inter-PLC Data Patterns on B&R Machines

Based on common OEM practices, these are the data types you are likely to find being exchanged:

Handshake Protocols

The most common pattern is a four-signal handshake between stations:

Station A sends:          Station B responds:
  Command_Ready ──────►    Status_Ready
  Command_Go    ──────►    Status_Busy
                           Status_Done  ──►  (Station A reads this)
  Command_Ack   ──────►    

Implemented as:

• POWERLINK: 4 BOOLs in the PDO payload
• OPC-UA: 4 BOOL variables
• Modbus: 4 coils or 2 registers (packed BOOLs)

Heartbeat/Watchdog

Almost every multi-PLC machine has a heartbeat:

• One PLC increments a counter every N ms
• Other PLCs check that the counter changes within a timeout
• If the counter stops changing, the watching PLC triggers a fault

Look for variables named: Heartbeat, HB, LifeCounter, Watchdog, CommOK

Recipe/Setpoint Distribution

One “master” PLC distributes recipe parameters to “slave” PLCs:

• Recipe number or name
• Process setpoints (temperature, speed, pressure targets)
• Product type selectors
• Batch identifiers

Safety Interlock Signals

Critical safety signals between PLCs:

• E-stop propagation (one E-stop stops all stations)
• Safety gate status sharing
• Light curtain acknowledgment
• Guard locking status

These may run on a separate safety PLC or through openSAFETY over POWERLINK. See safe-io-diagnostics.md for safety-specific considerations.

Reconstructing Project-Level Configuration

Using Automation Studio Online Mode

If you can get Automation Studio connected to a running PLC (see cp1584-forensics.md):

1. Connection → Set Target → Enter PLC IP
2. The physical view populates with the hardware tree from the running configuration
3. Logical View shows task names, program names, and library references
4. Variable Overview shows all PV variables with their types and current values
5. Hardware Configuration shows POWERLINK node list, PDO mappings, and module configuration

This is the single most valuable step for understanding inter-PLC communication. Even without the project source code, the online view reveals the entire hardware and communication configuration.

Extracting Configuration from the CF Card

If you can access the CF card (via SDM file browser, FTP, or physical card reader):

Key files to examine:

/System/PLC_Configuration.xml    # Full hardware tree
/System/AR_Config.xml             # Runtime config with task list
/System/OpcUa.Config.xml         # OPC-UA server config with variable list
/System/Powerlink/mn_config.xml   # POWERLINK MN node list and PDO map
/System/Powerlink/cn_config.xml   # POWERLINK CN parameters

The PLC_Configuration.xml file contains the entire physical and logical hardware tree, including all communication interfaces and their configuration. This is the closest thing to having the project file.

Troubleshooting Inter-PLC Communication Failures

Symptom: One PLC Shows “Communication Lost” Fault

Diagnostic steps:

1. Check physical connectivity (link LEDs on Ethernet ports)
2. Ping from the faulting PLC to its communication partner
3. Check POWERLINK node state in SDM (System Diagnosis → POWERLINK)
4. If POWERLINK: check if the faulted CN is in OPERATIONAL state
5. If OPC-UA: check if the ModuleOk flag is TRUE in the client PLC’s I/O mapping
6. If Modbus: check for timeout errors in the master PLC’s diagnostic variables

Symptom: Intermittent Data Corruption

1. Capture POWERLINK traffic and look for timing violations (SoC-to-SoC jitter)
2. Check for cyclic redundancy errors in the POWERLINK diagnostic counters
3. Verify cable lengths and termination
4. Check for electromagnetic interference sources near POWERLINK cables
5. Look for duplicate NodeIDs on the POWERLINK segment

Symptom: All PLCs Go Down Simultaneously

1. The MN has likely failed — no MN means no POWERLINK communication
2. Check if the MN PLC is running (power LED, run/fault LED)
3. If the MN is running but POWERLINK is down, check the IF3 port link status
4. Consider whether a POWERLINK ring redundancy failover has occurred

Symptom: New PLC Replacement Won’t Communicate

1. Verify the replacement PLC has the correct firmware version (AR version)
2. Check NodeID configuration — must match the original
3. The MN needs to recognize the new CN’s device description
4. If using cross-traffic configuration, the project on the MN must reference the new CN
5. Without the project, you may need to reconfigure the MN (see project-reconstruction.md)

Key Findings

1. POWERLINK is the most likely inter-PLC mechanism on B&R machines. Check for ethertype 0x88AB first. The MN-mediated exchange pattern is standard; CN-to-CN cross-traffic requires explicit project configuration.

2. OPC-UA is the most accessible discovery path when you have no project files. Port 4840, browse with UAExpert. Variable names alone tell you what data is shared — if the OEM exposed them.

3. PVI/INA2000 (port 11160) is always available on running B&R controllers and provides variable enumeration via the PVI API, even without project files.

4. Wireshark is your primary discovery tool for POWERLINK and custom TCP communication. The B&R POWERLINK dissector provides full protocol decoding including NodeID, frame type, and payload.

5. Variable naming conventions reveal purpose. OEMs typically use prefixes like Station_, Cell_, From_, To_, HS_ (handshake), HB_ (heartbeat) for inter-PLC variables.

6. Four-signal handshakes are the dominant pattern for inter-PLC coordination: Ready/Go/Done/Ack or equivalent BOOL exchanges.

7. The heartbeat/watchdog pattern is nearly universal in multi-PLC machines — one PLC increments a counter that others monitor for liveness.

8. Automation Studio online mode reveals the full hardware configuration of a running PLC, including POWERLINK node lists and PDO mappings — connect before anything else if you can get AS.

9. CF card configuration files (especially PLC_Configuration.xml and OpcUa.Config.xml) contain the entire communication setup. Access these via SDM, FTP, or physical card reader.

10. You cannot discover cross-traffic or custom TCP socket communication from outside — only through traffic capture and pattern analysis. These require the most effort to reverse-engineer.

11. Modbus TCP and EtherNet/IP are easy to discover via port scanning but hard to fully map without brute-forcing register spaces or CIP object models.

12. The SDM web interface (port 80/443) provides POWERLINK diagnostic status, I/O states, and file browser access — use it before reaching for Wireshark.

Sources

• B&R POWERLINK Communication Profile Specification (EPSG)
• B&R Automation Studio Online Help — POWERLINK configuration, OPC-UA server, and PVI settings
• B&R OPC-UA Server Configuration Guide — namespace, security, and endpoint configuration
• B&R PVI (Process Visualization Interface) Reference — variable enumeration and data exchange
• openPOWERLINK Wireshark Dissector Documentation — protocol decoding reference
• Wireshark Protocol Reference — ethertype 0x88AB (POWERLINK) filtering and analysis
• B&R Community Forum (community.br-automation.com) — inter-PLC communication discussions

Related Documents

• powerlink-internals.md — POWERLINK protocol deep internals and Wireshark analysis
• opcua.md — OPC-UA server configuration and variable browsing
• pvi-api.md — PVI API for programmatic variable access between PLCs
• network-architecture.md — Network topology and device enumeration
• modbus-gateway.md — Modbus TCP gateway as alternative inter-PLC communication
• cp1584-forensics.md — Initial information extraction from unknown PLCs
• config-file-formats.md — Configuration files controlling PLC communication