Resolving WinCC v8.0 Connection Failure on Omron CJ2M-CPU35

1. Problem Overview

WinCC V8.0 Update 6 (and V8.1 Update 2 on separate test benches) cannot establish a stable EtherNet/IP connection to an Omron CJ2M-CPU35 controller running firmware v2.2. Identical PLC hardware and identical WinCC channel configuration connect successfully to a CJ2M-CPU35 running firmware v2.1. The failure is reproducible on multiple v2.2 units. The plant network, IP addressing, and CX-Programmer communications are confirmed healthy; the drop occurs the instant the WinCC Runtime enters Runtime state and attempts to open CIP connections. Symptom signature:

• EtherNet/IP socket is reachable (ping, CX-Programmer transfer, and Web browser on port 80/443 succeed).
• CX-Programmer online connection remains active while WinCC Runtime is stopped.
• When WinCC Runtime starts, the Omron Ethernet IP channel reports a connection fault and the PLC rejects the CIP Forward_Open service.
• Downgrading to firmware v2.1 (or using an existing v2.1 CPU) restores normal WinCC communication without any change to WinCC configuration.

2. CJ2M-CPU35 Hardware and Firmware Context

The CJ2M-CPU35 sits in the middle of the CJ2M family. It integrates an EtherNet/IP port on the CPU module itself, eliminating the older ETN21/ETN21N communication unit requirement for many installations. Key parameters relevant to this case:

Omron periodically publishes firmware revisions for the CJ2M family. Minor revisions are not always fully backward-compatible at the CIP layer; firmware v2.x revisions in particular have historically changed the default handling of CIP connection originators, originator-to-target instance IDs, and the response payload of the Get_Attribute_Single service for the Identity Object (Class 0x01). Whenever a previously stable SCADA link breaks after a controller firmware update, treat the firmware as the prime suspect before touching the SCADA configuration.

Obtain the official release notes for the exact build string reported by CX-Programmer (e.g., CPU35 V2.2 (lot 23xxx)) from the Omron regional support portal before applying the corrective steps below. The release notes frequently disclose CIP behavior changes such as new connection originator restrictions, EDS updates, or new explicit-message authentication requirements.

3. WinCC Omron Ethernet/IP Channel Architecture

The WinCC channel used in this case is Omron Ethernet IP (internal channel number 0x10F). It is not the older Omron FINS Ethernet channel and is not a FINS-UDP implementation; it speaks native CIP/EtherNet/IP encapsulation as defined in Volume 1: Common Industrial Protocol (CIP) and Volume 2: EtherNet/IP Adaptation of CIP (ODVA, current revision at the time of integration).

3.1 Logical channel structure

The driver instantiates the following objects inside WinCC:

1. Logical connection – represents a single TCP connection to port 44818 of the CJ2M CPU.
2. Access points – typified WinCC tag groups; one access point can map to many tags.
3. Tags – either symbolic (Omron symbol name resolved via CIP Get_Attribute_Single on the Symbol Object, Class 0x6B) or absolute (CIO/DM/HR/WR area + offset + bit).
4. Subscription service – WinCC issues a Read_Tag_Fragmented or uses a class 3 Get_Attribute_Single polling cycle. Some installations rely on the implicit (I/O) class 1 connection; verify which model is in use before troubleshooting.

3.2 Connection establishment sequence

1. TCP three-way handshake to port 44818.
2. Encapsulation Register Session (command 0x0065).
3. CIP Forward_Open (service 0x54) for the configured connection path (typically 0x20 0x02 0x24 0x01 = Connection Manager, instance 1).
4. If the connection is class 1 (implicit I/O), the PLC allocates a T→O assembly and an O→T assembly; otherwise class 3 (explicit) connections are unicast-only.
5. WinCC begins cyclic polling according to the configured Update time and Timeout.

A failure at step 3 (Forward_Open) is the most common symptom reported by users moving from CJ2M firmware v2.1 to v2.2. The PLC responds with one of the standard CIP general status codes; recording the returned status is the fastest path to root cause.

4. Diagnostic Log Collection

Before changing anything, capture the full WinCC diagnostic trace. WinCC writes per-channel logs to a fixed location and rotates them by date.

4.1 Log file locations

4.2 Procedure

1. Stop the WinCC Runtime.
2. Archive the existing diagnose folder.
3. Open the project in WinCC Explorer and activate the channel's Diagnostics option: right-click Omron Ethernet IP → Properties → Connection tab → enable Trace and set the level to Verbose.
4. Start WinCC Runtime.
5. Wait for the connection fault to occur (typically within one polling cycle).
6. Stop Runtime, then open the channel log and search for the string ForwardOpen, GeneralStatus, and the CIP service byte 0x54.

4.3 Log entry interpretation

A failing channel produces entries resembling:

2024-05-12 14:02:11.473 [OmronEthernetIP] INFO  ChannelUnit::OpenConnection target=192.168.10.35:44818
2024-05-12 14:02:11.488 [OmronEthernetIP] INFO  Encapsulation::RegisterSession session=0x0000C021 OK
2024-05-12 14:02:11.502 [OmronEthernetIP] INFO  CIP::ForwardOpen path=0x20,0x02,0x24,0x01 T>O=0x64 O>T=0x65 timeout=2500
2024-05-12 14:02:11.518 [OmronEthernetIP] ERROR CIP::ForwardOpen Response GeneralStatus=0x01 ExtendedStatus=0x0100
2024-05-12 14:02:11.518 [OmronEthernetIP] ERROR Connection state -> FAULT

Map the returned GeneralStatus byte against the CIP specification:

5. Root Cause Analysis

The fact that the same WinCC project works against firmware v2.1 and fails against v2.2 narrows the search considerably. The dominant root causes seen in field reports are listed below in order of probability.

5.1 CIP connection originator count and instance handling

Newer CJ2M firmware builds have tightened the implementation of the CIP Connection Manager (Class 0x06). Specifically:

• The PLC now rejects Forward_Open requests whose Originator Serial Number does not match the registered EDS expected by the scanner.
• Re-key attempts within a short interval are throttled; a failed key followed by an immediate retry may be refused with GeneralStatus 0x02.
• WinCC's default retry cadence (configured under Connection properties → Timeout / Retry) can be interpreted by the v2.2 PLC as a connection storm, causing the PLC to reject the originator until the back-off timer expires.

5.2 CIP Security or explicit-message authentication

Omron firmware revisions in the v2.x line have added optional CIP Security flags. When the PLC has Use CIP Security ticked under CX-Programmer → PLC → Ethernet/IP → Security, all explicit CIP services from untrusted originators are refused unless they present a valid TLS-capable encapsulation header. WinCC V8.0 Update 6 and V8.1 Update 2 do not implement CIP Security; they speak legacy CIP encapsulation only. This is the single most common field cause when moving from a previously-working firmware to a newer one.

5.3 EDS revision drift

If the CJ2M EDS registered with WinCC's Omron Ethernet IP Device Catalog is older than the firmware installed on the CPU, the device descriptor's Vendor ID / Device Type / Product Code fields may no longer match. WinCC's CIP originator will issue the Forward_Open using the EDS-supplied connection parameters, and the PLC will refuse it with GeneralStatus 0x05. EDS files are versioned; v2.2 firmware commonly ships with a new EDS revision.

5.4 Connection table exhaustion

CJ2M v2.2 firmware tightened the connection timeout for unused class 3 sessions. If the project uses class 3 only (typical for WinCC tag polling), an existing CX-Programmer session left open from earlier troubleshooting can hold one slot, and other utilities such as the Omron Network Configurator or a second SCADA node can hold the rest. With the 64-entry ceiling, a single new originator can be refused.

5.5 Implicit/I/O configuration mismatch

When the WinCC channel is configured for implicit (class 1) connections rather than explicit (class 3), v2.2 firmware validates the requested RPI, Transport Type, and Trigger values. RPI values below the PLC minimum (commonly 5 ms on CJ2M) or transport types outside the supported set are refused with GeneralStatus 0x01.

6. Solution Procedures

Apply the fixes in the order listed. Stop WinCC Runtime before each change; start it after each step and verify the log before proceeding.

6.1 Step 1 – Disable CIP Security on the CJ2M CPU

1. Connect CX-Programmer to the affected CJ2M-CPU35 (this works whether WinCC is running or not because CX-Programmer uses FINS, not CIP).
2. Select the PLC in the project tree and choose PLC → Ethernet/IP → Security.
3. Uncheck Use CIP Security (or Enable CIP Security, depending on CX-Programmer version).
4. Click Transfer to PLC, confirm, and cycle the PLC to RUN mode.
5. Verify the WinCC connection now establishes.

6.2 Step 2 – Refresh the EDS catalog

1. Download the EDS file matching CJ2M-CPU35 firmware v2.2 from the official Omron download portal. Confirm the EDS file header contains Device Type = 0x0E (Communications Adapter) or 0x00 (Generic) and Product Code = 35.
2. Open WinCC Explorer and select Omron Ethernet IP Driver → Device Catalog.
3. Right-click and choose Install EDS; point to the new EDS file.
4. Restart the WinCC Runtime so the device catalog is re-read.
5. Verify the channel now opens.

6.3 Step 3 – Increase the retry and timeout window

1. In WinCC Explorer, right-click the failing connection under the Omron Ethernet IP channel and choose Properties.
2. Set Timeout to 5000 ms (default 1000 ms).
3. Set Retry count to 5 with a Retry delay of 2000 ms.
4. Click Apply and restart WinCC Runtime.

This change adapts the originator to the PLC's tightened throttling behavior.

6.4 Step 4 – Free connection table slots

1. Close all CX-Programmer instances that have an online connection open.
2. Close the Omron Network Configurator tool if it is running.
3. On the PLC, monitor CIP Connections In Use through the built-in web server (browse to http://<plc_ip>) and confirm fewer than 60 connections are active before WinCC starts.
4. Restart WinCC Runtime.

6.5 Step 5 – Convert to explicit (class 3) messaging

If the WinCC project uses implicit I/O, switch the channel's Connection Type from I/O (Class 1) to Explicit Messaging (Class 3). Class 3 messaging avoids RPI/Trigger validation and is more forgiving of firmware variations.

6.6 Step 6 – Firmware rollback

If Steps 1–5 do not resolve the issue and a firmware downgrade is operationally acceptable, install the previously working v2.1 firmware using CX-Programmer's PLC → Transfer PLC → Download Firmware workflow. The CPU retains the program and parameter set during the firmware transfer; always back up the project with CX-Programmer before initiating a downgrade. Downgrade the firmware only to a build that Omron officially supports on the same hardware lot.

7. Verification and Validation

After applying any combination of the steps above, perform the verification sequence below. Each test gates the next.

1. Runtime connection state: WinCC Explorer → Omron Ethernet IP channel shows a green dot. Channel log contains Connection state -> OPEN within 10 s of Runtime start.
2. Tag quality: Graphics with internal tags bound to CJ2M CIO/DM addresses show good quality. Any tag flickers to bad quality indicate intermittent failures; re-check the log for retry entries.
3. Sustained read/write: Drive a few tags from the PLC side (set/reset CIO 100.00 and DM 200) and confirm the value reaches the WinCC tag database within two update cycles.
4. Long-duration stability: Allow Runtime to remain active for at least 24 hours. WinCC V8.0 has historically masked intermittent drops; the Omron FINS Driver – Intermittent Drop Out symptom pattern (channel appears bound yet tag quality flips to bad) is a known failure mode and is most often caused by a half-open TCP session. Re-check the channel log for KeepAlive failures if a 24-hour test reproduces the issue.
5. Fault injection: Disconnect the Ethernet cable for 5 seconds and reconnect. WinCC should re-establish the connection automatically within the configured retry window. If it does not, increase Timeout and Retry count per Step 3.

8. Preventive Measures and Best Practices

• Pin WinCC versions: Run WinCC V8.0 Update 6 or V8.1 Update 2 with the matching Omron Ethernet IP driver revision. Mixed versions on the same plant floor cause inconsistent behavior. Maintain a documented baseline.
• Lock firmware revisions: Disable PLC → Allow firmware update via network in CX-Programmer to prevent unintended firmware drift on remote sites.
• Centralize EDS management: Keep the canonical EDS library on a network share and reinstall it whenever a controller is reflashed. Version the EDS folder alongside the WinCC project.
• Monitor CIP connection count: Poll Class 0x06, Instance 1, Attribute 8 (Number of Active Connections) into a WinCC archive tag. Alarm when the value exceeds 48 (75 % of 64) to give early warning before the table saturates.
• Avoid continuous class 1 connections: For SCADA polling, prefer class 3 explicit messaging unless the application is hard-realtime. Class 3 is more robust across firmware revisions and survives brief network interruptions without manual intervention.
• Subscribe to Omron firmware advisories: Register the plant with the Omron industrial automation customer portal and review the CJ2M Series Product Advisory Notice feed before approving any firmware update.

9. Frequently Asked Questions