A LabVIEW HMI using the DNET-UDP driver can initially communicate with a DL-05 through an H0-ECOM100, then lose the link unpredictably. DirectSOFT 5 remains able to view and edit the PLC, while HMI recovery may require cycling PLC power and reseating the Ethernet module. These observations narrow the fault domain, but the available evidence does not establish a permanent product-specific fix.
Known failure pattern
| Observation | Engineering implication |
|---|---|
| LabVIEW communication works after connection | The basic addressing and DNET-UDP path can operate before the failure. |
| The HMI link fails after an unpredictable interval | The symptom is intermittent rather than a repeatable initial-configuration failure. |
| DirectSOFT 5 can still view and edit the DL-05 | The PLC remains reachable through at least one communication path. This does not prove that the HMI driver session or module state is healthy. |
| Recovery has required PLC power removal and H0-ECOM100 reseating | Recovery may involve more than restarting the PLC, but the evidence does not distinguish an electrical connection problem from a module, session, driver, or host-computer state problem. |
| The installation was new and firmware was believed current | Firmware status is unverified; installation date alone cannot confirm the installed revisions. |
Separate confirmed behavior from hypotheses
The confirmed fault is limited to the LabVIEW DNET-UDP communication link. Continued DirectSOFT 5 access argues against treating the event as a complete PLC or Ethernet outage. It does not identify the failed layer because the engineering software and HMI may use different sessions, drivers, or traffic patterns.
Possible fault domains include the LabVIEW host, the DNET-UDP driver session, network transport, the H0-ECOM100, and the module-to-PLC connection. These are diagnostic hypotheses, not established H0-ECOM100 behaviors. The report supplies no packet trace, module status, firmware identifiers, network topology, error code, or comparison showing whether power cycling alone restores service.
Use the recovery response as the decision path
| Controlled test result | Next investigation |
|---|---|
| Restarting only the LabVIEW application restores communication | Concentrate on application and driver session handling. |
| Restarting the host computer restores communication | Investigate host networking and driver state before disturbing PLC hardware. |
| Cycling PLC power restores communication without reseating the module | Capture PLC and module state before the cycle; the evidence does not show which device state was cleared. |
| Only reseating the H0-ECOM100 restores communication | Inspect the module connection and distinguish a repeatable reseat effect from coincidental recovery. |
| DirectSOFT 5 and the HMI fail together | Expand the investigation to the shared network, PLC, power, and H0-ECOM100 path. |
Run a controlled diagnostic sequence
- When the HMI link fails, preserve the failed condition. Record whether DirectSOFT 5 can still view and edit the PLC and whether other communication clients remain connected.
- Restart only the LabVIEW application and its DNET-UDP communication session. Record whether this restores the link.
- If the link remains down, restart only the HMI computer. Do not cycle PLC power or reseat the module during this test.
- If the failure persists, test PLC power cycling without removing the H0-ECOM100. This resolves the unanswered question of whether reseating is actually required.
- Reseat the module only with power removed and only after documenting the preceding results. Inspect the connector and module seating while it is accessible.
- Read and record the actual PLC, H0-ECOM100, DNET-UDP driver, LabVIEW, and operating-system versions. Do not substitute installation date for firmware verification.
- Capture network traffic during normal operation, the transition into failure, and one recovery attempt. Compare whether the HMI continues sending requests, whether replies stop, and whether DirectSOFT traffic still receives responses.
Define verification before declaring a permanent fix
A successful recovery is not yet a permanent correction. Change one fault-domain variable at a time, then operate through the interval and workload that previously produced the random loss. Verify that LabVIEW values continue updating, commands receive valid responses, DirectSOFT 5 access remains available, and no PLC power cycle or module reseat is required.
If the event cannot be reproduced under controlled observation, retain the version inventory, packet capture, exact recovery step, and failure timestamps. Those records are necessary to distinguish a driver or host problem from an H0-ECOM100 or module-connection problem. The evidence does not support replacing hardware, changing a module switch, or declaring a firmware defect without those results.
FAQ
Why can DirectSOFT 5 communicate when LabVIEW DNET-UDP cannot?
It confirms that the PLC remains reachable through at least one path, but it does not validate the LabVIEW driver session. Compare both clients during the same failure and capture their network traffic before assigning the fault to the PLC or H0-ECOM100.
Does an H0-ECOM100 need to be reseated after every DNET-UDP link loss?
The evidence shows that reseating was used during recovery, not that it is required. Test application restart, host restart, and PLC power cycling separately before reseating the module.
Does a recent installation prove the DL-05 and H0-ECOM100 firmware is current?
No. Record the actual PLC and module firmware identifiers, along with the DNET-UDP driver, LabVIEW, and operating-system versions, before evaluating compatibility or requesting support.