Company Events Academic NI Developer Zone Support Solutions Products & Services Contact NI MyNI

Using CINs versus Call Library Function Nodes

LabVIEW 8.5 Help
August 2007

NI Part Number:
371361D-01

»View Product Info
Note   In most cases, a Call Library Function Node is easier to use than a CIN. Assuming the underlying code is the same, the calling speed is the same whether you use a Call Library Function Node or a CIN.

The LabVIEW Call Library Function Node and the CIN are block diagram objects that link source code written in a conventional programming language to LabVIEW. They appear on the block diagram as icons with input and output terminals. Linking external code to LabVIEW includes the following actions:

  1. You compile the source code and link it to form executable code. If you already have a compiled DLL, this step is not necessary.
  2. LabVIEW calls the executable code when the Call Library Function Node or CIN executes.
  3. LabVIEW passes input data from the block diagram to the executable code.
  4. LabVIEW returns data from the executable code to the block diagram.

The LabVIEW compiler can generate code fast enough for most programming tasks. Call CINs and shared libraries from LabVIEW to accomplish tasks a text-based language can accomplish more easily, such as time-critical tasks. Also use CINs and shared libraries for tasks you cannot perform directly from the block diagram, such as calling system routines for which no corresponding LabVIEW functions exist. CINs and shared libraries also can link existing code to LabVIEW, although you might need to modify the code so it uses the correct LabVIEW data types.

CINs and shared libraries execute synchronously, so LabVIEW cannot use the execution thread used by these objects for any other tasks.

LabVIEW cannot interrupt object code that is running, so you cannot reset a VI that is running a CIN or shared library until execution completes. If you want to write a CIN or shared library that performs a long task, be aware that LabVIEW cannot perform other tasks in the same thread while these objects execute.

Details of the Call Library Function Node

You can call most standard shared libraries with the Call Library Function Node. On Windows, these shared libraries are DLLs, on Mac OS, they are Frameworks, and on Linux, they are Shared Libraries. The Call Library Function Node includes a large number of data types and calling conventions. You can use the Call Library Function Node to call functions from most standard and custom-made libraries.

DLLs have the following advantages:

  • You can change the DLL without changing any of the VIs that link to the DLL, provided you do not modify the function prototypes.
  • Practically all modern development environments provide support for creating DLLs, while LabVIEW supports only a subset of development environments for creating CINs.
  • In some cases, you may want to perform additional tasks at certain execution times. For this purpose, the Call Library Function Node provides three entry points—Reserve, Unreserve, and Abort. For example, you may want to initialize data structures at reserve time for the Call Library Function Node or free private data when the Call Library Function Node is unreserved or aborted. For these situations, you can write and export routines from your DLL that LabVIEW calls at these predefined times. You can configure these entry points on the Callbacks page of the Call Library Function dialog box.

The Call Library Function Node is most appropriate when you have existing code you want to call, or if you are familiar with the process of creating standard shared libraries. Because a library uses a format standard among several development environments, you can use almost any development environment to create a library that LabVIEW can call. Refer to the documentation for your compiler to determine whether you can create standard shared libraries.

Details of a CIN

The CIN is a general method for calling C code from LabVIEW. You can pass arbitrarily complex data structures to and from a CIN. In some cases, you might have higher performance using CINs because data structures pass to the CIN in the same format that they are stored in LabVIEW.

CINs have the following advantages:

  • The CIN code is integrated into the code of the VI, so there is no extra file to maintain when the VI is distributed.
  • CINs provide certain special entry points, such as CINLoad, CINSave, and so on.

In some cases, you might want a CIN to perform additional tasks at certain execution times. For example, you might want to initialize data structures at load time or free private data structures when the user closes the VI containing the CIN. For these situations, you can write routines that LabVIEW calls at predefined times or when the node executes. Specifically, LabVIEW calls certain routines when the VI containing the CIN is loaded, saved, closed, aborted, or compiled. You generally use these routines in CINs that perform an ongoing task, such as accumulating results from call to call, so you can allocate, initialize, and deallocate resources at the correct time. Most CINs perform a specific action at run-time only.

To create a CIN, you must be an experienced C developer. Also, because CINs are tightly coupled with LabVIEW, restrictions exist about which compilers you can use.

After you write your first CIN, writing new CINs is relatively easy. The work involved in writing new CINs is mostly in coding the algorithm because the interface to LabVIEW remains the same, regardless of the development system.


Resources


 

Your Feedback! poor Poor  |  Excellent excellent   Yes No
 Document Quality? 
 Answered Your Question? 
Add Comments 1 2 3 4 5 submit