C-more Remote Access Can Extend Panel HMI Control to PCs

C-more Remote Access can put a panel HMI on a PC screen, while C-more programming software itself does not create a PC-based HMI runtime. For a PC that must operate a PLC directly, use a PC HMI application or build a client around a supported PLC communication interface; treat Excel/VBA as a custom integration that needs a suitable data interface and careful command design.

Stop treating the programming tool or OPC server as the PC HMI

Three common approaches fail because they confuse project editing, data access, and operator display:

Do not choose a touch panel just because its editor is available if the requirement is for a Windows application on a networked PC. Conversely, do not discard a panel architecture if local panel operation plus remote viewing/control meets the actual requirement.

Separate the PLC, data server, client, and operator display

Think of the system as four functions rather than one product: the PLC executes machine logic; an Ethernet interface carries communications; a server or driver maps PLC memory into readable and writable data items; and a client renders controls and values for an operator. The PC may host the client, the data server, or both, but each role still needs a configured communication path.

In the described arrangement, the PLC is a DL205 system and the proposed connection uses an ECOM module. The intended data includes input and output points such as X0 and Y0. The exact driver, addressing syntax, write permissions, and compatibility must come from the documentation for the installed PLC, ECOM hardware, server version, and client software. Verify those particulars before adopting a tag scheme.

A server tag is a representation of PLC data, not a separate physical output. Reading an input tag reports the PLC state exposed through the driver. Writing an output-related tag requests a data change; the PLC scan, program logic, interlocks, and output hardware determine what the machine actually does. A direct write to an output point can be overwritten by the PLC program or bypass intended operating logic, so prefer a command/request bit that PLC logic validates and then uses to control the output.

Choose the PC architecture that matches the operating requirement

Use a PC HMI package when the display and operator controls must run as a native PC application. In the 2008 exchange, Lookout Direct was identified as a PC GUI option, while C-more and C-more Micro were identified as panel products. Product names and support status can change, so check current manufacturer documentation before selecting software for a new installation.

Use an OPC or DDE client route when an existing client can consume the interface exposed by the PLC data server. A spreadsheet with VBA is one possible custom client arrangement, but it is not automatically a complete HMI: the macro must connect to the data source, handle read/write results, display communications state, and avoid issuing unsafe commands. Treat it as application development, not a shortcut that removes the need for a client interface.

Consider a C-more panel with remote access when the panel itself can remain the HMI and the PC only needs to view or interact with that panel remotely. This is different from running the C-more project locally as a Windows application. Confirm that the specific panel and software support the needed remote-access features before purchasing or designing around them.

Prove the Excel and OPC data path before adding controls

Keep a spreadsheet experiment small. First prove communication and tag behavior, then add operator controls. Use this sequence:

1. Confirm the PLC is reachable through the ECOM path and identify the correct driver and PLC address format from the installed product documentation.
2. Configure the server and verify that a known input such as X0 reads the expected state. Change the physical input under controlled conditions and confirm the displayed value follows.
3. Confirm which client interface the server exposes and which interface the Excel/VBA implementation can consume. Configure that connection and test a read before attempting any write.
4. Choose a non-hazardous test point or a PLC command bit designed for testing. Issue one deliberate write and check the client result, server status, PLC value, and machine response independently.
5. Only after the test succeeds, add buttons and status indicators. Display communications loss or stale data as an abnormal state, and prevent a button from appearing to confirm a command solely because it was clicked.

Do not assume that naming a tag after Y0 proves the client is writing the intended PLC location. Compare the server’s configured address with the PLC program and observe the PLC value during the test. If Excel cannot connect to the server through an available interface, changing the button macro alone will not fix the missing client/server path.

Use remote access with measured latency limits

Remote access can avoid building a separate PC GUI, but it adds display and interaction delay. One reported setup on a local machine network used a 500 ms screen refresh, 50 ms object refresh, and 90% graphic quality. The operator reported about 500 ms from a remote option change to confirmation at the remote end. Those figures describe that setup, not guaranteed settings or performance for another panel, network, or project.

Changing remote-end settings to reduce lag can increase network traffic and make the local C-more panel lag. Lower graphic quality may reduce transmitted display data, but readability and response must be checked on the actual screen. Object count, screen complexity, panel load, network path, and whether the connection crosses a VPN or the internet all affect observed behavior; measure the deployed route rather than extrapolating from a local network test.

Remote access was used in the reported case primarily for periodic monitoring, not as the sole means of control. That distinction matters: a delayed display or command confirmation is not suitable for functions requiring immediate operator feedback or time-critical response. Keep local controls available where the process requires them, and do not treat remote desktop interaction as a substitute for a designed safety function.

Verify the command, feedback, and fallback behavior

Test the whole path rather than relying on a successful tag browse or a button animation. Confirm the client command reaches the intended PLC data item, PLC logic accepts or rejects it as designed, and independent status feedback reflects the resulting machine state. Verify that communications interruption, stale values, and client restart do not leave controls displaying an assumed successful command.

• Check input indications against actual PLC input state.
• Check a test write at the server/client, PLC program, and physical output or downstream device.
• Test rejected commands and interlocks so an HMI write cannot bypass the PLC’s operating rules.
• For remote access, compare local-panel response with PC response while changing refresh and image-quality settings; record acceptable values for the real network route.
• Verify the operator can distinguish a requested state from confirmed machine feedback.

Keep the initial restore temporary if production needs a workaround: a local panel or a tested PC client may restore visibility or limited operation, but it does not resolve an unverified tag map, unsafe direct output writes, or excessive remote latency. Make the permanent repair the validated communication configuration and PLC-side command/feedback design.

FAQ

Stop if tag writes affect an unintended output, PLC interlocks are unclear, or remote delay makes operator feedback unreliable. Escalate unresolved driver, addressing, or product-compatibility questions to the official support channel for the installed PLC, communication hardware, and HMI/server products.