Troubleshooting DL205 ECOM Comms Through a Stride Switch

An empty NetEdit3 device list is not an IP problem. NetEdit3 finds ECOM modules by MAC address on the local Ethernet segment, before IP addressing matters, so a module with a blank, wrong, or duplicated IP still shows up in the list. A blank list means the discovery frames never reached the module at all: the wrong PC network adapter is selected, there is no link, or there is no ECOM card in the rack to answer.

Get it discovered, then get it addressed, then get DirectSOFT online. In that order.

Skip the Three Quick Fixes That Never Work Here

The crossover cable is the first thing everyone reaches for and the first thing to remove. Each port on the Stride switch already performs the crossover internally; a crossover cable into an auto-MDI/MDI-X port normally links anyway, so it neither causes this failure nor fixes it. It only leaves you guessing. Swap in a standard straight-through Cat5e patch cable on all four runs so cabling stops being a variable.

Reinstalling DirectSOFT 5 does nothing either. DirectSOFT does not discover hardware on its own; it consumes a communications link that NetEdit3 or the link wizard defines. If NetEdit3 is empty, DirectSOFT has nothing to bind to.

Power-cycling the switch is a third dead end. An unmanaged Stride switch learns MAC addresses in milliseconds and forwards broadcasts to every port regardless. A reboot cannot fix a discovery packet that left the laptop through the Wi-Fi adapter.

While you are in the panel, fix the vocabulary too: a 5-port switch has one switch and five ports. Calling the DL205 "switch 5" hides which physical jack it is on when someone else works the problem.

Check: with straight-through cable on every run, confirm the link LED is lit on Stride ports 1, 3, 4, and 5. Re-run the NetEdit3 scan. Still empty? Move to the adapter.

Bind NetEdit3 to the Right Network Adapter

A modern laptop has four or five network interfaces: onboard Ethernet, a dock or USB-Ethernet dongle, Wi-Fi, a VPN client, and one or more virtual adapters from Hyper-V or VMware. NetEdit3 sends its discovery query out of one of them. If it picked the wireless or virtual adapter, the query never touches the Stride switch and every device disappears.

1. Set the wired NIC to a static IP on the device subnet first. Leave DHCP off; there is no DHCP server on this segment.
2. Disable Wi-Fi, the VPN adapter, and any virtual switch adapters in Windows network connections. Do not just disconnect them.
3. In NetEdit3, open Network > Adapter and select the wired adapter whose address falls in the same subnet as the PLCs and HMI.
4. Trigger a re-scan.

Check: the ECOM modules appear in the list with MAC address, module type, and firmware revision. This works even if their IP addresses are wrong or blank, which is exactly why discovery comes before addressing.

Put the PC, Both ECOMs, and the HMI on One Subnet

Devices on this flat segment have no router. With a 255.255.255.0 mask, all four nodes must share the first three octets or the PC will never resolve an ARP request and the traffic goes nowhere.

Addresses above are an example scheme; use whatever your plant standard assigns, as long as the network portion matches on all four. The classic silent failure is a duplicate: HMI and ECOM both left at a factory default, or two ECOMs cloned from the same commissioning notes. The symptom is comms that work until the other device answers an ARP first, then drop for no visible reason.

Check: from a command prompt on the PC:

ipconfig /all
ping 192.168.10.20
ping 192.168.10.30
ping 192.168.10.40
arp -a

Every address must reply, and arp -a must show a distinct MAC per IP that matches the MACs NetEdit3 listed. Two IPs sharing one MAC, or one IP flipping between MACs, is a duplicate address.

Prove the Ethernet Hardware Exists and Is Linked

The 250-1 CPU has no onboard Ethernet. Its built-in ports are serial. The same is true of the DL05. Ethernet on either platform comes from an Hx-ECOM100 module, with the family digit matching the PLC: the 2-series card in the DL205 base, the 0-series card in the DL05 option slot. If those slots hold serial or I/O cards, no amount of subnet work will produce a connection.

Read the LEDs in pairs. Each ECOM module has its own link indicator, and each Stride port has one. Both ends lit means the physical layer is good. Dark on the module with a known-good patch cable points at the module, the module's seating in the base, or base power. Dark on the switch port only points at the cable or that port.

Older, non-100 ECOM cards are 10 Mbps only. The Stride switch auto-negotiates down without complaint, which is another reason to keep the switch in the path instead of going direct from a NIC forced to 100 full duplex.

Check: every populated Stride port and every ECOM module shows link at the same time.

Bring DirectSOFT 5 Online Through the ECOM

1. In NetEdit3, select the target module, write the IP address and subnet mask, and cycle power on the module if the tool prompts for it.
2. Re-scan and confirm the module now reports the address you wrote, not the old one.
3. In DirectSOFT 5, open link setup and add a new link.
4. Select the same wired PC adapter and the Ethernet protocol, not serial.
5. Pick the target from the discovered device list, or enter its IP directly.
6. Name the link something a technician will recognize at 2 a.m. — line and machine, not "Link1" — then connect.

Check: the DirectSOFT status bar reports the CPU mode, and a read of the program from the PLC completes without a timeout. Repeat for the DL05 with its own link.

Run the End-to-End Check, Then Escalate

Leave a continuous ping running to each node for several minutes with the machine cycling: ping -t 192.168.10.40. Zero dropped packets, or you have a marginal cable, a loose RJ45 in a vibrating panel, or a noise coupling problem on an unshielded run. Then force a bit from DirectSOFT and watch it change on the HMI to prove the HMI's own driver is pointed at the right PLC address. Finally, unplug the PC from port 1 and confirm the HMI and both PLCs keep running — the programming laptop must never be load-bearing. Write the finished IP table on a label inside the panel door.

Stop and call AutomationDirect technical support if NetEdit3 still lists nothing with a single adapter enabled, straight-through cable in place, and confirmed link LEDs on both the ECOM module and its Stride port. At that point you are looking at a failed module or a tool-to-firmware mismatch, not a configuration error. Have the module part number, the module firmware revision, and your NetEdit3 version in hand before you dial.

FAQ