Fixing CANopen Inclination Sensor Faults on B&R X90 CPUs

Problem Details

A CANopen inclination sensor (JN2100 class, two-axis tilt output) is wired to the CAN interface of a B&R X90 mobile control unit. Two symptoms appear together and are commonly confused with each other:

1. The sensor's process data does not appear in the mapped PV, or the CANopen node never reaches OPERATIONAL state.
2. The controller logger reports an error indicating that no safety application is running on the integrated safety CPU of the X90.

The instinct is to assume the safety CPU error is blocking the CANopen node. It is not. These are independent faults with independent fixes, and diagnosing them as one problem wastes hours.

Root Cause 1: CANopen Node ID Mismatch

Every CANopen slave is addressed by a 7-bit node ID (1-127). The COB-IDs of all default communication objects are derived from it:

If the node ID configured in the Automation Studio hardware tree does not match the node ID actually programmed into the sensor, the following happens:

• The master issues SDO requests to 0x600 + configured_ID. The sensor never answers because it only listens on 0x600 + actual_ID.
• Configuration/startup SDOs time out, so the master never transitions the node to OPERATIONAL.
• The sensor's TPDO is still on the bus at 0x180 + actual_ID, but the master has no mapping for that COB-ID, so the PV stays at its initial value (typically 0) and looks like a dead sensor.
• Bus load and error counters usually look normal — there is no CAN error frame, which is why this fault is easy to miss.

Confirming the actual node ID

1. Power the sensor with the CAN bus otherwise idle and capture traffic with a CAN analyzer. On power-up, a CANopen slave transmits a boot-up message with COB-ID 0x700 + NodeID and one data byte 0x00. Subtract 0x700 from the observed identifier to read the node ID directly.
2. If heartbeat is enabled, the recurring 0x700 + NodeID frame with data 0x05 (OPERATIONAL) or 0x7F (PRE-OPERATIONAL) gives the same information.
3. If no analyzer is available, temporarily configure the X90 project with a candidate node ID and check whether the node comes online; iterate over the plausible range from the sensor's factory-default setting.

Node ID on inclination sensors is set either by DIP/rotary switches, by an LSS (Layer Setting Services) sequence, or by writing to the manufacturer-specific object and storing it with 0x1010 sub-index 1 (signature "save" = 0x65766173). Confirm the method in the sensor's own manual and its EDS file before assuming a software-settable ID.

Bit rate must match before node ID matters

A bit-rate mismatch produces a different signature: error frames, rising receive-error counters, and a node that eventually goes bus-off. If you see error frames rather than silence, fix the bit rate first. All nodes plus both 120 Ω terminators must be present on the same segment.

Root Cause 2: "No Safety Application" on the X90 Safety CPU

X90 units ordered with the integrated safety CPU report a fault whenever that CPU has no valid, commissioned safety application. This is a state message about the safety processor, not about any I/O device on the CAN bus. Practical consequences:

Fix: commission a blank safety project

If the machine does not yet require safety logic, create, compile, and commission an empty safety application. This clears the recurring logger errors and releases the outputs.

1. In Automation Studio, add the safety release / safety application object to the project under the X90 safety CPU.
2. Leave the safety logic empty (no functional safety code) or contain only pass-through logic that you have risk-assessed.
3. Build the project so the safety application is compiled and a valid safety CRC/signature is generated.
4. Transfer the project to the controller, then run the safety commissioning (acknowledgement) step so the safety CPU accepts the downloaded application and its signature.
5. Power-cycle and confirm the safety CPU reports a running application in the logger.

Diagnostic Sequence

Work the faults in this order so each result is unambiguous:

1. Split the problems. Confirm the safety CPU error text refers to the safety application, not to a CAN node. If it does, park it — it will not stop CANopen reads.
2. Check physical layer. 24 VDC present at the sensor, CAN_H/CAN_L not swapped, common reference, one 120 Ω terminator at each end of the segment. Measure ~60 Ω across CAN_H/CAN_L with the bus de-energized.
3. Check bit rate. Error frames or bus-off = bit rate or wiring. Silence = addressing.
4. Verify node ID from the boot-up frame (0x700 + NodeID) and align the Automation Studio configuration to it, or reprogram the sensor.
5. Verify EDS/DPD import. The node object in the hardware tree must come from the sensor's own EDS; a mismatched device profile produces correct COB-IDs but wrong PDO lengths and garbage angle values.
6. Check PDO mapping and data type. Inclination angles are typically signed 16- or 32-bit with a documented resolution factor. Map into a matching INT or DINT PV and scale in software.
7. Commission the (blank) safety application to clear the safety CPU errors and enable outputs.

Verification

Sanity-check the scaling

Read the raw PDO value at a known reference: level (0°) and a measured incline. Compute the resolution factor from two points:

factor_deg_per_count = (angle_ref2_deg - angle_ref1_deg) / (raw2 - raw1)
angle_deg = (raw - raw_at_level) * factor_deg_per_count

Compare the derived factor with the resolution stated in the sensor manual. A factor off by a power of ten usually means the mapped data type or byte offset is wrong, not that the sensor is faulty.

Preventive Practices

• Record the node ID, bit rate, and firmware revision of every CAN device on the machine drawing and on a label at the device.
• Standardize node ID assignment (for example, sensors in one block, actuators in another) so a boot-up COB-ID immediately identifies the device class.
• Import the vendor EDS into the project rather than hand-building a generic node; this keeps PDO mapping and data types consistent with the device.
• Configure heartbeat or node guarding so a silent sensor raises a defined fault instead of freezing a stale angle value in the PV.
• Treat a frozen-at-zero angle as a communications fault until proven otherwise — add a timeout on the PDO update in application code.
• Commission the safety application as part of the initial controller setup, before I/O bring-up, so its error messages never mask field-device diagnostics.