T1H-EBC Swap on Win 11: Restore ERM Remote I/O Link

A replacement Terminator EBC that shows up in NetEdit3 and ERM Workbench but refuses to run I/O is almost never a protocol problem on the PC. The ERM-to-EBC link does not care what your laptop can speak. Chase the Windows socket error and you burn a shift; fix the ERM slave list and the rack comes back.

Check 1: Stop trying to switch NetEdit to IPX

Windows dropped the NWLink IPX/SPX transport after the XP era. There is no IPX patch for Windows 11, no optional feature to enable, no signed driver to install. The socket error you get when NetEdit3 switches its protocol combo box to IPX is the OS refusing to open a socket for a protocol family that does not exist in the stack. That branch is dead - do not spend time on it.

Here is the part that matters: the H2-ERM talks to the T1H-EBC slaves directly over Ethernet using IPX with MAC addresses. That traffic never touches your PC. Your laptop only needs to reach the ERM and the EBCs long enough to configure them, and both NetEdit3 and ERM Workbench can do that over UDP/IP broadcast. Discovery by broadcast returns the module's MAC address, which is all ERM Workbench needs to build the slave list.

Outcome: PC-side protocol is a non-issue. Go to Check 2.

Check 2: Read what the new EBC is reporting

Right-click the module in NetEdit3 and look at the identity fields.

• Ethernet Address shows the MAC, IP Address shows 255.255.255.255 and is flagged invalid - normal for a factory EBC that has never been given an IP. 255.255.255.255 is the limited broadcast address; the module is telling you "no unicast IP assigned." This does not block an IPX-based ERM link.
• Module does not appear at all in NetEdit3 - stop and go back to layer 1: switch port, patch lead, link LEDs on the EBC, and whether the EBC is powered from the Terminator base power supply. Broadcast discovery crosses a switch but not a router; keep the PC on the same subnet/VLAN as the ERM network.
• Module appears with a different name or a stale name - you are looking at the right hardware; the ERM just does not know about it yet.

Since you see all six slaves in both NetEdit3 and ERM Workbench, the network segment is fine. Resist the urge to start assigning IP addresses to "fix" the invalid address - the ERM and the EBCs both support IPX, and the existing system was commissioned on MAC addressing. Changing addressing mode on a running remote I/O drop is a bigger change than the repair you came to do. Get it running, then fix it properly if you ever want to migrate to TCP.

Outcome: hardware present, no IP needed. Go to Check 3.

Check 3: Compare the ERM slave list against the installed MAC

This is the root cause on virtually every EBC swap. The ERM's configuration table stores each slave by MAC address and by slave number (1-16), and it maps that slave's module slots into fixed V-memory, X, Y and C ranges in the CPU. Replace the EBC and the MAC changes. The ERM keeps polling a MAC that is no longer on the wire, the new EBC never gets addressed, and the drop stays dead while every diagnostic tool on the PC happily shows the module online.

Open ERM Workbench, connect to the ERM, and read its configuration. If the entry at the failed slave number still carries the old module's MAC, that is your fault - proceed to the fix procedure. If the new MAC is already listed but at the wrong slave number, the I/O map is shifted and the fix is the same reposition step.

Fix: Reconfigure the ERM slave list

Two hard prerequisites before you touch anything. The new T1H-EBC must already be installed in the existing Terminator base with the original I/O modules in their original slots. And the PLC must be in PROGRAM mode - the ERM will not accept a configuration write while the CPU is in RUN.

1. Print the current ERM configuration. Every slave, every slot, every V/X/Y/C assignment. Note the slave number (1-16) of the module you are replacing. This printout is your only reference if the write goes wrong.
2. Save the live configuration to a file. With ERM Workbench connected and the configuration read, use File -> Save to write a *.erm file. That file reopens in ERM Workbench later and is your rollback.
3. Enter the configuration screen. Skip the wizard or select the single ERM it finds, then press the ERM Workbench button at the bottom left.
4. Remove the dead entry. Press 2. Select Slaves, find the old slave in the ERM's Slaves List, confirm its slave number, and remove it.
5. Add the new EBC. Pick the new module from the PC Network Slaves list by its MAC address and press Add to Slave List.
6. Put it back in the same position. Select the new entry and use Move Up / Move Down until its slave number matches the number the old module held. Position determines the I/O map; a slave at the wrong index shifts every downstream address.
7. Configure the slave. Press Configure and rebuild the module-by-module layout to match the printout exactly.
8. Set the advanced options. Press Advanced and match the hot-swap and related settings from the original configuration.
9. Verify addressing before writing. Walk the whole table, not just the new slave: every V, X, Y and C for every module in every slot of every slave must land on the same addresses as the printout. If you use V40xxxx mapping, check those ranges specifically.
10. Write the configuration to the ERM while the CPU is still in PROGRAM mode.

Verify before you hand it back

• ERM Workbench shows the new slave online at the correct slave number with the correct MAC.
• Read the ERM configuration back from the module and compare it line-by-line to your printout - not to the file you just wrote from.
• Put the CPU in RUN and force/observe one known input and one known output on the replaced drop. A discrete input that toggles the expected X bit proves the map, not just the link.
• Check the other five drops. A slave-number shift shows up as I/O appearing at the wrong addresses somewhere else in the system, and it will not announce itself.
• Save the post-repair configuration to a new *.erm file and store it with the machine documentation.

Pitfalls that repeat on this platform

• Configuring before the hardware is in place. Build the slave list against an EBC sitting on the bench and the module list will not match the installed base.
• Trying to write in RUN mode. The write silently fails or is rejected; operators then report "it did nothing."
• Mixing up the two networks. An ECOM feeding HMI screens through hubs is a separate network from the ERM remote I/O segment. Do not merge them to "simplify" the fix - ERM traffic is deterministic polling and does not want HMI broadcast load on it.
• Assigning IP addresses mid-repair. Switching a working IPX/MAC-addressed link to TCP is a planned migration, not a breakdown repair.
• No printout. If you remove the old slave entry before recording its slave number and slot map, you are rebuilding the I/O map from the ladder logic at 2 a.m.

Stop here and call AutomationDirect technical support if the new EBC still fails to link after the configuration write and read-back, if the ERM rejects the write with the CPU confirmed in PROGRAM mode, or if you have lost the original configuration and cannot reconstruct the V-memory map from the printout or the PLC program. Do not experiment with slave numbering or address ranges on a production line to find out what the map used to be - a wrong map energizes the wrong output.

FAQ