Using LabVIEW Classes and LVOOP in Session-based APIs

[RDR]

What is a session-based API?

Many LabVIEW toolkits can be defined as session-based APIs where there is always a beginning and an end to an interaction with some object.  This could be an instrument driver like the DAQmx driver where the API is used to configure and control the DAQ board, an API for reading and writing to configuration (.INI) files, or even an API for communicating over TCP.   Session-based API is characterized by the definition "a period of time devoted to a specific activity".  We often see these session-based APIs with an initialization/configuration or 'open connection' operation, a series of operations to manipulate & control the session, and an ending or closing of the session.  This is a common model used for APIs in LabVIEW, let's take a look at DAQmx and the Configuration File palettes:

• A Configure HW - Read/Write Data - Clear Task session-based API model used in DAQmx for data acquisition
  

• A similar Create/Open File - Read/Write Data - Close File session-based API model is used with Configuration File I/O
  

Great, how does this relate to me?

As you can see in the images above and by browsing the palettes in LabVIEW, most LabVIEW APIs created by NI R&D have a unique reference data type (Instrument IO References, File I/O References, etc.), access to property & method nodes, and an associated wire color for the different reference types in these APIs.  To date, creating a new custom reference type has not been exposed to third-parties, which often results in third-party developers using a cluster to pass their session data between their API VIs.  However, LabVIEW classes provide some very useful features like defining custom wire appearances & property nodes.  Lets take a look at how LabVIEW classes can be used in our APIs.

In the image below, I have created a session-based API by defining my own ZIP File.lvclass.  Using a LabVIEW class lets me as the developer define my own custom wire appearance, which will set my API apart from other LabVIEW .ZIP toolkits and prevents my customers from attempting to accidentally misuse my API by combining it with other file I/O operations.  I also created a custom property for this API where, when called, behind the scenes it executes a VI to read the File Size for my .ZIP file.  The advantage of using a property node instead of a VI to read this property is you can combine multiple property operations into a single Property Node and avoid stringing together additional VIs on the block diagram.  This makes my API much easier for my customers to use.

This image displays a session-based API for working with .ZIP files that uses a LabVIEW class - notice the custom property node for reading the file size & the custom wire type.  I've attached the code below.

You mentioned LVOOP, where does it come into play?

In order to create the ZIP file API shown above, I used a tool created by Systems Engineering called the Extensible Session Framework (ESF) to generate the starter code & framework used in my session-based API.  This tool makes use of scripting, LVOOP and LabVIEW Classes to generate a template project and LabVIEW class framework with an architecture optimized for use in a session-based API.  Here are some of the features:

1. Multiple instances - You can instantiate multiple unique copies of your session, each with a unique string name to identify it. So if you have a session named "Serial Waveform" and want to generate multiple different serial messages in your program, you can do so by simply creating multiple wires and naming them uniquely.
2. Multiple accessors - Because the sessions are uniquely named, you can obtain a reference to any session that already exists from anywhere in your application space. This is analogous to the behavior provided by LV Notifiers and Queues.
3. LV Class features - Your session is implemented as a class in LabVIEW, so you get all the nice features of classes: encapsulation and inheritance, password protection of private methods, and (in LV 2010) native property nodes
4. Simple interface to C and TestStand - The session handle is a DVR to your class. This means that your methods, when called from TS or C/C++, only have to pass an integer (the DVR) to the caller. This is much much nicer than passing a cluster.

Please review the attached slide deck for an overview of the Extensible Session Framework and I encourage you to head over to the to view the accompanying example code & download their VI Package containing the tool used to generate ESF template classes as I have done:

Framework for creating Session-based APIs