LabVIEW
An NI Service is cause USB and Serial packet loss on the cRIO-9068
I am acquiring data from an IMU sensor (@ 1000 Hz) through the USB bus. I have a shell executable that can read the data from the IMU in addition to some VIs that wrap the same driver that the shell executable calls. The driver has the ability to count the number of packets lost due to a back checksum. Both the shell executable and VI report the instantaneous number of lost packets. If I reboot the cRIO and run the shell executable very first I get good clean data. I can continue to run the same executable over and over and will consistently get good clean data with a trivial number of lost packets (i.e. 1-2 losses over a number of minutes). However, if I run the LV VI I do get data but the number of lost packs grows at a very rapid rate (e.g. ~ 250-350 in 1 second). After the LV VI has been downloaded for the first time the shell executable also suffers from the same lost packet growth rate. So, there is a LV service being loaded/activated that is messing with USB communication somehow (so I thought).
While debugging, I found that it's not tied to LabVIEW itself but to some NI service being loaded/actived. I rebooted the system and again ran the shell executable and received no/low dropped packets. However, this time instead of downloading a LV VI I launched MAX and expanded REMOTE SYSTEMS->DEVICES & INTERFACES and clicked on one of the resources there. This also corrupted the system, meaning, subsequent runs of the shell executable would no longer maintain a low/no packet loss.
A third test, same as the second, rebooted the cRIO, ran the shell executable but this time left it running. It was still maintaining low/no packet loss but while it was running I launched MAX and expanded the same items in the tree. Each click in MAX would cause 1-2 lost packets in the actively running shell executable but that was it (it didn't run away with increasing lost packets). After expanding all the tree items (as described above) and noticing only incremental packet losses versus a steady growth rate of losses I decided to stop the shell executable. I then returned to MAX and pressed F5. After the refresh/rediscovery of remote systems (which kind of got hung up for a while this time) I then reran the shell executable. Sure enough, as expected, the packet loss was now rapidly growing again.
This indicates that some NI service on the cRIO-9068 is adversely affecting USB communication performance. It is tied to the downloading of the first LV VI to the cRIO and/or to launching MAX and expanding the DEVICES & INTERFACES of the cRIO. Since the packet growth rate did not switch to the rapid growth rate scenario when MAX was launched while the shell script was actively running AND MAX struggled to perform the refresh/rediscovery of the cRIO this tells me the shell script somehow blocked the offending NI service from getting access to the USB port. However, the refresh/rediscovery in MAX after stopping the shell executable then successfully launched the offending NI service and subsequent USB communication was now losing packets at a rapid rate again.
Final, observation, my IMU has the ability to communicate through USB and/or RS232. After the above USB observations, I switched the IMU over to RS232 in hopes that the problem was isolated to USB only. Sadly, this is not the case, the exact behavior as described above equally applies to RS232 based communication as well.
This is a showstopper for my application. My application cannot accept a 25-30% loss of packets. If you have any ideas of what NI service is causing this problem I would greatly appreciate your insight.
I am running LabVIEW 2014 sp1 (14.0.1) and the attached images shows the software installed on the cRIO. My host computer is Window 7.
