Solution
Note: LabWindows™
/CVI 2019 Real-Time Module will be the last version supported. For all other NI Software, NI will remove support for Phar Lap for cRIO in NI 2020 Software Release and for PXI in the NI 2022 Software Release. For more information, please see the Phar Lap RT OS EOL Road Map.NI recommends you use LabWindows™/CVI for C-based shared libraries. This will ensure proper compilation and will allow for remote debugging. LabWindows/CVI can be used to build a DLL specifically for the LabVIEW Real-Time environment by choosing
LabVIEW Real-Time Only for Run-Time Support in
Build»Target Settings. While LabWindows/CVI will check for any illegal or unsupported function calls, it does not run an exhaustive test. Use the attached utility to test the ability of your DLL to run properly in LabVIEW Real-Time.
If the shared library is C++-based, NI strongly recommends using the MSVC 2009 or MSVC 2010 compilers. Other compilers may not be supported in LabVIEW Real-Time (NI PharLap ETS) or will require run-time components to be statically linked when compiled, resulting in a larger DLL.
Note: NI strongly recommends that VeriStand users do not statically link MSVC runtimes.
If your DLL works on a Windows machine, it may work in LabVIEW Real-Time (NI PharLap ETS). However, the code will fail if it calls functions that are not included in the Real-Time operating system's subset of Win32 . For example, you may receive an error message similar to the one shown below:
Use the attached utility to determine whether or not the function calls in your DLL are supported on the real-time operating system. Use the version of the utility that corresponds with the version of LabVIEW Real-Time you are using.
Note: The same version of the utility can be used for LabVIEW Real-Time 2015 and 2016.
There are three categories that functions are sorted into: Good, Stubbed, and Bad (as shown below).
- Good indicates that the function is supported on the real-time operating system.
- Stubbed means that calling the function will not cause a deployment error, but the operation has been removed and will return a default value. Code dependent upon proper outputs from stubbed functions may not execute as expected.
- Bad means that the function has not been exported to the operating system. You cannot deploy code calling unexported functions.
For more information on building a DLL for use in LabVIEW Real-Time, please refer to the links below.
Note: If this utility asks for dependent DLLs (ex:
wsock32.dll), always try to use the version that exists on the real-time target or in
<National Instruments>/RT Images. These DLLs will sometimes differ from Windows DLLs even though they have the same name.
Automating the DLL CheckerFor versions 2013 and later the DLL Checker executable can now be called with additional arguments which specify the DLL to check and the path in which to place a log file with the results. This allows users to automate the check process using a batch script or a program that can invoke the command line, such as LabVIEW.
The argument to pass is:
-- -d "<path to dll>" -l "<path to log file>" -include "<path to DLL includes>"Here is an example of automating the check in LabVIEW.
-d "<path to dll>" - This flag specifies the path to the DLL you are checking.
-l "<path to log file>" - This flag specifies the path where resulting logs for the check will be stored. If the log file specified in the arguments path does not already exist on disc a new file will be created using the name specified.
-include "<path to DLL includes>" - By default, the DLL checker only checks the main DLL you specify with the -d flag. In order to check dependent .dll's the -include flag should be used. Use this flag to specify the directory for any other .dll that the DLL checker should also check.