On this DL405 installation, downloading the project to the C-More restored fast screen updates and push-button response through the observed Saturday-to-Monday interval, but the cause remains unresolved. Ethernet was suspected because response slowed when the C-More, PLC, and notebook were connected together; a serial test was proposed but not reported as completed.
Record the delay before changing the connection
Do not start by moving communication cables or changing several settings at once. First establish a repeatable baseline so a temporary improvement does not get mistaken for a root-cause fix.
- With the current wiring and operating state, time a representative screen value from a known PLC change to its visible update. Separately time a push-button press to the expected PLC response.
- Repeat each observation several times and record the slow and fast results, not just an average. Note whether the delay affects all screens and buttons or only particular objects.
- Record which devices are connected, whether a notebook is online or transferring a project, and whether the delay changes when that activity stops.
If the delay is reproducible only while the notebook is connected or communicating, investigate network traffic and connection behavior next. If it persists with the notebook disconnected, continue with the same baseline and check the HMI project and PLC-side response path as well; removing one device does not rule out a persistent network or configuration problem.
Use a project download only as a temporary restore
Downloading the C-More project restored fast operation in this case. Treat that as a recovery action, not proof that the PLC, Ethernet card, or HMI application was the root cause. A download can change the state of the HMI runtime or refresh its project state, while leaving an underlying network fault untouched.
- If production needs a temporary restore and the established site procedure permits it, capture the baseline first, then download the known-good project to the C-More.
- Repeat the same screen-update and button-response measurements immediately afterward.
- Keep the same cabling, PLC state, and notebook connection during the comparison. If response improves, record how long it remains fast and whether the change survives normal operating conditions.
If the response improves only after the download, retain that finding but continue testing. If the delay returns, the recurrence is important evidence: compare the HMI project state, communication load, and network diagnostics at the time of failure. Do not repeatedly download as the permanent repair without identifying what changes between fast and slow operation.
Check the Ethernet path while the delay is present
Ethernet communication time includes more than the wire rate: the HMI must issue requests, the PLC or communication interface must service them, and responses must return without excessive retries or queuing. A notebook added to the same network can coincide with increased traffic or a transfer, but the observation alone does not show that ordinary notebook presence causes the delay.
| Observed condition | What it points toward | Next check |
|---|---|---|
| Delay appears during notebook communication and clears when it stops | Traffic load, transfer activity, or a network-path issue | Compare switch-port counters, link status, and traffic during slow and fast periods. |
| HMI remains slow with the notebook disconnected | HMI project/runtime, PLC response, or persistent Ethernet-path issue | Compare affected and unaffected screens or test a controlled alternate path. |
| Several HMI objects update slowly together | Shared communications or controller response path | Check network diagnostics and PLC communication load before editing individual objects. |
| Only one button or screen element is delayed | Object configuration or the PLC logic/action associated with that object | Trace that object's tag and command path separately. |
During a slow period, inspect the network equipment's available port statistics and diagnostics: link state, CRC or other receive errors, dropped packets, and traffic rate. Compare the PLC communication interface and the switch port serving the HMI, then compare readings with a fast period. Check for duplicate IP addresses, incorrect addressing, poor cabling or connectors, and a port negotiating differently from its intended configuration. Use the actual switch and interface diagnostics; do not infer a bad ECOM card from response time alone.
If error counters rise or the link changes state, correct the physical link or network configuration before tuning the HMI. If counters remain clean, that does not prove the path is healthy; continue by isolating the path and checking controller/HMI request behavior. Avoid changing network speed or duplex settings without confirming the supported configuration at both ends.
Separate the DL405 behavior from the HMI project
The reported contrast is specific: the slow response was associated with a DL405 and its possible ECOM Ethernet interface, while the operator did not see the same behavior on DL205 systems, DL250/DL260 systems, or other PLC brands used with C-More HMIs. Those comparisons make the controller/interface path worth testing, but they do not isolate it unless the HMI project, requested data, network conditions, and operating state are comparable.
- During a slow period, check whether the PLC value itself changes promptly in an independent, approved PLC diagnostic or programming view. If the PLC value changes late, investigate PLC logic, scan/loading conditions, or the data source before blaming HMI display refresh.
- If the PLC value changes promptly but the C-More display lags, focus on the HMI communications path, project settings, and Ethernet interface. Compare the same tag on an unaffected screen or equivalent system, if available.
- Compare the C-More project and requested data workload against a known fast configuration. Look for unnecessarily frequent reads, excessive displayed tags, or objects that request data the operator does not need. Use the software's actual configuration and diagnostics rather than assuming a particular scan-time parameter.
If the fault consistently follows the DL405 Ethernet path under a controlled comparison, preserve the project, wiring details, communication settings, and diagnostic readings for the next test. If the fault follows the C-More project or a specific object, correct that configuration rather than replacing the PLC interface.
Run a controlled serial comparison before changing production wiring
A serial connection may help isolate whether the Ethernet route contributes to the delay, but it is not automatically faster. Serial has its own supported-port, driver, baud-rate, and workload limits; the Ethernet path may be the faster option when configured and operating correctly. The proposed arrangement—C-More to the DL450 by serial while retaining Ethernet for programming—was a test idea, not a verified fix.
- Confirm from the applicable C-More and PLC documentation that the exact controller, serial port, cable/pinout, and driver are supported. Record the communication settings at both ends.
- At a safe test opportunity, use the same C-More project and representative tags, and change only the HMI-to-PLC communication path. Keep the PLC logic and test conditions stable. Do not remove or repurpose the Ethernet connection needed for programming without a planned recovery path.
- Repeat the baseline measurements for screen updates and button actions. Record serial and Ethernet results separately, including whether the programming connection or other network activity was active.
If serial is consistently responsive while Ethernet is slow under comparable conditions, the Ethernet route or its configuration becomes the priority for diagnosis; that result does not by itself prove the ECOM card is defective. If both paths are slow, investigate the HMI project, PLC-side response, and the actual button/tag logic. If serial is slower, restore the supported Ethernet setup and use the diagnostics rather than treating serial as an upgrade.
Restore the proven path and verify the permanent repair
After the comparison, return to the intended production connection unless the serial path has been validated for the required workload and approved for the installation. Keep temporary recovery separate from permanent repair: a project download can get the line responding again, while the permanent correction must address the condition that produces the delay.
- Apply one corrective change at a time—for example, repair a confirmed cable or port fault, correct a verified addressing/configuration error, or reduce unnecessary HMI requests identified in the project.
- Repeat the original screen-update and button-response tests under normal connected conditions, including the notebook connection if it is part of normal operation.
- Observe operation through the conditions in which the delay previously appeared. Compare network counters and response measurements with the recorded baseline, and document the final wiring, settings, project revision, and results.
Consider the repair verified only when the same update and push-button tests remain responsive in normal operation and the relevant diagnostics no longer show the identified fault. If the symptom returns, capture diagnostics while it is slow; do not use a fresh project download to erase the comparison before recording the failure state.
FAQ: Decide whether to change the C-More connection
Can I connect the C-More to a DL450 by serial to make buttons respond faster?
Possibly, but serial is a diagnostic alternative, not a guaranteed speed improvement. Confirm the supported port, cable, driver, and settings, then compare timed button and screen response using the same project and PLC conditions.
Does downloading the C-More project fix the slow response?
It restored fast updates and button response in the reported installation, but that does not identify the root cause. Use the download as a temporary restore and track whether the delay returns under normal network conditions.
Can a notebook on the same Ethernet network slow the HMI?
It can add traffic or transfer activity, but its presence alone does not prove network congestion. Compare HMI response and switch/interface diagnostics with the notebook connected, communicating, and disconnected.
Does slow C-More response prove the DL405 or ECOM card is faulty?
No. First determine whether the PLC value changes promptly, inspect Ethernet link/error diagnostics, and compare a controlled serial path. A serial-only improvement implicates the Ethernet path but does not isolate the ECOM card as the failed component.
When should I stop troubleshooting and contact official support?
Stop changing production communications if the supported wiring or driver is unclear, a test risks losing PLC/HMI access, or the delay persists after controlled isolation. Provide official AutomationDirect support with the controller and interface details, HMI project/driver settings, wiring topology, timed results, and diagnostics captured during the slow condition.