Reference Design Content
Overview
The software solutions from National Instruments and OSIsoft—namely, LabVIEW and the PI System, respectively—each offer complementary and incredibly powerful tools for users who work with real-time sensor and process data. This Toolkit contains VIs that allow for simple, robust communication between National Instruments LabVIEW and the OSIsoft PI System, so that real-time data can be streamed in between the two. This empowers users of both software solutions with a far more cohesive set of real-time data capabilities, allowing, for example, data acquired from a National Instruments CompactRIO to be streamed through LabVIEW to an OSIsoft PI System for long-term archiving, real-time calculations, and on-the-fly visualization. This integration can also allow for real-time building or plant control system data that is collected by an OSIsoft PI System to be streamed into National Instruments LabVIEW for frequency-domain analysis.
Description
This integration between LabVIEW and the PI System allows users to stream data in both directions in between the two platforms. Before continuing, if a refresher on the terminology and architecture of an OSIsoft PI System would be helpful, see the following quick video tutorial from the OSIsoft Learning YouTube channel: https://youtu.be/18RgS8Y3JtQ.
Reading from an OSIsoft PI System
We will begin with a discussion of the approach used to allow LabVIEW to read live data from an OSIsoft PI System. The approach specifically relies on OSIsoft’s PI AF SDK (see https://techsupport.osisoft.com/Documentation/PI-AF-SDK/html/1a02af4c-1bec-4804-a9ef-3c7300f5e2fc.ht...), which is a .NET Framework-based library that provides direct programmatic access to any data stored within a PI System. The PI AF SDK can be made available for access within LabVIEW by installing the PI System Explorer client tool on the same Windows PC where LabVIEW is installed. The PI AF SDK can then be directly invoked from within LabVIEW via the LabVIEW native .NET Functions palette, which comes standard within a LabVIEW installation (see http://zone.ni.com/reference/en-XX/help/371361N-01/lvcomm/dotnet_pal/). Thus, this toolkit’s approach for allowing LabVIEW to read data from a PI System comprises a set of four sub-VIs that allow a user to perform each of the following steps needed to query data from a PI System (listed in the order in which they would be used together):
1. "Connect to AF Server.vi": Connect to a PI System, which requires specifying the hostname, FQDN, or IP address of that PI System
2. "Find AF Attribute.vi": Next, find a PI AF attribute (i.e. a data item within a PI System) to query for data, which requires specifying the path to that attribute within the OSIsoft PI System (the path for a particular data item, such as the temperature value of a temperature sensor that is monitored by the OSIsoft PI System, can be looked up from within the PI System Explorer client tool)
3. "Get Archive Values.vi": Then, query that PI AF attribute for a range of archive values, which requires specifying the start and end times for that query (using PI time syntax; for more on this, see https://livelibrary.osisoft.com/LiveLibrary/content/en/server-v11/GUID-2946A11C-6D35-43D2-AAA2-B002D...)
4. "Get Snapshot Value.vi": AND/OR query that PI AF attribute for the single most recent value, also referred to as the “snapshot” value, which doesn’t require specifying any inputs
Again, the sub-Vis contain the LabVIEW .NET palette nodes needed to call the PI AF SDK functions to accomplish all of the above four tasks needed to read data from a PI System into LabVIEW; feel free to inspect each of the sub-Vis to examine how specifically those SDK calls are made.
Below are screenshots of the block diagram and front panel of an example that uses all of the sub-Vis together:
The result of a query for archive values of snapshot values is either an array of or a single instance of a “data event” cluster, which contains the timestamp and value of a particular data event. You can see exactly what those results can look like in the example VI, “Read Data from PI System via AFSDK (Windows).vi”, which shows an example of how you can query for archive and snapshot data and, moreover, how you can unbundle the returned results and plot them on a chart.
The below animation shows how this example can be used; in the animation, you can see a user specify the start and end time for the query, then copy and paste the path for a particular PI AF attribute from the PI System Explorer client tool into the LabVIEW VI, and then finally extract the PI AF Server name (the first token in the path) from that path, so that the PI AF Server name can be pasted into the appropriate input in the VI. When the VI is run, you can then see how data will be retrieved and displayed within plots; that data can also be analyzed using any of the other capabilities of LabVIEW.
Writing to the OSIsoft PI System
The transmission of data in the opposite direction, from LabVIEW to the OSIsoft PI System, is accomplished using a different method, one that allows cross-platform data transmission from LabVIEW running on any host to a target PI System. (This is in contrast with the previous integration for reading data from a PI System into LabVIEW, which, by relying on the .NET Framework AF SDK, can only be used from LabVIEW running on a Windows PC.)
Sending data from LabVIEW to the OSIsoft PI System specifically relies on the OSIsoft Message Format (see https://omf-docs.readthedocs.io), a specification that defines a straightforward set of rules for how messages can be structured in order for them to be accepted by a PI System. The LabVIEW sub-VIs in this toolkit were thusly designed to form data from LabVIEW into JSON strings, following the specification outlined by the OMF documentation, and then transmit that JSON as HTTPS web requests to an installation of the PI Connector Relay, a free additional software component to the PI System that accepts and parses OMF-specification messages. Those HTTPS web requests are issued from within LabVIEW using the HTTP Client VIs that come standard with a LabVIEW installation (see http://zone.ni.com/reference/en-XX/help/371361M-01/lvcomm/http_client/).
Altogether, the sub-VIs (and sub-sub VIs) in this part of the Toolkit allow a user to perform each of the following steps needed to send data from LabVIEW to a PI System (listed in the order in which they would be used together):
1. "MakeAndSendInitialOMFJSON.vi": Make and send the one-time, initial OMF JSON messages, which prepares the target PI System to later receive continuous live data messages. This comprises two sub-Vis that perform the following:
A. "MakeInitialOMFJSON.vi": Making the initial OMF JSON, using Text Builders, which takes in several user inputs and formats them into the required initial OMF JSON messages; this includes making JSON messages for:
i. The OMF dynamic and static types, using the property names, formats, and (for static properties) values (see https://omf-docs.readthedocs.io/en/v1.0/Type_Messages.html)
ii. For an OMF container, which is used for sending later live data messages (see https://omf-docs.readthedocs.io/en/v1.0/Container_Messages.html)
iii. An OMF data message that creates an instance of a PI AF Element using that OMF static type (see https://omf-docs.readthedocs.io/en/v1.0/Data_Messages.html)
iv. OMF links that position that AF Element within an AF Database and that associate it with the dynamic properties (PI Points) that are created for holding the live data values (see https://omf-docs.readthedocs.io/en/v1.0/Link_Type.html)
B. "SendInitialOMFHTTPSPOSTS.vi": Sending those initial OMF JSON messages, which uses the HTTP Client VIs to direct outgoing OMF messages at the target PI Connector Relay URL (which the user specifies as an input parameter), with each outgoing message including in an HTTP message header (see https://omf-docs.readthedocs.io/en/v1.0/Headers.html) the OMF Producer Token (another input parameter, which a user can look up from the PI Data Collection Manager) needed to authenticate those messages
2. "MakeAndSendDataValuesOMFJSON.vi": Making and sending the continuous OMF JSON messages, which contain live data values (e.g., from sensors read by LabVIEW) and timestamps that will be send to the target PI System and stored in PI Points; this is often done in a timed loop, to send out new data values every few seconds, for example (as shown in the included example). This comprises two sub-Vis that perform the following:
A. "MakeDataValuesOMFJSON.vi": Making the data values OMF JSON message (see https://omf-docs.readthedocs.io/en/v1.0/Data_Messages.html), again using Text Builders, which also involves adding the current timestamp, formatted as required by the OMF specification (see https://omf-docs.readthedocs.io/en/v1.0/Type_Properties_and_Formats.html) to the outgoing message
B. "SendDataValuesOMFHTTPSPOSTS.vi": Sending out those continuous OMF JSON messages, again, using the HTTP Client VIs. Any error messages that occur at this step, or at any of the previous steps, can be printed out (as shown in the example); for details on what error status codes could mean, see https://omf-docs.readthedocs.io/en/v1.0/Standard_Responses.html
It is worth noting that since the OSIsoft Message Format simply defines a specification for messages, an application can be written to generate OMF messages in nearly any programming language. For other examples that have been written in other languages, and for other platforms (which may be helpful in comprehending the structure of this LabVIEW example), see https://github.com/osisoft/OMF-Samples.
Below are screenshots of the block diagram and front panel of an example that uses all of the sub-Vis together:
The result of this is that a PI AF element template will be created automatically, with static AF attributes that correspond to the static type properties (with the user-specified names, formats, and values), along with an instance of that template (a new AF element). That template (and the instance of it) will also have dynamic attributes that map to new PI Points (which will also be created automatically) that will receive and store the live data values sent from LabVIEW.
The below animation shows how this example can be used; in the animation, you can see that the VI is configured to send random data from random number generators, to simulate an actual data source. In the animation, the user looks up the correct value for the Ingress URL and Producer Token from the PI Data Collection Manager, then, when the example is run, a new PI AF Element is created within the OSIsoft PI System (which is seen within the PI System Explorer client tool), using the name and property names specified in the VI. Furthermore, you can also see that PI Points are created to store the continuous streams of data that are sent from LabVIEW to the PI System, and that as the user in PI System Explorer refreshes the client, those data values change in real-time as new values are received from LabVIEW.
The default example for sending data as OMF sends along data that simulates X, Y, and Z acceleration data from a three-axis (X, Y, and Z) accelerometer, along with a sample string data item and a pair of static properties. A second example is also included that sends real, live data from a myRIO’s built-in three-axis accelerometer; this example works identically to the example that sends simulated data, only the random simulators are replaced with direct readings taken from the myRIO’s internal accelerometer.
Software Prerequisites
These examples require that an OSIsoft PI System be available and equipped with the correct Connector software for receiving data from the LabVIEW VIs. All OSIsoft software can be downloaded from the OSIsoft Tech Support site Downloads page, https://techsupport.osisoft.com/Downloads/All-Downloads.
Specifically, to send data from LabVIEW to a PI System using OMF, you will need to download and install the PI Connector Relay and PI Data Collection Manager, version 2.2 or higher (see https://livelibrary.osisoft.com/LiveLibrary/content/en/con-admin-v3/GUID-DACC6B99-478E-4025-8C7C-29F...). After installing and configuring those two components, the VIs in this toolkit require that you look up the values of the Relay Ingress URL and Producer Token, which you’ll enter in as inputs to the Toolkit sub-VIs; for more on where to find the Relay Ingress URL and Producer Token, see https://livelibrary.osisoft.com/LiveLibrary/content/en/con-admin-v3/GUID-F0C0C524-EB8D-4951-A1F8-707....
Additionally, to read data into LabVIEW from a PI System, using the PI AF SDK, you must also install the PI AF Client (also known as PI System Explorer) on the same Windows machine from which you are running the LabVIEW VIs (see https://livelibrary.osisoft.com/LiveLibrary/content/en/server-v11/GUID-2DA60D77-90D8-4D80-9380-4FB1A...).
Regarding licensing, when using the read VIs to read data from the PI System into LabVIEW via the AF SDK, that source PI System must have a valid PI System Access license for allowing use of the AF SDK. Writing data to a PI System via OMF, through the PI Connector Relay, is at no additional cost and requires no additional licensing. For questions and concerns regarding licensing, please contact your OSIsoft Account Manager or Partner Manager.
Support
For general assistance with OSIsoft software, such as the PI Connector Relay, call or send email to OSIsoft Tech Support. OSIsoft Tech Support can be reached at any hour of the day, any day of the week, and any day of the year at techsupport@osisoft.com, and for a full list of regional OSIsoft Tech Support phone numbers, see https://techsupport.osisoft.com/Contact-Us/. For questions specific to this LabVIEW-PI System integration, please direct emails to nationalinstruments@osisoft.com.
Discussion
Feel free to open or join a discussion topic thread on the OSIsoft PI Square Community forums: https://pisquare.osisoft.com/. Full access to PI Square requires an OSIsoft Tech Support account (which is also required for downloading software from the Tech Support site); sign up for free at http://login.osisoft.com/Registration.aspx.
