Chapter 3 |
CINs |
-o is the name of the makefile lvmkmf creates. If you do not specify this argument, the makefile name default is Makefile.
The makefile produced assumes the cin.o, libcin.a, makeglueXXX.awk, and lvsbutil files are in certain locations,
where XXX is SVR4 on Solaris 2.x, linux on Linux, and HP on HP-UX. If these assumptions are incorrect, you can edit the makefile to correct the pathnames.
Step 5. Load the CIN Object Code
To load the code resource, right-click the node and select Load Code
Resource. Select the .lsb file you created in Step 4. Compile the CIN
Source Code.
LabVIEW loads your object code into memory and links the code to the current front panel or block diagram. After you save the VI, the file containing the object code does not need to be resident on the computer running LabVIEW for the VI to run.
If you modify the source code, you can load the new version of the object code using the Load Code Resource option. The file containing the object code for the CIN must have an extension of .lsb.
There is no limit to the number of CINs per block diagram.
LabVIEW Manager Routines
LabVIEW has a suite of routines that you can call from CINs. This suite of routines performs user-specified routines using the appropriate instructions for a given platform. These routines, which manage the functions of a specific operating system, are grouped into three categories: memory manager, file manager, and support manager.
External code written using the managers is portable, that is, you can compile it without modification on any platform that supports LabVIEW. This portability has the following two advantages:
•The LabVIEW application is built on top of the managers. Except for the managers, the LabVIEW source code is identical across platforms.
•The analysis VIs are built mainly from CINs. The source code for these CINs is the same for all platforms.
Using External Code in LabVIEW |
3-16 |
www.ni.com |
Chapter 3 |
CINs |
Refer to the Manager Overview section of Chapter 4, Programming Issues for CINs, for more information about the memory manager, the file manager, and the support manager.
Refer to Chapter 6, Function Descriptions, for descriptions of functions or file manager data structures.
Pointers as Parameters
Some manager functions have a parameter that is a pointer.
These parameter type descriptions are identified by a trailing asterisk (such as the hp parameter of the AZHandToHand memory manager function) or are type defined as such (such as the name parameter of the FNamePtr function). In most cases, the manager function writes a value to pre-allocated memory. In some cases, such as FStrFitsPath or GetALong, the function reads a value from the memory location, so you do not have to pre-allocate memory for a return value.
The following functions have parameters that return a value for which you must pre-allocate memory:
AZHandToHand |
AZMemStats |
AZPtrToHand |
DateToSecs |
DSHandToHand |
DSMemStats |
DSPtrToHand |
FCreate |
FCreateAlways |
FFlattenPath |
FGetAccessRightsFGetEOF |
|
FGetInfo |
FGetPathType |
FGetVolInfo |
FMOpen |
FMRead |
FMTell |
FMWrite |
FNamePtr |
FNewRefNum |
FPathToArr |
FPathToAZString |
FPathToDString |
FPathToPath |
FRefNumToFD |
FStringToPath |
FTextToPath |
FUnflattenPath |
GetAlong |
SetALong |
RandomGen |
SecsToDate |
NumericArrayResize
You must allocate space for this return value. The following examples illustrate correct and incorrect ways to call one of these functions from within a generic function foo:
© National Instruments Corporation |
3-17 |
Using External Code in LabVIEW |