Help - Selfish library functions... (Won't share)
 

I'm doing a non-competition project involving using the joystick to send a keyboard output to a drivers station computer file. I'm using a case structure reading the joystick values, which initializes a keybd_event from the user32.dll library on a pc. The problem I have is that when trying to deploy the program, labview wants to load user32.dll from the crio, so I get this error:

My question is do I have to/can I preload the dll file to the cRIO, or somehow keep it from needing the dll on the crio? The dll has nothing to do with how the robot functions; it's just used for reading joystick input.

Thanks!

Re: Help - Selfish library functions... (Won't share)
 

user32.dll is a windows dll, compiled for x86. It won't run on the cRIO, which runs vxworks on a power pc.

I can't tell from your post what you're actually trying to do. Do you want to attach a joystick directly to the cRIO? Thats what it sounds like the code you wrote is expecting.

Are you using the FRC cRIO image? Are you planning to use the FRC driver station? Where do you really want the joystick to attach?

Re: Help - Selfish library functions... (Won't share)
 

As Joe pointed out, the VI you've written is attempting to read the joystick directly from the cRIO. The joystick VIs make calls directly to the OS they are on, Windows, Mac, or linux, but will not work on VxWorks.

For the control system, the joystick is read by the driver station, then sent to the cRIO via UDP.

If you want more help, you will need to give more info about what you really want it to do.

Greg McKaskle

Re: Help - Selfish library functions... (Won't share)
 

My apologies for not being more clear. I have attached some screen shots.

When I asked the question, my program was as in the Main 3.0 shot. It's essentially a modified Arcade Drive Example. As both of you pointed out, I was having issues because I was trying to read everything from the cRIO, which due to my lack of understanding of how the system reads joystick information, was wrong.

What I'm attempting to do is on the driver's station, be able to read the joystick position and turn it into a keyboard command. I got confused regarding the Joystick VI's being on the cRIO, on how the system reads the joysticks. So I pulled out all of the guts and put it into a separate VI under My Computer.

Now my question is - how do the VI's communicate between My Computer and the cRIO? To be more specific, if I run my 3.5 VI's, the Main VI on the cRIO still reads, but how do I send that information to the My Computer VI? Do I have to make the inputs/outputs into shared/global variables?

Re: Help - Selfish library functions... (Won't share)
 

What will you do with it at that point? The cRIO doesn't have a keyboard, so it's not expecting any keyboard commands.

They communicate using the proprietary (but not exactly secret) DS-to-cRIO data exchange protocol implemented by the Driver Station application. Four joysticks (each with up to six axes and twelve buttons) are supported, along with a small number of analog and digital values associated with the Cypress interface board, and a bunch of control information such as robot mode and alliance color. There is no provision I'm aware of for general keyboard input.


I don't have any idea what you want to use a joystick-to-keyboard translation for. If what you want to do were possible, can you describe how you would use it? Give an example of what the operator would do, and what the result would be.

Re: Help - Selfish library functions... (Won't share)
 

What I want is to make the joysticks tell the computer that I'm pressing a key instead. For a simplified example, Pinball in Windows accepts keyboard inputs, so if I push the joystick right, the case loop outputs "Right Arrow" to the user32.dll, simulating the pressing of the key "<-" For a robotics application, you could open up a text file and have the program give you a history of the directions you gave to the robot. If you pushed the joystick right for 5 iterations, the case loop outputs "RRRRR"

Of course, this is all irrelevant to my question, which is:
How can I intercept the joystick input and send the value to a VI running on the computer? Looking at my second attachment, which is essentially the arcade drive with its input wires cut, how do I make the "Joystick Get Axis" tell the VI on the computer I'm running (NOT on the cRIO) what the values from the Joystick are?

Once again, this is NOT competition-related. I'm simply deploying the modified arcade drive example to the cRIO. What needs to take the place of "X in / X out" on the example to make this work?

Re: Help - Selfish library functions... (Won't share)
 

I'm still not 100% sure, but I'll throw out a couple things you can do.

Since this is offseason, and there are no rules, you can write a VI for the PC which reads the joysticks and keyboard directly. This is most easily done using the VIs in the Connectivity palette -- Connectivity>>Input Device Control. The VIs are a little bit old and all three devices are combined, but they work fine. You init the joystick and/or keyboard, and Query for the current state. Now you can do what you want with this info, essentially build your own DS or a supplement to the DS.

To get data to the robot, your low level approach is to use TCP or UDP. Until you have performance problems, start with TCP from Data Connectivity>>Protocols. You'll want one device to do a TCP Listen and the other device to Open a connection. Think about what you want to happen before both devices are booted.
Do you want the loop on the PC to block until the robot boots?
Do you want the loop on the robot to block until the PC boots?
There are some subtleties about which does the Open and which does the Listen, but it is pretty easy to switch later and I don't think you'll care in your application. Once the Open and Create succeed, you'll then want to enter a loop to Write your data on the PC and a loop to read it on the robot.

If you have difficulties with TCP, be sure to use the Help>>Find Examples to look at TCP usage. And if this is way off the mark, post a simple explanation of the problem you are trying to solve.

Greg McKaskle