A CANopen to Modbus TCP gateway is a protocol converter that reads CANopen process data objects (PDOs) and service data objects (SDOs) on a CAN 2.0A/2.0B physical layer and exposes them as Modbus TCP holding/input registers on an Ethernet port, with bidirectional translation performed by onboard configuration software [S1][S2].
The product class is mature and crowded, with the most cited active offerings being the HMS Anybus X-gateway family (CANopen Slave and CANopen Master variants, model AB7640-F and AB7308-B) [S1][S2], Moxa MGate 5121 series protocol gateways [S3][S5], and Eaton XN-GWBR-MODBUS-TCP multi-protocol gateways (34 mm width, 1.34 in.) [S6], plus converters from ADFweb and PUSR (ICStation) [S8][S9].
Master/slave role: which side of CANopen you sit on
Any CANopen to Modbus TCP bridge is asymmetrical, because CANopen itself is asymmetrical: one master (the NMT master) controls the network, while every other node is a slave with its own object dictionary [S1][S2]. The HMS Anybus X-gateway CANopen Slave variant (AB7640-F) attaches as a slave on the CAN side and presents a Modbus TCP server interface to the Ethernet side, so a CANopen master (typically a PLC) can read/write that gateway as if it were a regular I/O node [S1]. The Master variant (AB7308-B) inverts that: a non-CANopen Modbus TCP controller can poll CANopen slaves on the bus through the gateway, with the gateway performing the SDO and PDO transactions on behalf of the Modbus client [S2].
This role inversion is the single most consequential selection decision, because the wrong variant silently fails to scan the I/O rather than throwing a wiring error. Moxa lists CANopen as one of the supported conversion targets in its Modbus TCP gateway family, with configuration and troubleshooting handled through a Windows utility [S5]. Eaton's XN-GWBR-MODBUS-TCP gateway can currently be ordered in PROFIBUS-DP, CANopen, Modbus TCP, and EtherNet/IP variants, all sharing the same 34 mm housing width, which is useful when spare units are stocked for multi-line plants [S6].
Mapping model: registers, PDOs, and configuration work
Inside the gateway, a configuration tool maps CANopen PDOs and SDOs to Modbus registers; this is where the field integration actually happens [S4]. On a typical Anybus-class device the user defines, per PDO, the source CANopen node ID, the COB-ID, the transmission type, and the destination Modbus register address, then uploads the configuration to non-volatile memory [S1][S2]. The same approach is described in third-party guides for Moxa MGate 5121, where Modbus TCP register words are tied to CANopen object dictionary entries [S3].
Cycle times are dominated by the slower of the two buses. CANopen typically runs at 125 kbit/s, 250 kbit/s, 500 kbit/s, or 1 Mbit/s, with a default PDO inhibit time that, in practice, caps per-PDO refresh around 5-100 ms depending on bus loading and COB-ID priorities [S4]. Modbus TCP, on the Ethernet side, is poll-driven and limited by the master's scan period; the gateway does not actively push, so the effective update rate equals the Modbus poll interval when no spontaneous PDO is forwarded [S3][S5]. Diagnostic data, heartbeat, and emergency frames are tunneled in some implementations and dropped in others, which is a common reason a "working" gateway still fails to surface a node fault at the Modbus side [S4][S9].
Selection criteria, compared
Four decision criteria cover most procurement situations: CANopen role, configuration tooling, form factor, and how the device is wired into existing plant IP. The Anybus X-gateway line sits at the high end on tooling (HMS' Anybus Configuration Manager) and at the wider end of the protocol matrix, with explicit Slave (AB7640-F) and Master (AB7308-B) SKUs [S1][S2]. Moxa MGate 5121 targets Modbus-centric plants, where Modbus RTU/ASCII, Modbus TCP, CANopen, and J1939 are all translated by the same firmware, simplifying spares [S5]. Eaton XN-GWBR-MODBUS-TCP is positioned for DIN-rail density (34 mm / 1.34 in. width) and integrates into Eaton's PLC ecosystem as a slice on the XN bus [S6].
For greenfield CANopen or for bridging a non-PLC controller, PUSR-class converters and the ECAN-240 Modbus to 2-port CAN Bus Gateway are commonly cited, with the explicit feature claim of full CANopen compatibility on a 2-port CAN bus [S7][S8]. ADFweb's CAN to Modbus TCP family covers the same niche for European panel builders, with products that explicitly exchange commands, status words, and diagnostic data between CAN and Modbus TCP devices [S9]. Where a single Modbus TCP master must read 10-50 CANopen slaves, the dedicated Master gateway (AB7308-B or Moxa MGate 5121) is the right pick; for connecting one legacy CANopen slave to a Modbus TCP-only SCADA, the Slave variant (AB7640-F) avoids configuring NMT behavior on the gateway itself [S1][S2].
Failure modes and field tactics
Three failure modes recur on every CANopen to Modbus TCP retrofit. First, a node that powers up in Pre-Operational rather than Operational will not emit the PDOs the gateway expects, so the Modbus side sees stale or zero data even though the gateway link LED is green; the fix is an NMT Start command, often from the gateway's startup script [S4]. Second, a mismatch in byte order (Intel vs Motorola) between the CANopen object dictionary and the Modbus register map causes 16-bit and 32-bit values to read as swapped words; this is fixed in the mapping tool, not in the PLC code [S1][S3]. Third, gateways installed behind a plant firewall without proper Modbus TCP port (default 502) routing simply go silent after commissioning, and the symptom looks identical to a CANopen bus fault [S5][S9].
For plants running older PLCs that cannot be replaced in this budget cycle, the same bridging approach used in obsolete PLC migration is what the gateway implements, just at the bus protocol level rather than the rack level. Where the bottleneck is scan time rather than the physical bus, PLC scan time throughput is the more relevant read, because no gateway can poll faster than the Modbus master requests.
Standards, cabling, and EMC envelope
On the CAN side, gateways terminate or pass-through a 9-pin D-sub on a CAN 2.0A/2.0B physical layer with the standard 120 ohm termination, often switchable on the housing [S1][S6][S9]. On the Modbus TCP side, the physical layer is 100 Mbit/s Fast Ethernet on RJ45, and protocol behavior follows the Modbus organization specification (Modbus application protocol, port 502) [S5]. EMC and surge requirements depend on the cabinet the gateway lives in, but vendors typically cite industrial ratings (EN 61000-6-2 / EN 61000-6-4) and a 24 VDC supply tolerance suitable for DIN-rail power supplies [S1][S5][S6].
For hazardous-area use, the gateway itself is normally mounted in the safe area, with the CANopen bus confined to Zone 2 / Div 2 runs; a pressure transmitter on a CANopen slave typically inherits the gateway's zoning, not the gateway's certification. Where multiple protocols must converge on one SCADA node, the fieldbus gateway class is the parent category, and a protocol gateway is the more general term covering non-fieldbus conversions such as Modbus RTU to Modbus TCP.
Wiring, signals, and signal-chain context
A CANopen to Modbus TCP gateway does not change the analog signal chain; it only transports the digital representation of process variables. On a hydraulic skid, for example, the pressure sensor output still terminates at a CANopen slave, and the gateway only transports the 16-bit integer (or 32-bit float) representing the pressure to the Modbus TCP world. Where the same skid also needs a flow meter or a pressure transmitter reading, the practical question is whether each instrument already has a CANopen slave option, or whether a separate serial-to-CANopen converter is required before the gateway sees the data [S5][S8].
Modbus TCP does not natively carry the device-level diagnostics that CANopen carries in its Emergency and Heartbeat objects; gateways that drop those frames will hide a slave-side fault from the Modbus master until the next poll misses a heartbeat. This is why vendors like ADFweb list diagnostic data and status word exchange as explicit features rather than implicit behavior [S9].
Procurement and lifecycle signals
Two trackable signals matter for buyers in 2026. First, Moxa's Modbus TCP gateway product family continues to advertise CANopen conversion alongside Modbus RTU/ASCII, Modbus TCP, and J1939, indicating the firm is still investing in the protocol-bridging segment rather than migrating it to OPC UA-only [S5]. Second, the HMS Anybus X-gateway CANopen product line is still published in two distinct SKUs (AB7640-F Slave and AB7308-B Master) as of the 2026 product page snapshot, confirming both directions of bridging remain first-party supported rather than deprecated [S1][S2]. Watch for firmware notes around CiA 401 (generic I/O) and CiA 402 (drives) profile handling on the next revision cycle, since those profile IDs are where most mapping mismatches still surface in the field.