Open a new joystick attached to USB2 and set RefNum name for it. Get the joystick device associated with that RefNum name, but it comes back as another USB device (e.g. USB1).
On the driver station, the panel shows 2 separate devices, and pressing buttons on each one causes the indicators on the corresponding joystick lights to blink (effectively showing the classmate is reading two separate devices that are working correctly).
Probing the wire output of the Joystick’s Open.vi shows a USB1 device channel, even though USB2 is clearly wired to the input.
There is nothing must going on in the Joystick Open.vi
It just copies what is wired in into a cluster that just contains the device channel enum.
If you open a blank VI (without a project) Close your robot project and open a blank VI that will just run on your desk top not the cRIO.
Place a Joystick Open.vi in it and create an input control and an output indicator.
Run and see if you see the same results USB2 in but USB1 out. You can do multiple copies (4) of Joystick Open and try all 4 USB at the same time.
If you see the same results then I think the problem is with the TypeDef of the enum (USB1, USB2, USB3, USB4) DeviceEnum.ctl
Check to see if it is still connected to the type def.
Is the constant enum that you are feeding into the Open VI also still connected to the SAME type def
Are the items in the type def still
USB1 = 0
USB2 = 1
USB3 = 2
USB4 = 3
Plus is everything still a U16 data type?
These are the only things that I can think of that cause the Open VI to output USB1 even though USB2 is clearly wired to the input
I recently helped a team resolve symptoms that perfectly match what you describe. I’m 99% sure you have a minor mismatch in the RefNum names. Look for extra leading or trailing spaces, or upper/lower case differences.
The Begin vi is called only once. Probes I try to place there after it has already run always show the default values. It looks like the actual values on the wires go away once they are no longer needed.
One thing you can do to keep wire values (for probing) after you run, is to press the “Retain Wire Values” button. It’s the button next to the “Highlight Execution” (lightbulb) button. But be aware this can use a lot of memory if you have huge data arrays.
Could this also be related to that Joystick list on the DriverStation application? (I think it’s in the Diagnostics tab)
You can select one of the USB devices and drag it up or down and re-assign which joystick is which. I’ve often wondered how this gets implemented since it overrides the USB assignments made in the Begin VI.
The JoySticks are assign USB number based on the serial number of each USB Joystick. Windows remembers which actual phyical joystick was assigned which USB# based on the serial number of the joystick.
So when you drag the joysticks around in the Diagnostics tab you are tell the system that you want the joystick with serial number XXXXXXXX to be USB1 and the joystick with serial number YYYYYYY to be USB2. So when in the Begin.VI you know which phyical joystick you are opening
You do not need to know the serial number the Diagnostics tab takes care of that.
USB joysticks can have serial numbers, but due to cost issues, they rarely do. Instead, the vendor and product info identifies them, with the order they are identified on the bus being the id for identical joysticks.
This doesn’t really affect what you are saying except that there are corner cases which will not work as you might expect – for example, unplug the hub, swap two identical joysticks within the hub, replug the hub, and the computer can’t tell that anything changed. If they had serial numbers, the joystick values would follow the serial numbers. Without serial numbers, they are tied to the port.
