B&R X20IF2772 CAN Bus Module — Comprehensive Technical Reference

The X20IF2772 is B&R’s CAN bus interface module for the X20 system, implementing CANopen over CAN 2.0B. On legacy machines, CANopen networks often connect sensors, actuators, third-party devices, and subsystems that are critical to machine operation but poorly documented. This document covers the IF2772 hardware specifications, CANopen protocol stack implementation on B&R, PDO/SDO mapping, CAN identifier assignment, hardware-level CAN bus sniffing with tools like PCAN and Vector CANalyzer, and how to decode sensor data from raw CAN messages to diagnose field-level problems. Cross-references: io-card-hardware.md for IO card hardware architecture, physical-layer-sniffing.md for physical-layer CAN probing techniques, and io-sniffing.md for general fieldbus sniffing approaches.

Table of Contents

1. IF2772 Module Specifications
2. CANopen on B&R: Protocol Stack Implementation
3. PDO/SDO Mapping on B&R CAN Modules
4. CAN Identifier Assignment
5. Bit Timing Configuration
6. Hardware CAN Bus Sniffing
7. SocketCAN on Linux
8. Decoding Sensor Data from CAN Messages
9. CANopen Error Handling
10. IF2772 Configuration Parameters (Object Dictionary)
11. Setting Up CANopen on B&R Without the Original Project
12. Common CAN Bus Problems and Diagnostic Procedures
13. Wiring and Termination Requirements
14. CAN Analysis Tools Comparison

1. IF2772 Module Specifications

Module Overview

The B&R X20IF2772 is a dual CAN bus interface module for the B&R X20 I/O system. It provides application-specific expansion of X20 controllers via two independent, electrically isolated CAN bus interfaces, each capable of up to 1 Mbit/s.

Order number: X20IF2772 B&R ID code: 0x1F25 (decimal 7973)

Key Hardware Specifications

Connector Pinout (both IF1 and IF2)

Required accessory terminal blocks:

• 0TB2105.9010 — screw clamp, 2.5 mm²
• 0TB2105.9110 — push-in, 2.5 mm²

LED Status Indicators

Certifications

CE, UKCA, ATEX Zone 2 (II 3G Ex nA nC IIA T5 Gc), cULus, DNV, CCS, LR, KR, ABS, BV, KC.

Supported CANopen Features

• CANopen master operation (configurable in Automation Studio 3.0+)
• NMT master/slave functionality
• PDO (TPDO and RPDO) communication
• SDO (client and server) for configuration
• SYNC object generation/consumption
• EMCY (Emergency) object support
• Heartbeat producer/consumer
• EDS file-based device configuration
• DTM (Device Type Manager) configuration mode

Limitations: The module does NOT support CAN RTR messages with extended CAN identifiers (29-bit) due to memory/performance constraints of the SJA1000 controller. Standard 11-bit identifiers work fully.

Module Specifications Sources

• B&R X20IF2772 datasheet V2.30: https://docs.rs-online.com/5f80/A700000013921576.pdf
• B&R product page: https://www.br-automation.com/en-us/products/io-systems/x20-system/x20-interface-module-communication/x20if2772/
• Automation Distribution: https://automationdistribution.com/b-r-x20if2772-x20-interface-can-can/

2. CANopen on B&R: Protocol Stack Implementation

Architecture

B&R’s CANopen implementation on the X20 platform is integrated into the Automation Studio development environment and runs on the X20 controller (CPU). The CANopen protocol stack runs as a system-level service managed by the controller’s firmware, not on the IF2772 module itself. The IF2772 provides the physical CAN bus interface (SJA1000 CAN controller + transceiver), while the protocol processing occurs in the controller.

B&R CANopen Module Family

The IF2772 differs from the IF1041-1 in that it has two CAN interfaces and was originally designed as a generic CAN bus module. CANopen master capability was added via firmware/Automation Studio support starting with Automation Studio 3.0.

Configuration Methods

B&R supports two primary configuration approaches for CANopen:

1. DTM (Device Type Manager) Configuration

   • Import EDS (Electronic Data Sheet) files for each slave device
   • Drag-and-drop configuration in Automation Studio’s hardware tree
   • Graphical PDO mapping via the DTM interface
   • Recommended for most applications

2. Programmatic (ArCAN Library) Configuration

   • Use B&R’s AsCAN / AsArCAN library in Automation Studio
   • Configure PDOs, SDOs, and node parameters via structured data types in IEC code
   • Necessary when no EDS file is available or for custom/raw CAN communication
   • Provides full control over CAN identifiers and timing

B&R CANopen in Automation Studio

1. Add the X20IF2772 module to the hardware tree
2. Right-click the CAN interface and select “CANopen (DTM)”
3. Import slave device EDS files via Tools → Manage 3rd Party Devices or drag from Hardware Catalog
4. Configure PDO mappings, node IDs, and baud rates
5. The firmware is part of the Automation Studio project and is automatically loaded to the module

CANopen Protocol Sources

• B&R CANopen products: https://www.br-automation.com/en-us/products/network-and-fieldbus-modules/canopen/
• B&R Community — CANopen over X20IF2772: https://community.br-automation.com/t/canopen-communication-over-x20if2772/6000
• B&R Community — CANopen trace guide: https://community.br-automation.com/t/how-to-trace-description-guide-canopen/4929
• CiA CANopen knowledge: https://www.can-cia.org/can-knowledge/canopen

3. PDO/SDO Mapping on B&R CAN Modules

PDO (Process Data Object) Overview

PDOs are single CAN frames (up to 8 bytes in CAN 2.0B) used for time-critical, real-time process data exchange. They are broadcast without acknowledgment — no confirmation or retry.

Two types:

• TPDO (Transmit PDO): Device sends data to the bus (e.g., sensor reading, status)
• RPDO (Receive PDO): Device receives data from the bus (e.g., setpoint, command)

PDO Communication Parameter Objects

Each PDO communication record contains:

• Sub 0: Highest sub-index supported
• Sub 1: COB-ID (11-bit CAN identifier + validity bit 31)
• Sub 2: Transmission type (0–255)
• Sub 3: Inhibit time (minimum interval between transmissions, in 100 µs units)
• Sub 5: Event timer (periodic transmission in ms)

PDO Mapping Parameter Objects

Each mapping record contains up to 64-bit (8 bytes) of mapped objects:

• Sub 0: Number of mapped objects
• Sub 1..N: Mapped object = [31:24] sub-index, [23:16] byte length, [15:0] object index

PDO Mapping Procedure (Standard CiA 301)

1. Invalidate PDO: Set bit 31 of the COB-ID entry (sub-index 1) to 1
2. Clear mapping: Write 0x00 to sub-index 0 of the mapping object
3. Write new mapping: Write each object mapping to sub-indices 1, 2, 3…
4. Validate mapping: Set sub-index 0 to the number of mapped objects
5. Re-enable PDO: Clear bit 31 of the COB-ID entry

SDO (Service Data Object) Overview

SDOs are used for configuration and parameter access. They use a client-server model with confirmed communication (request/response). An SDO transfer requires multiple CAN frames:

• Client → Server (SDO Download): Initiator writes to a remote OD entry
• Server → Client (SDO Upload): Initiator reads from a remote OD entry

SDO CAN IDs default to:

• Rx SDO (Client to Server): 0x600 + Node-ID
• Tx SDO (Server to Client): 0x580 + Node-ID

B&R-Specific PDO Behavior

Important: B&R controllers may not use the PDO channel mappings defined in the EDS file for all objects. B&R’s default PDO mapping in Automation Studio can differ from what the EDS file specifies. When configuring PDOs on a B&R CANopen master:

1. Always verify the actual PDO mapping in Automation Studio after importing the EDS
2. Check which objects are actually mapped in the generated configuration
3. Use the DTM interface to visually confirm mapping before deployment
4. If the EDS defines objects that aren’t mapped, use the ArCAN library to add custom mappings programmatically

PDO Transmission Types

PDO/SDO Mapping Sources

• CiA PDO protocol: https://www.can-cia.org/can-knowledge/pdo-protocol-1
• CiA CANopen tutorial: https://www.csselectronics.com/pages/canopen-tutorial-simple-intro
• B&R PDO mapping (non-EDS): https://industrialmonitordirect.com/blogs/knowledgebase/br-canopen-pdo-mapping-not-using-eds-file-definitions
• B&R Community — CANopen help: https://community.br-automation.com/t/help-with-canopen-communication-using-x20if1041-1/5158

4. CAN Identifier Assignment

CANopen Default COB-ID Scheme

CANopen uses 11-bit CAN identifiers (COB-IDs) assigned according to a function-code-based scheme:

COB-ID = (Function Code × 0x80) + Node-ID

where Node-ID ranges from 1 to 127.

Default CANopen COB-ID Table

B&R IF2772 Node Addressing

The IF2772 uses two hex rotary switches to set the node number. Both CAN interfaces share the same node number (switches are per-module, not per-interface).

• Valid node IDs: 1–127
• Node ID 0 is reserved for NMT commands (cannot be assigned to a physical node)

Customizing CAN Identifiers

CANopen allows COB-ID customization through the object dictionary:

1. NMT state must be Pre-operational or Operational (for some devices)
2. Write new COB-ID to the PDO communication parameter (index 1400h–19FFh, sub-index 1)
3. Bit 31 of the COB-ID: 0 = PDO valid, 1 = PDO invalid
4. Bit 30: 0 = PDO is mapped to the CANopen default COB-ID range, 1 = PDO uses the full 11-bit range (0x000–0x7FF)

When using the B&R ArCAN library, COB-IDs can be assigned directly in structured data types without relying on the default formula.

CAN Identifier Sources

• CiA identifier usage: https://www.microcontrol.net/wp-content/uploads/2021/10/td-03011e.pdf
• Renesas CANopen manual: https://www.renesas.com/en/document/mas/canopen-library-user-manual
• CSS Electronics CANopen intro: https://www.csselectronics.com/pages/canopen-tutorial-simple-intro

5. Bit Timing Configuration

Timing Overview

The SJA1000 CAN controller on the IF2772 uses bit timing registers (BTR0 and BTR1) to configure baud rate, sampling point, and synchronization jump width. In B&R’s Automation Studio, these are abstracted — you select a baud rate and the firmware calculates the register values.

Standard CANopen Baud Rates (CiA 301)

Bit Timing Parameters

A CAN bit is divided into Time Quanta (Tq) segments:

| SYNC_SEG | TIME_SEG1 | TIME_SEG2 |
|   1 Tq   |  1..16 Tq |  1..8 Tq  |

• SYNC_SEG: Always 1 Tq — synchronizes nodes on the bus
• TIME_SEG1: Propagation segment + Phase Buffer Segment 1
• TIME_SEG2: Phase Buffer Segment 2
• SJW (Synchronization Jump Width): 1..4 Tq — how much a node can resynchronize per bit

Sampling Point

The sampling point is where the CAN controller samples the bus level to determine bit value:

Sampling Point (%) = (1 + TIME_SEG1) / (1 + TIME_SEG1 + TIME_SEG2) × 100

Recommended sampling points (CiA 301 / CiA 105):

A sampling point of 87.5% is the CANopen standard recommendation. At higher baud rates, slightly lower values (75–80%) provide more tolerance for clock drift.

SJA1000 Register Details

The SJA1000 uses a 16 MHz crystal (typical on B&R modules).

BTR0 (Bus Timing Register 0):

| SJW1 SJW0 | BRP5 BRP4 BRP3 BRP2 BRP1 BRP0 |

• SJW: Synchronization Jump Width (0–3, actual value + 1)
• BRP: Baud Rate Prescaler (0–63, actual value + 1)

BTR1 (Bus Timing Register 1):

| SAM | TSEG2.2 TSEG2.1 TSEG2.0 | TSEG1.3 TSEG1.2 TSEG1.1 TSEG1.0 |

• SAM: Sampling mode (1 = triple sampling, 0 = single)
• TSEG1: Time Segment 1 (0–15, actual value + 1)
• TSEG2: Time Segment 2 (0–7, actual value + 1)

Example: 500 kbit/s with SJA1000 @ 16 MHz

Prescaler = 1 (BRP = 0)
Tq = 2 × (BRP + 1) / 16 MHz = 125 ns
Bit time = 500 kbit/s → 2 µs → 16 Tq

SYNC_SEG  = 1 Tq
TSEG1     = 12 Tq (register value 11)
TSEG2     = 3 Tq  (register value 2)
SJW       = 1 Tq  (register value 0)
Sampling  = (1 + 12) / 16 = 81.25%

Configuring in B&R Automation Studio

1. Open the hardware configuration for the IF2772
2. Select the CAN interface (IF1 or IF2)
3. Set the baud rate from the dropdown (125k, 250k, 500k, 1M, etc.)
4. Automation Studio calculates the SJA1000 BTR0/BTR1 register values automatically
5. For non-standard baud rates, use the ArCAN library to write BTR values directly

Bit Timing Sources

• SJA1000 datasheet (NXP): Standard CAN controller reference
• CiA 301 specification: Bit timing requirements
• B&R X20IF2772 datasheet: https://docs.rs-online.com/5f80/A700000013921576.pdf

6. Hardware CAN Bus Sniffing

Sniffing Overview

To capture CAN bus traffic without interfering with the running B&R system, you need a CAN-to-USB/PCI adapter connected in listen-only mode as a passive node on the bus. This is essential for debugging communication between the IF2772 and field devices.

Connection Methods

1. Y-Cable / T-Junction Tap

                    ┌──────────────┐
B&R IF2772 ────────┤  T-junction  ├──────── Field Device
                    │   (tap)      │
                    └──────────────┘
                          │
                    CAN Adapter (sniffer)

Connect the CAN adapter’s CAN_H and CAN_L to a tap point on the bus. Do NOT add a third terminating resistor — the adapter should be in high-impedance mode.

2. In-Line Pass-Through Adapter

Some CAN adapters (e.g., Kvaser Leaf, PEAK PCAN) support in-line pass-through where the adapter sits between two bus segments. Ensure proper termination.

PEAK PCAN Hardware

Software:

• PCAN-View (free): Basic monitor, transmit, record
• PCAN-Explorer 6 (paid): Advanced analysis, DBC import, graphical display, scripting

Vector CANalyzer / CANoe

Features:

• Real-time trace window
• DBC/LDF/A2L database import for symbolic decoding
• Graphics, data, and statistics windows
• IG (Interactive Generator) for injecting frames
• CAPL scripting for automated tests
• Network management and gateway simulation

Kvaser Hardware

Software: Kvaser CANlib SDK (C/C++ API), Kvaser TRCAN, Kvaser Viewer

Ixxat (HMS Networks)

Important: Listen-Only Mode

When sniffing a live CANopen network with the B&R master, always configure the CAN adapter in listen-only mode:

• PEAK PCAN: Set PCAN_listen_only flag in PCAN-View or API
• Vector: Enable “Listen Only” in CANalyzer channel configuration
• SocketCAN: Set ip link set can0 type can bitrate 500000 listen-only on
• Kvaser: Set canOPEN_LISTEN_ONLY in canOpen() call

Listen-only mode ensures the adapter never sends ACK bits, error frames, or any data on the bus, preventing interference with the production system.

Hardware Sniffing Sources

• PEAK PCAN: https://www.peak-system.com/products/software/analysis-software/pcan-view/
• Vector CANalyzer vs PCAN: https://controltechuk.com/blog/vector-canalyzer-alternative/
• CAN tool comparison: https://rpubs.com/daniel_pas/can_tool_comparison
• Affordable CAN tools: https://spin.atomicobject.com/affordable-can-bus-tools/

7. SocketCAN on Linux

SocketCAN Overview

SocketCAN is the Linux kernel’s native CAN protocol stack, exposing CAN devices as network interfaces (like eth0). This makes CAN accessible through standard socket APIs and network tools.

Setup

# Load the CAN controller driver (varies by hardware)
sudo modprobe peak_pci        # PEAK PCAN PCI cards
sudo modprobe vcan            # Virtual CAN for testing
sudo modprobe mcp251xfd       # Microchip MCP251xFD SPI-based

# Configure a CAN interface
sudo ip link set can0 type can bitrate 500000
sudo ip link set up can0

# Verify
ip -details link show can0

Core Utilities (can-utils)

Install: sudo apt install can-utils

candump — Capture CAN Traffic

# Capture all frames
candump can0

# Capture with timestamps
candump -t a can0

# Capture and log to file
candump -l can0

# Filter by CAN ID (only ID 0x181)
candump can0,181#FFFFFFFF

# Filter by ID range
candump can0,180:7FF#00000000

# Filter by data bytes (first byte = 0x01)
candump can0,~0#01000000

# Multiple interfaces
candump can0,can1

cansend — Transmit CAN Frames

# Standard data frame (ID=0x123, data=01 02 03 04)
cansend can0 123#01020304

# Remote frame
cansend can0 123#R

# Extended 29-bit ID
cansend can0 12345678#01020304

cangen — Generate CAN Traffic

# Generate random frames
cangen can0

# Generate at 100 ms interval with ID range 0x100-0x1FF
cangen can0 -g 100 -I 100 -L 1FF

# Generate specific length frames
cangen can0 -l 8 -D r

cansniffer — Real-Time CAN Sniffer

# Interactive sniffer showing changing bytes
cansniffer can0

# Shows which bytes change between frames
# Useful for identifying sensor data in unknown protocols

canplayer — Replay CAN Traffic

# Record
candump -l -n 1000 can0

# Replay
canplayer -I candump-2026-07-10_143022.log can0

slcanattach — Serial/Lawicel CAN Gateway

# For serial-based CAN adapters (e.g., LAWICEL, ELM327)
slcanattach -w -s 500000 -c /dev/ttyUSB0

bcmsocket — Broadcast Manager

# Receive a specific CAN ID with timeout
cansend can0 123#01020304 &

# Set up cyclic transmission
cangen can0 -e -g 100 &

CAN-FD Support

# Configure CAN-FD interface
sudo ip link set can0 type can bitrate 500000 dbitrate 2000000 fd on
sudo ip link set up can0

# Capture CAN-FD frames
candump can0

# Send CAN-FD frame (8 bytes data, bit-rate switch)
cansend can0 123##01122334455667788

Python Integration (python-can)

import can

# Initialize SocketCAN interface
bus = can.Bus(channel='can0', interface='socketcan', bitrate=500000)

# Receive messages
for msg in bus:
    print(f"ID: {msg.arbitration_id:03X}  Data: {msg.data.hex()}  DLC: {msg.dlc}")

# Send messages
msg = can.Message(arbitration_id=0x181, data=[1, 2, 3, 4], is_extended_id=False)
bus.send(msg)

SocketCAN Sources

• SocketCAN kernel documentation: https://docs.kernel.org/networking/can.html
• Linux can-utils: https://github.com/linux-can/can-utils
• can-utils tutorial: https://dbcutility.com/blog/can-utils-candump-guide/
• SocketCAN practical guide: http://sgframework.readthedocs.io/en/latest/cantutorial.html

8. Decoding Sensor Data from CAN Messages

The Challenge

When troubleshooting field-level sensor problems via CAN bus traffic, you need to interpret raw CAN data bytes. CANopen PDOs carry sensor values as mapped objects from the device’s object dictionary. Without the correct DBC/EDS file, decoding requires understanding the mapping.

Step-by-Step Decoding

Step 1: Identify the PDO COB-ID

Given a node with ID = 5:

• TPDO1 = 0x180 + 5 = 0x185
• TPDO2 = 0x280 + 5 = 0x285
• TPDO3 = 0x380 + 5 = 0x385

Step 2: Consult the Device’s Object Dictionary

The EDS file (or device manual) tells you which objects are mapped to each TPDO.

Example: A temperature sensor (Node 5) maps:

• TPDO1 (0x185): Object 6004h:01 (Temperature value, INT16, in 0.1°C units)

Step 3: Extract the Data Bytes

Captured frame: ID=0x185  Data=0x01 0xF4 0x00 0x00 0x00 0x00 0x00 0x00

First 2 bytes = 0xF401 (little-endian INT16) Decimal = -179

If the unit is 0.1°C: Temperature = -17.9°C

Common Data Types in CANopen

Endianness

CANopen uses little-endian byte order by default (LSB first). For a 16-bit value spanning bytes 0–1 of a CAN frame:

• Byte 0 = low byte (bits 0–7)
• Byte 1 = high byte (bits 8–15)

Practical Diagnostic Example

Suppose you have a pressure sensor on CANopen node 12 and it reports erratic values:

# Capture only this sensor's TPDO1
candump can0,18C#FFFFFFFF

Output:

(1609456789.123456) can0 18C#0300800000000000
(1609456789.623456) can0 18C#0420810000000000
(1609456790.123456) can0 18C#FF3F820000000000

Decoding (assume mapping: sub-index 0 = pressure UNS32, sub-index 1 = status UNS8):

• Frame 1: Pressure = 0x00008003 (32771 units, e.g., 3.277 bar), Status = 0x00 (OK)
• Frame 2: Pressure = 0x00008120 (33056 units, 3.306 bar), Status = 0x04 (Warning)
• Frame 3: Pressure = 0x000082FF (33535 units, 3.354 bar), Status = 0xFF (Error)

This reveals the sensor is drifting and entered error state.

Using DBC Files with candump

# Convert DBC to SocketCAN attribute format
# (Using python-can or cantools)

# With cantools + python-can:
python3 -c "
import cantools, can
db = cantools.database.load_file('sensor.dbc')
for msg in db.messages:
    print(f'{msg.name}: ID=0x{msg.frame_id:03X}')
"

Reverse-Engineering Unknown Sensors

When no documentation exists:

1. Use cansniffer to observe which bytes change with sensor activity
2. Correlate changes with physical events (apply pressure, change temperature, etc.)
3. Identify data types by observing value ranges and step sizes
4. Document findings in a DBC or mapping table

Sensor Data Decoding Sources

• CSS Electronics — CAN bus data reading: https://www.autopi.io/blog/how-to-read-can-bus-data/
• Tektronix CAN troubleshooting: https://www.tek.com/en/solutions/industry/automotive-test-solutions/in-vehicle-networks/can-bus-troubleshooting-oscilloscope-can-bus-decoder
• PicoScope CAN decoding: https://www.picotech.com/library/knowledge-bases/oscilloscopes/can-bus-serial-protocol-decoding

9. CANopen Error Handling

CAN Error States

Each CAN node maintains two error counters:

• TEC (Transmit Error Counter): Increments on transmit errors, decrements on successful transmits
• REC (Receive Error Counter): Increments on receive errors, decrements on successful receives

Based on these counters, a node transitions between three states:

Error Active (TEC and REC < 128)

• Normal operating state. The node can send and receive normally.
• When an error is detected, the node sends an Active Error Flag (6 dominant bits).
• The active error frame forces all other nodes to acknowledge the error.
• Both counters decrement by 1 on each successful message (TEC) or successful reception (REC).

Error Passive (TEC > 127 OR REC > 127)

• The node can still communicate but with restrictions.
• When an error is detected, the node sends a Passive Error Flag (6 recessive bits).
• The passive error flag does NOT dominate the bus — other nodes may not notice it.
• After sending a passive error flag, the node waits 8 bit times (Suspend Transmission) before trying to transmit again.
• This gives other nodes priority in bus arbitration.

Bus-Off (TEC > 255)

• The node completely disconnects from the bus.
• No transmission or reception is possible.
• The CAN controller internally sets the bus-off status bit.
• Recovery: The node must monitor 128 consecutive occurrences of 11 consecutive recessive bits on the bus (128 × 11 recessive bits = 11 bit times of dominant-free bus).
• In B&R systems, bus-off recovery can be configured:
  • Automatic recovery after a timeout (via Automation Studio settings)
  • Manual recovery via NMT Reset command or module restart
  • Physical reset (power cycle the IF2772)

CAN Error Types

Error Frame Structure

An error frame consists of:

1. Error Flag: 6 dominant bits (active) or 6 recessive bits (passive)
2. Error Delimiter: 8 recessive bits (marks end of error frame)

After an error frame, bus arbitration restarts from the beginning.

CANopen Emergency Protocol (EMCY)

CANopen adds an application-level error reporting mechanism via the Emergency object:

• COB-ID: 0x080 + Node-ID
• Triggered when: A device detects an internal error (overcurrent, temperature, communication loss)
• Payload: 8 bytes:

Common CiA Emergency Error Codes

Heartbeat / Node Guarding Errors

CANopen uses two mechanisms to detect node failures:

Heartbeat (recommended in modern CANopen):

• Producer sends heartbeat at a configurable interval (OD index 1017h)
• Consumer monitors for heartbeat timeouts
• Consumer sets HeartbeatTimeoutEvent in status register on timeout
• Timeout threshold configured in OD index 1016h (consumer)

Node Guarding (legacy):

• Master polls each slave with a Remote Transmission Request (RTR) on the node’s guard COB-ID
• Slave responds with its toggle bit and status
• If toggle bit doesn’t change between polls or response is missing → error

CANopen Error Handling Sources

• HMS Networks error states: https://www.hms-networks.com/support/tech-support/kb-articles/10436555566354-CANOpen-Error-States–Error-Active–Error-Passive–and-Bus-Off
• CSS Electronics CAN errors: https://www.csselectronics.com/pages/can-bus-errors-intro-tutorial
• Kvaser error handling: https://kvaser.com/lesson/can-error-handling/
• STMicroelectronics bus-off recovery: https://www.st.com/resource/en/technical-note/tn1367-spc5x-can-errors-management-and-bus-off-recovery-stmicroelectronics.pdf

10. IF2772 Configuration Parameters (Object Dictionary)

Object Dictionary Structure

The CANopen Object Dictionary (OD) is accessed via 16-bit indices with 8-bit sub-indices. The IF2772, when configured as a CANopen master, exposes configuration parameters through the standard OD ranges.

Communication Profile Area (1000h – 1FFFh)

Error Register (1001h) Bit Definitions

Store Parameters (1010h)

Identity Object (1018h)

Device Type (1000h) Format (32-bit)

Bit 31-26: Profile number (0 = CiA301, 402h = DSP, etc.)
Bit 25-16: Additional profile information
Bit 15-8: Device type (flags)
Bit 7-0: Flags (e.g., bit 0 = simple device, bit 1 = complex device)

Object Dictionary Sources

• CiA 301 specification: CANopen application layer and communication profile
• B&R IF2772 datasheet: https://docs.rs-online.com/5f80/A700000013921576.pdf
• Siemens CANopen tutorial: https://cache.industry.siemens.com/dl/files/771/109479771/att_993267/v1/109479771_CANopen_Tutorial_V20_en.pdf

11. Setting Up CANopen on B&R Without the Original Project

Scenario

You have a B&R X20 system with an IF2772 module running an unknown CANopen configuration. The original Automation Studio project is lost or unavailable, and you need to reconfigure CANopen.

Prerequisites

• Automation Studio (version 3.0 or later for IF2772 CANopen master)
• Physical access to the X20 controller and IF2772 module
• EDS files for all CANopen slave devices on the bus
• Knowledge of the target baud rate and node IDs

Step-by-Step Procedure

Step 1: Connect to the Controller

1. Connect your PC to the X20 controller via Ethernet
2. In Automation Studio: Online → Connection Settings
3. Enter the controller’s IP address
4. Select “Online without project” if prompted
5. Click Connect (F5)
6. You can now browse the controller’s running configuration and firmware version

Step 2: Identify Connected CANopen Devices

1. Physically inspect the CAN bus — note any slave devices and their node ID switches
2. If you have a CAN sniffer (PCAN, Vector, SocketCAN), capture traffic to identify active nodes
3. Look for EMCY (0x080+NodeID) and Heartbeat (0x700+NodeID) frames to enumerate nodes

# Using SocketCAN to identify nodes
candump can0 | grep -E "^.*can0 [78][0-9A-F]{2}"

Step 3: Create a New Automation Studio Project

1. File → New Project
2. Select the correct controller model (e.g., X20CP1585)
3. Add the IF2772 to the hardware tree in the correct slot
4. Configure the firmware version to match the controller’s current firmware

Step 4: Configure the CAN Interface

1. In the hardware tree, expand the IF2772
2. Select IF1 (or IF2) → right-click → “CANopen (DTM)”
3. Set the baud rate to match the existing bus (commonly 125k, 250k, or 500k)
4. Set the node number (match the DIP switch setting on the module)

Step 5: Import EDS Files and Add Slaves

1. Tools → Manage 3rd Party Devices (or drag from Hardware Catalog)
2. Import the EDS file for each slave device
3. Set each slave’s node ID to match its physical switch setting
4. Configure PDO mappings according to the device documentation

Step 6: Configure PDOs

1. In the DTM configuration, open the PDO mapping view
2. Verify which TPDOs from the slaves you want to receive (as RPDOs on the master)
3. Configure which RPDOs the master sends to the slaves (as TPDOs on the slave side)
4. Map the PDO data to variables in your IEC program

Step 7: Configure NMT and Heartbeat

1. Set the heartbeat producer time on the master (index 1017h)
2. Configure consumer heartbeat times for each slave (index 1016h)
3. Set the NMT startup sequence (boot-up → Pre-operational → Operational)

Step 8: Deploy and Verify

1. Download the configuration to the controller
2. Monitor CAN traffic for proper communication
3. Verify PDO data exchange using Automation Studio’s online view
4. Check the IF2772 LEDs: STATUS green, TxD yellow (flashing during transmit)

Using the ArCAN Library for Raw CAN

If you need to work with non-CANopen CAN protocols or custom identifiers:

PROGRAM _CAN_Init
    // Configure CAN interface
    AsArCAN_Init(
        pInterface := ADR(ifCAN1),
        nBaudrate := 500000,
        pTxBuffer := ADR(aTxBuffer),
        nTxBufSize := 16,
        pRxBuffer := ADR(aRxBuffer),
        nRxBufSize := 16
    );
END_PROGRAM

CANopen Setup Sources

• B&R Community — CANopen over X20IF2772: https://community.br-automation.com/t/canopen-communication-over-x20if2772/6000
• B&R Community — Vehicle CAN setup: https://community.br-automation.com/t/how-to-setup-communication-on-a-vehicle-can/2778
• B&R Automation Studio connect: https://industrialmonitordirect.com/blogs/knowledgebase/br-automation-studio-connect-to-controller-and-view-program
• B&R Community — CANopen trace guide: https://community.br-automation.com/t/how-to-trace-description-guide-canopen/4929

12. Common CAN Bus Problems and Diagnostic Procedures

Problem 1: No Communication (No TxD LED Activity)

Possible Causes:

• Wrong baud rate (mismatch between master and slaves)
• CAN bus wiring open (broken cable)
• Missing or incorrect terminating resistors
• Module not properly initialized

Diagnostics:

1. Verify baud rate matches on all devices
2. Measure resistance between CAN_H and CAN_L at the module connector (should read ~60 Ω with two 120 Ω terminators)
3. Check the STATUS LED — should be green
4. Use oscilloscope to verify CAN_H/CAN_L differential signals

Problem 2: Intermittent Communication Errors

Possible Causes:

• EM interference (cable routing near power cables)
• Poor shield grounding
• Loose connections
• Near baud rate limit for cable length
• Too many nodes causing bus load > 70%

Diagnostics:

1. Monitor error frames with CAN sniffer
2. Check bus load (should be < 70% at peak)
3. Verify cable length is within limits for the baud rate
4. Inspect shield connections — SHLD should be grounded at one or both ends
5. Check REC/TEC counters on nodes (via SDO read of OD index 1001h or vendor-specific)

Problem 3: Nodes Going Bus-Off

Possible Causes:

• Wiring fault (short, open, corrosion)
• Faulty transceiver on one node
• External interference
• Ground loops
• Incorrect termination

Diagnostics:

1. Disconnect nodes one at a time to isolate the faulty device
2. Measure CAN_H and CAN_L voltages at idle:
   • CAN_H ≈ 2.5–3.5 V (recessive ≈ 2.5 V, dominant ≈ 3.5 V)
   • CAN_L ≈ 1.5–2.5 V (recessive ≈ 2.5 V, dominant ≈ 1.5 V)
3. Check for shorts between CAN_H and CAN_L (should be ~60 Ω, not 0 Ω)
4. Check for shorts between CAN lines and ground

Problem 4: High Bus Load / Too Many Messages

Possible Causes:

• Too many PDOs transmitting at high rates
• Event-driven PDOs firing too frequently
• SYNC rate too high

Diagnostics:

1. Use CANalyzer/PCAN-Explorer to measure bus load percentage
2. Reduce PDO transmission rates (increase inhibit time, change transmission type from synchronous to event-driven)
3. Reduce SYNC period if synchronous PDOs are used
4. Consolidate multiple objects into fewer PDOs (use full 8-byte payload)

Problem 5: Heartbeat Timeout Errors

Possible Causes:

• Slave node crashed or powered off
• CAN cable disconnected
• Slave in Error-Active/Passive state, not transmitting
• Wrong heartbeat consumer timeout configured

Diagnostics:

1. Verify the slave is powered and its STATUS LED is active
2. Check for EMCY messages from the slave before heartbeat loss
3. Verify heartbeat producer interval on the slave matches expected rate
4. Increase consumer heartbeat timeout if transient delays are expected

Problem 6: PDO Data Not Updating

Possible Causes:

• Wrong COB-ID mapping
• PDO marked invalid (bit 31 of COB-ID set)
• Wrong node ID
• NMT state not Operational

Diagnostics:

1. Verify NMT state is Operational (not Pre-operational or Stopped)
2. Read PDO communication parameters via SDO to verify COB-ID
3. Verify PDO mapping is valid
4. Check if the PDO is being transmitted on the bus (use sniffer)

Diagnostic Flowchart

Start
  │
  ├─ No communication at all?
  │   ├─ Check STATUS LED (green = active)
  │   ├─ Measure bus termination (60 Ω expected)
  │   ├─ Check CAN_H/CAN_L voltages
  │   └─ Verify baud rate
  │
  ├─ Communication but errors?
  │   ├─ Monitor error frames (sniffer)
  │   ├─ Check wiring/shielding
  │   ├─ Check bus load (< 70%)
  │   └─ Measure REC/TEC counters
  │
  ├─ Node going bus-off?
  │   ├─ Isolate by removing nodes one by one
  │   ├─ Check for ground loops
  │   └─ Verify transceiver health
  │
  └─ Data incorrect/missing?
      ├─ Verify PDO mapping (EDS vs. actual)
      ├─ Check NMT state (Operational?)
      ├─ Verify node IDs match physical switches
      └─ Check byte order / data scaling

Diagnostic Procedures Sources

• CSS Electronics CAN bus errors: https://www.csselectronics.com/pages/can-bus-errors-intro-tutorial
• Total Phase CAN debugging: https://www.totalphase.com/blog/2025/09/debugging-can-automotive-industrial-medical-robotics-aerospace-systems/
• Kvaser error handling: https://kvaser.com/lesson/can-error-handling/

13. Wiring and Termination Requirements

CAN Bus Physical Layer (ISO 11898-2)

The CAN bus uses a differential pair (CAN_H and CAN_L) with common-mode rejection to provide noise immunity.

Cable Requirements

Bus Topology

CAN is a linear bus topology (not star or ring). Devices are connected via drop lines (stubs) from the main bus trunk.

┌───────────── 120 Ω ─────────────────────┐
│                                          │
├──[Node 1]──┬──[Node 2]──┬──[Node 3]──┤ 120 Ω
              │             │               │
              Stub         Stub            Stub
              (<0.3m)       (<0.3m)        (<0.3m)

Termination

The bus must be terminated with 120 Ω resistors at both ends of the trunk:

• Without termination: Signal reflections cause data corruption
• With termination: The 120 Ω resistors match the cable’s characteristic impedance, preventing reflections
• Total bus resistance (measured at any point): Should be approximately 60 Ω (two 120 Ω resistors in parallel)

IF2772 Termination

The IF2772 has integrated terminating resistors (one per CAN interface), selectable via hardware switches on the bottom of the module:

• TERM CAN 1: Switch for IF1 terminating resistor (ON/OFF)
• TERM CAN 2: Switch for IF2 terminating resistor (ON/OFF)

LED indicator: The TERM CAN 1/TERM CAN 2 LED lights yellow when the resistor is active.

Proper configuration:

• IF2772 is at one end of the bus → turn terminating resistor ON
• IF2772 is in the middle of the bus → turn terminating resistor OFF
• IF2772 is at both ends (if bus is short and only connects to one IF2772 interface) → turn resistor ON on the far-end device, OFF on IF2772

Wiring Diagram (IF2772 TB2105 Terminal Block)

TB2105          TB2105 (next device)
──────          ──────────────────
Pin 1: CAN_GND ─────── Pin 1: CAN_GND
Pin 2: CAN_L   ─────── Pin 2: CAN_L
Pin 3: SHLD    ─────── Pin 3: SHLD
Pin 4: CAN_H   ─────── Pin 4: CAN_H
Pin 5: NC      ─────── Pin 5: NC

Shield grounding options:

• One-side grounded: Connect SHLD to ground at one end only (prevents ground loops)
• Both-side grounded (with care): If ground potential difference is < 2 V, can ground at both ends
• Never leave SHLD floating in noisy industrial environments

Voltage Levels

Common Wiring Mistakes

1. Swapped CAN_H and CAN_L — causes total communication failure; the bus appears to work intermittently due to dominant/recessive inversion
2. Missing termination — reflections cause errors at high baud rates; may work at low baud rates
3. Double termination in the middle — reduces signal swing, causes margin issues
4. No ground reference — common-mode voltage drifts outside transceiver range
5. Star topology — causes reflections and timing violations
6. Long stubs — creates impedance discontinuities

Wiring Sources

• B&R IF2772 datasheet: https://docs.rs-online.com/5f80/A700000013921576.pdf
• CiA 301 specification (physical layer recommendations)
• ISO 11898-2: Road vehicles — Controller area network — High-speed medium access unit

14. CAN Analysis Tools Comparison

Hardware + Software Comparison Matrix

Detailed Comparison

Vector CANalyzer — Industry Standard

Strengths:

• Gold standard for CANopen analysis
• Excellent CANopen NMT, PDO, SDO, EMCY trace with symbolic names
• CAPL scripting for automated tests and simulations
• DBC/LDF/ARXML database support
• Powerful graphics and data analysis windows
• IG (Interactive Generator) for manual frame injection
• Network statistics (bus load, error counters)

Weaknesses:

• Expensive
• Windows only
• Steep learning curve for CAPL
• Requires Vector hardware (or compatible)

Best for: Professional automotive/industrial development labs with budget

PEAK PCAN-Explorer 6 — Cost-Effective Alternative

Strengths:

• Significantly cheaper than Vector
• Good CANopen support with symbolic trace
• DBC import for symbolic decoding
• VBScript/JScript scripting
• Supports CAN FD
• Includes PCAN-View (free basic monitor)

Weaknesses:

• Less powerful scripting than CAPL
• Fewer analysis windows than CANalyzer
• CANopen features not as deep as Vector

Best for: Mid-range industrial applications, cost-conscious teams

SocketCAN + can-utils — Free and Open Source

Strengths:

• Free, included in Linux kernel
• Works with many cheap CAN adapters
• Excellent for scripting and automation
• python-can library for high-level CANopen
• cansniffer for reverse engineering

Weaknesses:

• No built-in CANopen protocol decode (need python-can or manual)
• No graphical DBC viewer (use SavvyCAN, CanLover, or cantools)
• Linux-only
• No official CAN FD database support in core tools

Best for: Linux-based systems, CI/CD pipelines, budget setups, scripting automation

SavvyCAN — Open Source GUI

Strengths:

• Free and open source
• Cross-platform (Windows, Linux, Mac)
• DBC import and symbolic decoding
• CANopen NMT state machine display
• Supports many CAN adapters (SocketCAN, PCAN, Kvaser, Lawicel, etc.)
• Frame injection and playback
• Active development

Best for: Budget-friendly GUI-based analysis with CANopen features

Budget Recommendations by Use Case

CAN Analysis Tools Sources

• Vector CANalyzer: https://www.vector.com/int/en/products/products-a-z/software/canalyzer/
• PEAK PCAN-View: https://www.peak-system.com/products/software/analysis-software/pcan-view/
• PCAN-Explorer 6 guide: https://controltechuk.com/blog/vector-canalyzer-alternative/
• Kvaser vs PEAK discussion: https://www.eevblog.com/forum/chat/kvaser-or-peak-can-bus-adapters-for-can-open/
• CAN tool comparison (RPubs): https://rpubs.com/daniel_pas/can_tool_comparison
• CanLover: https://canlover.ddns.net/
• SavvyCAN: https://github.com/savvycan/SavvyCAN
• Linux can-utils: https://github.com/linux-can/can-utils

Cross-References

• x2x-protocol.md — X2X bus; how IF2772 data reaches the CPU
• powerlink-internals.md — ETHERNET Powerlink; the primary real-time fieldbus on CP1584
• network-architecture.md — Overall network topology and device discovery
• physical-layer-sniffing.md — Probing CAN bus signals with oscilloscopes and logic analyzers
• cp1584-hardware-ref.md — CP1584 interface module slot and compatible modules
• io-card-hardware.md — IO module signal conditioning and hardware internals
• python-diagnostics.md — Python scripts for CAN message analysis (see canopen-message-interpreter below)

Community Tools for CANopen Diagnostics

Appendix: Quick Reference

Common CANopen CAN IDs (Node ID = 1 example)

IF2772 Quick Specs Summary

• 2x CAN interfaces (SJA1000 controller each)
• Max 1 Mbit/s per interface
• Integrated 120 Ω termination (switchable)
• 5-pin TB2105 terminal blocks (order separately)
• Node address: 2 hex DIP switches
• Power: 1.2 W
• CANopen master via Automation Studio 3.0+
• No 29-bit RTR support
• ATEX Zone 2 certified

Key SocketCAN Commands

# Setup
sudo ip link set can0 type can bitrate 500000 && sudo ip link set up can0

# Capture
candump can0                           # All frames
candump can0 -t a -l                   # Timestamped, log to file
candump can0,181#FFFFFFFF              # Filter single ID

# Send
cansend can0 181#0102030405060708      # 8-byte data frame

# Monitor changes
cansniffer can0                        # Interactive byte-change view

# Replay
canplayer -I logfile can0

# Status
ip -details -statistics link show can0

Key Findings

1. The X20IF2772 uses a SJA1000 standalone CAN controller (NXP/Philips) per interface – not a modern integrated MCU CAN peripheral. This limits the module to standard 11-bit CAN identifiers only; 29-bit extended IDs with RTR are not supported due to SJA1000 memory/performance constraints. Maximum baud rate is 1 Mbit/s per interface.

2. CANopen master configuration on the IF2772 is available in Automation Studio 3.0+. Two configuration approaches exist: DTM (Device Type Manager) for graphical drag-and-drop setup with EDS file import, and programmatic (ArCAN library) for code-based PDO/SDO configuration when no EDS file is available or for custom raw CAN communication.

3. B&R’s default PDO mapping in Automation Studio may differ from what the EDS file specifies. Always verify actual PDO mapping after EDS import using the DTM interface. PDO communication parameters live at object indices 0x1400+ (RPDO) and 0x1800+ (TPDO), with mapping at 0x1600+ and 0x1A00+. The PDO invalidation/remapping procedure requires setting bit 31 of the COB-ID, clearing the mapping, writing new entries, then clearing bit 31.

4. CANopen COB-ID assignment follows COB-ID = (FunctionCode * 0x80) + NodeID: TPDO1 = 0x180+NodeID, RPDO1 = 0x200+NodeID, SDO Rx = 0x600+NodeID, SDO Tx = 0x580+NodeID, Heartbeat = 0x700+NodeID. The IF2772 uses two hex rotary DIP switches for node addressing (1-127), shared across both interfaces.

5. SocketCAN on Linux provides full sniffing and injection capability: sudo ip link set can0 type can bitrate 500000 && sudo ip link set up can0 to configure, candump can0 to capture, cansend can0 181#0102030405060708 to transmit, cansniffer can0 for interactive byte-change monitoring. The python-can library (can.Bus(interface='socketcan')) provides programmatic access.

6. Built-in 120 ohm termination resistors are individually switchable per interface (TERM CAN 1 / TERM CAN 2 LEDs indicate active state). Both interfaces are electrically isolated from each other and from the PLC. Required terminal blocks (TB2105, screw clamp or push-in 2.5 mm2) are ordered separately.

7. For sensor data decoding from CANopen PDOs: calculate the node’s TPDO1 CAN ID (0x180 + NodeID), consult the EDS object dictionary mapping, extract data bytes in little-endian order (byte 0 = LSB), and apply the device’s scaling (e.g., INT16 in 0.1C units). CANopen data types: UNSIGNED8/16/32, INTEGER8/16/32, REAL32 (IEEE 754).

8. Common diagnostic procedures: candump can0,080:7FF captures all emergency messages; candump can0,181#FFFFFFFF filters a single node’s TPDO1; ip -details -statistics link show can0 shows bus error counters. A correctly terminated two-node bus reads approximately 60 ohm between CAN-H and CAN-L with power off. Single-node CAN-H to ground should be 2.5-3.0 V, CAN-L to ground 2.0-2.5 V when powered.

Document generated from research of B&R Automation documentation, CiA (CAN in Automation) specifications, B&R Community forums, and CANopen reference materials. Last updated: July 2026