On the reported setup, NetEdit communicated with the ECOM module, but DirectSOFT V4.0 returned a protocol error when creating a link to a 260 CPU. That confirms that one communication path reached the module; it does not confirm that DirectSOFT is using a compatible protocol or that its programming session can be established.
Stop repeating the three connection methods
Trying the module ID, IP address, and Ethernet address rules out a simple typo in one addressing method only if each value is correct. It does not repair a protocol mismatch, a DirectSOFT configuration problem, or a damaged network path. Re-entering all three values repeatedly is unlikely to isolate the fault.
- Do not treat NetEdit discovery as proof that DirectSOFT is configured correctly. NetEdit and DirectSOFT can use different communication paths or session procedures.
-
Do not install or change IPX settings blindly. IPX was installed on this PC, and its network number was reported as
000000. That value alone does not establish whether IPX is correctly configured for this network or whether DirectSOFT is using it. - Do not treat three missing frames as the cause. NetEdit displayed that count under Ethernet Stats. It is a reason to inspect the network path, not a diagnosis of the DirectSOFT protocol error.
Keep the current working NetEdit connection available for diagnostics. Avoid changing several network settings at once; otherwise, a change that restores communication will be difficult to identify and preserve.
Separate module discovery from the programming session
Discovery and programming are separate tests. NetEdit communication shows that its selected path can exchange enough traffic with the ECOM module to identify or communicate with it. Creating a DirectSOFT link requires DirectSOFT to select a compatible driver or protocol, address the intended module, and establish its own session. A failure at any of those stages can produce a protocol error even while NetEdit works.
Use the distinction to narrow the fault:
| Observation | What it tells you | Next check |
|---|---|---|
| NetEdit communicates; DirectSOFT cannot create a link | The module is reachable through the NetEdit path, but the DirectSOFT path or session remains unverified. | Check DirectSOFT's selected communication driver/protocol and link configuration. |
| NetEdit also stops communicating | The fault is no longer isolated to DirectSOFT. | Check module power, Ethernet link, addressing, cabling, and the PC network interface. |
| DirectSOFT creates a link but transfers are slow | Link establishment succeeded; transfer performance is a separate issue. | Check the CPU operation and transfer type before changing network settings. |
Do not infer that the IP address, module ID, or Ethernet address is interchangeable in every DirectSOFT configuration. Select the connection method supported by the installed software and module configuration, and verify the value against the module's current configuration rather than an old project or note.
Check the PC protocol and network path
Inspect the protocol and network interface that DirectSOFT actually uses. The reported PC had IPX installed and an IPX network number of 000000, but those facts do not say whether DirectSOFT selected IPX, whether the network requires a nonzero IPX network number, or whether a different protocol is intended. Do not assign a nonzero value without the network administrator's configuration; an incorrect network number can create a separate connectivity problem.
- In the PC's network configuration, identify the active Ethernet adapter and the protocols bound to it. Confirm which protocol or driver the DirectSOFT link is configured to use.
- Compare the PC-side configuration with the ECOM module's configured connection method and network settings. Resolve any disagreement before trying another addressing method.
- Check the physical link and adapter status. Inspect the Ethernet Stats counter in NetEdit again after a short, controlled communication test. Record whether the missing-frame count changes; a counter that changes during the test justifies investigating the link, cabling, adapter, or network traffic.
- If the network is managed, ask the network administrator to confirm the required IPX network number and any protocol restrictions before changing those settings.
A missing-frame count is a symptom to correlate with link conditions, not proof that it caused the link-creation error. If the count remains static and NetEdit continues to communicate, focus next on DirectSOFT configuration. If it increases during the attempt, resolve the network-path issue before treating the DirectSOFT session as the only fault.
Rebuild the DirectSOFT link with one controlled change
Use the DirectSOFT version already identified in the report, V4.0, as part of the diagnostic record. Do not substitute settings or assumptions from a different software version. The available information does not identify which DirectSOFT driver, protocol selection, or ECOM configuration was active, so read those values from the running installation and module rather than guessing.
- Record the DirectSOFT connection configuration and the exact protocol-error wording before changing anything.
- Confirm that the selected DirectSOFT driver supports the communication method configured for the ECOM module. If the selection is unclear, consult the DirectSOFT and ECOM documentation for that installed software/module combination.
- Verify the chosen address against the live module configuration. Use one addressing method for the test rather than changing method and protocol together.
- Remove or correct only a demonstrably stale or incorrect link entry, then create a fresh link using the verified driver, protocol, and address.
- Attempt a non-disruptive read or status operation first. Do not download or write a program as the first test of a connection that has not yet been verified.
If the link still fails, capture the selected driver/protocol, addressing method, module settings, PC adapter/protocol configuration, NetEdit status, and exact error text. Those details distinguish an addressing problem from an unsupported or misconfigured protocol path far better than repeating the same three address choices.
Restore communications without risking a program change
Once the correct DirectSOFT path is known, restore the link and verify read communication before attempting edits or downloads. Keep any temporary network change limited to the test and record its original value. If changing the PC protocol or adapter configuration disrupts other network services, roll back that change and involve the network administrator instead of broadening the troubleshooting changes.
For a temporary production restore, use a communication path already known to work at the site, if one is available and approved for the task. The report mentions Port 1 as a comparison with ECOM for program transfers, but it does not establish that Port 1 is available, configured, or appropriate as a workaround on this particular 260 CPU. Confirm the actual port configuration before using it.
Do not mistake a slow program transfer for a failed link. A separate discussion in the evidence attributes slower ECOM program downloads, relative to Port 1, to CPU firmware and flash-write behavior; it describes smaller backplane communication buffers for ECOM than local serial buffers and notes that RUN-mode edit performance can depend on CPU firmware. Those observations concern transfer time after communication is established, not the reported protocol error during link creation. The 250-specific firmware behavior in that discussion does not establish what a 260 CPU supports.
Verify the repair and keep transfer speed separate
After correcting the configuration, verify the same operation that failed: create the DirectSOFT link, then perform a read or status check. Confirm that NetEdit still communicates and that the selected DirectSOFT address resolves to the intended ECOM module and 260 CPU. Record the final driver/protocol, addressing method, and relevant network settings so the connection can be recreated after a PC or project change.
Only then test a program transfer if the work requires it and the machine state permits it. Compare like-for-like operations: a program-mode download is not the same test as a RUN-mode edit, and transfer duration is not a reliable test of whether the link protocol is correct. The evidence gives no definitive expected download time for a 260 CPU; measure the site's normal operation and check the CPU documentation and firmware information if performance is unexpectedly different.
NetEdit's three-missing-frames indication should be rechecked under the same conditions. If the counter rises, preserve that observation for network troubleshooting. If it does not rise and NetEdit remains stable while DirectSOFT fails, return to the DirectSOFT driver/protocol and link settings instead of repeatedly altering the Ethernet path.
Use the right escalation point
Stop before changing an IPX network number, making a program write, or altering a managed network configuration when the required setting is unknown. Escalate to the network administrator for protocol and network-number requirements, and to official AutomationDirect support for the DirectSOFT/ECOM compatibility and configuration path; provide the recorded software version, CPU, module settings, protocol selection, error text, and NetEdit counter behavior.
FAQ
How do I fix a DirectSOFT ECOM protocol error when NetEdit works?
Verify that DirectSOFT's selected driver or protocol matches the ECOM configuration, then confirm the module address from its live settings and create a fresh link using one addressing method. NetEdit communication alone does not verify the separate DirectSOFT session.
How do I interpret IPX network number 000000?
Treat 000000 as a configuration value to verify, not as proof of the fault. Ask the network administrator whether this network requires a nonzero IPX network number and confirm that DirectSOFT is actually using IPX before changing it.
When should I stop and contact support for an ECOM connection?
Stop if the required protocol, network number, or module configuration is unclear, or if communication changes could affect a managed network or running machine. Contact official AutomationDirect support with the DirectSOFT version, 260 CPU, ECOM settings, selected connection method, exact error, and whether NetEdit's missing-frame count changes during the test.