So I am using an add-on that allows me to interface with special hardware in labview, and it works fine on brand new test projects unrelated to robot code (Blank VI’s in a New Project.) The problem comes when trying to add it to our robot code, as (I believe) the cRIO does not have native support for the C#/.NET code. I am limited as to how much I can share on the nature of the add-on api, as I don’t have permission from the author.
What I want to know, is if it’s possible to make a generic addon that uses .NET 3.5 C# code to operate, compatible with the cRIO.
Oh, and the compiling error I get says
“Wire: Type not supported in current target.”
It is not going to be possible to run .NET code on the current CRIO because the libraries do not exist on the current VXWorks system. You can write native C++ code and interface with that through LabVIEW, but not .NET.
Now this could all change when the new RoboRIO comes out because there is .NET compiled for ARM Linux, and the base libraries should be compatible with a little work.
To confirm. I do not know of a .NET runtime for vxworks. LV supports ActiveX and .NET interfaces, but only on Windows for OSes where they libraries are there to interface with.
If the author can give C code such as a DLL, then it can be compiled as a .out for vxworks. That can be called by LV on all platforms.
Alternatively, you can read from the sensor or bus and pull the data straight into LV.
Greg McKaskle
Thanks for the info, I guess i’ll have to create a custom driver for windows to emulate a controller and program it in using normal methods. Alas, no custom interface for me >_<
If you’re trying to write code to interface with a custom game controller/user interface, that would have to execute on the driver station side of things anyway. You could write a program in LabVIEW targeted to the driver station (where .NET is available) that interfaces with the controller, then sends data to the robot using Network Tables, UDP, or some other protocol.
This is assuming that the driver station will play nice with other programs running on the driver station that try to claim game controllers. As long as the driver station doesn’t crash, the worst case scenario might be you have to start your software before you start the driver station.