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 Table 1).
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).
To Next Page
Loading...