Linking Omron NJ/NX with Allen-Bradley via EtherNet/IP

Overview

Inter-vendor PLC communication between Omron and Allen-Bradley (Rockwell Automation) platforms requires deliberate protocol selection because each vendor defines its own application-layer semantics on top of TCP/IP and CIP. Omron controllers expose the FINS (Factory Interface Network Service) protocol over Ethernet and serial, while Allen-Bradley controllers expose EtherNet/IP, the CIP-based encapsulation of the Common Industrial Protocol defined by ODVA. Because FINS and CIP are not interoperable at the application layer, an Omron FINS packet received by a ControlLogix chassis is silently discarded by the CIP stack even though the TCP three-way handshake succeeds. Three production-proven integration patterns resolve this problem: EtherNet/IP explicit messaging between NJ/NX and CompactLogix/ControlLogix controllers, a dual-scanner DeviceNet bridge using an AB scanner in slave mode, and protocol-translating gateways that map DF1, Host Link, and Modbus/TCP into a uniform register space. This reference documents each path with controller compatibility tables, CIP service code mappings, MSG ladder examples, and a fault-clearing matrix drawn from field deployment notes.

Protocol Stack Comparison: FINS, CSP, and EtherNet/IP

Ethernet TCP/IP provides only a transport for opaque byte streams. The application-layer protocol determines whether two controllers can exchange meaningful data. Omron controllers default to FINS over TCP port 9600, while Allen-Bradley controllers default to EtherNet/IP over UDP port 2222 (I/O) and TCP port 44818 (explicit messaging). CIP originates from ControlNet and DeviceNet specifications; the EtherNet/IP adaptation encapsulates CIP messages inside TCP/UDP envelopes using the ENIP encapsulation header.

CSP has been superseded by EtherNet/IP on all current ControlLogix and CompactLogix firmware; however, legacy PLC-5 and SLC 5/05 controllers still expose CSP, and bridging from CSP to EtherNet/IP is supported through ControlLogix backplane routing. Omron NJ/NX-series controllers running Sysmac Studio version 1.20 or later expose an EtherNet/IP scanner and adapter interface directly, allowing CIP explicit messages to be initiated from structured-text (ST) CIP message instructions or from the controller's built-in CIP routing table.

Controller Compatibility Matrix

The NJ/NX family implements CIP through the integrated EtherNet/IP port labelled PORT1 (built-in switch) or PORT2 (separate IP, used for CIP routing). Sysmac Studio version 1.40 added CIP Security compatibility, but for inter-vendor messaging with Studio 5000 v33 or later, the standard ENIP encapsulation (no TLS) is the supported baseline.

Method 1 — EtherNet/IP Explicit Messaging Between NJ/NX and ControlLogix

EtherNet/IP explicit messaging uses CIP request/response service codes to read or write tag data on a remote controller. The originator (originator endpoint, OE) opens a TCP connection to port 44818 on the target (target endpoint, TE), sends an ENIP encapsulation header followed by a CIP request, and waits for a CIP response. Studio 5000 implements this through the MSG instruction with message type CIP Generic or, preferably, the typed variants CIP Data Table Read and CIP Data Table Write. Sysmac Studio implements the equivalent through the CIP_UCMM (unconnected) and CIPConnection (connected) function blocks.

CIP Service Codes Used in Cross-Vendor Messaging

The Omron implementation supports service codes 0x4C and 0x4D from firmware 1.11 onward, but tag names must match exactly including case (CIP treats tag names as case-insensitive strings, but RSLogix-classic exports may preserve case). Studio 5000 v28 added symbolic CIP addressing, allowing the originator to specify the remote tag by name without pre-declaring a route. Prior to v28, the Connection Path string in the MSG instruction had to use the form 1, 0, 192.168.1.50, 1, 1 where the leading 1 selects the backplane port, 0 is the backplane slot of the 1756-EN4TR module, the IP address is the target module, 1 is the CIP port (backplane), and the final 1 is the controller slot. With symbolic addressing the path simplifies to CompactLogix_Tag because Studio 5000 auto-resolves the route from the controller's I/O and routing configuration.

Sysmac Studio Side: CIP Message in Structured Text

The CIP message instruction on NJ/NX is invoked from a POU using the CIPUCMMRead or CIPUCMMWrite function blocks, or directly via the _EIP_ service instructions available in firmware 1.20 and later. The variables that must be populated before each call are:

• SrcVariable — pointer to a tag of any CIP-supported type (BOOL, SINT, INT, DINT, LINT, REAL, LREAL, STRING, or array thereof)
• DstVariable — destination tag on the remote controller
• ConnectionPath — STRING variable holding the CIP path, e.g. '192.168.1.50\1\1\0'
• ServiceCode — 16#4C for read, 16#4D for write
• RequestDataSize — number of bytes to transfer
• Timeout — DINT in milliseconds, typically 5000

A working ST snippet that reads a DINT named RecipeNumber from a ControlLogix 1756-L82E at IP 192.168.1.50 follows.

VAR
    EIP_Read : CIPUCMMRead;
    Path    : STRING[260] := '192.168.1.50\1\1\0';
    LocalBuf : DINT;
    Done    : BOOL;
    Busy    : BOOL;
    Error   : BOOL;
    ErrID   : DINT;
END_VAR

EIP_Read(
    Execute := NOT Done,
    ConnectionPath := Path,
    SrcVariable := 0,                  (* unused on read *)
    DstVariable := LocalBuf,
    ServiceCode := 16#4C,
    RequestDataSize := 4,
    Timeout := T#5s,
    Done => Done,
    Busy => Busy,
    Error => Error,
    ErrorID => ErrID
);
IF Error THEN
    (* escalate via alarm block *)
END_IF;

Studio 5000 Side: MSG Instruction Ladder

On the Allen-Bradley side the symmetric instruction reads or writes a tag on the remote NJ/NX. Because NJ/NX exposes user-defined tags as CIP assembly instances, the Connection Path must include the IP address of the NJ/NX EtherNet/IP port and the CIP port 1 for the built-in ENIP interface. The path is 192.168.1.20, 1, 1.

(* Ladder rung, MSG instruction *)
MSG(  
    MessageType  := CIP Data Table Read,
    TagName      := AB_FromOmron,         (* destination tag *)
    NumElements  := 1,                    (* one DINT *)
    SrcTag       := NJ_RecipeNumber,      (* remote tag, must be DINT *)
    ConnectionPath := '192.168.1.20, 1, 1',
    Timeout      := 5000,                 (* ms *)
    CacheConnections := FALSE
);

When configured with CacheConnections := TRUE, Studio 5000 establishes a CIP Class-3 connected message; the connection stays open until the timeout expires, and only one TCP connection per pair of OE/TE is consumed. Set this to FALSE for unconnected messaging (UCMM) when the NJ/NX firmware is older than 1.20 or when the connection count must be minimized. The Omron-supplied sample library illustrates the explicit-message variants and is available at Omron NJ/NX EIP to Allen-Bradley CompactLogix Sample Code. The library contains two projects: one for the Sysmac Studio side showing CIPUCMMRead/Write function blocks, and one for Studio 5000 v32 showing MSG instructions targeting Omron tag names directly.

Tag Name and Atomic Type Mapping

LREAL is the only mismatched type: NJ/NX treats REAL as 32-bit IEEE 754 and LREAL as 64-bit, while Studio 5000 LREAL is also 64-bit but CIP packaging may pad to 8 bytes. For high-resolution analog values above the LREAL limit, prefer writing two DINTs and reassembling on the AB side, or move to an EtherNet/IP I/O assembly connection instead of explicit messaging.

Method 2 — DeviceNet Bridge Using Dual Scanners in Slave Mode

For plants that already operate a DeviceNet backbone, a bridge architecture avoids any CIP routing through the backplane. Install two DeviceNet scanners on the same trunk: a 1756-DNB or 1769-SDN for the AB side and a CS1W-DRM21 or CJ1W-DRM21 for the Omron side. Configure the AB scanner in slave mode so it appears as a 1024-bit I/O slave to the Omron scanner. The Omron scanner reads its own remote I/O and exchanges a polled I/O block of up to 128 words with the AB scanner, which then exposes that block to the ControlLogix backplane as a regular 1756-DNB rack image.

The dual-scanner architecture is favored in brown-field upgrades because it survives any mix of legacy PLCs: an SLC 5/04 in the same rack as the ControlLogix can pull data from the same 1756-DNB without any cross-vendor CIP messaging. The cost is additional trunk length and a second scanner node per chassis, and the 128-word ceiling per poll cycle is hard-limited by the CS1W-DRM21 buffer size. Latency on a 500 kbps trunk with two scanners and three drops is approximately 12-18 ms per scan, which is acceptable for supervisory interlocking but too slow for high-speed motion hand-off.

Method 3 — Serial Protocol Mapping (DF1, Host Link, Modbus RTU)

For small data volumes and existing RS-232/RS-485 infrastructure, point-to-point serial remains the lowest-cost path. The Omron CP1H and CJ2 serial port can be configured to speak Host Link (default), Modbus RTU slave, or raw ASCII. The Allen-Bradley MicroLogix 1400 serial port can be configured to speak DF1 full-duplex, Modbus RTU master, or ASCII. Cross-wiring a Host Link link between two Host Link peers fails because both sides speak the same role and neither initiates; one side must be reconfigured as a Modbus RTU master/slave pair.

The MicroLogix 1400 supports Modbus RTU master via the MSG instruction with message type Modbus Master. The instruction frame includes a Modbus function code (0x03 for holding-register read, 0x06 for single-register write, 0x10 for multi-write) and the address of the slave. Omron's Modbus address space starts at 0x0000 for CIO, 0x1000 for DM, 0x3000 for HR, and 0x6000 for WR; the CP1W-CIF11 must be configured with Serial Gateway Mode = Modbus RTU Slave and the CIO/DM/HR/WR bases set to match the master. Polling rates of 50 ms are typical for 16-word reads at 19200 bps, well below the 128-word ceiling of the DeviceNet bridge.

Method 4 — Modbus/TCP Gateway Translation

A protocol-translating gateway (such as ProSoft, HMS Anybus, or Red Lion CR3000) presents an EtherNet/IP scanner interface to the ControlLogix side and a Modbus/TCP server interface to the Omron side. The gateway itself consumes the application-layer translation, so the ControlLogix sees standard CIP tags and the NJ/NX sees standard Modbus registers. This approach is the cleanest when the data volume exceeds 256 words or when CIP Security on the Omron side blocks explicit messaging from non-Rockwell originators.

The gateway adds 5-15 ms of latency per transaction and a single point of failure for both legs of the conversation. Plan a hot-standby gateway or a direct CIP fallback for safety-related interlocks that the gateway cannot serve.

Configuration Walkthrough: NJ501 to CompactLogix 5380 via EtherNet/IP

Prerequisites

• Sysmac Studio 1.40 or later (NJ501 firmware 1.18 baseline)
• Studio 5000 v33 or later (CompactLogix 5380 firmware 30.011 or later)
• Ethernet switch supporting IGMP snooping if multicasts will be used for I/O assemblies
• Static IP addresses on a private subnet (192.168.1.0/24 typical)

Step-by-Step on Sysmac Studio

1. Open the NJ501 project and navigate to Configurations and Setup -> EtherNet/IP Port Settings. Verify IP Address, Subnet Mask, and that TCP/IP Keep Alive is enabled (default 30 s).
2. Under EtherNet/IP Connections, add a new Tag Set named ToCompactLogix containing all DINT and REAL tags to be exposed. Configure the connection as Output from the NJ501 perspective.
3. Add the CompactLogix 5380 as a target device with IP address 192.168.1.50. Set the Requested Packet Interval (RPI) to 50 ms (10 ms minimum, 100 ms typical).
4. Bind the Tag Set ToCompactLogix to the connection. Sysmac Studio will auto-generate the CIP assembly instance numbers (typically instance 101 for output, 102 for input).
5. Insert the CIPUCMMRead function block into a POU as shown in the snippet above. Set the path string to '192.168.1.50\1\1\0' and the service code to 16#4C for reads.

Step-by-Step on Studio 5000

1. Open the 5069-L306 project and add an Ethernet device to the I/O tree under the embedded Ethernet port. Use the EDS for the NJ501 (downloadable from the ODVA site if the EDS is missing from Studio 5000 v33).
2. Configure the connection RPI to match the NJ501 setting (50 ms). Select Point-to-Point for unicast or Multicast if multiple AB controllers must consume the same data.
3. Create MSG instructions for any explicit reads/writes that cannot be routed through the I/O assembly (rare for periodic data, common for recipe management and diagnostics).
4. In the MSG instruction properties, set Communication Path to 192.168.1.20, 1, 1 where 192.168.1.20 is the NJ501 PORT1 IP and the trailing 1, 1 selects CIP port 1, slot 1.

Verification

• Force a tag on the NJ501 (e.g., HMI_LinkOK := TRUE) and observe the corresponding tag on the CompactLogix update within one RPI (50 ms).
• On the NJ501, navigate to Troubleshooting -> EtherNet/IP Connection Status and confirm the connection state shows Connected, not Timeout or Duplicate Node.
• On the CompactLogix, open Module Properties -> Connection and verify the Status field reads Running with zero Sequence Count Errors after 1000 scans.
• Use Wireshark with a CIP dissector (port 44818) to capture one CIP round-trip and confirm the response service code echoes 0x4C with General Status = 0x00.

Diagnostic Tags and Fault Codes

The Omron ErrorID output on CIPUCMMRead/Write is a DINT whose low word encodes a transport-level result and whose high word encodes the CIP general status. Decode with the formula CIP_Status := SHR(ErrorID, 16) AND 16#00FF in ladder or ST on either side.

Troubleshooting Matrix

Performance and Throughput Expectations

EtherNet/IP explicit messaging with a cached Class-3 connection on a 100 Mbit/s switch typically completes one DINT read in 3-6 ms. A 10-DINT block read finishes in 8-12 ms. Connected I/O assemblies at a 50 ms RPI deliver deterministic 50 ms update latency with sub-millisecond jitter, while unconnected UCMM messages are jitter-sensitive and may vary from 4 ms to 30 ms under load. The DeviceNet bridge at 500 kbps delivers 128 words every 12-18 ms per scanner pair. Modbus RTU at 19200 bps yields 16 words every 50 ms. Plan cycle-time budgets accordingly: use I/O assemblies for interlocking, MSG for recipe and diagnostics, and Modbus RTU only for non-time-critical supervisory data.

Selection Guidance

Choose EtherNet/IP explicit messaging when both controllers are NJ/NX and CompactLogix/ControlLogix and the data set is under 200 words. Choose the DeviceNet dual-scanner bridge when the backbone already exists and additional CIP routing would be too costly or when legacy PLC-5/SLC 5/04 controllers must share the same data. Choose the Modbus/TCP gateway when CIP Security requirements on the Omron side block direct explicit messaging or when the data must fan out to more than two controllers. Avoid serial protocols for new installations; reserve them for brown-field retrofits where the existing cable plant and panel space are fixed.