cancel
Showing results for 
Search instead for 
Did you mean: 
Knowledge Base

Reference Design Content

Top Contributors
Sort by:
CompactRIO-based reference design for developing embedded high speed data acquisition, monitoring and data logging applications  
View full article
One of the projects included in the effort is a set of tools intended to be used while developing code in LabVIEW. For example, this could include tools for arranging front panel items to match their terminals, ensuring that all front panels meet a minimum size requirement, or any other development-focused utilities.   The source code for this project is located in this repository: https://github.com/NISystemsEngineering/LV-Dev-Utilities   The repository is covered by the BSD 2-Clause license and may be forked freely by any GitHub user.   The current alpha build, attached, includes the following utilities. They are installed to VI lib, and a tools menu item is installed as "LabVIEW Development Utilities".   This initial version of the code includes three tools: A tool/framework for applying a set of functions to a set of VIs. This tool uses the Configuration Editor Framework (CEF) to produce a simple UI for running code to modify VIs in bulk. The idea is that these functions can be used to apply common style requirements to an entire codebase. Each function is a class, and these classes are stored in vi.lib\NI\LabVIEW Utilities\Apply changes to VIs Tool\tools. At present, the available functions include: Reset to origin -- Moves all front panels back to center on the origin. Set source seperate -- Walks through existing code to set it as source separate, similar to the project tool Protection Settings -- Locks or unlocks VIs, and can set passwords Execution settings -- Modified reentrancy, debugging, and error handling Cosmetic change -- Resizes the front panel and moves it to the primary monitor Control label adjustment -- Can reset the selected font and size of a set of VIs The VI documentation tool currently found here: VI Properties Editor   If you have any code which you think would be a good fit for this repository, if you'd like to make changes to the existing code, feel free to fork the repository and work on it.
View full article
In distributed applications using the current value table (CVT) there is a fundamental need to pass CVT data between hosts. This document describes one method of communication between CVT instances using a TCP/IP client/server protocol.   As an example, this document uses a machine control system consisting of a machine controller and an HMI. It assumes the reader is generally familiar with the machine control reference architecture. Throughout this document the term client refers to the device that serves as the HMI and the term server refers to the device that contains the logic and I/O for handling the machine control.   This attached file contains an installer for the CVT Client Communication (CCC) reference library, which provides a LabVIEW application programming interface for communication between CVT instances in a distributed system.   Description   The primary function of the client communication interface is to share information between CVT instances on the server and the client.  This is done by mirroring portions of the CVT from one side to the other and vice versa.  Generally speaking, there will be certain tags on the server that the client has an interest in.  By the same token, there will be information on the client that needs to be passed down to the server.  For example, if we want to control temperature, then the client needs to send setpoints to the server and then monitor the temperature readings returned by the server.   In applications involving hundreds or perhaps thousands of tags, the importance of efficient communication becomes obvious.  TCP/IP is a standard protocol that is relatively simple yet it offers high throughput and scales well for high-channel-count systems.   Implementation   The CVT client communication interface is made up of two separate elements.  The server portion of the interface acts as a TCP server and consists of a command parser which processes requests for data from the client.  The client portion of the interface acts as the TCP client and initiates the communication with the server.  It then sends commands to the server for configuring and sending/receiving data.   Figure 1 - CVT Client Communication Overview   The client communication protocol implementation emphasizes performance optimization by configuring as much as possible on the first call, leaving the repetitive operations with less work to do.  Accordingly, the protocol is implemented in such a way that the client must first identify all of the tags of interest using the "Bound Address" parameter.  On the first execution the server looks up the tags by their index in the CVT.  From that point forward, only the CVT index API is used to ensure the highest possible performance.   On both the client and server components, all of the repetitive operations are implemented with determinism in mind.  They allocate all of the necessary resources on the first call of each function and use a functional global variable to store blocks of data between iterations, ensuring that no memory allocation takes place after the first iteration.   The underlying implementation is TCP/IP.  Specifically, it is an adaptation of the Simple Messaging Protocol (STM), which offers a platform-independent way of sending messages by name while maintaining the performance and throughput of raw TCP communication.   The STM messages for the CVT client communication interface are:   Configure Write – Prepares the server for receiving a block of tags Configure Read – Prepares the server for sending a block of tags Write Block – Writes a block of tags to the server Read Block – Instructs the server to send its block of tags Data – The server’s reply to the “Read Block” command Error – Reports an error Disconnect – Instructs the server to close the client connection   API The CCC server is a VI that is designed to run in parallel with the rest of the application.  This allows the rest of the machine control to execute asynchronously, offering better control over the application timing.  The server API provides functions for starting and stopping the CCC server.  The CVT needs to be initialized prior to calling CCC Start Server.vi. Figure 2 - CCC Start Server.vi Figure 3 - CCC Stop Server.vi   The client API follows the familiar LabVIEW style of Initialize, Write, Read, and Close.  CCC Client Init.vi is responsible for initiating the connection with the server.   Figure 5 - CCC Client Init.vi   Rather than specifying the CCC Tag List as a constant or control, it is generally desirable to load the configuration from a file, such as a tag configuration file. Using a file allows you to modify the available tags and the properties of tags without having to modify the code of your program.   CCC Client Write.vi configures and writes a block of data to the server.  Any client tags that are configured as network tags and are designated as “write” tags will be sent to the server.   Figure 6 - CCC Client Write.vi   CCC Client Read.vi configures and reads a block of data from the server.  Any client tags that are configured as network tags and are designated as “read” tags will be read from the server.   Figure 7 - CCC Client Read.vi   CCC Client Synchronize Data combines the functionality of Client Write and Client Read in one function, reducing the communication overhead between client and server.     CCC Client Close.vi simply closes the connection to the server.   Figure 8 - CCC Client Close.vi Examples In most cases both the server and client elements of the interface can be used as drop-in components.  The server needs only to have the TCP port configured (default is 54444) and the client will need the server’s IP address and port number. Figure 9 - CCC Example - Server.vi   In the corresponding client application, you can see that the CCC Synchronize operation is performed in series with the rest of the HMI code.  This ensures that the values for both the read and the write tags are updated on each iteration.   Figure 10 - CCC Example - Client.vi   The client tag list is shown here for reference.  As you can see, each tag on the client has a corresponding server tag’s name in the “Bound Address” field.       Figure 11 - Client Tag List     Installation and Requirements Installation   The CVT Client Communication (CCC) Library is available for installation from VI Package Manager™.   Install CCC     Requirements   The CVT Client Communication reference library requires the following software:   LabVIEW 2010 or later Simple Messaging Protocol (STM)  reference library Current Value Table (CVT) reference library   Additional information on features, installation and licensing are available in the ReadMe file included in the attached source distribution.   Older Version   Installers for previous versions of the CCC library are attached below to provide compatiblitiy applications built with these versions. For new development you should always use the latest version available in VI Package Manager.   Version 2.0   ccc200 Installer requires LabVIEW 8.6. ccc200 Zip provides a source code distirbution   Version 1.0   ccc100 Installer is included for compatibility with LabVIEW versions earlier than 8.6. Support   Please submit your feedback in the CVT Client Communication (CCC) discussion forum so that we can improve this reference library for future applications.   Please direct general product support questions to NI Technical Support.
View full article
Overview Since 2013, National Instruments has been shipping real-time targets with NI Linux Real-Time, a Linux distribution specifically built to support real-time applications. NI Linux Real-Time targets support SSH connections that enable a remote application to execute commands at the OS level. Intermediate and advanced Linux users can leverage this important feature to execute various tasks such as installing or running third-party software on the target, altering the file system, debugging the OS or any running LabVIEW application, and retrieving system-level information.   Description ShellRT is a small add-on that allows quick access to a remote console window of a Linux Real-Time target from the LabVIEW project explorer. Developers can interact with a selected target without leaving the LabVIEW environment, thus improving the overall development experience using the Linux Real-Time hardware platform.     This utility provides quick access to a remote console to improve the development experience with our LinuxRT Real-Time targets.   Features Open a remote shell from the LabVIEW project window Facilitates interactions with NI Linux Real-Time targets by executing supported Linux commands Ideal for intermediate or advanced developers Offers a logging mode to debug onboard behaviors. Allows multiple shell consoles to be used in parallel to execute independent tasks (2.0 and later) Allows path autocompletion pressing the Tab key when typing a command (2.0 and later)     Requirements Windows 7/8/10 LabVIEW 2015 LabVIEW 2015 Real-Time Module NI-RIO 15.0    Support Please post questions, comments, and feedback on this utility in the comments below.   History   Version Description 2.0.0.2 - Added possibility to have multiple opened shells (create a new shell with Ctrl+N after authentication). - Added path autocompletion when pressing Tab key while typing a relative or absolute path. - Fixed an issue when the NI ShellRT made LabVIEW crash if the authentication was wrong. - Fixed an issue with key focus on the command which preventing copying text from the console. 1.1.0.1 - Fixed an issue where not all possible LinuxRT targets were supported. Now supports all LinuxRT targets except Ethernet-RIO. - Fixed an issue where the console UI was modal and prevented any further action in the LabVIEW IDE. - Added auto-enable SSH feature from the LabVIEW project. - Fixed an issue where the console UI help was not working from the contextual help. 1.0.0.8 Initial Release   Download NI ShellRT 2.0.0.2
View full article
The LabVIEW Replication And Deployment (RAD) Utility is a turn-key utility for creating and deploying application images for LabVIEW Real-Time applications. It is based on the NI System Configuration API and designed to easily replicate the image (disk content) of a LabVIEW RT target (CompactRIO, PXI, FieldPoint) from one master target system to other target systems as part of an application installation process.   A detailed description of the RAD utility is available in http://www.ni.com/example/30986/en/.       Support   Please post comments, feedback and questions in the following Discussion Forum: http://forums.ni.com/ni/board/message?board.id=RTControl&thread.id=18   Downloads   Utility Version 5.5.2 – Built with LabVIEW 2012 Download the Replication and Deployment (RAD) Utility 14.0 Requirements:  NI System Configuration (14.0.1 or higher recommended) Optional: NI-RIO Driver Source Code RAD 14.0 Source
View full article
This TLB` (prime) template is a basic application VI design to create system components.  
View full article
LabVIEW-based reference application for basic temperature control applications, designed to run on CompactRIO and other LabVIEW-RT targets.
View full article
Please submit any bug reports, issues, or feature requests for the following reference designs:   Current Value Table (CVT) - https://github.com/NISystemsEngineering/CurrentValueTable/issues CVT Client Communication (CCC) - https://github.com/NISystemsEngineering/CVTClientCommunication/issues   Reference Design Repositories on GitHub - https://github.com/NISystemsEngineering  
View full article
Due to a particular need I went ahead and created a new version of the CIE which supports the newest version of the CVT. At present it is incompatible with prior versions of the CIE, and I'm not sure it is feasible to create a compatibility layer. On the plus side, this new version now supports non-local I/O, including I/O from networked ethernet devices like the 9148.   The included example (installed to <LabVIEW>/Examples/CIE) shows how to discover non-local I/O. I minor bug with this example is that one must set the "PSP/IOV" boolean to true. This will be resolved with the next build.   Feedback is welcome. This is an initial release so there may be unforseen issues, but the code is significantly simpler than version 2.0, making it easier to detect bugs.
View full article
This library provides enhanced functionality for handling INI configuration files. Instead of using the Config File VIs included in LabVIEW, use the like-named top-level VIs in Enhanced Config.llb, or access them via the Config Main folder in Enhanced Config.lvlib.
View full article
This Reference Design is replaced by the Configuration Editor Framework (CEF). Code and Documentation: http://zone.ni.com/devzone/cda/epd/p/id/6249 Discussion Forum: http://forums.ni.com/ni/board/message?board.id=Components&thread.id=241 System configuration is a large task for application architecture. In  an attempt to make system configuration easier for designers as well as  end-users, configuration editors are often implemented.  This article  accesses the common features of configuration editors, and presents an  implementation of a Generic Configuration Editor (xCE) for LabVIEW.
View full article
Code and Documentation: http://zone.ni.com/devzone/cda/tut/p/id/9851 Discussion Forum: http://forums.ni.com/t5/Sound-Vibration-Applications/cRIO-Reference-Designs-for-Structural-Health-Monitoring/m-p/950965 This document presents CompactRIO reference designs  with a focus on structural health monitoring applications.
View full article
We are updating the TCE. This update will allow it to work with the latest version of the CVT, and be able to use the new features from it. Some changes will be making will affect how the tags are displayed in the tree, and adding additional functions like multiple variable editing and filtering.  If you have any feedback on using this tool please let me know what features you like and would still require in the new version. The new version will be able to import configurations created in the previous version. We are considering removing the folders of the editor, and allow creating Groups as defined in the new CVT. Is anyone using the folders or have several layers of the folders? How many tags have your biggest projects using TCE? Thank you for the feedback Benjamin Celis
View full article
A proxy mechanism to allow LabVIEW programs to easily write out to the command line.   Libary and component shared by Wiresmith Technology.     Source Code and Documentation:  https://github.com/JamesMc86/LabVIEW-CLI     Questions and comments about the code itself, should be posted to the Github repository of the code: https://github.com/JamesMc86/LabVIEW-CLI/issues
View full article
The Event Logger Library (ELL) provides an API for logging user events and errors to disk. Description The Event Logger Library is an event logging API which supports two different event file types: TDMS and CSV.  The ELL works by storing events in a buffer and then flushing the events to disk at a user defined interval. It is recommended to use the Event Logger Library in conjunction with the LogRotate Library in order to control the size of the event log file. Examples Below is a screenshot of an example of user the ELL: Requirements Software LabVIEW 2012 Support Please post comments, feedback and questions in the comments below. History Version Date Description/Changes 1.0.0.8 July 2013 Initial Release 1.0.0.9 April 2016 Fixed issue related to the timestamp formatting for CSV files Downloads Use VI Package Manager (VIPM) to install this library. Event Logger Librar on VIPM
View full article
The Watchdog Process library uses the Software Watchdog library in conjunction with the RT hardware watchdog to make sure that all of the processes registered with it are still operating in a timely manner.  This process is meant to be executed on a real-time target and will reboot the target if one of its registered processes does not respond as expected.   Examples   The Watchdog Process Library will run asynchronous to the rest of the application and make sure that all of the other processes continue to run.     Requirements   Software LabVIEW 2015 LabVIEW 2015 Real-Time Module Hardware LabVIEW Real-Time Target   Support   Please post comments, feedback and questions in the comments below.   History       Version Date Description/Changes 1.0.0.24 March 2016 Initial Release                 Downloads   Use VI Package Manager (VIPM) to install these libraries.   Software Watchdog Library Watchdog Process Library
View full article
This library controls the blink behavior of the USER1 LED on the front panel of a CompactRIO controller. Description Actions Performed: Defines and implements the default behavior of the USER LED: blinking at a rate of once every two seconds after the device starts up. Implements custom LED behvaior that other processes request, such as blinking twice per second when a process returns an unhandled error. Examples The palette for the Blink Process Library can be found under Addons. The process will run asynchronously next to the rest of the application. Requirements Software LabVIEW 2015 LabVIEW 2015 Real-Time Module Qbus Messaging Libary Watchdog Process Library Hardware CompactRIO NI-RIO 15.0 References <links to related information or content> Support Please post comments, feedback and questions in the comments below. History Version Date Description/Changes 1.0.0.2 March 2016 Initial Release Downloads Use VI Package Manager (VIPM) to install this library. Blink Process Library on VIPM
View full article
This process implements timer tasks that other processes register by sending Qbus messages to those processes. When a process registers a timer task, the Timer process sends a particular type of Qbus message at a configurable time interval to cause the original process to execute the desired subdiagram. This works similarly to a callback in that this process can also return a value along with the name of the subdiagram to execute. Description Actions Performed Creates a new timer task a process registers it. Ensures only instance of a task with a particular name exists by overwriting previous versions with the most recent one. Starts counting time upon receipt of the RegisterTimerEvent message. Evalutes whether any timers for registered timer events have expired. Initiaties the callback action by sending a routed message to the originating process. Recall that you specify the return process, message name, and message value when you register an event, so this process uses that information to create the routed message. If the event type was to be performed a single time, removes the task from the internal list of timer tasks. Unregisters a task upon receipt of an Unregister message whose value is the name of that task. Examples The palette for the Timer Process Library can be found under Addons. The process will run asynchronously next to the rest of the application. Requirements Software LabVIEW 2015 Qbus Messaging Libary Watchdog Process Library Support Please post comments, feedback and questions in the comments below. History Version Date Description/Changes 1.0.0.2 March 2016 Initial Release Downloads Use VI Package Manager (VIPM) to install this library. Timer Process Library on VIPM
View full article
<Short overview of the content - what does it do, how does it help the user> Description <Longer description of the content, when to use it, common use cases.> Examples <Example of using the code, include screen shots of code or diagrams> Requirements Software <software requirements, what version of the IDE, additional modules, toolkit or reference/resue code required> Hardware <hardware requirements if applicable> References <links to related information or content> Support Please post comments, feedback and questions in the comments below. <Modify if you want users to post questions in a different location> History Version Date Description/Changes <0.5> 1/1/10 <Initial Release> Downloads <links to download code, if not attached to this document>
View full article
Version 3 of the Current Value Table (CVT) introduced some significant changes in the library. This document provides a summary of these changes as well as some comparative performance benchmarks. Changes in CVT v3 Addition of new data types (all scalar types). The API has been changed to a polymorphic implementation to allow easier selection of the correct data type. Tags can be added or removed from groups which can be referenced as a single item. Numerous tags of a single data type can be referenced in a set, allowing for much faster data access. Tag management VIs have been rewritten to provide large performance gains. API calls have been modified to implement a smarter lookup process. Utility VIs allow users to save the entire CVT to an XML file. A compatibility layer is included to ensure compatibility with tools like the CIE and CCC which rely on version 2 of the CVT API. Runtime performance has been improved across the board. See below for details. Tags can be added at any point during runtime. Implementation of CVT v3 The Current Value Table is implemented in a two layer hierarchy consisting of core VIs and API VIs. The core contains all of the functionality of the CVT, including the data storage mechanism and additional service functions. The API VIs provide access to the CVT functionality in a simple interface. There are a few sets of API functions that provide slightly different access to the CVT and vary in flexibility and performance, as well as easy-of-use. The core data structure consists of two VIs which support tag management for the entire CVT, and an additional data storage VI for each data type supported. The Memory Block polymorphic function stores all data for the system, and consists of a single VI for every data type supported. This functional global variable allows you to clear memory, read or write a single value in memory, and read or write a set of values in a single call. The Tag List and Group List functions store all information necessary for the access and management of that data. The tag list stores the name, type, description, and memory location of each tag. The group list stores information about any groups formed in the table. Both of these functions store information by name in the form of variant attributes. Variant attribute "get" and "set" functions provide an extremely fast lookup which is superior to a linear array search for data sets larger than approximately 40 tags. API in CVT v3 The CVT contains a number of API function sets to provide different interfaces that can be chosen according to the needs of an individual application. The basic API provides simple write and read functionality. The additional APIs provide a higher performance interface to the CVT, but place some restrictions on the application when using the CVT. All three APIs share the same common core VIs and can be used in conjunction with one another, so you can choose the appropriate function for each individual access to the CVT. Create Tags Before the CVT can be used to store and retrieve data it needs to be initialized. Initialization allocates memory for contained tags, forms any groups specified, and stores any user-defined metadata. The initialization of the CVT is defined using a cluster array that contains the attributes of all variables used by an application. Version 3 of the CVT introduces a new cluster which allows the system to handle new features like groups. This cluster is incompatible with the cluster used in prior versions of the library, but a conversion VI is provided for backwards compatibility. This cluster can be created as a constant on the diagram or loaded from a file. Version 3 of the CVT also adds the ability to create new tags as needed during runtime, without overwriting existing tags. The initialize VI allows the user to select whether or not they wish to clear the CVT. Standard API The standard API contains functions to read and write data items in the CVT using the variable name as an identifier. Using the basic API the variable name can be a static string or can be created at runtime using the LabVIEW string functions. In the API call, the variable name is used to lookup the index of the variable and then the value is accessed in the using the index. To improve performance, version 3 of the CVT only performs the lookup on the first call, if the lookup previously failed, or if the tag name input changed from the previous iteration. This API uses polymorphic VIs to switch between data types. For writes, this data type is selected automatically based on the wire type. Reads can be selected by providing a default value or by manually selecting a type. The appearance of the VI will change based on the instance selected. Static API The Static API is very similar to the standard API. However it requires that you use a static name (constant string) in your application when accessing a variable. This restriction allows each instance of the Static API to only perform the variable index lookup operation once on the first call to each instance. It then buffers the index for subsequent accesses providing a significant performance advantage when repeatedly reading or writing the same variable in the CVT. Version 3 of the CVT also allows the static API to perform the lookup again if an error occurred, rather than relying on the "first call?" primitive. This API can be distinguished by the inclusion of a small glyph which indicates that the lookup value is stored internally. Advanced API The Advanced API provides even better performance with the tradeoff of requiring the application-level code to perform the lookup. Using the Advanced API you use two VIs to access a value in the CVT. The first VI is used to retrieve the index and type of a variable in the CVT. This step is only performed once for each variable used. Then the index is used to access the variable value. This provides the thinnest possible API to repeatedly access the same value in the CVT. For sets of tags which share the same data type, the Advanced API can be used to further boost performance by eliminating the sub-VI overhead of each lookup in memory. Performance will vary, but a rule of thumb is to use set of indices any time you wish to access three or more tags of the same type. Because tag names themselves are untyped, the Advanced API look-up function returns the tag type along with the references in order to provide a type confirmation to the application code. Group API Sometimes, it can be beneficial to attach a name to a set of tags of varying data types rather than referencing each tag individually. Version 3 of the CVT adds a group API which allows the user to read or write a set of tags simultaneously. One method for forming a group is to create the group during initialization. Groups can also be formed at run-time. Once a group has been formed, it can be accessed by the group name rather than the individual tags. Similarly to the Basic API, a look-up will only be performed if the group name changes or if an error occurs. Users cannot modify an already formed group, but groups can be deleted and reformed using this API. Care should be taken to ensure that tags are looked up after a group has been deleted or reformed. Once the lookup has been performed, the group can be read as a whole, in the order specified. Utilities Functions In addition to the VIs that access the stored variable values, the CVT also provides utility VIs to access additional properties or attributes of each variable or group. Read Tag Description.vi provides a tool for retrieving the stored description of a tag. List Grouped Tags.vi and List Grouped Tags By Type.vi provide a utility for retrieving the members of a group. The first function returns the full list as entered. The second returns a list which is organized by type, with a type descriptor for each set. Finally, Save CVT to Disk.vi and Save Grouped Tags to Disk.vi provide tools for storing the currently loaded CVT data to disk. Save CVT to disk will initiate a lookup of every tag in the system on first call, and will use that information to perform an extremely efficient index read on the data on subsequent calls. Save Grouped Tags to Disk will perform a lookup in the same fashion as the Basic API. Both functions will then pack the data into an XML file and save it in the location specified. Performance of the CVT v3 A series of performance tests were generated and run using the Unit Test Framework in order to compare the performance of any change to the performance of the CVT v2.0.1. The results of these tests, when run on a Quad-core laptop, are shown below. All tests consist of 1000 reads. For individual access APIs, a single value is read. For bulk access APIs, 1000 values are read. The only exception is for the 4x Parallel Static Reads and Writes tests shown in Figure A, where 400,000 accesses are performed across 4 parallel loops. Figure A: Performance results for the higher-speed CVT APIs. This demonstrates the improvements offerred by the modified memory function. Note: Since CVT 2.0.1 can only read items by index, I have used that as the result for Reference Read, Reference Write, Group Read, and Group Write. Figure B: Performance results for static access and for named access. These tests demonstrate the improvements made to the tag management functions. Even across 1000 reads, the single lookup performed by the static reads function is enough to slow the entire test down for CVT 2.0.1, as compared to the more direct comparison offered through the tests in Figure A. The Named Read and Write tests use the basic API to read 1000 tags in sequence, performing the lookup every time. Figure C: Performance results for tag management functions. Because run-time performance was the goal, some slight sacrafices were made to init-time performance. This test also demonstrates the time taken to save 2000 tags to disk and to form a group of 2000 tags. Note: For CVT 2.0.1, the "Load CVT1 Tags" test is equivalent to the "Init" test. Init uses the native tag type for each API. As such, the "Load CVT1 Tags" does not include groups, but does include the code required to convert from CVT1 tags to CVT3 tags.
View full article