Two simulators, one PC, and the screen objects sit dead while the soft PLC scans happily beside them. The instinct is to build a bridge between them — a shared file, a CSV, some kind of handshake. Skip it. The panel simulator and the soft CPU already speak the same protocol over a socket, and the only thing standing between them is the device connection defined inside the panel project.
Try These First, Then Stop
These are the fixes that eat a shift. Each one fails for a structural reason, not a settings reason.
| Quick fix | Why engineers reach for it | Why it fails |
|---|---|---|
| Build a shared "simulator file" both tools read and write | Looks like a simple mailbox between two PC programs | Neither simulator exposes a documented file-based tag mailbox. The panel's data engine is a protocol driver bound to a configured device, and there is no clock to make a file read atomic against a PLC scan — you would get torn words and stale bits even if a hook existed. |
| Hand-toggle values in the simulator's object/value pane | Proves the graphics render | Never exercises the tag database, address typos, data type mismatches, or the interlock logic. Every fault it would have caught still ships to the panel. |
| Point the panel project at the real PLC's IP address | The project already has it typed in | The soft CPU does not answer on that address. You get read timeouts, and the address stays in the project for the next download. |
| Install a virtual COM pair and run Modbus RTU between the tools | Serial feels lower-risk than TCP | Check whether the Sim CPU maps its serial ports to Windows COM ports at all. If it does not, the path is dead before you start — and you have added two drivers to uninstall. |
| Open every firewall rule | "It must be blocked" | Loopback traffic is not filtered by the Windows firewall in a normal configuration. If the connection fails on 127.0.0.1, the firewall was never the cause. It becomes relevant only when you bind to the PC's physical NIC address. |
What Actually Moves the Data
The Do-more Simulator is a soft CPU with a real protocol stack sitting on a Windows socket. It does not care whether the client asking for memory is the programming software, a data-collection tool, or a panel. The C-more simulator runs the panel's screen engine plus the same communications driver the physical panel uses, so it behaves like a client asking for the same memory blocks over the same protocol.
Put both on one machine and the loopback interface carries the frames — no cable, no switch, no NIC required for the transport itself. The single place the target address lives is the PLC/device entry inside the panel project. Change that entry to the loopback address, and the panel simulator polls the soft CPU. Change it back before download, and it polls the real CPU. That is the entire mechanism.
One caveat on binding: some HMI runtimes bind their driver to a physical adapter rather than to the loopback stack. If the panel simulator refuses 127.0.0.1, use the PC's live NIC address instead, or install the Microsoft KM-TEST loopback adapter, give it a static address, and bind to that.
Bring Up the Sim CPU and Prove It Scans
Get the PLC side provably alive before you touch the panel project. Half the "C-more won't connect" calls are a soft CPU sitting in PROGRAM mode.
- Open the project in Do-more Designer and switch the link to the simulator CPU rather than a hardware CPU.
- Read the address and port the simulator reports in its status or connection dialog. Write them down — that is the pair you will type into the panel project. Do not assume a default.
- Put the Sim CPU in RUN.
- Add a heartbeat so you can tell "connected" from "connected and scanning":
- Watch
HMI_Heartbeatincrement in Data View. If it is frozen, the CPU is not scanning and nothing downstream matters. - Confirm the socket exists from a command prompt and match the PID to the simulator process in Task Manager → Details:
ping 127.0.0.1
netstat -ano -p udp
netstat -ano -p tcp | findstr /i "listening"
Point the Panel Simulator at the Sim CPU
- Open the panel project in the C-more programming software and go to the panel/device setup where the PLC connection is defined.
- Set the connection type to Ethernet and select the Do-more protocol driver. If the project is currently set to a DirectLogic or Modbus driver, understand that you are changing the addressing model, not just the transport — see the pitfalls below.
- Enter
127.0.0.1as the PLC address and the port the simulator reported. Save the project. - Match the tag database. If your version of the panel software offers an import from the Do-more project file, use it — hand-typed nicknames are the single biggest source of "connected but blank" objects. Otherwise verify every address character by character, including data type and signed/unsigned.
- Launch the panel simulation and open its status or error display before you look at the screens.
Get it running, then fix it properly: bring up one test screen with the heartbeat, one indicator, and one pushbutton first. Do not debug forty screens at once.
Verify the Link End to End
- Live poll, not cached values. The heartbeat numeric must count on the panel screen. A static number means the driver connected once and stopped, or you are looking at a default value.
- PLC to panel. Force a bit in Data View and watch the indicator change on the simulated screen.
- Panel to PLC. Press a screen pushbutton and watch the bit set in Data View. Confirm a momentary object drops on release — that is a write path fault you will otherwise find on commissioning day.
- Range and type. Write a value beyond the object's configured limits from the PLC side and confirm the object clamps or flags as designed.
- Read the error banner, not the object. A communications error means transport: wrong address, wrong port, CPU stopped. An object-level error with a healthy link means addressing: wrong tag, wrong data type, or a tag that does not exist in the Sim CPU.
Pitfalls That Bite on the Next Download
-
The loopback address ships to the panel. Keep a separate simulation copy of the project, or make restoring the real PLC IP the last edit before every download. A panel in the field pointed at
127.0.0.1looks exactly like a dead PLC. - Simulator memory resets. Retentive ranges do not survive a Sim CPU restart the way battery-backed CPU memory does. Recipe values, alarm counters, and totalizers reload from defaults — do not read that as an HMI fault.
- No physical I/O. The soft CPU has no modules, so discrete inputs stay off forever. Drive screen logic from simulated inputs or a dedicated test rung, and remove that rung before it reaches the machine.
- Timing means nothing here. The simulator scans at PC speed, not CPU speed, and loopback latency is far below Ethernet latency. Never tune alarm debounce, screen refresh, or handshake timeouts against the simulator.
- Driver change is an addressing change. Converting a project built for a DirectLogic PLC over to the Do-more driver invalidates the old address model. Budget time to re-map every object rather than expecting an in-place switch.
- Two clients, one CPU. Designer and the panel simulator both hold sessions to the Sim CPU. That is normal, but if one drops, close and relaunch that client rather than restarting the CPU and losing your forced values.
Stop here if the Sim CPU scans, the socket is confirmed with netstat, and the panel simulator still reports a transport error on both the loopback address and the NIC address — that is a driver or version compatibility issue between the two software packages, not a configuration mistake you can fix at 2 a.m. Capture the exact software version of both packages, the protocol driver selected, the address and port you used, and a screenshot of the simulator error, then open a ticket with AutomationDirect technical support. Run the shift on the panel-simulator value pane for graphics work until you have an answer.
FAQ
What happens if I point the C-more simulator at 127.0.0.1 and it still times out?
The panel driver is likely bound to a physical adapter instead of the loopback stack. Retry with the PC's live NIC address, and if the machine has no active adapter, install the Microsoft KM-TEST loopback adapter, assign it a static address, and use that address in the panel project.
What happens if I leave the simulation IP in the project and download to the panel?
The panel boots, renders every screen, and reports a communications error because nothing answers at that address — it looks identical to a failed PLC or a dead network port. Keep a separate simulation copy of the project, or make restoring the real PLC address the final edit before any download.
What happens if the Do-more Simulator is in PROGRAM mode while the panel simulator polls?
The link stays up and reads succeed, but values never change because the logic is not scanning. Add a self-incrementing heartbeat word to a test screen — a frozen heartbeat with no error banner means PROGRAM mode, not a comms fault.
What happens if my panel project was originally built for a DirectLogic PLC?
Switching the driver to Do-more changes the addressing model, not just the transport, so existing object addresses will not resolve against Do-more nicknames. Plan on re-mapping every object, and use the tag import from the Do-more project file if your version of the panel software supports it.
Can the two simulators exchange data through a shared file instead of a network connection?
No, and you do not need one. Neither tool exposes a documented file-based tag mailbox, and a file handoff has no mechanism to keep reads atomic against the PLC scan; the supported path is the panel project's Ethernet device entry pointed at the soft CPU's address and port.