4.6.4. USB connection autorecovery¶
This unit is designed to reboot the USB in the event of loss of communication (for example, this may occur in the event of electrostatic discharge or when the USB is disconnected without powering down the controller). The on/off state of this unit is determined by the USB_BREAK_RECONNECT flag (see Critical parameters). If the unit is turned on, it monitors the connection loss on the USB. In the case of communication loss on the USB after 500 ms the firmware reconnects the device and then checks the state of the USB bus. If for a certain time there is no recovery of connection (i.e. data communication), then this unti reconnects the USB again. Thus, in case USB connection is not restored, the controller will continuously reconnect to the USB bus until connection is restored or until the time between reconnection attempts exceeds 1 minute. So, in the case the USB is disconnected without powering down the controller (for example, in the case of motor control with buttons or joystick) controller will remain in USB reconnection mode for about 5 minutes.
Note
USB reconnection mode does not affect other controller functions (for example movement or winding current maintenance) in any way.
To avoid simultaneous reconnect to the USB bus from both the controller and the computer side, the time between the reconnections changes exponentially (see Time between USB reconnections).
| Restart number | timeout, ms |
|---|---|
| 0 (after communication is lost) | 500 |
| 1 | 483 |
| 2 | 622 |
| 3 | 802 |
| 4 | 1034 |
| 5 | 1333 |
| 6 | 1718 |
The status of the unit can be determined by LED flashing frequency. In the case controller is in reconnection mode the LED will flash with a frequency of 10 Hz (see Operating modes indication).
Warning
Because of the structure of the program unit, as well as USB bus specification, unit doesn’t guarantee \(100\%\) recovery of the communication with the computer after a static discharge.
Xilab software also tries to reconnect to the controller when it is running. On connection loss, which is defined as “result_nodevice” libximc library call error, Xilab waits for 1000 milliseconds, then attempts to reopen device port. On Windows operating systems Xilab uses WINAPI functions to check if corresponding COM-port device is present. If it is, then after two unsuccessful attempts to reopen it calls libximc ximc_fix_usbser_sys function, which resets the usbser.sys driver to fix the driver error. On Linux or MacOS Xilab simply tries to reopen the device every 1000 ms. After the device is opened Xilab sends several commands to read serial number, firmware version and controller settings which are needed to set up user interface.
Libximc library considers device lost (return error code result_nodevice) on critical errors from system calls ReadFile/WriteFile (Windows OS) or read/write (Linux/Mac OS).