Resolving Omron FINS Ethernet AdvancedHMI Read/Write Errors

Resolving Omron FINS Ethernet AdvancedHMI Read/Write Errors

This field-proven guide addresses the most common communication failures between AdvancedHMI (AHMI) and Omron CP1/CJ1/CJ2 series PLCs over FINS Ethernet. Symptoms covered include the BasicLabel not displaying live values, the driver sending values 0–3 correctly but failing from 4–9, BCD interpretation of binary data, and bit addresses such as W1.01 raising the runtime error Input string was not in a correct format. Each problem is mapped to its root cause in the OmronFINSEthernetCom driver and the underlying FINS/UDP protocol stack.

1. FINS Protocol Architecture on CP1/CJ1 Controllers

FINS (Factory Intelligent Network Service) is Omron's application-layer protocol used across the CP1, CJ1, CJ2, CS1, and NJ/NX series. Over Ethernet, FINS rides on UDP port 9600 by default and uses a four-byte service ID (0x80 0x00 0x02 0x00 for the CP1H CPU unit). A typical FINS request to read the Work area looks like the frame in the table below.

The corresponding FINS memory-area codes that the AdvancedHMI driver must translate user-friendly addresses into are listed below.

Reference: Omron Industrial Automation product portal and the CP1H CPU Unit Operation Manual (W450), available through MyOmron at https://www.myomron.com/.

2. Symptom Matrix

3. Driver Configuration Prerequisites

1. Open Visual Studio and create a Windows Forms Application.
2. From the Toolbox, drag OmronFINSEthernetCom onto the form.
3. In the Properties window, set the following fields to match the CP1H/CJ1 CPU's IP configuration:

For CP1H Ethernet (model CP1W-CIF41) the module must be enabled in the PLC's Built-in Ethernet Port Settings tab of CX-Programmer, with FINS/UDP ticked and the IP address visible on the front of the unit. For CJ1W-ETN21 modules, confirm the Node Address Setting Switches on the front panel match TargetNodeAddress.

4. Why "Nothing Displays" in the BasicLabel

If a Wireshark trace shows the FINS read request leaving the PC (frame size 28 bytes for a single-word read) but no UDP 9600 response comes back from the PLC within ~3 s, the most common causes are listed in order of frequency.

1. CX-Programmer holds the FINS port. Older CJ1 firmware (v3.0 and earlier) refuses a second UDP socket. Close CX-Programmer entirely, or use a separate Ethernet card to attach to CX-Programmer while AHMI talks to a second ETN21.
2. Windows Firewall blocks inbound UDP 9600. Create a new inbound rule for OmronFINSEthernetCom.exe on UDP 9600, or disable the firewall for the local subnet during commissioning.
3. CPU is in PROGRAM mode with a fatal FINS error. Read the CPU's A401.07 (FINS Protection Flag). If set, the ETN21 responds with the FINS end code 0x0202 — operation prohibited at this time.
4. Sub-net mismatch. The PC's IP must be on the same subnet mask as the CPU (e.g. 255.255.255.0). Multicast routing is not supported on CP1W-CIF41.

5. Bit Address Format Issues ("Input string was not in a correct format")

AdvancedHMI's BasicLabel parses bit addresses as {AREA}{WORD}.{BIT} using the exact two-digit bit position. The driver uses a Convert.ToInt16 call on the bit portion, so W1.01 raises FormatException because the period is not a valid integer character.

Use the following rules when filling PLCAddressValue:

• Work area bit: W100.00 through W511.15 (dot plus two digits).
• CIO area bit (most common, often written without prefix in CX-Programmer): 200.00, 100.00.
• DM bit: D200.00–D32767.15 on CJ1; CP1L limits DM to D0–D9999.

The driver wraps the parser in a try/catch that re-throws the FormatException. The patch below makes the driver tolerant of single-digit bit indices and of the alternative W100/00 notation used in some CX-Programmer exports.

// FINSBaseCom.vb — tolerant address parser
Private Function ParseAddress(raw As String) As FinsAddress
    Dim s = raw.Trim().ToUpper()
    Dim bitIdx = s.IndexOf("."c)
    If bitIdx = -1 Then
        bitIdx = s.IndexOf("/"c)   ' accept "W100/00" too
    End If
    If bitIdx > 0 Then
        Dim area = Left(s, bitIdx)
        Dim bitTxt = s.Substring(bitIdx + 1).PadLeft(2, "0"c)
        Dim bit As Integer
        If Not Integer.TryParse(bitTxt, Globalization.NumberStyles.Integer, _
                                Globalization.CultureInfo.InvariantCulture, bit) Then
            Throw New FormatException("Invalid bit index in '" & raw & "'")
        End If
        Return New FinsAddress(area, 0, bit)
    End If
    Return New FinsAddress(s, 0, -1)
End Function

6. The Keypad Bug: 0–3 OK, 4–9 Become 0–3 (Driver < 3.97d)

Field reports show a keypad address such as W100 storing 1, 2, and 3 correctly but mapping 4, 5, 6, 7, 8, and 9 to 0, 1, 2, 3, 4, and 5 respectively. The pattern repeats: 8, 9, 10, 11 all return correctly, and 100, 101, 102, 103, 104 also read back correctly — except W101, which the application never re-polls after the first read of W100.

The root cause is in the keypad write path of BasicLabel where the integer entered is converted using Convert.ToString(value, 16) and then re-read with Convert.ToInt16(text, 16). Values ≥ 16 cause wraparound if the receiving register is interpreted as BCD. The driver does not use BCD; the PLC does, because the affected data area was declared as BCD(4) in the CX-Programmer symbol table.

Verification of the keypad fix

1. Drop a BasicButton on the form. Set PLCAddressClick to 200.00.
2. Run the application in Debug mode and click the button. Execution should pause in FINSBaseCom.vb at the SendRequest call.
3. Inspect commandBuffer; the last two bytes should be 01 02 (Memory Area Write) followed by 00 02 (two bytes of payload) and the binary word.
4. Confirm with Wireshark that the FINS request body uses the BCD bit clear in the area code byte (lowest two bits = 00 = binary).

7. Stale FINS Responses and the TargetNetworkAddress Pitfall

If the response carries end code 0x1101 (destination address error), the driver is sending a valid FINS request to the wrong node. CP1H/CJ1 controllers default to network 0 and node 0 when the ETN21 has not had its rotary switches moved, regardless of the IP address's last octet. To confirm the node:

1. Connect with CX-Programmer over USB or the same Ethernet link.
2. Read CIO 225 and CIO 226 (network and node number set in the ETN21's CPU Bus Unit Settings).
3. Set the driver's TargetNodeAddress to that value and run the read test again.

If the response carries end code 0x0000 but no payload, the PLC processed a write from another FINS client (often CX-Programmer's auto-refresh). This is normal and does not indicate a driver defect.

8. Coexistence with CX-Programmer

The CP1L / CP1H Ethernet Communication Manual (W466) confirms that on the CP1W-CIF41 module only one FINS client at a time may use the UDP/9600 socket when FINS Protection is enabled. Symptoms include AHMI receiving an empty FINS frame and the BasicLabel freezing on the previous value. The recommended practice is to leave FINS Protection disabled during AHMI development and to either:

• Connect CX-Programmer over USB (CP1W-CIF41-C USB port) while AHMI uses Ethernet, or
• Add the PC's IP to the FINS routing table (ETN21 Setup > FINS/UDP Table) with a high priority so AHMI always wins the socket.

For CJ1W-ETN21 modules, the same rule applies but the protection bit is CIO 226.15. Always stop CX-Programmer's background transfer (ladder monitor, I/O comment upload) before starting AHMI in run mode.

9. Wireshark Capture Recipe for FINS Debugging

1. Start Wireshark on the PC's Ethernet interface. Apply the display filter udp.port == 9600.
2. Trigger a read in AHMI by toggling the BasicLabel's Refresh property or forcing a write from the keypad.
3. Inspect the first packet — it should be a UDP datagram of 26 bytes from the PC to the CPU IP, sport 9600, dport 9600. If it is missing, the driver is failing before UdpClient.Send.
4. Inspect the second packet. If it is a FINS ACK (FINS Service ID = 80 00 02 00, end code 0x0000), the read succeeded but the AHMI parser dropped the data. Patch the parser to honour the FINS header version (the 0x80 0x00 pair at offset 2) and the read quantity.
5. If there is no response within 3 s, run plcmon (Omron CX-Programmer's monitoring tool) and watch the FINS traffic. CX-Programmer will show a No Response from Node dialog with the same symptom.

Save the trace and share the first eight bytes of the request and the full response payload when escalating. The advancedHMI project's GitHub issues page collects these traces for the maintainers.

10. Memory Area Address Cheat Sheet for AHMI

11. Recommended Verification Procedure

1. With AHMI closed, use CX-Programmer to put a known value (e.g. 1234 in DEC) into D100. Confirm with a CX-Programmer watch window.
2. Start AHMI. Set the BasicLabel's PLCAddressValue to D100. Run.
3. Confirm the BasicLabel shows 1234. If yes, the FINS read pipeline is functional.
4. Change PLCAddressValue to W100.00. Toggle the bit from CX-Programmer (force-on, then force-release). Confirm the label changes between 0 and 1.
5. Use the keypad to write values 1, 5, 9, 100, 1023, and 65535. Confirm each writes correctly. This is the definitive test for the 3.97d BCD bug.
6. Run for one hour and confirm no FormatException or ObjectDisposedException is raised. If a disposed UdpClient is observed, enable KeepAlive in the driver properties or upgrade to the current 3.97x branch.

12. Frequently Asked Questions