- •Worldwide Technical Support and Product Information
- •National Instruments Corporate Headquarters
- •Worldwide Offices
- •Important Information
- •Warranty
- •Copyright
- •Trademarks
- •WARNING REGARDING USE OF NATIONAL INSTRUMENTS PRODUCTS
- •Contents
- •About This Manual
- •Conventions
- •Related Documentation
- •Calling Code in Various Platforms
- •Characteristics of the Two Calling Approaches
- •Details of Call Library Function
- •Details of a CIN
- •Calling Shared Libraries
- •Figure 2-1. Call Library Function Dialog Box
- •Calling Conventions (Windows)
- •Parameters
- •Calling Functions That Expect Other Data Types
- •Building a Shared Library (DLL)
- •Task 1: Build the Function Prototype in LabVIEW
- •Task 2: Complete the .c File
- •Required Libraries
- •Task 3: Build a Library Project in an External IDE
- •Figure 2-2. Creating a Project in Visual C++
- •Figure 2-3. Setting the Use run-time library control, Microsoft Visual C++
- •Gnu C or C++ Compilers on Solaris, Linux, or HP-UX
- •Metrowerks CodeWarrior on Power Macintosh
- •Calling External APIs
- •Common Pitfalls with the Call Library Function
- •Incorrect Function Name
- •Data Types
- •Constants
- •Calling Conventions
- •Example 1: Call a Shared Library that You Built
- •Configuration of Call Library Function
- •Create Front Panel
- •Create the Block Diagram
- •Example 2: Call a Hardware Driver API
- •Figure 2-4. VI That Calls Hardware
- •Example 3: Call the Win32 API
- •Table 2-1. Mapping Win32 Data Types to Standard C Data Types
- •Table 2-2. Mapping Win32 Data Types to LabVIEW Data Types
- •Constants
- •Table 2-3. Selected Constants for MessageBox
- •Figure 2-5. Combining Function Constants in LabVIEW
- •Determining the Proper Library and Function Name
- •Unicode Versions and ANSI Versions of Functions
- •Configuring a Call to the Win32 API
- •Figure 2-6. Configuring Call Library Function to call the Win32 API
- •Figure 2-7. Block Diagram for a Call to the Win32 API
- •Figure 2-8. Running a LabVIEW Call to the Win32 API
- •Additional Examples of LabVIEW Calls to DLLs
- •Debugging DLLs and Calls to DLLs
- •Troubleshooting the Call Library Function
- •Troubleshooting your DLL
- •Troubleshooting Checklist
- •Module Definition Files
- •Array and String Options
- •Arrays of Numeric Data
- •String Data
- •Figure 2-9. The LabVIEW String Format
- •Figure 2-10. The Pascal String Format
- •Figure 2-11. The C String Format
- •Array and String Tip
- •Supported Languages
- •Macintosh
- •Microsoft Windows
- •Solaris, Linux, and HP-UX
- •Resolving Multithreading Issues
- •Making LabVIEW Recognize a CIN as Thread Safe
- •Using C Code that is Thread Safe
- •Creating a CIN
- •Step 1. Set Up Input and Output Terminals for a CIN
- •Input-Output Terminals
- •Output-Only Terminals
- •Step 2. Wire the Inputs and Outputs to the CIN
- •Step 3. Create a .c File
- •Step 4. Compile the CIN Source Code
- •Compile on Macintosh
- •Microsoft Windows
- •Solaris 2.x
- •HP-UX and Linux
- •gcc Compiler
- •Step 5. Load the CIN Object Code
- •LabVIEW Manager Routines
- •Pointers as Parameters
- •Debugging External Code
- •DbgPrintf
- •Windows
- •UNIX
- •Passing Parameters
- •Parameters in the CIN .c File
- •Passing Fixed-Size Data to CINs
- •Scalar Numerics
- •Scalar Booleans
- •Refnums
- •Clusters of Scalars
- •Return Value for CIN Routines
- •Examples with Scalars
- •Creating a CIN That Multiplies Two Numbers
- •Passing Variably Sized Data to CINs
- •Alignment Considerations
- •Arrays and Strings
- •Paths
- •Clusters Containing Variably Sized Data
- •Resizing Arrays and Strings
- •SetCINArraySize
- •NumericArrayResize
- •Examples with Variably Sized Data
- •Concatenating Two Strings
- •Working with Clusters
- •Manager Overview
- •Basic Data Types
- •Scalar
- •char
- •Dynamic
- •Memory-Related
- •Constants
- •Memory Manager
- •Memory Allocation
- •Memory Zones
- •Using Pointers and Handles
- •File Manager
- •Identifying Files and Directories
- •Path Specifications
- •File Descriptors
- •File Refnums
- •Support Manager
- •CIN Routines
- •Data Spaces and Code Resources
- •One Reference to the CIN in a Single VI
- •Loading a VI
- •Unloading a VI
- •Loading a New Resource into the CIN
- •Compiling a VI
- •Running a VI
- •Saving a VI
- •Aborting a VI
- •Multiple References to the Same CIN in a Single VI
- •Multiple References to the Same CIN in Different VIs
- •Single-Threaded Operating Systems
- •Multithreaded Operating Systems
- •Code Globals and CIN Data Space Globals
- •Examples
- •Memory Manager Functions
- •Support Manager Functions
- •Mathematical Operations
- •ASCIITime
- •AZCheckHandle/DSCheckHandle
- •AZCheckPtr/DSCheckPtr
- •AZDisposeHandle/DSDisposeHandle
- •AZDisposePtr/DSDisposePtr
- •AZGetHandleSize/DSGetHandleSize
- •AZHandAndHand/DSHandAndHand
- •AZHandToHand/DSHandToHand
- •AZHeapCheck/DSHeapCheck
- •AZHLock
- •AZHNoPurge
- •AZHPurge
- •AZHUnlock
- •AZMaxMem/DSMaxMem
- •AZMemStats/DSMemStats
- •AZNewHandle/DSNewHandle
- •AZNewHClr/DSNewHClr
- •AZNewPClr/DSNewPClr
- •AZNewPtr/DSNewPtr
- •AZPtrAndHand/DSPtrAndHand
- •AZPtrToHand/DSPtrToHand
- •AZPtrToXHand/DSPtrToXHand
- •AZRecoverHandle/DSRecoverHandle
- •AZSetHandleSize/DSSetHandleSize
- •AZSetHSzClr/DSSetHSzClr
- •BinSearch
- •BlockCmp
- •Cat4Chrs
- •ClearMem
- •CPStrBuf
- •CPStrCmp
- •CPStrIndex
- •CPStrInsert
- •CPStrLen
- •CPStrRemove
- •CPStrReplace
- •CPStrSize
- •CToPStr
- •DateCString
- •DateToSecs
- •FAddPath
- •FAppendName
- •FAppPath
- •FArrToPath
- •FCopy
- •FCreate
- •FCreateAlways
- •FDepth
- •FDirName
- •FDisposePath
- •FDisposeRefNum
- •FEmptyPath
- •FExists
- •FFlattenPath
- •FFlush
- •FGetAccessRights
- •FGetDefGroup
- •FGetEOF
- •FGetInfo
- •FGetPathType
- •FGetVolInfo
- •FileNameCmp
- •FileNameIndCmp
- •FileNameNCmp
- •FIsAPath
- •FIsAPathOfType
- •FIsAPathOrNotAPath
- •FIsARefNum
- •FIsEmptyPath
- •FListDir
- •FLockOrUnlockRange
- •FMakePath
- •FMClose
- •FMOpen
- •FMove
- •FMRead
- •FMSeek
- •FMTell
- •FMWrite
- •FName
- •FNamePtr
- •FNewDir
- •FNewRefNum
- •FNotAPath
- •FPathCmp
- •FPathCpy
- •FPathToArr
- •FPathToAZString
- •FPathToDSString
- •FPathToPath
- •FRefNumToFD
- •FRefNumToPath
- •FRelPath
- •FRemove
- •FSetAccessRights
- •FSetEOF
- •FSetInfo
- •FSetPathType
- •FStrFitsPat
- •FStringToPath
- •FTextToPath
- •FUnFlattenPath
- •FVolName
- •GetALong
- •HexChar
- •HiByte
- •HiNibble
- •IsAlpha
- •IsDigit
- •IsLower
- •IsUpper
- •LoByte
- •Long
- •LoNibble
- •LStrBuf
- •LStrCmp
- •LStrLen
- •LToPStr
- •MilliSecs
- •MoveBlock
- •NumericArrayResize
- •Offset
- •PPStrCaseCmp
- •PPStrCmp
- •Printf
- •PStrBuf
- •PStrCaseCmp
- •PStrCat
- •PStrCmp
- •PStrCpy
- •PStrLen
- •PStrNCpy
- •PToCStr
- •PToLStr
- •QSort
- •RandomGen
- •SecsToDate
- •SetALong
- •SetCINArraySize
- •StrCat
- •StrCmp
- •StrCpy
- •StrLen
- •StrNCaseCmp
- •StrNCmp
- •StrNCpy
- •SwapBlock
- •TimeCString
- •TimeInSecs
- •ToLower
- •ToUpper
- •Unused
- •Word
- •Glossary
Chapter 3 |
CINs |
Using C Code that is Thread Safe
The CINProperties function only labels your CIN as being safe to run from multiple threads. Whether the CIN is actually thread-safe depends entirely upon what C code has been written. For information about what makes C code safe or unsafe to be run from multiple threads simultaneously, please consult C programming documentation. The following list presents basic answers to the question, Is my CIN code thread safe?
•The CIN code is thread safe when it stores no unprotected global data (for example, no global variables, no files on disk, and so on); does not access any hardware (in other words, does not contain register-level programming); and makes no calls to any functions, shared libraries, or drivers that are not thread safe.
•The CIN code is thread safe when it uses semaphores or mutexes to protect access to global resources.
•The CIN call is thread safe when only one non-reentrant VI calls the CIN; and the code accesses no global resources through CIN
housekeeping routines, such as, CINInit, CINAbort, CINDispose, and others.
Creating a CIN
In general, to create a CIN, describe in LabVIEW the data you want to pass to the CIN. Then, write the code for the CIN using one of the supported programming languages. After you compile the code, run
a utility that puts the compiled code into a format LabVIEW can use. Then, instruct LabVIEW to load the CIN.
If you run the VI at this point and the block diagram needs to execute the CIN, LabVIEW calls the CIN object code and passes any data wired to the CIN. If you save the VI after loading the code, LabVIEW saves the CIN object code along with the VI so LabVIEW no longer needs the original code to execute the CIN. You can update your CIN object code with new versions at any time.
The examples directory contains a CINs directory that includes all of the examples given in this manual. The names of the directories in CINs correspond to the CIN name in the examples.
To create a CIN, complete the following steps.
© National Instruments Corporation |
3-3 |
Using External Code in LabVIEW |