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?

Topic: LabVIEW Design Patterns – VIG Timer, Producer/Consumer, and more

This meeting will be at Seneca5, Tuesday June 1st at 6:30. We serve pizza, so you can come straight from work.

Check out the LabVIEW Advanced User Group page for more details.

This meeting will be at Seneca5, Tuesday April 6th at 6:30. We serve pizza, so you can come straight from work.

Check out the LabVIEW Advanced User Group page for more details.

(Actually, you can just use the listbox control. Right click and select Replace. Replace it with a multicolumn listbox. The new multicolumn box will maintain the improved icons.)

Download VI: MulticolumListBoxIcons2.0

Now it’s all about the young kids and their automatic tool selection. La-ti-da! Manual tool selection was good enough for us, and it should be good enough for them too!

I don’t let my work shed tell me when to use a hammer and when to use a screwdriver! And if I ever get any of those new “power tools” I won’t want my shed picking those either!

It is not Labview, LabView, or LABVIEW.  It’s LabVIEW!

Maybe we could never remember what the acronym stood for but we knew it was one.

Violent Inhuman Enormous Wildebeest
Vital Inheritance Expense Withholding
Virtually Idiot-proof Enhanced Whatchamagig

It doesn’t matter. It’s an acronym. Now you know. So spell it right!

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.