Factory I/O conveyor model linked to a Mitsubishi PLC simulation

Connecting GX Simulator to Factory I/O Through OPC

A stable Mitsubishi virtual commissioning setup requires more than matching addresses. This guide explains the GX Simulator–OPC–Factory I/O data path, namesp...

Virtual commissioning becomes useful when the simulator behaves like a controlled machine rather than a disconnected animation. For Mitsubishi projects, that means building a traceable path from GX Simulator device memory, through an OPC server, into Factory I/O tags.

The goal is not merely to make a conveyor move. It is to prove address ownership, signal direction, sequence behavior, fault handling, and restart logic before physical I/O is available.

Virtual conveyor scene used for Mitsubishi PLC commissioning

A small conveyor model can expose mapping and sequence errors before they reach a real panel.

Define the data contract first

Create an I/O list that states each Factory I/O signal, Mitsubishi device address, data type, read or write direction, default state, and safe state. Inputs such as start buttons and photoeyes should be written by the simulation and read by PLC logic. Motor and emitter commands should flow in the opposite direction.

A typical FX example might map inputs to X devices and outputs to Y devices, but server and simulator drivers may expose these through different tag syntax. Confirm the exact naming convention with one known bit before importing a full list.

Build the connection in layers

Start GX Works and the matching simulator, download a minimal program, and place it in RUN. Configure the OPC server for the simulated CPU and create a small group of tags. Verify live changes in the OPC client view before opening Factory I/O. Only after that layer works should the Factory I/O OPC client subscribe to the tags.

OPC tag configuration linking Mitsubishi device addresses to simulation signals

Layer-by-layer testing separates PLC, OPC, and scene configuration faults.

Timing and state matter

OPC update rate, PLC scan time, and Factory I/O physics timing are independent. A short simulated sensor pulse can disappear between subscriptions. Latch important events in the PLC, lengthen test pulses, or choose an update rate appropriate to the sequence.

Also test cold start, warm restart, communications loss, and counter reset. Outputs should not resume motion merely because the simulator reconnects with old state. Establish permissives and a deliberate start sequence.

Mitsubishi hardware options can be reviewed in the Mitsubishi Electric collection, with broader controller choices in PLC and PAC systems.

Use simulation as evidence

Record expected steps and acceptance criteria: no output before start, one count per product, controlled stop at the target, safe response to blocked sensors, and predictable recovery. Screenshots alone are weak evidence; tag trends and repeatable test cases are more useful.

Author opinion: OPC is a bridge, not the commissioning objective. The real payoff comes when the virtual cell becomes a repeatable test harness for PLC behavior, naming conventions, and recovery logic that will survive the move to real hardware.

Connecting GX Simulator to Factory I/O Through OPC

A stable Mitsubishi virtual commissioning setup requires more than matching addresses. This guide explains the GX Simulator–OPC–Factory I/O data path, namespace design, scan timing, validation, and...

Virtual commissioning becomes useful when the simulator behaves like a controlled machine rather than a disconnected animation. For Mitsubishi projects, that means building a traceable path from GX Simulator device memory, through an OPC server, into Factory I/O tags.

The goal is not merely to make a conveyor move. It is to prove address ownership, signal direction, sequence behavior, fault handling, and restart logic before physical I/O is available.

Virtual conveyor scene used for Mitsubishi PLC commissioning

A small conveyor model can expose mapping and sequence errors before they reach a real panel.

Define the data contract first

Create an I/O list that states each Factory I/O signal, Mitsubishi device address, data type, read or write direction, default state, and safe state. Inputs such as start buttons and photoeyes should be written by the simulation and read by PLC logic. Motor and emitter commands should flow in the opposite direction.

A typical FX example might map inputs to X devices and outputs to Y devices, but server and simulator drivers may expose these through different tag syntax. Confirm the exact naming convention with one known bit before importing a full list.

Build the connection in layers

Start GX Works and the matching simulator, download a minimal program, and place it in RUN. Configure the OPC server for the simulated CPU and create a small group of tags. Verify live changes in the OPC client view before opening Factory I/O. Only after that layer works should the Factory I/O OPC client subscribe to the tags.

OPC tag configuration linking Mitsubishi device addresses to simulation signals

Layer-by-layer testing separates PLC, OPC, and scene configuration faults.

Timing and state matter

OPC update rate, PLC scan time, and Factory I/O physics timing are independent. A short simulated sensor pulse can disappear between subscriptions. Latch important events in the PLC, lengthen test pulses, or choose an update rate appropriate to the sequence.

Also test cold start, warm restart, communications loss, and counter reset. Outputs should not resume motion merely because the simulator reconnects with old state. Establish permissives and a deliberate start sequence.

Mitsubishi hardware options can be reviewed in the Mitsubishi Electric collection, with broader controller choices in PLC and PAC systems.

Use simulation as evidence

Record expected steps and acceptance criteria: no output before start, one count per product, controlled stop at the target, safe response to blocked sensors, and predictable recovery. Screenshots alone are weak evidence; tag trends and repeatable test cases are more useful.

Author opinion: OPC is a bridge, not the commissioning objective. The real payoff comes when the virtual cell becomes a repeatable test harness for PLC behavior, naming conventions, and recovery logic that will survive the move to real hardware.

Leave a comment

Please note, comments need to be approved before they are published.