What a protocol bridge actually has to do
CANopen and Modbus describe application data in different ways. CANopen devices expose entries in an object dictionary and may exchange process data through PDOs, configuration data through SDOs, network state through NMT, and faults through emergency or error-control objects. Modbus presents coils, discrete inputs, input registers, and holding registers through a client/server request model. A bridge therefore needs an explicit semantic mapping between the two sides.
The CAN in Automation overview is the right starting point for CANopen communication objects and profiles. The Modbus Organization specification library provides the application protocol and implementation guidance for Modbus serial and TCP systems. These references define the protocols; they do not define the data map for your machine.
Start with an endpoint inventory
Record the exact devices, firmware, roles, and physical interfaces before choosing a gateway. On the CANopen side, obtain the electronic data sheet where available and list every object index and sub-index that the application reads or writes. Mark whether each value arrives through a PDO, requires an SDO transaction, changes with NMT state, or is tied to a device profile.
On the Modbus side, identify RTU or TCP, the client and server roles, unit addressing, supported function codes, and the existing register map. Do not infer a data type from a register address. A single value may occupy more than one register, and signedness, scaling, word order, and invalid-value conventions must be documented separately.
If the inventory is incomplete, treat gateway selection as pending. A list of protocol names is not enough to establish that the required objects, roles, and diagnostic behavior can be reproduced.
Build a mapping contract
Create one row for every signal that crosses the bridge. Each row should identify the CANopen source or destination object, the Modbus target, read/write ownership, data type, engineering units, scaling, update trigger, timeout, default state, and diagnostic response. Keep command data separate from status data so that a stale status word cannot be mistaken for a valid command.
The mapping contract should also state what happens during startup. Decide whether the Modbus side can read data before the CANopen node reaches its required NMT state, how configuration is applied after a reset, and which side owns recovery after communication returns. These decisions belong in the application design, not in an undocumented gateway setting.
If the bridge also requires controller or HMI logic changes, scope that work separately through the programming service. The program, gateway map, and commissioning record should point to the same signal names and failure-state decisions.
Review timing and failure behavior
CANopen PDO traffic may be event-driven, synchronous, or configured around device-specific behavior. Modbus clients usually poll. The bridge must reconcile those models without presenting stale data as current. Define an acceptable update policy from the process requirement, then confirm that the gateway, network load, and endpoint behavior can support it.
Failure handling needs equal attention. Map CANopen emergency and node-state information into visible Modbus diagnostics. Define the commanded state when either network is unavailable, when data exceeds its valid range, or when the bridge restarts. Safety-related functions must remain inside the verified safety architecture; a general protocol bridge should not be assumed to provide a safety function.
Bench validation before machine connection
Test the mapping with representative devices away from production. Exercise normal reads and writes, startup order, node reset, cable loss, gateway power cycle, invalid data, timeout, and recovery. Capture the observed values on both sides and compare them with the mapping contract. Only after those checks should the bridge be introduced to machine commissioning.
Use the Gateways and IIoT product family to review available hardware records, or read the protocol bridge definition for the broader engineering boundary. Hardware availability, lead time, documentation, and commercial terms are confirmed at RFQ.
Boundaries and limitations
This workflow defines what to verify; it does not establish that a particular gateway is suitable for a particular machine. Keep these limits visible during selection and commissioning:
- A gateway cannot create a device function that the source endpoint does not expose.
- Matching protocol labels do not establish compatible device roles, object profiles, timing, or diagnostics.
- Register maps, firmware behavior, and recovery logic require application-specific verification.
- Safety, motion synchronization, and deterministic control boundaries require separate engineering evidence.
Questions engineers ask
Can a CANopen object be copied directly into one Modbus register?
Sometimes the value fits, but direct copying should never be assumed. Check data width, signedness, units, scaling, byte and word order, access rights, validity state, and whether the CANopen value is produced by PDO or SDO behavior. Document the resulting Modbus representation in the mapping contract.
Should the gateway be the Modbus client or server?
That depends on the existing controller, SCADA, or device roles. Choose the role that fits the maintained architecture, then confirm connection handling, polling ownership, write permissions, and recovery behavior. The gateway data sheet and endpoint manuals must support the selected role.
What information is needed for an engineering review?
Provide device part numbers, firmware, network topology, CANopen object or EDS data, the Modbus register map, signal ownership, update expectations, failure-state requirements, and a description of which values affect control. That evidence allows a gateway to be reviewed as a candidate for the application.