8.2. Device loses connection

Note

If the provided solutions don’t resolve the issue, please send a detailed description of the problem to tech support:

8.2.1. Connection via USB

The most common cause of frequent USB disconnects is poor grounding. To figure out why the USB connection is constantly lost, we suggest:

Use dielectric as an insulator:
If the controller or positioner is attached to a metal table, the table can act as a conductor of parasitic currents. These currents create electromagnetic interference that can affect the operation of electronics, causing errors, control failures, or signal distortion. By placing a dielectric material, you break the unwanted electrical contact between the controller, the positioner and the metal table, thereby eliminating the path for stray currents and reducing the likelihood of interference. If the problem disappears after that, the cause will be determined.

Grounding loops:
When different devices are “connected” through a common metal table (or other conductor), a closed loop known as a ground loop can occur. In such a loop, a parasitic current may flow due to a potential difference, which will lead to noise and unstable operation of the system.
It is assumed that the controller is grounded on two sides: through the power supply and through the computer. The grounding on the computer side cannot be broken without a separate galvanic isolation module. Power supplies are often made without grounding at the output. Standa power supplies are grounded.
As a quick system solution, it is proposed:

As an additional solution, it is proposed:

  • Change USB cable. Use verified USB cables only! Damaged or low-quality USB cable may cause improper controller operation, including motor rotation errors and errors of device recognition by PC operating system. Super short cables with thick wires and screening are ideal for sustainable connection;
  • Change USB port;
  • Change PC.

8.2.2. Connection via Ethernet

The loss of the previously established Ethernet connection may appear in following situations:

  • Due to a loose or faulty Ethernet cable. Check that the ends of the cable are firmly connected or try a different cable.

  • A controller may change its IP address if it has an autoIP in the range 169.254.xxx.xxx and reboots during an active XILab xi-tcp protocol connection session. The autoIP address is given to the controller if it’s configured for automatic IP acquisition (DHCP), but there is no DHCP server in the network. This is most often the case when the controller is directly connected to a PC. The reason for the change of IP address is that XILab sends ARP requests to reconnect to the lost device by its previously known IP address. Simultaneously, after the reboot the controller performs IP address probing to check the availability of its previous IP. The controller receives the ARP requests from the PC and treats this as a conflict in accordance with RFC 5227, Section 2.1.1, which forces it to pick a different IP address.
    To avoid this behavior, there are two options to consider:

    • Close the XILab connection before performing a power reboot of the controller.
    • Set a static IP address in the controller’s network settings. If you are sure the network doesn’t provide a DHCP server, don’t use the automatic IP configuration mode (DHCP) for the controller.
  • A controller that is connected to a router may change its IP address when the router reboots after a power loss. The problem occurs only with some entry-level or low-budget router models that lose their DHCP lease tables when powered off.

    To avoid this problem, consider setting up a static IP address for the controller in the same subnet as the other network devices.