Connecting GX Simulator to Factory I/O Through OPC

Virtual commissioning becomes valuable when the simulated scene behaves like a controlled machine rather than a disconnected animation. For a Mitsubishi PLC project, that requires a traceable data path from the GX engineering simulator, through a compatible OPC server, to Factory I/O tags.

The objective is not merely to make a conveyor move. A useful setup proves address ownership, signal direction, sequence behavior, interlocks, timing, communication-loss response, and restart logic before physical I/O is available.

A small virtual conveyor can reveal mapping, timing, and recovery defects before they reach a real control panel.

Confirm software compatibility before mapping tags

“GX Simulator” can refer to simulation functions associated with different GX Works generations and MELSEC CPU families. OPC products also differ by version and by whether they expose OPC DA or OPC UA. Factory I/O provides driver choices that may not support every combination in the same way.

Record the exact PLC family, GX Works version, simulator component, OPC server product and version, interface type, and Factory I/O version. Then verify that the OPC server can connect to that simulated CPU. Do not assume a connection method that works with a physical Ethernet module will automatically work with a software simulator.

Mitsubishi describes MX OPC as software that exposes MELSEC programmable-controller data through OPC. Newer MELSEC iQ-R hardware can also use an embedded OPC UA server module, but that architecture is different from a PC-hosted server connected to a simulated controller. Keep those paths distinct in design notes and troubleshooting.

Write the data contract before configuring software

Create an I/O list with one row for each signal. Include the Factory I/O tag, Mitsubishi device address, data type, direction, engineering meaning, default state, safe state, update requirement, and owner. The simulation should normally own field-input states, while PLC logic owns actuator commands.

That ownership rule prevents two applications from writing the same point. A simulated photoeye may write a PLC input device, while the PLC writes a motor command that Factory I/O reads. If both sides write one tag, the display may flicker or appear random even though every individual connection is technically active.

Bit devices, words, signed integers, floating-point values, and arrays require explicit type handling. An OPC client may display a value successfully while Factory I/O interprets the wrong type or bit order. Begin with one Boolean point and one word whose changing values are unmistakable. Expand only after direction and scaling are proven.

Build and test the connection in layers

First create a minimal PLC program and run it in the supported GX simulator. Force or toggle a known internal device and confirm the ladder monitor shows the expected state. This establishes that the program, selected CPU, and simulator are operating.

Second, configure the OPC server for that simulated controller. Create only a few test tags. Use the server’s own client or diagnostic view to confirm quality, timestamp, value, and write capability. A value marked “bad” or “uncertain” should be corrected at this layer before Factory I/O is opened.

Third, configure the Factory I/O OPC client and browse or enter the proven tags. Map one simulated sensor and one actuator command. Confirm both directions independently: change the scene input and observe PLC memory, then change the PLC output and observe the scene.

This layered method separates faults. If GX memory does not change, the PLC simulation is the problem. If GX changes but the OPC client does not, inspect server configuration and device addressing. If the OPC server is healthy but Factory I/O is static, inspect client connection, item names, access rights, and tag mapping.

Layer-by-layer verification isolates PLC, OPC-server, and Factory I/O configuration faults.

Account for timing across three independent systems

The PLC scan, OPC server polling, client subscription, and Factory I/O physics update do not occur at the same instant. A sensor pulse shorter than the combined sampling interval can disappear before the PLC observes it. Network or PC loading can add jitter even on a local workstation.

Important events should be designed to survive sampling. A simulated device can hold a state until acknowledged, or PLC logic can latch a detected transition until the sequence consumes it. Lengthening every pulse is convenient for demonstration but can hide edge-handling defects. Match the test behavior to the expected physical sensor and production speed.

Measure effective end-to-end delay rather than assuming the configured OPC update rate is the complete latency. Log the scene transition, OPC timestamp, PLC observation, output decision, and resulting scene action when timing matters to the sequence.

Plan for OPC DA and workstation constraints

Classic OPC DA uses Microsoft COM technology. When all applications run under one Windows account on one computer, setup is usually simpler. Distributed configurations introduce DCOM identity, permissions, firewall, and service-account issues. A connection that works interactively may fail after reboot if the OPC server starts under a different account.

OPC UA uses a different security model with endpoints, certificates, and policies. It avoids DCOM but still requires certificate trust, user permissions, and compatible data models. Use the interface actually supported by the selected software rather than treating DA and UA as interchangeable labels.

Test failure and restart states deliberately

Disconnect the OPC client while the conveyor is active. Stop the PLC simulator. Restart the OPC server. Reopen Factory I/O with outputs previously on. The machine should not resume hazardous motion merely because stale values reappear or a client reconnects.

Define the response to bad quality, lost communication, and startup values. Commands can be forced off, held, or handled by a controlled stop depending on the process. Inputs may need an explicit communication-health bit so the PLC can distinguish a genuine false state from unavailable data.

Also test cold start, warm restart, counter retention, recipe mismatch, blocked sensors, simultaneous arrivals, and operator reset. Document the initial state of every writable tag and the sequence required to enter automatic mode.

Turn the virtual cell into a test harness

Use repeatable acceptance cases: no actuator before start permissives; one count for each product; controlled stop at the target; timeout on a blocked sensor; fault on communication loss; and predictable recovery after reconnect. Tag trends and pass/fail records provide stronger evidence than screenshots of a moving scene.

Mitsubishi controller options can be reviewed in the Mitsubishi Electric collection, with broader controller hardware under PLC & PAC Systems.

OPC is only the transport layer. The engineering value appears when the virtual cell becomes a repeatable test environment for PLC behavior, signal ownership, timing assumptions, fault response, and restart logic that will carry over to the physical machine.