Calling External Code on VxWorks Targets
Primary Software:
Primary Software Version: 8.2
Primary Software Fixed Version: N/A
Secondary Software: N/A
Problem: I have external code (such as a shared library) that I would like to call from my LabVIEW Real-Time application that has a VxWorks target. How can I do this from LabVIEW?
Solution: You can build shared libraries for VxWorks targets using the GNU toolchain distributed with Wind River VxWorks, and call them through the Call Library Function Node in LabVIEW. You should keep the following in mind when developing your code:
- LabVIEW can only call C functions: The Windows host cannot look up the symbols present in VxWorks-compiled shared libraries. All function calls from LabVIEW must have extern "c" linkage.
- The Win32 API is not available: VxWorks does not support Windows API calls. Replace them, when possible, with ISO C or C++ calls.
- Autodownloading is not supported: LabVIEW will not download a shared library to a VxWorks target if it is referenced by a VI and does not already exist on the target. Modules must be transferred via FTP to the ni-rt/system target directory.
Shared libraries can be called in a near-identical manner on VxWorks compared to how they are called on other LabVIEW Real-Time (PharLap) targets. However, there is one limitation: VxWorks targets use a *.out file, instead of *.dll. Thus, the LabVIEW development environment cannot read the library information in VxWorks shared libraries, and configuration of the Call Library Function Node must be done with a stub DLL. Follow these steps to configure you external code:
- Compile and FTP your *.out shared library to the real time target.
- Compile a stub DLL using the same function prototypes as those exported by the *.out shared library. A stub DLL typically only contains the function prototype themselves without any implementation (ie, empty functions.) This stub DLL will only be used on your Windows host machine, and must have the same name as the original *.out shared library - for example:
foo.dll and foo.out.
- Place a Call Library Function Node on your block diagram and specify
foo.* as the Library name or path. On the host machine, LabVIEW will find foo.dll, but on the real time target the executable/VI will find foo.out.
- Note that the Calling Convention configuration parameter is ignored.
- The stub DLL must have the same path relative to the VI in the host development environment as the executable on the real time target
For more information on calling and creating shared library code, consult
LabVIEW Help: Configuring the Call Library Function Node and
Developer Zone Tutorial: Developing Shared Libraries for the cRIO-901x and Other VxWorks Targets
Related Links: LabVIEW Help: Configuring the Call Library Function NodeDeveloper Zone Tutorial: Developing Shared Libraries for the cRIO-901x and Other VxWorks TargetsDeveloper Zone Tutorial: An Overview of Accessing DLLs or Shared Libraries from LabVIEWKnowledgeBase 4LRA4IQ0: What Operating System is my Real-Time Controller Running and Why?
Attachments:
Report Date: 11/27/2006
Last Updated: 08/28/2012
Document ID: 43QD6TS9
