May
07

Tomi’s NIDays 2008 Presentation

by Tomi Maila, May 7, 2008 at 12:01 am
1 Star2 Stars3 Stars4 Stars5 Stars (No Ratings Yet)
Loading ... Loading ...

NI Days logo
I’m giving a presentation on LabVIEW Object-Oriented Programming at NIDays 2008 in Helsinki today. The presentation is titled Software Development with LabVIEW Object-Oriented Programming. The slides for the presentation as well as the presentation related example application can be downloaded below.

Download NIDays 2008 Presentation Slides


Drawing Tool 1.0

604.7 KB
You must be logged in to download this item!
Please login or register now.

Discussions in English | Finnish

Print This Post Print This Post
Feb
29

Active VI Toolkit public alpha - Erlang style message passing concurrency toolkit for LabVIEW

by Tomi Maila, Feb 29, 2008 at 4:54 pm
1 Star2 Stars3 Stars4 Stars5 Stars (5 votes, average: 4.4 out of 5)
Loading ... Loading ...

Active VI Toolkit logo ExpressionFlow today announced a public alpha release of Active VI Toolkit, an Erlang style message passing library for development of concurrent LabVIEW applications. The toolkit provides easy-to-use LabVIEW language abstractions for writing concurrent applications based on message passing between parallelly executing VIs. ExpressionFlow Active VI Toolkit greatly simplifies the authoring of highly concurrenct LabVIEW applications.

Download now!

Background

A few months ago I compared the LabVIEW and Erlang concurrency models in my article Two Paths to Concurrency - Comparing Erlang and LabVIEW. Whereas Erlang concurrency model provides means to write highly concurrent highly scalable applications, LabVIEW dataflow model allows very easy ways to write concurrent applications taking advantage of a few processor cores.

Active VI Toolkit is a research project, whose aim is to find the best way to fit Erlang style concurrency model into LabVIEW so that LabVIEW developers can take advantage of both concurrency models depending on their needs. The main design goal in the development of the toolkit so far has been simplicity of use. To reach this design goal, the toolkit tries to utilize existing LabVIEW language aspects as well as possible; the intention is not to reinvent the wheel.

The Active VI Toolkit consists of two modules, the Active VI Toolkit module and a One-Time Store module. Active VI Toolkit module provides language abstractions for message passing whereas One-Time Store module provides language abstractions for returning values as response to received messages.

Active VI Toolkit basics

The Active VI Toolkit is based on a concept of parallely executing VIs (LabVIEW functions) called Active VIs. When a new Active VI instance is created, the connector pane connected controls are initialized in exactly the same way as in a normal subVI (function) call. When an Active VI instance is created, a new thread is spawned that will execute the Active VI. Or to be more precise, a new parallel VI is executed that will call the Active VI.

After the Active VI has been initialized and started, it can usually execute some internal initialization procedures and then start waiting for messages in a loop. The messages can be send to the Active VI with a Send Message to Active VI node. The messages are identified by label and type of some wire connected to type type input of the node. The messages are passed to Active VI as value change events of Active VI front panel controls and can received with a LabVIEW event structure.

When an Active VI needs to be stopped, it’s sent a special Close message with some timeout value using a Close Active VI node. If the Active VI cleanly closes within this timeout, the values of Active VI connector pane indicators are passed to the VI requesting the Active VI to close, otherwise the Active VI will be aborted.

The very basics of creating an Active VI, sending a simple message to an Active VI and Closing an Active VI can be seen in the figure below. The first node on the left creates a new Active VI instance from a strict static VI reference and initializes with string value expressionflow.com. The second node sends a message My Message of type I32 with value 7 to the Active VI. The third. node requests the Active VI to close with infinite timeout and returns the value of the error out indicator on the Active VI connector pane.

Creating, sending message to and closing an Active VI

Writing an Active VI itself is very simple. What is practically needed is some connector pane connected controls and indicators to pass initialization data and return values to and from the Active VI. In addition one needs some controls that define the supported messages and a event structure to handle the receiving of the messages. Usually one also wants to have a while loop to receive more than one message only. Nothing else is needed. A simple Active VI block diagram is illustrated in the figure below.

Basic Active VI block diagram

A basic library that ships with Active VI Toolkit is One-Time Store Toolkit. One-Time Store is a by-reference type that can store a single value of chosen type. It is very similar to a LabVIEW single element queue. However, once the value of the One-Time Store is set, it can never be modified again. In computer science terms One-Time Store is a dataflow variable. However I chose not to use this term as it might confuse LabVIEW users that usually think of dataflow in a little different way.

One-Time Stores can be used as place holders for asynchronous replies to sent messages. The figure below illustrates initializing an empty One-Time Store of string type and sending the One-Time Store reference to an Active VI within a message. After the message is sent, the sender can start waiting for a value of the One-Time Store to be set by the Active VI. In the figure the One-Time Store is immediately destroyed after the value is received. However this doesn’t need to be the case.

Using a One-Time Store as a place holder for a response from an Active VI

From Active VI point of view, replying to this message is simple. To respond to the sender only needs to set the One-Time Store value. Receiving the message in the above image and replying to it is illustrated in the image below.

Active VI responding to a message using a One-Time Store reference

Conclusions

In this post I covered the very basics of Active VI Toolkit. The Active VI toolkit is much more powerful a toolkit that is directly evident from this post. I left some aspects and properties of the toolkit out of this post and will discuss about them in my later posts. Also note that the Active VI toolkit is currently at alpha pre-release version targeted for mainly for concept testing and public discussion.

I’ll soon post follow-up articles on more advanced features of the Active VI toolkit. Meanwhile download the Active VI toolkit from and play around with it and provide us feedback. I especially appreciate feedback on the concept itself and how it could be made better.

Download now!

Print This Post Print This Post
Jan
07

Recursive Data Types in LabVIEW - making recursive data structures type safe

by Tomi Maila, Jan 7, 2008 at 4:15 pm
1 Star2 Stars3 Stars4 Stars5 Stars (4 votes, average: 5 out of 5)
Loading ... Loading ...

LabVIEW Object-Oriented Programming (LVOOP) was introduced in LabVIEW 8.20. LVOOP allows developers to build recursive tree-like data structures within LabVIEW dataflow model. Recursive data structures are enabled by allowing class private data members to be of ancestor class type. As ancestor class private data members can hold descendant class objects, recursive data structures are possible.

However LabVIEW doesn’t allow using recursive type structures where a type refers to itself. I present here that indeed building such types would be possible within the dataflow framework of LabVIEW. Such recursive types would allow building recursive data structures in more intuitive and type safe manner than what is possible with current LVOOP implementation.

more…

Print This Post Print This Post
Dec
21

Snowflake LabVIEW Block Diagram Game

by Tomi Maila, Dec 21, 2007 at 9:43 pm
1 Star2 Stars3 Stars4 Stars5 Stars (3 votes, average: 5 out of 5)
Loading ... Loading ...

Snow Flake LabVIEW Block Diagram Game PreviewI’d like to thank you all ExpressionFlow readers for our first amazing year. You may have received a large number of season’s greeting cards, but I bet none of them can even closely compete with ours. To thank you for our first year, we’ve developed you a LabVIEW block diagram arcade game for LabVIEW 8.5!

To play the game, use the left and right arrow keys and try to catch all the LabVIEW block diagram compoents with your LabVIEW object. Don’t forget to post your high scores to this thread.

I wish you all Merry Christmas and Happy New Year 2008!

EDIT: Version 1.1 released with a bug fix.

Download

Print This Post Print This Post
Nov
26

LabVIEW 8.5 on a multi-user Windows 2003 Server

by Tomi Maila, Nov 26, 2007 at 12:00 am
1 Star2 Stars3 Stars4 Stars5 Stars (1 votes, average: 4 out of 5)
Loading ... Loading ...

Windows 2003 Server with LabVIEW Large majority of LabVIEW developers use Microsoft Windows as the development environment. However only single user Windows environments namely Windows 2000/XP/Vista are supported by National Instruments. We lately experimented installing LabVIEW 8.5 on a Windows 2003 server with multiple simultaneous users over terminal services remote desktop connections. Our initial experiences are encouraging.

Although Windows 2003 server was used for this experiment, the results can be applied to other Windows environments with multiple users as well. It can be beneficial to more carefully separate multiple users all using a single workstation with a single LabVIEW installation. more…

Print This Post Print This Post
Nov
12

Two Paths to Concurrency - Comparing Erlang and LabVIEW

by Tomi Maila, Nov 12, 2007 at 11:46 pm
1 Star2 Stars3 Stars4 Stars5 Stars (3 votes, average: 5 out of 5)
Loading ... Loading ...

The clock speed of computer processors has reached the ceiling and the processor manufactures have moved from developing even faster single core processors into developing processors with increasing number of cores on a single chip. The increasing number of parallel processors is a challenge for software industry as writing parallelly executing software with mainstream programming languages is a challenging job. This dilemma is sometimes referred to as the multicore crisis.

Even though writing parallel programs with languages like C++, Java or C# is a rather complicated job, programming for parallel environments doesn’t necessarily have to be a challenge. Two programming languages both having their roots in the end of 80’s, Erlang and LabVIEW, have both been inherently concurrent from the very beginning. Both languages have started as special purpose programming languages and during the last two decades evolved into full featured general purpose programming languages. Although being both inherently concurrent languages, Erlang and LabVIEW solve the problem of concurrency in rather different ways.

more…

Print This Post Print This Post
Aug
08

LabVIEW data corruption bug

by Tomi Maila, Aug 8, 2007 at 9:40 am
1 Star2 Stars3 Stars4 Stars5 Stars (5 votes, average: 4 out of 5)
Loading ... Loading ...

I don’t normally blog about bugs. However with this particular bug I decided to make an exception as it potentially affects everyone in a very nasty way. A few days ago a severe LabVIEW data corruption bug was found by a LAVA forums member Wolfram. As a result of this bug LabVIEW incorrectly reuses calling VI data buffer when calling a value property node in a subVI. The content of a calling VI data buffer gets overwritten by the data passed to value property node. As LabVIEW stores block diagram constants as data buffers, also the values of block diagram constants get changed. The bug is present in all recent LabVIEW version including LV 8.5.

The most common use case I can think of that reproduces the bug is when passing data to an subVI to be interactively viewed by the user. In such cases it’s common to use value property to modify the displayed data. As a result of the bug, the values written to value property node ‘backpropagate’ to the calling VI or to where ever LabVIEW decided to make the last buffer copy. Main VI

Main VI passes data for subVI to be visualized

SubVI uses value property node to modify the displayed data
SubVI uses value property node to modify the displayed data

Main VI after execution, moving mouse over the constant displays the changed constant value
Main VI after execution, moving mouse over the constant displays the changed constant value

Download an example project from the link below:

Buffer bug example for LabVIEW 8.0

Print This Post Print This Post
Aug
03

National Instruments releases LabVIEW 8.5

by Tomi Maila, Aug 3, 2007 at 4:58 pm
1 Star2 Stars3 Stars4 Stars5 Stars (4 votes, average: 5 out of 5)
Loading ... Loading ...

National Instrument has just released version 8.5 of its visual programming language and integrated development environment LabVIEW. The following new features have been added to LabVIEW development environment

In addition the language has got some new features as well

The full list of changes can be found in the upgrade notes pdf document. NI has also published the list of most important bug fixes.

It’s interesting to see how these new features affect the software development with LabVIEW. I’m especially happy to see the support for recursion in LabVIEW object-oriented programming, as the lack of that was one of the most restrictive things in the previous LVOOP implementation. As of now, I found no evaluation download link for the latest release. I guess we’ll have to wait to really get our hands on this latest toy from NI. Any comments and further information is very welcome.

EDIT: The download link for LV 8.5 for Windows evaluation is now online.

Print This Post Print This Post
Jul
23

LabVIEW Object-Oriented Programming Introductory Walktrough

by Tomi Maila, Jul 23, 2007 at 6:01 pm
1 Star2 Stars3 Stars4 Stars5 Stars (8 votes, average: 5 out of 5)
Loading ... Loading ...

LabVIEW Object-Oriented Programming, or LVOOP for short, has been around for about a year now. Have you had time to take a look at it? If not, it’s about the time. I made you a short video on the very basics of LVOOP development process. It doesn’t go into details of inheritance and all that but it gives you and idea on how to get started. So get yourself a cup of coffee, sit down comfortably, and press the play button.


(length 09:05)

Print This Post Print This Post
Jun
12

Concepts Behind OpenG Class Templates

by Tomi Maila, Jun 12, 2007 at 10:09 am
1 Star2 Stars3 Stars4 Stars5 Stars (No Ratings Yet)
Loading ... Loading ...

Yesterday the OpenG Class Template Framework together with a few OpenG class templates were released. I now try to explain shortly what these templates actually are and how do they function.

OpenG Class Templates are nearly normal LabVIEW classes that are stored under resource\OpenG\openg_object\class_templates folder under LabVIEW installation directory. To be used OpenG Class Templates require a separate tool that can create new classes from the templates and that can manipulate existing classes created from class templates.

The class file of LabVIEW classes is always an XML file with information of class properties, class private data and class item properties. OpenG Class Templates differ from regular LabVIEW classes in that additional information is added to the lvclass XML file of the templates. This additional information explains the template tool such as Endevo GOOP Development Suite how to work with the templates. Based on this additional information the template tool knows how to create new classed based on the templates, how to create new methods from method templates, how to rename class based on a template and how to update template changes to template based classes.

When user wants to create a new class that is based on a OpenG class template, he needs to do this via a tool that support OpenG class templates. In the process, the tool creates a copy of the template and manipulates the copy according to the template meta data written in the template XML file. The tool also adds additional attributes to the class file created from the template so that this class can be recongnized to be based on a tempalte and the template used can be located. When there are changes in the template, these changes can be applied to the classes based on the template using this metadata in the class files.

As the templates are more or less regular LabVIEW classes, they can also depdend on other templates in a very similar manner as LabVIEW classes inherit from parent classes. For example OpenG Active Object Template is based on OpenG Reference Object Template. Active object is actually a referece object with some extra features and with a few changes in some underlying mechanisms. The inter-template dependency means that changes to parent templates can propagate via the child templates to classes created from the templates. This of course requires support from the tool being used.

The tools that support OpenG Class Template specification should be able to recognize any template in the above mentioned template directory. This makes it possible for the developers to create their own class templates specific to their own needs. However OpenG Class Template specifications are quite complex yet capable and it is not very easy to create new class templates. The complexity of the template mechanism also means that it’s probable that in the beginning only tested templates will work with tools supporting OpenG Class Templates and actually the support for custom templates will see light only when the tools get more mature.

Print This Post Print This Post