Stop treating the quick fixes as the diagnosis
After a power loss, the failed H2-ECOM and H2-ECOM100 modules still appear in NetEdit, but PLC-link editing in DS returns an error and OPC communication remains down. Three common recovery attempts can hide the failure without locating it.
| Quick fix | Why it fails as a diagnosis | What it actually proves |
|---|---|---|
| Restart the OPC server | A direct PLC-link operation also fails, so the fault is not confined to the SCADA client. | Nothing about module health unless direct communication works afterward. |
| Power-cycle the PLC | The Ethernet module may not have lost power completely, or the same rack and network startup sequence may recreate the fault. | A normal PLC restart does not necessarily produce a cold restart of the module. |
| Reload the same firmware | The unchanged image restores service but does not correct the condition that appears after an outage. | The reload process resets or reinitializes more module state than the attempted power cycle. |
Use a firmware reload once as a controlled production-recovery step if the approved image is already available. Do not turn it into the routine outage procedure: interrupted flashing adds risk, and repeated reloads erase the best opportunity to capture the failed state.
Separate discovery from operational communication
NetEdit visibility does not prove that the PLC communication service is healthy. Device discovery can identify a module through a lower-level network exchange while the configured programming or OPC path depends on a valid IP configuration, an initialized application service, a working backplane interface, and available communication resources.
This split explains the symptom: Ethernet link and discovery are alive, yet a higher-level connection cannot complete. Reloading firmware forces a boot path that can clear volatile sessions, restart network services, reload configuration, and reinitialize the PLC-side interface. The recovery therefore points to failed initialization or communication state, not automatically to defective firmware.
The failed modules are from the H2-ECOM/H2-ECOM100 group. Five H4-ECOM modules and two H0-ECOM modules on the system do not show the same outage behavior. Treat that model grouping as a strong fault boundary: compare rack power, module configuration, network ports, startup order, and firmware strings between failed and working units before changing the sitewide SCADA configuration.
Capture the failed state before resetting it
Do these checks while the module is visible but communication is still down. A reset destroys much of the useful evidence.
- Record the complete error text from the
DSlink editor. The installation report does not include an error code, so the exact message is needed to separate timeout, addressing, connection, and configuration failures. - Record the model and installed firmware string shown by
NetEdit. Do not write “current” in the maintenance log; store the actual displayed value. - Record every module and Ethernet status indicator exactly as labeled on the hardware. Note whether link activity continues during a connection attempt.
- Compare the discovered address and identity with the saved working configuration. A discovered device can still have the wrong address or conflict with another station.
- Check for a duplicate address by inspecting the managed-switch and host address tables, then disconnecting or isolating one suspected device at a time. If the hardware identity associated with an address changes, correct the conflict before resetting the module.
- Test a direct engineering connection with OPC polling paused. If the direct link works only after polling stops, investigate connection load or repeated client reconnection. If it still fails, keep the fault boundary at the module, its configuration, backplane, power, or network path.
- Check the switch port for link transitions and address movement after the outage. A stable physical link with failed application communication supports an initialization or configuration problem.
Restore communication with a controlled cold start
Get production running, then fix the outage behavior properly. Use this sequence during an approved interruption:
- Save the module settings and capture screenshots or exported configuration before changing anything.
- Stop OPC polling to prevent a burst of reconnection attempts while the module boots.
- Remove power from the complete PLC rack and the affected Ethernet module using the equipment shutdown procedure. Do not remove a module from an energized rack.
- Verify that module indicators extinguish and measure the rack supply output. If voltage remains present, find the alternate feed, stored-energy path, or incomplete isolation before calling the action a cold restart.
- Bring the Ethernet switch and upstream network path online first. Wait for the infrastructure to finish booting, then energize the PLC rack.
- Confirm that
NetEditfinds the module with the expected identity and address. Test the directDSlink before restarting OPC polling. - If the direct link still fails and the approved firmware file matches the module, perform the manufacturer-defined firmware load from a stable engineering connection and uninterrupted power source. Do not substitute an image intended for another model.
- After the module reboots, recheck its configuration before restoring OPC communication.
If firmware loading restores the link, log it as temporary recovery. The result shows that deeper reinitialization clears the failed state; it does not show that rewriting the identical firmware corrected the outage trigger.
Verify the whole communication path
Do not release the system when the module merely reappears in NetEdit. Verify each layer in order:
| Layer | Pass condition | Failure direction |
|---|---|---|
| Physical network | Stable link indication and no repeated port transitions | Power, cable, connector, switch port, or startup sequencing |
| Discovery | Correct module identity and configured address in NetEdit
|
Address configuration, duplicate address, or discovery path |
| Engineering connection | The DS link opens and can be edited without the previous error |
Module service, backplane interface, configuration, or connection resources |
| OPC session | The server reconnects without continuous retries | OPC link configuration, session load, or client restart sequence |
| Process data | Known changing values update correctly and quality remains valid | Wrong PLC target, stale data, or incomplete application recovery |
Repeat a controlled outage during a maintenance window using the recorded startup order. Capture module, switch, PLC, and OPC timestamps. A repair is credible only when the system starts without another firmware load.
Remove the condition that makes reloads necessary
Compare failed and unaffected racks as matched sets. Check power-supply behavior during loss and restoration, complete removal of module power, network readiness at rack startup, address uniqueness, saved module configuration, installed firmware strings, switch-port configuration, and OPC reconnection load.
If the H2 units share a supply, rack arrangement, or switch while the H4 and H0 units do not, test that common dependency first. If only one H2 unit fails, swap cables or switch ports during a maintenance window without changing multiple variables at once. A fault that follows the port points toward the network path; a fault that remains with the rack points toward module power, configuration, backplane communication, or the module itself.
Do not normalize firmware flashing as preventive maintenance. Preserve the failed-state records and the known-good configuration so official support can distinguish a startup defect from power quality, configuration corruption, address conflict, or hardware failure.
FAQ
How do I restore an H2-ECOM after a power outage?
Pause OPC polling, fully remove rack and module power, start the network infrastructure first, and then restart the rack. Test the direct DS link before re-enabling OPC; use the approved firmware reload only if the controlled cold start fails.
How do I know whether NetEdit visibility means the module is healthy?
It does not. NetEdit discovery proves that part of the Ethernet interface responds, while successful DS and OPC connections prove that the operational communication services are running.
How do I prove that the Ethernet module was fully power-cycled?
Confirm that all module indicators extinguish and measure the rack supply output after isolation. Residual or alternate power means the action was not a complete cold restart.
How do I check for a duplicate IP address?
Compare the configured address with switch and host address tables, then isolate suspected devices one at a time. A changing hardware identity for the same address identifies a conflict that discovery alone may not expose.
How do I know when to stop troubleshooting and call support?
Stop here if an H2-ECOM or H2-ECOM100 repeatedly requires the same firmware reload, loses saved configuration, will not complete a controlled cold start, or cannot be flashed without interruption risk. Give official support the exact model, displayed firmware string, full DS error, module indicators, power measurements, network captures or switch logs, and the recovery sequence that restored service.