Troubleshooting DirectSoft Ethernet Connection Errors

DirectSoft reconnects after the competing VirtualBox network adapter is disabled and Windows is rebooted. For a permanent repair, keep the control-network interface first in the adapter order, then prove that DSLaunch5 stays bound to the correct path while the virtual machine is running.

Skip the fixes that do not address adapter selection

A fresh software installation is not the first repair when previously operational Ethernet links suddenly report error connecting to ethernet device. The affected Windows 7 64-bit installation had already worked for weeks, and the fault appeared about fourteen hours after VirtualBox was installed and a Linux server was configured with virtual networking. That sequence points to a network-interface selection problem, not immediate corruption of every saved link.

Do not spend the first outage rebuilding PLC projects, recreating all links, or repeatedly reinstalling DirectSoft. Those actions leave the competing interfaces in place. A reboot by itself may also produce only a temporary recovery because Windows rebuilds its network state during startup without removing the condition that lets the wrong interface be selected.

Driver certification does not settle this diagnosis. A virtual adapter can operate correctly as a Windows driver and still change interface enumeration, routing, or the path selected by an application. Get it running by isolating that change, then fix the adapter order properly.

Confirm that the failure follows the workstation

Take the first reading at the DirectSoft workstation: open the previously operational link in DSLaunch5 and record whether the exact connection error appears. Then determine whether the PLC and the workstation still have a usable physical Ethernet path. Check cable indication, switch-port indication, adapter state, and whether the control interface still has the network configuration assigned for the PLC network.

1. Test more than one previously operational DirectSoft Ethernet link when the machine has several configured links.
2. Note whether every link fails at the same workstation or only one destination fails.
3. Check whether another authorized maintenance station can reach the same controller without changing the controller.
4. Leave the PLC program and controller network settings unchanged while isolating the PC.

If several old links fail together immediately after a workstation networking change, continue with the interface checks. If one controller alone is unreachable while other DirectSoft Ethernet links work, follow that controller's cable, switch, address, and operating-state branch instead. If no alternate station is available, use physical link indication and the workstation's network status to avoid changing the PLC merely to test a PC-side theory.

Stop here if the controller or switch shows a separate hardware fault, the control network has been modified, or changing controller settings could interrupt running equipment. Treat that as a plant-network incident rather than a VirtualBox-only repair.

Count every active physical and virtual NIC

Open the Windows network-adapter list and count every enabled interface, including wired adapters, wireless adapters, VPN interfaces, and VirtualBox adapters. The decisive reading is not the number of physical Ethernet sockets; it is the number of enabled interfaces Windows can present to applications.

DirectSoft can encounter the error when two or more network interface cards or logical interfaces are active. Windows networking selects which interface serves a connection, and DirectSoft does not fully control that allocation. A virtual interface therefore matters even though no additional physical card was installed.

1. Identify the adapter physically connected to the PLC or control-network switch.
2. Identify VirtualBox Host-Only Network separately.
3. Identify the physical adapter used by the VM's bridged configuration.
4. Mark any other enabled adapter that cannot reach the PLC network.

If only the control-network interface is enabled, skip to the physical-path and link-configuration checks. If two or more interfaces are enabled, continue by disabling one competing interface at a time. Do not disable an interface carrying a required plant service until its function and recovery method are known.

Disable the competing adapter and retest

Use VirtualBox Host-Only Network as the first isolation target because disabling it and rebooting restored DirectSoft communication in the affected setup. This is a controlled diagnostic, not yet the permanent configuration.

1. Close DirectSoft and stop any VM operation that depends on the host-only adapter.
2. Disable VirtualBox Host-Only Network in Windows.
3. Reboot the workstation so Windows and DirectSoft start with the reduced interface set.
4. Open DSLaunch5 and connect through the same previously operational link.
5. Record whether the connection succeeds without editing that link.

If communication returns, the virtual adapter is part of the failure path. Leave it disabled long enough to restore production, then move to adapter prioritization before returning the VM to service. If the error remains, disable other nonessential interfaces one at a time and repeat the clean-start test.

If DirectSoft still fails when the PLC-network adapter is the only enabled interface, stop blaming interface competition. Recheck the selected DirectSoft link, the workstation's control-network configuration, the cable, switch port, and controller state. Avoid changing several settings together; one change per test preserves the diagnosis.

Separate host-only networking from bridged networking

Do not treat every VirtualBox interface as the same path. A host-only adapter creates communication between the host and virtual machines on a separate virtual network. A bridged VM uses a host interface to participate on the network connected to that interface. The installation description mentions both a bridged Linux server and VirtualBox Host-Only Network, so inspect both configuration paths instead of silently assigning the fault to only one.

If the Linux server does not require host-only communication, leaving the host-only adapter disabled removes the conflict with the least configuration work. If the VM requires it, keep the adapter but correct Windows interface priority. If the VM must bridge onto the control network, involve the plant-network owner before changing its design; an unintended VM presence on a control network is a separate operational concern.

Put the control-network NIC first

Reprioritize the Windows interfaces so the adapter used by the DirectSoft link is above virtual and unrelated adapters. The reading that matters after this change is whether DirectSoft connects while all required interfaces remain enabled.

1. Identify the exact Windows interface connected to the PLC network.
2. Move that interface to the top of the applicable adapter order or assign it the preferred interface priority through the Windows networking configuration.
3. Place VirtualBox Host-Only Network and unrelated adapters below it.
4. Restart Windows to clear the previous network state.
5. Test the existing DirectSoft link before launching the VM.
6. Launch the VM, then repeat the same connection test.

Priority corrects the selection decision while preserving the virtual adapter for applications that need it. Disabling the adapter removes the decision entirely. Use disabling for fast recovery; use a deliberate priority arrangement when both DirectSoft and VirtualBox must operate on the same workstation.

If prioritization does not hold after restart, inspect the Windows adapter configuration for another service that is rewriting interface settings. Do not compensate by repeatedly rebuilding DirectSoft links. The repair target remains the workstation's interface selection.

Use the delayed failure as a test condition

An immediate successful connection does not close this fault. In the affected setup, DirectSoft continued working for hours after the host-only adapter and VM were enabled, then stopped. The original occurrence was approximately fourteen hours after VirtualBox installation and configuration.

The delay means the acceptance test must reproduce the operating condition, not just the startup condition. Interface state can change as a VM starts, stops, renews its network state, or activates a virtual path. DirectSoft may therefore work at launch and fail after Windows has reevaluated available interfaces.

1. Connect through DSLaunch5 before starting the VM.
2. Start the Linux VM in its normal network mode.
3. Disconnect and reconnect the DirectSoft link after the VM is active.
4. Repeat the connection periodically across the shift.
5. Include a test after any VM network transition normally performed in production.
6. Record which adapters were enabled at the first failed attempt.

If the error returns only while the host-only adapter is enabled, remove that adapter from the normal maintenance configuration or keep it below the control-network interface. If it returns with the adapter disabled, compare the active-interface list before and after failure; another virtual or physical interface may be taking its place.

Restore production with the smallest reversible change

When the line needs the programming connection back, use the confirmed recovery path: disable the troublesome virtual adapter and reboot. This preserves the PLC program, the saved DirectSoft link, and the control-network configuration.

1. Stop VM workloads that depend on VirtualBox Host-Only Network.
2. Disable that adapter.
3. Reboot Windows.
4. Open DSLaunch5 and connect with the existing link.
5. Perform only the authorized maintenance work.
6. Leave the adapter disabled until its priority or the VM network design has been corrected and tested.

Do not re-enable every interface during the outage just to prove the diagnosis. Restore the required DirectSoft path first. Schedule the permanent multi-interface test when loss of the programming connection will not extend downtime.

If disabling the virtual adapter would interrupt a required server function, stop before taking it down. Coordinate a maintenance window or move PLC programming to a workstation that does not host competing virtual networks.

Verify the permanent repair under normal load

Close the job only after DirectSoft and the required VM networking coexist without changing the saved PLC link. Verification must cover restart behavior and the delayed-failure pattern.

A pass at startup followed by a failure hours later is not a pass. Keep the temporary adapter-disable recovery documented for the night shift until the extended test completes.

FAQ