Configuring NI OPC Server for Omron PLC Communication

1. Overview

LabVIEW from National Instruments is a graphical development environment widely deployed in automated test, validation, and production data acquisition systems. When a LabVIEW front-end must exchange data with a PLC—especially an Omron CJ, CS, CP, NJ, or NX series controller—the most reliable integration path runs through an OPC (OLE for Process Control) server. The NI OPC Server (formerly Matrikon OPC and previously NI Lookout OPC Server prior to its rebranding) acts as the protocol translator: it speaks the PLC's native protocol on one side and exposes a standards-compliant OPC DA 2.05 / 3.0 / UA interface on the other. LabVIEW applications then consume the tags as standard OPC items without any knowledge of FINS, Host Link, or EtherNet/IP framing.

This reference documents the field-proven configuration of NI OPC Server against an Omron CJ2H (CP1H, NJ101, and CP1L are addressed in the alternates section) using the FINS Ethernet driver, plus the construction of a LabVIEW OPC client. Includes channel/device tree setup, memory-area addressing, data-type handling (including STRING), and a verification procedure that confirms both read and write paths before line integration.

2. Architecture

The integration uses a three-tier model. The Omron PLC is the data owner. The NI OPC Server is the protocol/format translator that runs as a Windows service or interactive application. LabVIEW VIs act as OPC DA clients and use the same tag space as any other SCADA client. This separation has two practical benefits: (a) multiple LabVIEW or HMI clients can subscribe to the same tag without each re-implementing the PLC driver; (b) the OPC server can apply smoothing, dead-banding, and scan-rate decimation that protects the PLC from excessive unsolicited read traffic.

The OPC server is the sole owner of the PLC's socket. Because all read/write traffic is funneled through it, you can configure a single scan rate (e.g., 100 ms) for high-priority tags and a slower rate (1,000 ms) for diagnostics, reducing the FINS message load on the CJ2 CPU by roughly an order of magnitude versus raw looping from LabVIEW.

3. Prerequisites

4. Step-by-Step: NI OPC Server Configuration

4.1 Install and launch the configuration console

Install the NI OPC Server package and start the configuration utility. The default tree shows Connectivity on the left and the property sheet on the right. Right-click Channels and add a new channel named OMRON_FINS. Select the Omron FINS Ethernet driver (also called the "OMRON FINS" or "OMRON FINS Ethernet" device driver depending on version). Leave the default Write Optimizations enabled (multiple writes within 10 ms are coalesced into a single FINS frame).

4.2 Add the PLC as a device

Right-click the new channel and choose Add Device. Configure the device properties as follows:

Click Test Connection. A successful test returns Success in the driver log and the device icon turns green. Failure codes are summarized in Section 8.

4.3 Add tags with Omron memory area addresses

Right-click the device, select New Tag, and create the items your LabVIEW application will consume. Omron memory areas are mapped to address strings with a specific syntax. The following mapping is the standard used by the Omron FINS driver shipped with NI OPC Server.

Tag examples for a typical discrete/continuous cell:

OMRON_FINS.PLC_LINE_1.CIO100,0.05      Boolean  RUN command bit
OMRON_FINS.PLC_LINE_1.D200              Float    (use two D-words; configure as DWord, scaled in LabVIEW)
OMRON_FINS.PLC_LINE_1.D300              STRING   32 chars; configure Native Data Type = "String"
OMRON_FINS.PLC_LINE_1.WR5,0             Boolean  Ready bit
OMRON_FINS.PLC_LINE_1.D10000            Short    Recipe parameter

4.4 Configure STRING support

Omron DM areas carry text as packed ASCII in 16-bit words; the FINS driver exposes them as String native type when you set Native Data Type = String on the tag properties. Specify a Length in characters (each character uses one word). For Unicode/Japanese strings on newer CJ2/NJ controllers, switch the FINS drive to the Symbol Protocol and bind the tag directly to the variable name (RecipeName) instead of using DM addresses—this honors the PLC's declared string encoding.

5. Step-by-Step: LabVIEW OPC Client

5.1 Add a Server / I/O Server in the LabVIEW project

If the LabVIEW DSC Module is licensed, right-click My Computer » New » I/O Server and select OPC Client. Browse the local registered OPC servers and pick National Instruments.OPCServer (or the DA 3.0 server registered by your NI OPC Server build). Then drag any tag from the device tree onto a Shared Variable. The Shared Variable becomes the canonical read/write point for every consumer VI.

5.2 Use DataSocket if DSC is not available

Without DSC, use the Datasocket Open, Datasocket Read, and Datasocket Write primitives (Programming » Data Communication » DataSocket). The URL takes the form opc://localhost/National Instruments.OPCServer/OMRON_FINS.PLC_LINE_1.D200. Two critical parameters:

• Access Mode: readOnly or readWrite. Set readOnly by default; reserve write access for command paths.
• Connection Mode: Buffered (Polling) for status values; Streaming (Subscription) for unsolicited updates as the PLC writes.

5.3 Boilerplate LabVIEW reads/writes

A minimal programmatic read of a DINT tag with error handling uses this DataSocket snippet (LabVIEW pseudo-code / G-language transcription):

function ReadDINT(tagURL: String) returns (value: I32, errCode: I32, errMsg: String):
    dsRef := DataSocket.Open(tagURL, readOnly, Buffered, 1000)
    result := DataSocket.Read(dsRef, -1, value)
    errCode := DataSocket.GetLastStatusCode(dsRef)
    errMsg  := DataSocket.GetLastErrorString(dsRef)
    DataSocket.Close(dsRef)
    return value, errCode, errMsg

Wrap the call in a polling while-loop with the desired period. For subscription-style acquisition, register a callback using the DataSocket event structure—LabVIEW notifies the consumer VI the moment the OPC server publishes a new value, eliminating the polling delay.

6. Data Type Mapping Reference

7. Performance and Reliability Tuning

Three knobs dominate throughput:

1. Tag scan rate. Default 100 ms is the sweet spot for status and process values. Increase to 500–1,000 ms for trending parameters that change slowly. The driver coalesces multiple tag reads inside the same scan cycle into a single batched FINS frame.
2. PLC CPU utilization. Each unique DM address read by the OPC server translates to a FINS Memory Area Read command. Reading D0, D1, D2 individually is three FINS frames; reading D0 with length 3 is one frame. Set the address and length so contiguous areas are read in a single frame.
3. Subscription vs. polling. Use DataSocket streaming for tags that LabVIEW must react to within one cycle. Polling at a fixed 50 ms is acceptable for slow-changing data and avoids event-queue overhead.

For bandwidth-planning engineers, the approximate message size of a single 32-word read over FINS/UDP is 26 bytes of header plus 64 bytes of payload = 90 bytes. At 100 ms scan with 64 tags batched into four frames the link load is on the order of 24 kbit/s — negligible on any modern Ethernet.

8. Verification Procedure

1. In the OPC Server Quick Client, observe the green dot on every tag; values should refresh at the configured scan rate.
2. Click the device, navigate to the Statistics sheet, and confirm Failure Count = 0. Any non-zero entries mean partial responses are being lost.
3. In LabVIEW, build a test VI using the DataSocket read snippet from Section 5.3. Display the value on a front-panel indicator. Toggle a known DM bit in CX-Programmer and confirm the indicator updates within one scan interval.
4. Reverse the loop: write a constant from the LabVIEW VI to a DM word and observe the change in CX-Programmer's online edit window.
5. For STRING tags, write an ASCII phrase from LabVIEW and confirm CX-Programmer's character monitor shows the same text in the destination DM range.
6. Disconnect the Ethernet cable for 10 s, restore it, and confirm the OPC driver logs Auto-reconnect successful and tags begin updating without restart.

9. Troubleshooting Matrix

10. Alternative Paths and Platform Notes

When the dedicated OPC server is overkill or a single LabVIEW instance is the only consumer, two direct paths exist:

• EtherNet/IP direct (Logix-class PLCs): Allen-Bradley ControlLogix and CompactLogix expose tags natively over EtherNet/IP. National Instruments distributes the EtherNet/IP LabVIEW Library on the NI Tools Network; it implements explicit messaging I/O so that LabVIEW can call cip_read_tag("Recipe.ID") and cip_write_tag(..., value) without an OPC server. This is also appropriate for newer Omron NJ/NX CPUs that ship with Sysmac Studio tags, but the public library targets ControlLogix; for NJ use the Sysmac Gateway + OPC UA bridge instead.
• UDP/FINS direct from LabVIEW: Send raw FINS packets via the LabVIEW UDP primitives. This avoids server licensing entirely but is brittle (FINS sequencing, frame CRC, exception codes) and is generally recommended only for advanced prototypes, not for production.
• OPC UA over Ethernet (NJ/NX and CX-Designer variables): CJ2H/NJ CPUs with the SYSMAC OPC UA option or CJ2H-OCPxx expand the built-in Ethernet socket to port 4840. NI OPC Server supports UA 1.04 in parallel with DA 2.05; bind the same tags and your LabVIEW client becomes publisher-agnostic.

11. Safety and Security Caveats

• Do not use the standard OPC DA interface across an untrusted network without a UA tunnel or VPN — DA is unauthenticated COM/DCOM and is trivially spoofable.
• Treat every tag map as part of your safety file. Writes from LabVIEW should never target safety-rated memory areas (CPM/CJ2 safety points are routed through the safety CPU, not the standard CPU).
• Disable Allow Anonymous on the OPC server, and configure a Windows user account whose only role is OPC access. Run the OPC server service under that account — not as Local System.
• Set the PLC Ethernet port IP and the FINS Node Number explicitly in the CPU's CX-Programmer » IO Table » Built-in Ethernet settings. Auto-negotiated node numbers confuse the driver.

12. Reference Documentation

• LabVIEW product overview — National Instruments
• LabVIEW Download & release notes — National Instruments
• LabVIEW background and architecture — Wikipedia (general reference only)