Why an HMI simulator shows no live PLC data

The simulator is an offline screen test by design

Two test jobs sound alike and they are not interchangeable.

• An offline screen test checks navigation, object appearance and behavior driven by test values, all on the PC. Vendor documentation describes the PC simulator as a way to catch project errors before the hardware arrives, and that is the point: the cheapest place to fix a mistyped tag address is the desk, not the panel.
• A live PLC test runs the downloaded project on a panel, which opens its own session to the controller through the selected driver and the controller's network address.

The simulator exercises the project interface on the PC and stops there. A screen can look correct in simulation while the driver selection, the controller address, the tag reference or the network path is wrong, and none of that surfaces until a panel tries to read real data. Treat every value you see in the simulator as a test value the software supplied, never as a read of the controller. No amount of restarting the simulator, re-entering the PLC address or forcing values turns it into a runtime; the live test needs a panel.

Symptoms and what each points to

Match what you see against this list before changing anything.

• Simulator screens run but values never change. Expected. The simulator supplies test values and reads nothing, so move the live test to a panel.
• Panel downloaded, every value blank or frozen, communication error on screen. The session is failing: driver selection, controller address or the network path. Start with the ping in the worked example below.
• The panel's offline indicator stays red while a TCP port test from your PC passes. Those are two different questions, and why an offline link indicator stays red when the TCP port test passes walks that one down.
• One object blank while its neighbors update. That object's tag address or data type; why an HMI numeric display shows nothing starts at the tag address.
• Strings blank while numbers update. Byte order in the string tag; why a string object comes up blank and the byte swap fixes it.
• Only the objects bound to a second controller sit dead. That points at the connection budget; the triage list below gives the number to check.

Check the project before the panel

The bench session stays short only if the project is clean. In the programming software:

1. Confirm the project targets the panel family and model you will download to; the software's help lists compatibility and the available device drivers.
2. Confirm the PLC device configuration selects the driver that matches the controller's protocol family, an EtherNet/IP driver for an EtherNet/IP controller, for example. Ethernet on both ends is not a driver match; serial and Ethernet variants for the same controller family are separate entries.
3. Enter the controller's IP address as it will be on the test network, not the office network.
4. Open every object that should show live data and check its tag reference, data type and display format against the controller's tag definition.
5. Run the simulator once at the end of this pass and fix what it finds, so the panel session is spent on the live path, not on typos.

If you are still choosing the panel itself, driver support and bench time decide more than screen size; choosing an HMI panel by testing startup and runtime first covers the checks worth running before anything is mounted.

Example: bench test with the panel at 192.168.1.20 and the PLC at 192.168.1.10

The inputs, and where each comes from:

• Panel address 192.168.1.20 with subnet mask 255.255.255.0, entered in the panel's Ethernet setup screen. These are example values for this bench build.
• Controller address 192.168.1.10 with mask 255.255.255.0, taken from the controller's Ethernet channel configuration.
• Bench PC at 192.168.1.50; all three devices on one unmanaged switch.
• One numeric object with its update rate set to 500 ms, so you know how long an update should take.
• One spare integer tag in the controller, used read-only for the first pass.

The rule in words: two IPv4 addresses exchange packets on one subnet without a gateway when each address ANDed with its mask gives the same network number. The ping then proves the path, and a tag comparison proves the data.

The arithmetic:

• 192.168.1.20 AND 255.255.255.0 = 192.168.1.0
• 192.168.1.10 AND 255.255.255.0 = 192.168.1.0

Both give 192.168.1.0, so panel and controller sit on one subnet: one switch between them, no default gateway. Had the controller been at 192.168.2.10, its network number would be 192.168.2.0, different from the panel's 192.168.1.0; the panel would then need a default gateway, and a firewall or VLAN between the devices would need the ports assigned to EtherNet/IP open, TCP 44818 for explicit messages and UDP 2222 for implicit I/O.

Run it:

1. From the PC, ping 192.168.1.10. Four replies, each under 1 ms with zero loss, is a normal bench result and proves the path exists.
2. Download the project. Prove the panel runs the new one by putting a temporary version label or test screen on the first page.
3. With the machine in a safe state, read the spare tag on the panel and in the controller software, then change it from 0 to 47 in the controller.
4. Expect the panel to display 47 within three updates: 3 × 500 ms = 1.5 s.

Result: network numbers match at 192.168.1.0, the ping replies in under 1 ms, and the panel shows 47 within 1.5 s of the change. The live path works end to end.

Decision: the handover passes when all three checks pass. Fail the subnet test and fix the mask or add a gateway; fail the ping and fix the cable, the address or a duplicate IP; fail the tag and work the triage list below. Keep the first session read-only or on the spare tag; write to an output or a motion tag only in a controlled commissioning state, when you know what the write will do.

If values stay blank after download

Work down in this order and change one thing at a time:

1. Path. Ping the controller from the PC again. A timeout sends you to cabling, the address or the mask; nothing in the project fixes a dead path.
2. Driver. Confirm the device configuration names the driver that matches the controller family actually on the network, and that the address in that configuration is the controller's real address.
3. Tags. Compare a failing object's tag reference and data type with the controller's tag definition. One dead object beside live neighbors is an object problem.
4. Connection budget. If only the objects from a second controller are dead, count the panel's connections against the limit printed in your driver documentation; one vendor's EtherNet/IP manual caps a single HMI device at 8 parallel PLC connections, and yours prints its own number.
5. Diagnostics. Panels report communication status on a diagnostics screen or through the programming software; read what it says before drawing conclusions about addresses.

After each fix, re-download and repeat the spare-tag test from the example before moving on.

The decision

Recommendation: treat the simulator as a screen check only, and gate the live handover on three passes: matching subnet math, a ping reply from the controller, and one noncritical tag on the panel that follows a change you made. Spend your time in the project up to that gate, and on the network and driver after it. If any of the three fails, fix that layer before touching the project again, and repeat the whole gate after each fix. One bench session covers the gate, and it is the difference between a screen test and a working panel.

Questions