I have encountered a very strange problem. I'm writing a Training program that runs on a PC not connected to the network (so no autoupdates and other things to interrupt us). The idea is when the program is running, the Front Panel display is black, with a fairly large green circle in the middle ("Home") and a smaller white circle inside it ("Avatar"). The Avatar is controlled by a Joystick, and will move when the Joystick position changes. When the Avatar leaves Home, I want to turn on a relay and provide a reward, and when the Avatar returns Home (for example, by releasing the Joystick), I want to turn the relay off.
My code consists of two loops running as Start Asynchronous Call routines. Loop 1 reads a USB Joystick, puts the X,Y coordinates on a Queue, and goes to sleep for 100 milliseconds (i.e. it gets the Joystick to spit out a reading at 10 Hz).
The other loop dequeues data from the Joystick. For every point, it repaints the Front Panel (black background, Green Home, White Avatar), and decides whether or not we've entered or left Home. If we just left, it tells an NI USB-6501 to turn on Port 0-0 (which produces a TTL high that energizes our relay, whose coil voltage comes from a separate battery), and if we just reentered, it tells the 6501 to turn the Port off. Then we wait for another element in the Queue.
This is running on an Acer Aspire V5 notebook, powered by an AMD Dual-core processor running at 1GHz with 4GB of memory, running Windows 8.1. A bit underpowered, but it seems to run LabVIEW OK (if slowly).
We compiled this program into an executable and tested it. It ran fine -- the Joystick moved around, the relay went on and off, and everyone was happy. Then they tried to use it in the actual Training Paradigm -- it worked for 10-15 minutes, and then froze, with the Joystick apparently unresponsive (the Avatar didn't move, was "stuck" outside Home even though the Joystick was released) and the relay left On.
I changed the Dequeue routine to time out after 5000 seconds (in which time 50 Joystick points should have been received). Sure enough, the Dequeue timed out, providing a Log message and ending the program "gracefully".
Most of the time (and maybe all of the time), we seem to "get stuck" just as we are moving the Joystick out of Home (and turning on the relay) -- it does seem to be the case that the Relay On routine occurs just over 5 seconds before the Queue times out. My interpretation of what I'm observing is that sometimes issuing a "Turn Port 0-0 On" to the 6501 (I'm using standard DAQmx calls) seems to "lock up" the Joystick loop, running asynchronously, so that it stops putting values in the Joystick Queue.
I've tried a few variations. We had been combining the two USB cables (from the Joystick and the 6501) into a USB 2-port unpowered minihub. In this configuration, as I said, we can run for minutes without trouble, but if we are sufficiently persistent, we seem to get "stuck". I tried using a powered 4-port hub -- got stuck right away (I didn't test further). I had been running the Laptop on its own battery, so I tried plugging it in -- gets "stuck".
For my final test, I plugged the two USB devices into the two USB ports on the Laptop. Program seemed to run without getting stuck, with periodic tests of a few minutes over the course of an hour. But then I noticed that if I moved the Joystick out and back quickly, the relay stayed on for 2-3 seconds (and the Avatar remained "stuck" outside the Home circle for the same time). This suggests, to me, that I still have the same problem (traffic on one USB port, namely the 6501, where I'm only issuing a Digital Line On or Off) is preventing traffic on another USB port connected to my Joystick. [Incidently, if I just test how fast I can read data from the Joystick, even on this slow laptop the rate seems to be on the order of 10KHz].
I'm 99.9% certain that this is not my code, nor LabVIEW's fault (though I don't know about the robustness of their "Read from Joystick" routines), and think that it is probably hardware. I'm planning to test with a completely different notebook (heck, maybe I'll try running this on my Surface Pro).
I would welcome suggestions, or information if you have seen similar cases of one USB stream preventing another from transmitting data to the Host. I will also post a followup here once I do the additional Hardware tests.
Bob (confused) Schor
