A T1H-EBC100 slave that ERM Workbench lists as offline with a MAC of 00 00 00 00 00 00, while the label reads 00.E0.62.40.B8.2E, is a failed module. The MAC is set at the factory, so a module that reports all zeros has lost or corrupted its identity. On this ERM100 network (five T1H-EBC slaves and one T1H-EBC100), replacing the module returned the slave to normal operation. Before the swap, several other fixes are worth ruling out, because each looks reasonable and none of them works.
Skip these fixes: they do not repair a zero MAC
Night-shift instinct is to treat an offline slave as a network fault. With a zero MAC, the fixes below burn time.
| Quick fix | Why it fails on this symptom |
|---|---|
| Power-cycle the base and the ERM100 | The zero MAC is what the module reports after boot. A cycle only helps if the fault is a transient lockup; a burned-in identity that reads back as zeros does not recover. |
| Re-download the ERM configuration | The ERM cannot match a configured slave to a module that answers with an all-zero identity. The configuration is not the problem. |
| Type the label MAC into the slave entry | The module still answers as 00 00 00 00 00 00, so the configured value never matches. |
| Swap the patch cable or switch port | The physical layer is already healthy: 100 MBIT is solid and LINKED ACTIVITY is flashing. |
| Update firmware | A firmware update needs a module that responds normally. A module that cannot present its own MAC is not a firmware-update candidate. |
| Hunt for a network fault elsewhere | One slave reading zeros while five others and the ERM100 run is a single-module fault, not a network-wide one. |
Read the LEDs before you condemn the module
The LED pattern on the failed T1H-EBC100 shows that power, link, and the Ethernet PHY are alive. The failure is in the module's identity or its communication stack.
| LED | State observed | What it tells you |
|---|---|---|
| MODULE GOOD | Solid green | Module power and self-test pass. Base power is not the issue. |
| LINKED ACTIVITY | Flashing | Link is up and frames are moving. The cable and switch port are working. |
| 100 MBIT | Solid | Link negotiated at 100 Mbit. |
| ERROR-Serial TX / RX | All three off | No serial error indication. The fault does not show up as a serial-port error on the module. |
Healthy LEDs with an offline status and a zero MAC point at the module. Do not let a solid MODULE GOOD talk you out of the swap.
Understand why a zero MAC takes the slave offline
ERM100 slave addressing depends on the ERM finding the module it was configured for. If the slave entry is matched by MAC, a module that reports zeros can never be matched, and Workbench shows it offline. Even when the physical layer is fine, the identity handshake fails.
In this installation the module was most likely damaged during a swap with a working unit. The rack also mixed obsolete T1H-EBC slaves with a T1H-EBC100, so modules were being pulled and reseated during troubleshooting. Prying modules out of the base and flexing them during removal is the usual way a working slave ends up damaged. Log that failure mode in the incident report rather than treating the network as suspect.
Confirm the failure with a second query path
Confirm the fault from a second tool before you spend a module. ERM Workbench is primarily for configuring the ERM and its I/O. It no longer handles firmware. NetEdit3 queries the OT network, updates firmware on ERMs and EBCs, and assigns IP addresses. The current release noted for this job is 3.17 (M release, March 2026), which improves handling of multiple subnets (IT versus OT networks) and fixes bugs in the 2022 standalone install. It also installs the latest ERM Workbench. Download it from the manufacturer page: Host Engineering NetEdit3 download.
- Connect the engineering PC to the same subnet as the ERM100 and slaves. If the network is split across IT and OT subnets, use NetEdit3 3.17 rather than the older install.
- Scan the network in NetEdit3 and locate the six slaves.
- Compare each reported MAC against the module label. The five healthy slaves match. The failed T1H-EBC100 shows zeros or fails to appear.
- If NetEdit3 also reads zeros or cannot see the module, treat it as failed. Do not attempt a firmware update on it.
Swap the module to restore production
This is the temporary restore. It gets the line running; the permanent repair follows in the next section.
- Remove power to the base per your lockout procedure.
- Release the failed T1H-EBC100 with steady, even pressure. Do not lever or twist it. A damaged connector on a good module produces the exact fault you are chasing.
- Seat the replacement fully and apply power.
- Watch for MODULE GOOD solid green, 100 MBIT solid, and LINKED ACTIVITY flashing.
- In ERM Workbench, confirm the slave shows online and the MAC matches the new module's label. If the slave entry was configured by MAC, update it to the new module's MAC. Stop here if the new module also reads zeros and call support.
Address slaves by DIP switch to make the next swap painless
The permanent repair on this network was to rearrange it so the ERM100 identifies each slave by its DIP switch setting instead of its MAC. With MAC-based identification, every module swap requires editing the slave entry in Workbench and a matching download. With DIP-switch identification, the replacement module takes the same switch setting and the ERM picks it up.
- Set each slave's DIP switches to a unique slave number before you change the ERM configuration.
- In ERM Workbench, change the slave identification method to the DIP-switch option and confirm every slave entry matches its switch setting.
- Record the switch setting on a label or in the panel drawing. A duplicate setting produces a slave conflict that looks like an offline module.
- Train maintenance to copy the DIP setting to the replacement before installing it.
Chase the analog fault that started the call
The network problem that triggered this call was not the original fault. The original complaint was an analog problem on a T1K-08B remote I/O analog socket. All analog output reference pins read 20.3 VDC, and every channel read the same, with all output wires disconnected from the socket.
That result is diagnostic. If the voltage persisted with no field wires attached, no downstream device could be causing it, so unplugging outputs one at a time is wasted effort. The fault sits in the base or socket. Once all wires were removed and 20.3 VDC remained, replacing the T1K-08B socket cleared it.
- Disconnect all field wiring from the analog output terminals.
- Measure the reference pins with the module and base powered. A reading that matches on every channel and persists with no load points at the base.
- Compare against a known-good base of the same part number if one is available.
- Replace the socket, then reconnect field wiring one channel at a time and recheck.
A single fault often hides a second one. Here the analog fault triggered network troubleshooting, and the swap during that troubleshooting damaged the T1H-EBC100. Ask what changed, when, and by whom before you accept a single root cause.
Verify the repair end to end
- ERM Workbench shows all six slaves online, including the replaced T1H-EBC100.
- NetEdit3 lists each slave with a MAC that matches its label. None reads
00 00 00 00 00 00. - LEDs on the replacement: MODULE GOOD solid green, 100 MBIT solid, LINKED ACTIVITY flashing, ERROR-Serial TX/RX off.
- Analog output reference pins on the new T1K-08B socket no longer read 20.3 VDC with the output wires disconnected.
- Cycle power on one slave and confirm it returns online in ERM Workbench without any configuration edit.
FAQ
Why does ERM Workbench show 00 00 00 00 00 00 for a T1H-EBC100 MAC address?
The module is reporting a blank or corrupted identity instead of its factory-set MAC, so the ERM cannot match it to the configured slave and lists it offline. Healthy link LEDs do not clear this; replace the module.
Why does the T1H-EBC100 show MODULE GOOD solid green but stay offline?
MODULE GOOD reflects power and self-test, and LINKED ACTIVITY and 100 MBIT reflect the Ethernet link. Neither reflects whether the module presents a valid MAC to the ERM, so a module can look healthy and still fail identification.
Why does a replacement module still show offline, and when do I call support?
Check the slave identification method: a MAC-based entry still points at the old module's MAC, and a DIP-switch entry needs a matching, unique switch setting. If the replacement also reads zeros in NetEdit3 and ERM Workbench, or the slave stays offline with correct addressing, stop and contact AutomationDirect or Host Engineering support with the module label MAC, the LED states, and the NetEdit3 scan result.