B&R ETHERNET Powerlink (EPL) — Deep Internals Technical Reference

Scope: Comprehensive technical reference covering the architecture, timing, diagnostics, configuration, and troubleshooting of B&R ETHERNET Powerlink networks.

Standards referenced: EPSG DS 301 (Communication Profile), EPSG DS 302-B (Application Layer), IEC 61158-13, IEC 61784-2, EN 50325-4 (CANopen profiles), ISO 15745-4 (XML device description)

Table of Contents

1. Architecture Overview
2. CN / MN State Machine
3. POWERLINK Cycle Timing
4. Phase Timing Within a Cycle
5. Ethernet Hardware Requirements — PHY / MAC
6. POWERLINK Frame Format
7. Node Addressing and Identification
8. PDO Mapping over POWERLINK
9. SDO Communication
10. Object Dictionary Layout
11. Error Handling and Recovery
12. Capturing and Analyzing EPL Traffic with Wireshark
13. Identifying Dropped Packets and Timing Violations
14. POWERLINK Configuration Files (XML Descriptors)
15. Modifying POWERLINK Parameters Without Automation Studio
16. Troubleshooting Intermittent Communication Failures
17. References and Source URLs

1. Architecture Overview

1.1 What is POWERLINK?

ETHERNET Powerlink is a real-time Ethernet (RTE) communication profile that extends standard IEEE 802.3 Fast Ethernet with deterministic scheduling. It was introduced by B&R (Bernecke+Rainer) in 2001 and was managed by the EPSG (Ethernet POWERLINK Standardization Group) until the EPSG dissolved in 2023. B&R now stewards the technology.

Key facts:

• Software-based protocol — no proprietary ASICs required
• Runs on any standard Ethernet silicon (MAC + PHY)
• Cycle times down to 100 µs with jitter < 1 µs (modern implementations)
• Up to 240 networked real-time devices per segment
• International standards: IEC 61158-13, IEC 61784-2, GB/T 27960-2011 (China)
• CANopen application layer (DS301/DS302) — “CANopen over Ethernet”

1.2 Managing Node (MN) and Controlled Nodes (CN)

Only one MN exists per POWERLINK segment. The MN grants deterministic media access to each CN sequentially — eliminating the CSMA/CD non-determinism of standard Ethernet.

1.3 Physical Topology

POWERLINK operates on standard IEEE 802.3u 100BASE-TX (or 1000 Mbps with EPL Gigabit).

• Recommended: Repeating hubs (not switches) within the real-time domain — minimizes delay and jitter
• Switches introduce variable latency due to store-and-forward and queuing
• Topologies: line, star, tree (any combination)
• Connectors: RJ-45 (8P8C) and M12 industrial
• Cabling: IAONA Industrial Ethernet Planning and Installation Guide

Real-time and non-real-time domains are separated. Standard IP routing connects the two.

2. CN / MN State Machine (NMT)

The Network Management (NMT) state machine governs boot-up, configuration, and runtime behavior of every POWERLINK device. The MN controls the states of all CNs by issuing NMT commands and monitoring status.

2.1 NMT States

Each POWERLINK device (both MN and CN) implements the following NMT states:

2.2 CN State Machine — Transitions

The CN state machine is controlled by the MN through NMT commands sent in ASnd frames:

                    ┌─────────────────────┐
                    │ NMT_Initializing     │
                    └──────────┬──────────┘
                               │ (auto: init complete)
                               ▼
               ┌───────────────────────────────┐
    ┌──────────│ NMT_Reset_Application (0x01)    │◄──────────────────┐
    │          └───────────────┬───────────────┘                   │
    │                          │ (NMT_Reset_Communication cmd)    │ (NMT_Reset_Application
    │                          ▼                                   │  cmd from MN)
    │          ┌───────────────────────────────┐                   │
    │          │ NMT_Reset_Communication (0x02) │◄──────────────────┘
    │          └───────────────┬───────────────┘
    │                          │ (auto: reset complete)
    │                          ▼
    │          ┌───────────────────────────────┐
    │          │ NMT_PreOperational1 (0x04)     │◄── NMT_Reset_Comm cmd
    │          └───────────────┬───────────────┘
    │                          │ (MN assigns nodeID via DNA; configuration starts)
    │                          ▼
    │          ┌───────────────────────────────┐
    │          │ NMT_PreOperational2 (0x05)     │
    │          └───────────────┬───────────────┘
    │                          │ (NMT_EnableReadyToOperate cmd from MN)
    │                          ▼
    │          ┌───────────────────────────────┐
    │          │ NMT_Ready_To_Operate (0x06)    │
    │          └───────────────┬───────────────┘
    │                          │ (NMT_Start_Node cmd from MN)
    │                          ▼
    │          ┌───────────────────────────────┐
    │          │ NMT_Operational (0x07)         │
    │          └──────────┬────────┬───────────┘
    │                     │        │
    │       (NMT_Stop_   │        │ (Error detected:
    │        Node cmd)   │        │  timeout, loss of PRes, etc.)
    │                     ▼        ▼
    │          ┌───────────────────────────────┐
    │          │ NMT_Stopped (0x08)            │
    │          └───────────────┬───────────────┘
    │                          │ (NMT_Start_Node cmd)
    │                          └──────────────► back to Operational
    └───────────────────────────┘ (any error or NMT_Reset cmd returns
                                   to appropriate reset state)

2.3 MN Cycle State Machine

In addition to the NMT state machine, each device has a Cycle State Machine that controls the POWERLINK cycle on the Data Link Layer. The Cycle State Machine is itself controlled by the NMT state machine — it only runs when the NMT state is OPERATIONAL.

The MN Cycle State Machine steps through the cycle phases:

1. Send SoC (Start of Cycle) — broadcast
2. Send PReq to CN #1, wait for PRes
3. Send PReq to CN #2, wait for PRes
4. … (all configured CNs)
5. Send SoA (Start of Asynchronous)
6. Wait for ASnd (from invited CN, if any)
7. Cycle complete — start next SoC

2.4 Boot-Up Sequence (Observed in Wireshark)

1. MN enters Operational and begins sending SoC frames
2. Unconfigured CNs send StatusRequest frames (identifying as node 0xF0 — unaddressed)
3. MN responds with IdentResponse (IRes) — acknowledges the CN
4. MN sends DNA (Dynamic Node Allocation) command — assigns a nodeID
5. MN reads CN’s XDD parameters via SDO
6. MN configures PDO mapping via SDO
7. MN issues NMT_EnableReadyToOperate command
8. CN transitions to Ready_To_Operate
9. MN issues NMT_Start_Node command
10. CN transitions to Operational — now participates in cyclic PDO exchange

3. POWERLINK Cycle Timing

3.1 Key Parameters

3.2 Calculating Minimum Cycle Time

From the B&R FAQ, the minimum cycle time is determined by:

Frames per cycle:
  1x SoC          = 64 bytes
  Nx PReq/PRes    = 64 to 1500 bytes each (depends on PDO payload size)
  1x SoA          = 64 bytes
  1x ASnd         = 300 to 1500 bytes (if async data present)

Transmission time = (payload_bytes * 8 + 64) bits * 10 ns/bit
                    (at 100 Mbit/s = 10 ns per bit)

Inter-frame gap  = 960 ns (IEEE 802.3 minimum IFG; ideal target for EPL)

Total CycleTime >= sum of all frame transmission times
                   + all inter-frame gaps
                   + PRes response time per CN (typically 960 ns minimum)

Example calculation for 10 nodes, each with 32 bytes of PDO data:

SoC:               (64 * 8 + 64) * 10 ns  =   5,760 ns
10x PReq:         10 * (64 * 8 + 64) * 10 ns =  57,600 ns
10x PRes:         10 * ((64+32) * 8 + 64) * 10 ns = 96,000 ns
10x IFG (PReq→PRes): 10 * 960 ns = 9,600 ns
SoA:               (64 * 8 + 64) * 10 ns  =   5,760 ns
ASnd (no data):    0 ns (if unused)

Total minimum:  ~174,720 ns ≈ 175 µs

With fewer nodes or smaller payloads, cycle times can reach 100 µs.

3.3 Prescaler and Multiplexed Mode

POWERLINK supports a prescaler mechanism that allows groups of CNs to be polled at different rates:

• Prescale factor N: A CN with prescaler N is only polled every Nth cycle
• The SoC frame contains a PS (Prescaled Slot) flag and MC (Multiplexed Cycle Completed) flag
• This allows combining fast motion axes (polled every cycle) with slow temperature sensors (polled every 10th or 100th cycle)

4. Phase Timing Within a Cycle

The POWERLINK cycle consists of three distinct phases:

|<------------- CycTime (e.g., 200 µs) ----------------->|
|                                                        |
|  Start     |  Isochronous Phase          | Asynchronous |
|  Phase      |                             | Phase       |
|             |                             |             |
|  SoC ──► PReq1──►PRes1 ──► PReq2──►PRes2 ──► ... ──► SoA──►ASnd ──►|
|             |<-- Time Slot 1 -->|<-- TS 2 -->|        |            |
|             |  (CN1 exclusive)  |(CN2 excl.) |        |            |

4.1 Start Phase

• MN broadcasts a SoC (Start of Cycle) frame to all nodes
• Destination MAC: broadcast (FF:FF:FF:FF:FF:FF)
• Contains: NetTime (global network timestamp), RelativeTime, flags
• All CNs synchronize to this frame — it is the cycle trigger
• Flags in SoC: PS (Prescaled Slot indicator), MC (Multiplexed Cycle Completed), AN (Asynchronous Needed)

4.2 Isochronous Phase (Real-Time Data Exchange)

During this phase, the MN polls each configured CN sequentially:

1. MN sends PReq (Poll Request) — unicast to the specific CN’s MAC address

   • Contains: MN’s TX PDO data for that CN
   • Fields: RD (Ready), EA (Exception Acknowledge), MS (Multiplexed Slot), PDOVersion
   • Payload: the process data (PDO) directed to this CN

2. CN responds with PRes (Poll Response) — multicast to all nodes

   • Contains: CN’s TX PDO data
   • Fields: NMTStatus, RD, PR (Priority), RS (RequestToSend), EN (Exception New)
   • Multicast: All CNs receive this — enabling peer-to-peer producer/consumer communication (a drive can listen to another drive’s PRes without routing through the MN)

Time Slot: Each PReq/PRes pair occupies a dedicated time slot. The MN tracks elapsed time and if PRes is not received within the configured timeout, the CN is marked as having a communication error.

4.3 Asynchronous Phase

After all isochronous slots, the MN sends SoA (Start of Asynchronous):

• Contains: EPLVersion, NMT status, sync control, svid (service ID), svtg (service target)
• The SoA frame names which CN is invited to send asynchronous data
• The invited CN responds with ASnd (Asynchronous Send)
• ASnd can carry: SDO transfers, NMT commands, NMT responses, status/error information
• Standard IP-based protocols (TCP, UDP, HTTP, etc.) can be tunneled through ASnd
• If no async data is needed, the SoA frame alone ends the cycle

4.4 Phase Duration Configuration

• The isochronous phase duration is determined by: number of CNs × (PReq transmission time + PRes transmission time + inter-frame gap + PRes response time)
• The asynchronous phase duration is the remainder of CycTime after the isochronous phase
• If the isochronous phase takes longer than CycTime, the MN cannot maintain the cycle → communication error

5. Ethernet Hardware Requirements — PHY / MAC

5.1 What Makes POWERLINK Special About the PHY/MAC

POWERLINK’s key design principle: it uses completely standard Ethernet hardware. There is no custom ASIC or modified MAC required. This is what distinguishes POWERLINK from protocols like EtherCAT (which requires a custom EtherCAT slave controller ASIC).

However, several hardware considerations are critical:

5.1.1 Half-Duplex Mode

POWERLINK operates in half-duplex mode within the real-time domain.

• All frames are broadcast/multicast on a shared segment
• No switches in the real-time domain — only repeating hubs
• Switches introduce store-and-forward delay (frame must be fully received before forwarding) and queuing latency — both destroy deterministic timing
• Hubs simply repeat bits at the PHY level with minimal delay (typically < 1 µs)

5.1.2 Physical Layer

• 100BASE-TX (100 Mbit/s, twisted pair) — primary specified physical layer
• 1000 Mbps (Gigabit Ethernet) also supported since 2006
• Standard Ethernet PHY transceivers are used
• Auto-negotiation should be disabled or fixed to 100 Mbps half-duplex in the real-time domain
• Auto-crossover (MDI-X) is acceptable and simplifies cabling

5.1.3 MAC Layer

• Standard IEEE 802.3 MAC is used
• The CSMA/CD mechanism is effectively bypassed because POWERLINK’s scheduling ensures only one node transmits at a time — no collisions occur under normal operation
• The MAC does not need any modification; the scheduling is implemented in software
• Some implementations use a hardware-assisted “selective forward” mechanism or FPGA-based MAC to reduce software latency (e.g., port PE2MAC IP core, Xilinx solutions)

5.1.4 Network Card Setup for Diagnostics

When capturing traffic with a PC:

• Set to 100 Mbps, half-duplex
• Disable all protocols (TCP/IP, Windows File Sharing, etc.) on the capture interface
• Connect via a hub (not a switch) to see all traffic
• A switch will only forward unicast traffic to the capture port if the port is the destination, missing all other CNs’ traffic

5.1.5 Hardware Acceleration for CNs

While no custom ASIC is required, many CN implementations use hardware acceleration to meet the strict 960 ns PRes response time requirement:

• FPGA-based implementations: Xilinx Spartan/Virtex, Altera Cyclone
• SoC approaches: TI Sitara (AM335x) with PRU-ICSS, NXP i.MX, ARM Cortex with dedicated Ethernet DMA
• Dedicated communication processors: Hilscher netX, IXXAT, Kunbus

5.2 Frame Timing on the Wire

At 100 Mbps:

• 1 bit = 10 ns
• Minimum Ethernet frame = 512 bits (64 bytes) = 5.12 µs (with preamble and IFG)
• Maximum Ethernet frame = 12,288 bits (1536 bytes with preamble) = 122.88 µs
• Inter-frame gap (IFG) = 96 bits = 960 ns

For a 64-byte SoC frame:

• Preamble (8 bytes) + Frame (64 bytes) + FCS (4 bytes) + IFG (12 bytes) = 88 bytes
• 88 × 8 bits × 10 ns = 7,040 ns ≈ 7 µs

6. POWERLINK Frame Format

6.1 EtherType

POWERLINK frames use EtherType 0x88AB (registered with IEEE).

This is how a protocol analyzer (Wireshark) distinguishes POWERLINK frames from standard IP traffic.

6.2 Frame Structure

┌──────────────────────────────────────────────────────────────────┐
│ Ethernet Header (14 bytes)                                       │
│ ┌──────────────┬──────────────┬──────────────────────────────┐   │
│ │ Dest MAC (6B)│ Src MAC  (6B)│ EtherType: 0x88AB (2B)       │   │
│ └──────────────┴──────────────┴──────────────────────────────┘   │
├──────────────────────────────────────────────────────────────────┤
│ POWERLINK Header                                                  │
│ ┌──────────────────┬──────────┬──────────┐                       │
│ │ Message Type (1B)│ Src (1B) │ Dest (1B)│                       │
│ └──────────────────┴──────────┴──────────┘                       │
├──────────────────────────────────────────────────────────────────┤
│ Message-specific payload (variable length)                       │
│ SoC: NetTime, RelativeTime, flags                                │
│ PReq/PRes: PDO data, status flags                                │
│ SoA: EPL version, NMT status, service IDs                         │
│ ASnd: SDO commands, NMT commands, status responses               │
├──────────────────────────────────────────────────────────────────┤
│ Ethernet FCS (4 bytes — CRC32)                                   │
└──────────────────────────────────────────────────────────────────┘

6.3 POWERLINK Message Types

6.4 Destination / Source Fields in the EPL Header

• Source (epl.src): Node ID of the sending device (1-240, 0xF0 for MN, 0xFF for broadcast)
• Destination (epl.dest): Node ID of the intended receiver (or broadcast)

Note: The MAC addresses are derived from the nodeID. POWERLINK uses a convention where the last byte of the MAC address encodes the nodeID.

7. Node Addressing and Identification

7.1 Node ID

• Each POWERLINK device is addressed by an 8-bit Node ID (1 to 240)
• Node ID 0xF0 is reserved for the MN (Managing Node)
• Node ID 0xFF is broadcast (all nodes)
• The Node ID has only local significance within a POWERLINK segment
• A CN with nodeID 0 (unset) sends StatusRequest frames during boot-up to get assigned an ID

7.2 Dynamic Node Allocation (DNA)

During boot-up, the MN assigns nodeIDs to unconfigured CNs via the DNA (Dynamic Node Allocation) command in an ASnd frame. The DNA command contains:

7.3 CN Number

In B&R systems, the “CN number” is the logical number (1, 2, 3…) assigned to each CN in the Automation Studio project. This maps to the POWERLINK nodeID during configuration.

7.4 MAC Address Convention

POWERLINK uses the assigned nodeID to construct the destination MAC for PReq frames. The MAC address format is:

01:01:00:00:00:XX   where XX = NodeID (in hex)

For example:

• Node 1: 01:01:00:00:00:01
• Node 10: 01:01:00:00:00:0A
• Node 240: 01:01:00:00:00:F0
• MN broadcast: FF:FF:FF:FF:FF:FF

PRes frames use multicast MAC addresses so all CNs can receive them (producer/consumer model).

8. PDO Mapping over POWERLINK

8.1 PDO in POWERLINK vs. CANopen

In CANopen, PDOs are limited to 8 bytes. In POWERLINK, a single PDO can carry up to 1490 bytes of net data (limited by the Ethernet MTU minus headers).

POWERLINK has only one TxPDO per device (since the frame can carry all data in one transmission), unlike CANopen which has up to 4 TPDOs and 4 RPDOs.

8.2 PDO Mapping Objects (Object Dictionary)

Each mapping object contains sub-indices:

• Sub-index 0: Number of mapped objects
• Sub-index 1..254: Mapping entries (16-bit each)

Each mapping entry encodes:

Bits 15..8: Index of the OD object
Bits  7..0: Sub-index of the OD object

The actual number of bytes per mapped object is determined by the data type of the referenced OD entry (e.g., UNSIGNED16 = 2 bytes, REAL32 = 4 bytes, etc.).

8.3 Static vs. Dynamic Mapping

8.4 PDO Communication Parameters

8.5 PDO Version

The PDOVersion field (epl.preq.pdov / epl.pres.pdov) in PReq/PRes frames indicates whether the PDO mapping has changed. If the MN detects a PDO version mismatch, it may trigger reconfiguration.

9. SDO Communication

9.1 SDO Transfer Mechanisms

SDOs (Service Data Objects) are used for non-time-critical parameter exchange:

• Configuration during boot-up
• Reading/writing OD entries at runtime
• Diagnostic data access

SDOs can be transferred via three mechanisms in POWERLINK:

9.2 SDO Protocol Layers

The SDO protocol in POWERLINK has multiple layers (visible in Wireshark):

1. Command Layer (epl.asnd.sdo.cmd): Initiate read/write, segment, abort

   • command.id: SDO Command ID
   • data.index / data.subindex: OD object reference
   • data.size: Total data size

2. Sequence Layer (epl.asnd.sdo.seq): Segmentation and flow control

   • send.sequence.number / receive.sequence.number: Sequence counter
   • send.con / receive.con: Confirmation toggle

3. Fragmentation: Wireshark can reassemble fragmented SDO transfers using the fragment fields

9.3 SDO Abort Codes

SDO transfers can be aborted with a 32-bit abort code (visible in epl.asnd.sdo.cmd.abort.code). Common abort codes include:

• 0x05040001: Toggle bit not alternated
• 0x06040000: SDO protocol timeout
• 0x06040001: Client/server command specifier not valid
• 0x06040041: SDO blocked by the SDO client
• 0x06040042: Memory size exceeds SDO block size
• 0x06060000: Unsupported access to an object
• 0x06070010: Data type does not match (length error)
• 0x08000000: General error

10. Object Dictionary Layout

10.1 Standard POWERLINK Object Dictionary Structure

10.2 Key Communication Objects

10.3 Identity Object (0x1018)

11. Error Handling and Recovery

11.1 Error Detection Mechanisms

POWERLINK uses multiple layers of error detection:

11.2 DLL Error Counters

Each POWERLINK device maintains error counters accessible via SDO:

B&R devices provide additional Ethernet-level error counters for diagnosing physical network connections (cable and connector quality).

11.3 Timeout Handling

When the MN sends a PReq to a CN and does not receive a PRes within the configured PresTime:

1. Immediate cycle: The MN marks the slot as “missed” and continues to the next CN
2. LossOfFrameTolerance: If the CN misses a configurable number of consecutive cycles, the MN declares the CN as lost
3. CN state transition: The MN may issue an NMT_Stop_Node or NMT_Reset_Command to the affected CN
4. Error logging: The error is recorded in the MN’s error counters and typically triggers a diagnostic alarm (WCC or mapp alarm in Automation Studio)

11.4 CRC Error Handling

CRC errors are detected at the Ethernet MAC level:

• The received frame’s FCS does not match the computed CRC-32
• The frame is discarded — no POWERLINK processing occurs
• The CRCErrCnt counter is incremented
• If the corrupted frame was a PRes, the MN treats it as a missed response (same as timeout)
• Common causes: damaged cables, EMI (variable frequency drives, welding equipment), loose connectors, exceeding cable length limits

11.5 Duplicate Detection

POWERLINK’s sequence layer includes mechanisms to detect duplicate frames:

• The Sequence Layer (epl.asnd.sdo.seq) maintains SendSequenceNumber and ReceiveSequenceNumber counters
• Wireshark flags duplicated frames with the epl.asnd.sdo.duplication expert info
• Invalid sequence values trigger epl.error.value.send.sequence or epl.error.value.receive.sequence errors

11.6 Error Register (0x1001) — Static Error Bitfield

11.7 Automatic Recovery

• CN timeout recovery: After the MN declares a CN as lost, the CN may automatically restart its state machine and attempt to re-join the network (back to PreOperational1)
• Watchdog: The MN has an internal watchdog timer. If the MN itself fails, all CNs detect loss of SoC frames and enter a safe state (typically Stopped or Reset)
• Hot-plugging: New CNs can be hot-plugged into a running POWERLINK network. They send StatusRequest frames, get assigned a nodeID via DNA, and go through the full configuration sequence

12. Capturing and Analyzing EPL Traffic with Wireshark

12.1 EPL Protocol Support in Wireshark

Wireshark has built-in POWERLINK (EPL) protocol support since version 1.0.0. No additional plugin is required — the dissector is registered for EtherType 0x88AB.

The dissector is identified by the protocol field epl.

12.2 Hardware Setup for Capture

12.3 Wireshark Display Filters

Wireshark provides a comprehensive set of epl.* display filters:

Message type filters:

epl.soc          # Start of Cycle frames
epl.preq         # Poll Request frames
epl.pres         # Poll Response frames
epl.soa          # Start of Asynchronous frames
epl.asnd         # Asynchronous Send frames
epl.ainv         # Async Invitation (Multi-ASnd)

Node filters:

epl.src == 1              # All frames sent by NodeID 1
epl.dest == 1             # All frames addressed to NodeID 1
epl.src == 0xf0           # All frames from the MN

Status and error filters:

epl.pres.stat == 0x07     # PRes with NMT state = Operational
epl.pres.stat == 0x04     # PRes with NMT state = PreOperational1
epl.pres.en == 1           # PRes with Exception New flag set
epl.error                  # Any EPL error expert info
epl.error.payload.length.differs  # Payload length mismatch

SDO filters:

epl.asnd.sdo              # Any SDO transfer
epl.asnd.sdo.cmd.abort     # SDO abort frames
epl.asnd.sdo.cmd.data.index == 0x1006  # SDO access to cycle time object

PDO content visualization: To visualize cyclic user data, add a custom column:

1. Select a PRes frame
2. Right-click the “Payload” field
3. Select “Apply as Column”
4. Rename to “PRes-Payload”

12.4 Color Rules for Quick Analysis

Define Wireshark coloring rules for quick visual identification:

epl.soc           → Blue    (sync frame)
epl.preq          → Green   (MN polling)
epl.pres          → Orange  (CN response)
epl.soa           → Purple  (async phase start)
epl.asnd          → Brown   (async data)
epl.error         → Red     (errors)

12.5 Sample Captures

Wireshark includes sample EPL captures on the Wireshark Wiki SampleCaptures page:

• EPLv1 capture: MN and three CNs in operational mode
• EPLv2 capture: Boot-up of MN and one CN

These are excellent references for learning the frame sequences.

12.6 Practical Capture Workflow

1. Connect PC to POWERLINK segment via hub
2. Disable all network protocols on the capture NIC
3. Start Wireshark, select the capture NIC
4. Apply a capture filter if needed: ether proto 0x88AB (captures only EPL frames)
5. Let it run for several cycles (typically 1-2 seconds is enough)
6. Stop capture, save as pcapng
7. Sort by “Time” column to see the repeating cycle pattern
8. Apply display filters to focus on specific nodes or frame types

13. Identifying Dropped Packets and Timing Violations

13.1 Symptoms of Sensor Glitches Caused by EPL Issues

• Intermittent position/velocity jumps in drives
• Sporadic sensor readout errors (stale data, wrong values)
• Unexpected NMT state transitions on CNs (dropping from Operational to Stopped)
• Watchdog or communication alarms in the PLC

13.2 Identifying Missed PRes in Wireshark

Look for a PReq without a corresponding PRes:

1. Filter: epl.preq
2. Examine the time between consecutive PReq frames
3. If the gap for a PReq→PRes pair is abnormally long (or there’s no PRes between two PReq frames), the CN missed its slot

The MN’s behavior on a missed PRes:

• The cycle continues to the next CN’s PReq
• The CN’s error counter increments
• After LossOfFrameTolerance consecutive misses, the CN is dropped

13.3 Identifying CRC Errors

1. In Wireshark, look for frames with “Frame check sequence: [incorrect, should be …]” in the Ethernet layer detail
2. Filter with eth.fcs_bad == 1 (if the NIC reports FCS errors)
3. Check the DLL error counters via SDO: read the CRCErrCnt object

Note: Many modern NICs strip the FCS before passing frames to the operating system, so CRC errors may not be visible in Wireshark. Use the device’s internal error counters instead, or use a network analyzer that preserves FCS (like B&R X20ET8819).

13.4 Cycle Timing Violations

To verify cycle timing in Wireshark:

1. Filter: epl.soc
2. Examine the time delta between consecutive SoC frames
3. Compare against the configured CycTime
4. If the delta varies significantly (> 10% of CycTime), there may be:
   • Too many CNs for the configured cycle time
   • Async phase taking too long
   • NIC/driver latency on the capture PC

Important: PC-based timestamps are inherently inaccurate for sub-microsecond measurements. For precise jitter analysis, use hardware-based network analyzers.

13.5 Frame Sequence Errors

If the frame order appears wrong in a capture:

• This is almost always a capture artifact (PC NIC buffer timing, OS scheduling)
• Connect the PC via a hub (not switch)
• Disable all protocols on the capture NIC
• Use hardware-based capture for definitive results

The MN itself handles frame timing with much tighter tolerances than a PC can observe.

14. POWERLINK Configuration Files (XML Descriptors)

14.1 XDD — XML Device Description File

Every POWERLINK CN is described by an XDD (XML Device Description) file. This is standardized per ISO 15745-4 and EPSG DS311.

The XDD file contains:

• VendorID, ProductCode, RevisionNo — device identity
• Object Dictionary — all OD entries with index, sub-index, data type, access rights, defaults
• PDO mapping — default TPDO/RPDO mapping entries
• Device profile — profile-specific parameters (e.g., DSP402 for drives)
• EPLVersion — supported POWERLINK version
• Feature flags — isochronous support, SDO by UDP/IP, dynamic PDO mapping, multiplexing, etc.

Format:

<?xml version="1.0" encoding="UTF-8"?>
<ISO15745ProfileContainer>
  <ISO15745Profile>
    <ProfileBody>
      <ApplicationLayers>
        <DeviceProfileClass>
          <ProfileBody>
            <ISO15745ProfileContainer ...>
              <!-- Object Dictionary entries -->
            </ISO15745ProfileContainer>
          </ProfileBody>
        </DeviceProfileClass>
      </ApplicationLayers>
    </ProfileBody>
    <ProfileHeader>...</ProfileHeader>
  </ISO15745Profile>
</ISO15745ProfileContainer>

14.2 XDC — XML Device Configuration File

After network configuration is complete in Automation Studio, a build process generates an XDC file for each CN. The XDC file is the configured version of the XDD — it contains the actual parameter values (PDO mapping, nodeID, cycle parameters) as configured in the project.

The XDC is used by:

• The MN at runtime to know how to configure each CN
• openCONFIGURATOR or other tools for network setup
• Third-party integration tools

14.3 CDC — Configuration Description File

The MN’s configuration is stored in a CDC file. This is generated by the network configuration tool (Automation Studio, openCONFIGURATOR, or CODESYS) and contains:

• All CN configurations
• Node IDs
• PDO mappings
• Cycle time parameters
• Prescaler assignments
• Asynchronous MTU

14.4 Configuration Files on the CF Card

On B&R PLCs, the POWERLINK configuration is deployed to the Compact Flash (or SD) card as part of the Automation Studio project:

/Synchronize/
  └── <ProjectName>/
       ├── Config.prc
       ├── <MN_Interface>.cfg
       └── Powerlink/
            ├── MN_Configuration.xml (or .cdc)
            ├── CN1_Configuration.xdc
            ├── CN2_Configuration.xdc
            ├── ...
            └── CNn_Configuration.xdc

The exact file structure may vary by Automation Runtime version. The MN reads these configuration files at startup to configure the POWERLINK network.

14.5 ETS/EDS — Legacy CANopen Device Description

Some legacy devices may provide EDS files (CANopen Electronic Data Sheet format). These can be imported into Automation Studio or openCONFIGURATOR, which converts them into XDD/XDC format for POWERLINK use.

15. Modifying POWERLINK Parameters Without Automation Studio

15.1 Via SDO Access

Since POWERLINK uses CANopen’s object dictionary, any OD entry can be read or written via SDO:

Using openCONFIGURATOR:

• Import the XDD files for all devices
• Configure the network visually (node IDs, PDO mapping, cycle time)
• Generate the CDC configuration file
• Deploy to the MN

Using B&R tools:

• The B&R Automation Studio “Physical View” allows direct configuration of the POWERLINK interface parameters
• Configuration is compiled into the project and deployed on next download

15.2 Via OPC UA (POWERLINK for OPC UA)

The OPC UA companion specification (OPC-30110) provides direct access to the POWERLINK Object Dictionary from any OPC UA client. This allows:

• Reading/writing OD entries without Automation Studio
• Diagnostic access from standard HMI/SCADA systems
• Configuration changes at runtime

15.3 Via Network Trace Tools (Read-Only)

You can observe but not modify parameters via Wireshark by examining:

• SDO write commands during boot-up (epl.asnd.sdo.cmd.write.by.index)
• NMT commands (epl.asnd.nmtcommand)
• PDO mapping configuration SDOs

15.4 Using the openPOWERLINK Stack API

For developers using the openPOWERLINK stack, parameters are modified via the API:

// Example: Read/write OD entry
tOplkError oplk_readObject(UINT16 index_p, UINT8 subIndex_p,
                            tPlkDataType *pDataType_p, void *pDstData_p, UINT16 *pSize_p);
tOplkError oplk_writeObject(UINT16 index_p, UINT8 subIndex_p,
                             tPlkDataType dataType_p, UINT16 dataSize_p, const void *pSrcData_p);

15.5 Direct File Editing (Advanced)

On B&R systems, the XDC/CDC configuration files on the CF card are XML files that can theoretically be edited directly. However:

• This is NOT recommended by B&R and may void support
• The MN may verify file integrity (checksums, signatures)
• Incorrect edits can cause the network to fail to start
• Always back up the original files before modification

If you must edit offline, use a validated XML editor and check against the DS311/XDD schema.

16. Troubleshooting Intermittent Communication Failures

16.1 Systematic Troubleshooting Checklist

Layer 1 — Physical Layer

• Verify all cable lengths are within 100 m (Cat5) specification
• Check for damaged cables, kinks, sharp bends, crushed sections
• Inspect RJ-45 connectors for oxidation, bent pins, poor crimps
• Ensure proper grounding and shielding (use industrial-grade cable)
• Check for EMI sources near cables (VFDs, welding, power cables)
• Verify hub port LEDs show consistent link activity
• Separate POWERLINK cables from high-power cables

Layer 2 — Ethernet / MAC

• Verify half-duplex mode on all devices (no duplex mismatch)
• Confirm all devices are at 100 Mbps (no speed mismatch)
• Check Ethernet error counters: CRC errors, frame alignment errors, collisions
• Verify no switches in the real-time domain (only hubs)
• Check for broadcast storms from non-EPL sources

Layer 3 — POWERLINK DLL

• Read DLL error counters from all devices via SDO
• Check LossOfFrameCnt — if incrementing, SoC is not arriving consistently
• Check CRCErrCnt — if incrementing, physical layer issue
• Check TimeoutCnt — if incrementing, CNs are too slow or cycle time too short

Layer 4 — POWERLINK NMT

• Check NMT state of all CNs (should be 0x07 = Operational)
• Look for CNs dropping to Stopped (0x08) or lower states
• Check PLC alarm log for POWERLINK errors (WCC_WATCHDOG, mnuErrorStat)
• Verify all CNs completed boot-up and configuration successfully

Layer 5 — Application / Configuration

• Verify PDO mapping is correct (no mismatch between MN expectation and CN configuration)
• Verify CycTime is long enough for all nodes and their data payloads
• Check async MTU is sufficient for async traffic requirements
• Verify node IDs are unique and correct

16.2 Common Root Causes of Intermittent Failures

16.3 Network Diagnostic Tools

16.4 B&R PLC Diagnostic Approach

1. Check the PLC alarm log (System → Diagnostics in Automation Studio or web interface)
2. Look for POWERLINK-specific alarms: WCC_WATCHDOG, mnuErrorStat, plkErrorState
3. Use the POWERLINK library diagnostic FBs (e.g., MC_Powerlink_STATE, MC_Powerlink_DIAG)
4. Read error counters from the MN and each CN via SDO or OPC UA
5. If the PLC log shows specific nodeIDs failing, focus on those CNs

16.5 Advanced: EPL-Viz

EPL-Viz is a visualization tool for Ethernet POWERLINK networks that provides:

• Network state monitoring
• Cycle timing analysis
• Error pattern detection
• Timeline visualization

Available at: https://epl-viz.github.io/

Cross-References

• x2x-protocol.md — X2X bus protocol; the local IO bus that feeds data into POWERLINK
• physical-layer-sniffing.md — Probing Ethernet/POWERLINK signals at the physical layer
• network-architecture.md — Network topology design, Ethernet switching requirements for POWERLINK
• execution-model.md — How POWERLINK cycle timing interacts with task class scheduling
• acopos-drives.md — ACOPOS servo drive POWERLINK communication and diagnostics
• cp1584-hardware-ref.md — CP1584 POWERLINK interface specifications (IF3)
• io-sniffing.md — Higher-level sniffing methodology combining POWERLINK capture with IO analysis
• config-file-formats.md — POWERLINK configuration in ARConfig.ini and X2X Link settings
• cf-card-boot.md — How POWERLINK configuration is loaded at boot from the CF card
• diagnostic-workstation.md — Wireshark setup and network tap hardware for POWERLINK analysis
• plc-to-plc.md — POWERLINK as the primary PLC-to-PLC communication mechanism
• firmware.md — AR version requirements for POWERLINK features and fixes

17. References and Source URLs

Official Specifications (EPSG / B&R)

OPC Foundation — OPC UA for POWERLINK

Wireshark Resources

openPOWERLINK (Open Source)

Using openPOWERLINK for POWERLINK protocol analysis on Linux: The openPOWERLINK stack implements both MN (master) and CN (slave) roles and runs on standard Linux with either user-space or kernel-space (via Xenomai or PREEMPT_RT) execution. For diagnostic purposes, you can:

1. Build a POWERLINK CN (slave) on a Linux PC that joins the B&R POWERLINK network, allowing you to receive and log all PDO data from the MN in real-time without needing Wireshark.
2. Use the openPOWERLINK MN (master) on Linux to independently poll all CNs on the network, verifying node addressing and identifying nodes that the B&R MN may not be communicating with.
3. Capture raw POWERLINK frames at the application layer using openPOWERLINK’s event/callback system, which provides decoded frame data (SoC, PReq, PRes, SoA, ASnd) — more structured than raw Wireshark captures.

The stack is BSD-licensed and supports Linux, Windows, and Xilinx/Altera FPGAs. See the GitHub README for build instructions. This is an advanced technique for complex multi-node POWERLINK diagnostics where Wireshark capture alone is insufficient. See io-sniffing.md for the full fieldbus sniffing methodology.

Hardware and Implementation

Community and Knowledge Base

Configuration File Tools

B&R Configuration Guides

Key Findings

1. POWERLINK is a software-based real-time Ethernet protocol requiring no proprietary ASICs – it runs on any standard 100BASE-TX Ethernet MAC/PHY silicon. The MN (Managing Node) controls media access via Slot Communication Network Management (SCNM), granting deterministic time slots to each CN (Controlled Node). Cycle times down to 100 us with jitter < 1 us are achievable; up to 240 CNs per segment are supported.

2. The POWERLINK cycle has three phases: Start Phase (SoC broadcast with NetTime), Isochronous Phase (sequential PReq/PRes polling of each CN), and Asynchronous Phase (SoA + ASnd for SDO, NMT, diagnostics, and tunneled IP traffic). If the isochronous phase exceeds CycTime, the MN cannot maintain the cycle and triggers a communication error.

3. Minimum cycle time calculation: each PReq/PRes pair adds (payload_bytes * 8 + 64) * 10 ns transmission time plus 960 ns inter-frame gap. For 10 nodes with 32 bytes PDO each, the minimum is approximately 175 us. The Prescaler mechanism allows polling different CN groups at different rates (e.g., every Nth cycle for slow sensors).

4. The CANopen application layer means PDO mapping objects (0x1400/0x1600 for RPDO, 0x1800/0x1A00 for TPDO) and SDO communication (abort codes, sequence layers) work identically to CANopen over CAN. The object dictionary structure (0x1000-0x1FFF communication area, 0x6000-0x9FFF device profiles) is standard CiA DS301.

5. Wireshark capture setup: connect a PC NIC directly to the POWERLINK hub (not switch), deactivate TCP/IP on the capture interface, set half-duplex 100 Mbps. Key display filters: epl.service_type == "PRes" for IO data, epl.service_type == "ASnd" for configuration/diagnostics, epl.src == <NodeID> to isolate a specific station.

6. Error handling uses multiple layers: Ethernet CRC-32 (FCS) for frame corruption, DLL error counters (LossOfFrameCnt, CRCErrCnt, TimeoutCnt, InvalidFrameCnt, BufferOverflowCnt accessible via SDO), and NMT state machine transitions. When a CN misses the configurable LossOfFrameTolerance consecutive cycles, the MN declares it lost and issues NMT_Stop_Node.

7. The MN boot-up sequence visible in Wireshark: unconfigured CNs send StatusRequest (node 0xF0), MN responds with IdentResponse, assigns nodeID via DNA, reads XDD parameters via SDO, configures PDO mapping, issues NMT_EnableReadyToOperate, then NMT_Start_Node to enter Operational state.

8. Intermittent POWERLINK failures are most commonly caused by: damaged cables/loose connectors (CRC errors), EMI from VFDs/welders, exceeding 100 m cable length limit, switches introducing variable latency (use hubs instead), and bus overload (isochronous phase exceeding CycTime). Monitor DLL error counters to distinguish physical-layer errors from timing violations.

Document compiled from official EPSG specifications, B&R documentation, OPC Foundation companion specifications, Wireshark dissector documentation, openPOWERLINK source code references, community knowledge base posts, and hardware vendor application notes.