We are using the Advanced Framework. In there, the joystick (USB1) is initialized in TeleOp-Init. How do we make a second one there? The JoystickDevRef is what’s confusing us…
[see attached image for where I mean]
We are using the Advanced Framework. In there, the joystick (USB1) is initialized in TeleOp-Init. How do we make a second one there? The JoystickDevRef is what’s confusing us…
[see attached image for where I mean]
You need to edit the typedef for the Robot Data In control. There are at least three ways to open the typedef. Use any one of the these three:
2.or right click the control and select “Open Typedef”.
Once the typedef is open, add a 2nd JoystickDevRef and name it to reflect what it does. Save the control
We are having a problem related to this. After we create a new joystick devref, build, and then deploy the code motors won’t be controlled by only their own joystick or button. The inputs from one joystick sort of mix with those of the other. IE. the drive joystick starts to control the device at random.
I presume you are opening two separate joystick channels, correct?
Can you post the code?
Are you rebundling the device references back into the cluster? If so, you need to be careful to rebundle them into the correct device references. If they are mixed, you will end up with the type of behavior that you are describing.
Here is the code. I don’t see where the bundling can mixed up in the Teleop file. Also, I have made sure to have the joysticks on separate USB ports.
Is there a way to create a devref that does not require copy and pasting or cloning using ctrl? That is the only way I or the other programmers know…
Finally, is there a need to initialize another joystick devref inside of the Joystick.lvlib’s Open VI and Close VI?
REX build up.zip (339 KB)
REX build up.zip (339 KB)
Sorry to double post, but I though that this may make it easier to see:
This is does exactly the same thing as the posted code, but uses the basic structure rather than the advanced structure. There is a 2 wired to the second “OpenJoysick.vi” because I was messing around and hoped that it might fix it.
I believe the problem is that in your Teleop.vi you never initialized the Joystick DevRef 2. You definitely ought to Open the joystick and assign the Joystick DevRef 2 before using it.
OK, looking back at the image I posted at the top…
I created the second DevRef as instructed. I added it and set it for USB2. I expanded the bundle on the left to now show “JoystickDevRef2” and sent the brownish wire out of that into the case structure (Init). Then I branched in the pink line (RobotData In) as the input cluster. However, if I try to send the output cluster to RobotData Out I get an error that states: Wire connects to an undirected tunnel.
So, the question: once I create the second JoystickDevRef, how do I get it’s output to continue on and be used in the RobotData Out?
PS: With it configured as above, the RUN arrow is not broken…
You can do this one of two ways:
(by the way bundle refers to the operation of putting values into a cluster. Unbundle refers to the operation of getting values out of a cluster).
If you bundle each value one at a time as you are doing, you need to wire the output of one bundle (the right most connector of the bundle) into the input of the next one (the middle connector of the bundle).
Thank you airnate. You are a wise and powerful LabView master. I shall test this tomorrow.
My init case looks exactly the same as yours. The problem must lie deeper… When I get accesses to the robot I’m going to start checking for physical issues. I already have checked the robot wiring, so I suspect that there may be something wonky with our O/I station.
Pausert,
The REX build up zip that you posted yesterday at 07:15 pm is missing a Joystick Open in the Teleop.vi Init case. The USB 1 Joystick is opened and assigned to JoystickDevRef, but the JoystickDevRef 2 is unassigned.
This could certainly create strange behavior.
-Nate
Thank you for all your help! It appears that there were some code issues, but also there were problems with how Labview handles Victors. Once we cleaned up the code and changed to Spikes the code worked as intended. Thanks!
Wanna elaborate on the victor issue?
Greg McKaskle
Sure. Essentially, whenever we used a Victor, it would receive some form of crosstalk from joystick 1 even though it was supposed to be received by joystick 2. If we changed the motor VIs to Jaguar ones and put a Jaguar into the electronics the code would run fine, otherwise one of our 2 Victors would start to move with both of the 2 Jaguars we had. If we unplugged the Victor that was receiving the crosstalk, the other Victor would start to move in response to the crosstalk. That behavior alerted us to something odd with the Victors or Victor VIs. Because we didn’t really need analog control where the Victors were and we didn’t have any extra Jaguars we replaced them with Spikes and used the Relay library.
In short, I have no idea what is actually wrong with the Victors or their associated code, but something is weird about it.