His presentation and example VI’s are included in this post.

Definition

An area of memory  used to store a continuous stream of data by starting again at the beginning of the buffer after reaching the end. A circular buffer is usually written by one process and read by another. Separate read and write pointers are maintained. These are not allowed to pass each other otherwise either unread data would be overwritten or invalid data would be read.

Simple CB Models

• FIFO: first IN first OUT
• (first WRITTEN first READ)
• Number of elements: n+1
• Predefined # of elements: n
• “n+1” element is forbidden for write/read pointers
• Elements could be of any data type including arrays, clusters or even clusters of arrays of clusters

A function global uses uninitialized shift registers to maintain state information and a typedef function to select the mode of operation.

This example implements a stopwatch timer. You can use it to time up to 16 independent events in your application.

For more information on functional globals, check out these links:

Basic Functional Global Example

Functional Global Flags to Protect a Shared Resource

Other “functional global” examples in NI Developer Zone

Download the Code here:

• Stopwatch LV2009
• Stopwatch LV61

The Certified LabVIEW Associate Developer (CLAD) is the first step in getting certified. The test shows knowledge of LabVIEW basics. If you have had the LabVIEW Basics class (now called Core 1) or if you have some real-life experience with LabVIEW, you might be ready. If you want to find out, there are some sample tests you can download from NI’s web site:

clad_sample_exam1.pdf

clad_sample_exam2.pdf

Certified LabVIEW Associate Developer (CLAD) Sample Exams

How Can I Prepare for the Certified LabVIEW Associate Developer (CLAD) Exam?

Replicating these tasks on a computer is nothing short of impossible with today’s level of research and design.

What the computer does well though is sequential logic very quickly. Vision systems use this to their advantage by constraining the vision problem to one task at the time. In the end the computer can attack and solve particular vision problems better than our own vision systems can.

Today we will be detecting the value of an off-the-shelf PSI gauge using NI Vision Builder. Hopefully our solution gives some insight into the current level of vision systems.

Acquire

The first step in any vision application is to acquire the image.  Vision Builder makes this particularly easy for USB, Firewire, or Ethernet cameras.

• Separating logical tasks
• Avoiding race conditions
• Avoiding thread starvation conditions
• Managing communication between the threads

LabVIEW, on the other hand, lends itself easily to multithreaded programming. In fact, if you follow the dataflow rules, multithreading will happen automatically when LabVIEW finds the opportunity.

Dataflow Programming

LabVIEW follows a programming model called dataflow programming. Rather than writing a program in the form of Step 1, Step 2, Step 3, …, LabVIEW programs pass the data on wires. Any VI taking inputs must wait for all of its inputs to be ready before it can run. In the example below, Loop A must run before Loop B is able to run, because Loop A produces data that is used by Loop B. The data dependency controls the order of execution.

Loops with a data dependency

However, if we remove the data dependency, we no longer force the order of execution. LabVIEW gets to decide which loop will run first. But is it Loop A or Loop B? Actually, it is both. This is where LabVIEW’s automatic multithreading kicks in. LabVIEW will create multiple threads and run each loop simultaneously, one in each thread.

Loops with no data dependency

Sharing Data

Remember, LabVIEW can do automatic multithreading only because there is no wired data dependency between the two loops, so the next question is, how do we share data between the two loops?

Local Variable

The first way of sharing data between loops that probably comes to mind is a local variable. It provides a way for you to access the value of data without wiring, so it can indeed be used and still allow automatic multithreading. But there are some drawbacks to local variables: they can cause race conditions, they need to be initialized, they break the dataflow programming paradigm, so you should not get used to using them (if you are a LabVIEW purist, you would never use a local variable).

Queues

A better way to share data between loops is with a queue. One loop can send a message to the other with a queue without creating a data dependency. And the message is delivered in a more predictable manner than a local variable. A great example of this technique is the standard Producer/Consumer template.

Producer-Consumer Template

Spinning Off Threads

Multithreading with multiple parallel loops is fine, but it takes you only so far. Take for example a program that needs to capture data from a DAQ card as fast as possible, handle the user interface at a medium rate to keep up with the operator, and log the data to a file as a background function. Using parallel loops, you cannot control the priority of the various loops, which means the file loop runs as an equal to the DAQ task. That will likely slow down the DAQ and cause data to be lost.

One solution is to put each of the loops into a separate VI and “spin off” each of those VI’s to run independently. You can control the priority of a VI (under VI Properties->Execution), so you can set the DAQ VI to be time critical and the file I/O to be a background task.

How to Spin Off a Thread

To run a VI as a thread, you can’t just call it as you would a normal VI. Normally, when a VI calls another, that VI suspends its execution until the sub-VI completes. That’s the opposite of the multithreaded operation we are after. To spin off a VI, we can make use of some of the VI Server VI’s. These can be found in the Application Control palette.

The process is not difficult:

1. Open VI Reference
2. Invoke Node – Invoke Run VI, specifying to not Wait Until Done
3. (Optionally) Invoke Node – Invoke FP.Open to show the front panel of the VI you are spinning off
4. Use a named queue to communicate between the threads
5. When the thread is terminated, use Close Reference to dispose of the reference to the VI

Priority

When you spin off a thread, it will run with the priority specified in VI Properties->Execution. You can also set the Preferred Execution System to tweak performance.

By using tab controls, you can create the same visual effect and the same functionality as a pop-up window, but you don’t need to create a sub-VI. Since you never leave the VI, you don’t need to worry about passing information into and out of the dialog, simplifiying the code.

While this technique may not be appropriate for every situation, it is a nice trick to have when you need a quick pop-up window.

Give it a try. An example VI is attached.

Download VI: QuickPopUp.vi

For example, if you want to close a program in Windows, you click the red X button in the upper right-hand corner of the window. Most LabVIEW™ have a tell-tale “Stop” or “Done” button. That always bugs me. Why shouldn’t a LabVIEW program end the same way any other Windows program ends?

Why indeed. Here’s how to do it.

In order to catch the press of the Close button, you need to use an event structure. The event structure allows you to tie into the Panel Close? event to make it run your code.

You will find the event under <This VI>Event Source. Take note of the question mark in the event name. There is also an event called Panel Close. You need the one with the question mark. It is a filter event. Since it is a filter event, it is indicated with a red arrow.

Filter events get called before the event is processed. By wiring a TRUE to the discard, the event is killed, so the standard event handling is not processed. We have complete control over what we want to do in response to the event.

Now you have no excuse. So, please, no more “Stop” buttons.

Download Example: CloseButtonToStopVI.vi

Let’s be honest, you will never go back and do it. If you can’t take time to do it right the first time, how do you expect to find time to do it over again?

Error handling is not the most fun aspect of programming, but doing it right can separate a buggy program from good solid code.

Seneca5 Error Logging Class

We have created a simple class that helps handle errors. It takes care of the most common needs for dealing with errors: Reporting, Cleaning, Displaying, and Logging. This is not an error handler, in the sense that it takes no particular action based on an error; you can still do that with code specific to the event. The purpose is to provide a way to make sure all errors are caught and recorded.

Features

• Central collection of errors that occur throughout your program
• Timestamps errors
• Save errors to a file
• Optionally supresses duplicate consecutive errors

Class Methods

Example Program

This example shows the basic usage of the ErrorLog class. Once the object is constructed, you can use the same object from multiple loops in your program. You can also use the object reference to pass to sub-VI’s that you call. You can even pass a reference to a VI executing in parallel (although that is a little trickier).

Every place that can generate errors uses the Log Error VI to process the error. Each call to LogError includes a string to indicate the context of the code that generated the error. That ensures that all of the errors are collected, including a timestep and context, which can be very helpful later for finding the source of a problem.

You can use the Get Errors function in your main GUI loop to watch for errors to occur and light up an indicator. When the user sees that an error has occurred, he can hit the Show Errors button to bring up a dialog box that shows the history of errors.

Download

The example program is written in LabVIEW 8.5 with full access to the source. There is a simple example, as well as a more complex example that shows how to use multiple loops and customized a popup window.
Download: [Example] S5Tools ErrorLog Class.zip

This class has been saved in LabVIEW 8.5. Although password protected, the diagrams are present, so upgrading should be no problem. Download ErrorLog.llb and install into <LabVIEW>\user.lib\S5Tools
Download: ErrorLog.llb

The class is built with the Endevo GOOP Toolkit, version 2. The GOOP2 run-time is required to use the class. Download _goop2.llb and install into <LabVIEW>\vi.lib\addons
Download: _goop2.llb