Quote:
Originally Posted by Guy Davidson
How would you combine LabVIEW and C?
|
Through the Code Interface Nodes and the Call Library Nodes, but after thinking about it a little more I think I would not use the Code Interface Nodes since the Call Library Nodes are the easiest to work with.
You can build .out files for VxWorks (the equivalent of .dll files for Windows/ETS) and call into them using the Call Library Node - this allows you to have a C-compiled library that you can use. It's incredibly easy to build libraries with WorkBench, the VxWorks IDE you should be getting, we even have a
step-by-step instruction set to help you build your own libraries under VxWorks.
Quote:
Originally Posted by Guy Davidson
What functions, for example, would you use C rather than LabVIEW for?
|
There are multiple reasons why it would be beneficial to have a hybrid system.
First, I'm what I call a "realist" - I don't think you should be forced to take algorithms you've already written in C and convert them to LabVIEW just for the sake of having them in LabVIEW. I know there are a lot of great algorithms for performing lots of different kinds of advanced calculations floating around, and a good number of them are in C. Sometimes you want to break them apart and study them in-depth in order to become a master of the algorithm, and sometimes you realize you have 2 weeks before ship and you just want to plug-and-chug. Being able to build/access C-based libraries are beneficial in this case.
Second, having a c-based library gives you the power to change out modules on a filesystem level, or access modules on a given filesystem. This makes a lot more sense on NI controllers with USB Mass Storage support, you could have different program code on different USB flash drives, and change them out at will. You can do the same thing with the FTP server on the controller, it would allow you to update specific portions of your code without recompiling everything (and it can also be done through an automated script).
Code sharing. If you have the .out files, you can share code with teams using the LabVIEW interface as well as the C/C++ interface. This would be especially useful for autonomous algorithms and sharing them with rookie teams without autonomous.
Lastly, using C instead of LabVIEW can be a valuable crutch. Depending on when the controller gets in your hands and how much time you have to learn how to use it, having an out can make you more comfortable with the whole 6 week deadline thing. I would hope that teams would pick up the LabVIEW software we provided in the KOP, maybe even pick up an NXT robot and the LabVIEW NXT Toolkit, and learn how to use LabVIEW in the off season. However, that's not going to be possible for all teams. Giving a way to experiment with LabVIEW but being able to use some C code if necessary can help facilitate teams moving to using LabVIEW without being cornered into an all LabVIEW or all C/C++ situation.
Quote:
Originally Posted by Guy Davidson
Could you give a few examples or links to see how this all comes together?
|
LabVIEW itself is chock full of examples. Just use the example finder found in the lower right-hand corner of the LabVIEW 8.5 opening splash screen. Look up "Call Library Node" and you'll find tons of examples of how to use this feature.
I hope I answered your question adequately.
-Danny