NetEdit Can't See ECOM100: It's Routing, Not the Module

Two NICs in the PC — one on the ISP feed, one on the machine LAN — and the ECOM100 modules drop off the scan list. Disable the internet adapter and they come straight back. The modules, the patch cords, and the switch are fine. Windows is putting the discovery broadcast out the wrong interface, and NetEdit has no working way to override it on that build.

Get it running, then fix it properly. The order below is the order to work it on shift.

Check 1 — Disable the Internet NIC and Rescan

Open ncpa.cpl, right-click the adapter carrying the ISP DHCP address, choose Disable, then run a fresh scan in NetEdit.

• Modules appear: the problem is interface selection for the discovery probe. Go to Check 2. Do not touch module IPs.
• Modules still missing: this is not the dual-NIC defect. Go to Check 3.

Unplugging the WAN cable is not the same test as disabling the adapter, but it is close enough for a fast triage: media-disconnect pulls that interface's routes out of the table, so if pulling the cable also restores the scan, you have confirmed routing rather than a software conflict.

Check 2 — Read the Route Table, Not the Adapter List

NetEdit finds modules by probing, not by connecting to an address you typed. When the probe goes out over UDP/IP as a limited broadcast to 255.255.255.255, Windows does not flood every interface — it picks one, using the on-link 255.255.255.255 route with the lowest metric. The ISP adapter carries the only default gateway and usually the better automatic metric, so it wins, and the broadcast never reaches the machine LAN.

Confirm it before changing anything:

route print -4
netsh interface ipv4 show interfaces

In the IPv4 route table, look at the two on-link entries and compare metrics:

Network Destination      Netmask          Gateway      Interface        Metric
        0.0.0.0          0.0.0.0      100.x.x.1      100.x.x.x        <low>
    192.168.0.0      255.255.0.0        On-link    192.168.1.100      <high>
255.255.255.255  255.255.255.255        On-link    100.x.x.x          <low>
255.255.255.255  255.255.255.255        On-link    192.168.1.100      <high>

If the ISP interface holds the lower metric on the 255.255.255.255 entry, you have the cause. The 100.x address is carrier-grade NAT space, so it will not collide with 192.168.x.x — the address range is not the issue, the metric is.

Do not open Network > Adapter to force the selection. That menu enumerates adapters and crashes on multi-NIC machines; the crash is the defect, not a corrupt install.

Check 3 — Clear the Firewall and Mask Before Blaming the Build

With the ISP NIC still disabled, ping a module you know the address of, then check the ARP cache:

ping 192.168.1.x
arp -a

Observation	What it means	Next step
Scan works only with the ISP NIC disabled	Probe is leaving the ISP interface	Metric override, Check 2 fix
Ping replies, scan empty, both NICs up	Unicast routes fine; broadcast or reply path blocked	Firewall profile on the LAN NIC
Ping fails with ISP NIC disabled	Layer 1/2 fault or mask/gateway mismatch on the module	Cabling, switch port, module IP settings
NetEdit crashes on Network > Adapter	Adapter enumeration defect	Update NetEdit; avoid that menu
Module listed, IP column blank or 0.0.0.0	Never configured; answers the Ethernet-layer probe only	Assign the IP from the LAN NIC

A machine LAN NIC with no gateway and no DNS gets classified by Windows as an unidentified network and lands in the Public firewall profile, where inbound UDP replies to NetEdit are dropped. Add an inbound allow rule for the NetEdit executable on all three profiles rather than switching the firewall off.

The 255.255.0.0 mask on 192.168.1.100 is not fatal, but it widens the directed broadcast to 192.168.255.255 and it will bite you the day the PC sits behind a router handing out 192.168.1.0/24. Match the mask the modules actually use.

Know Why DirectSOFT and Do-more Designer Still Connect

Those tools open a unicast session to an address or module number you configured. Windows matches the destination against the on-link 192.168.0.0 route and sends the frame out the LAN adapter — the default route never enters the decision. NetEdit's scan has no destination to route on, so it inherits whichever interface owns the broadcast route. "DirectSOFT works, NetEdit doesn't" therefore proves the cabling and the module are good; it proves nothing about NetEdit.

Fixes that get tried first and do nothing here:

• Reinstalling NetEdit or repairing the DirectSOFT install.
• Changing the ECOM100 IP address or power-cycling the base.
• Swapping cables and switch ports.
• Turning the firewall off completely — if disabling the ISP NIC fixed it, the firewall was never in the path.
• Adding a default gateway to the machine LAN NIC. Two default routes will break internet access, the LAN, or both, intermittently.

Fix It: Give the Machine LAN the Broadcast

1. Right now, to keep working: disable the ISP adapter, run NetEdit, finish the module work, re-enable. Costs you internet for ten minutes and nothing else.
2. Permanent, both NICs up: open the machine LAN adapter Properties > Internet Protocol Version 4 > Advanced, clear Automatic metric, and set Interface metric to 10. Leave the ISP adapter on automatic. Command-line equivalent: netsh interface ipv4 set interface <Idx> metric=10, with <Idx> from netsh interface ipv4 show interfaces.
3. Correct the mask: set the LAN NIC to the mask the modules use — 255.255.255.0 for a 192.168.1.0/24 machine network. Gateway and DNS stay empty.
4. Re-run route print -4: the 255.255.255.255 on-link entry for 192.168.1.100 must now show the lowest metric. If it does not, the override did not attach to the interface you think it did — recheck the index.
5. Update the tool: the multi-adapter behavior and the Network > Adapter crash were acknowledged as defects with a new release planned. Install the current NetEdit release from Host Engineering before building workarounds on an old build.
6. If nothing else holds: move the ISP feed to a USB NIC you unplug during commissioning, or put the PC behind a router so it has one active interface.

Verify, and the Traps That Bring It Back

1. Scan with both adapters enabled. Every ECOM100 must list with MAC and IP.
2. Browse a website from the same PC while the scan list is populated — that proves the ISP path still routes.
3. Force a lease renew with ipconfig /renew on the ISP adapter and rescan. On a service that rotates the WAN address every 12 hours, a fix that survives only until the next renew is not a fix.
4. Reboot and rescan. Metric overrides bind to the interface, and dock changes or adapter reinstalls create a new index that drops the override.

Recurring traps on this class of machine: VMware, Hyper-V, and VirtualBox host-only adapters, plus VPN clients, all present virtual interfaces that can grab the low-metric broadcast route and reproduce the exact symptom with the ISP NIC already disabled — disable them before you start. Wi-Fi and wired both associated does the same thing. And a module still sitting at 0.0.0.0 answers only the Ethernet-layer probe, so a scan that reaches the right wire may still show it with an empty IP column; that is normal, not a second fault.

Stop and escalate if the scan is still empty with the ISP adapter disabled, ping to a known module IP replies, and an inbound firewall rule for NetEdit is in place on all profiles — that combination points past routing at the module or its firmware. Stop as well if the current NetEdit release still crashes on launch or on the adapter menu. Contact AutomationDirect or Host Engineering technical support with the NetEdit version, the full route print -4 output, both adapter configurations, and the ECOM100 firmware revision.

FAQ