Many modern programming languages implement generic programming support with the concept of type parameters. Generic programming using type parameters is the feature I have been missing the most in LabVIEW. Generic programming is about writing reusable blocks of code in terms of types that are specified in later time. In LabVIEW terminology type parameters would specify the type of wires and terminals of generic type. Type parameters can either be implicit or explicit. Implicit type parameters are determined by the compiler automatically where as explicit type parameters are specified by the developer. Furthermore type parameters can have variation limits, specifying what kind of type are accepted. Type parameters could be in principle applied to a VI, to a class, to a library, to a mixin class (trait), to an interface or any other kind of module that includes executable code or front panels. (EDITED Introduction & title 10/25/2009 9:36 GMT)

more…

I’m very excited to announce a new ExpressionFlow Studio video series that will concentrate on LabVIEW software development. The first episode starts an ExpressionFlow Studio series introducing to LabVIEW object-oriented programming. The topic of the day is introducing the concepts of objects and classes.

Download Drawing Tool example presented in the video

There are numerous reasons why you would like to allow your LabVIEW application to be extended with plugins. First you may want to allow your customer or a third party to add some new functionality to your application. LVOOP plugins provide a way for you to allow third parties to extend your application. Second you may want to separate the built and development process of the core application from the development process of the features of the applications. With OOP projects LabVIEW development environment slows down dramatically as the number of classes gets too high. It may be wise to separate your application so that only the core elements form the main application and all other elements are provided as add-on components. Third you may want to control the memory footprint of your application and specify at runtime which components are loaded into memory; there is no need to keep the code for unused features in memory. Consider for example that your application supports multiple file formats or device drivers. You can load the needed file format plugins or device drivers on demand into memory at runtime. more…

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

Discussions in English | Finnish

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…

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)

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.

For the past few months I’ve been working on a very interesting project together with Endevo from Sweden with Jim Kring from JKI. I have had the opportunity to design open source OpenG Class Templates for LabVIEW Object-Oriented Programming. Endevo has developed a GOOP Development Suite that allows developers to create classes from these OpenG templates directly from LabVIEW user interface. OpenG templates together with Endevo GOOP Development Suite has the potential to fundamentally change the LabVIEW object-oriented development process.

OpenG Class Templates

When LabVIEW Object-Oriented Programming was released about a year ago, I had a lot of expectations. Unluckily the features of LabVIEW OOP didn’t meet with my development needs. I needed by-reference classes to be able to represent complex data structures and encapsulate storage interface to classes. I needed user definable constructor and destructor for my classes to guarantee initialization and clean-up. With these needs I started to think of the ways how I could best implement these features on top of native LabVIEW OOP.

The aim of the OpenG Class Templates is to overcome the above mentioned shortcomings of native LabVIEW object-oriented programming by including features lacking from native LabVIEW OOP to OpenG class templates. Two most interesting OpenG templates are without doubt a queue based by-reference class template and a class template for active asynchronous objects.

Queue based by-reference class template allows developers to create by-reference classes with user defined object construction and destruction steps and with asyncrhonous parallel data access and data locking. By-reference classes are the proper choice when one needs to create objects with indentity and lifetime. Numerous use cases include encapsulation of instrument drivers, file handling, database access, network interface and urser interface components.

Template for active asynchronous objects combine by-reference objects with a thread of their own. Each object includes a parallely executed VI that is started during object construction and closed when object is closed. This parallely executed VI can receive and reply-to asyncrhonous messages from other parts of the program. Active objects can be considered to provide an active state-machine based service that other parts of the program or external components can communicate with using the object methods.

OpenG class templates are based on OpenG class template specifications. These specifications define a standard which allows all developers to create new class templates either from scratch or based on existing class templates. Furthermore developers can use these templates with any LabVIEW tool that confroms with the template specifications. Currently the only tool available is Endevo GOOP Development Suite.

OpenG wiki provides instructions on how to get and install OpenG class templates.

Endevo GOOP Development Suite

Endevo GOOP Development Suite (GDS) has an opportunity to revolutionize LabVIEW object-oriented programming based development. Being integrated directly to LabVIEW project environment Endevo GDS makes it very easy and fast to work both with native LabVIEW classes and with template based LabVIEW classes. The speed-up of the development process is actually enormous when the development suite takes automatically care of things like creating method icons etc.

Endevo GOOP Development Suite supports three kinds of classes; native LabVIEW classes, classes based on OpenG templates and classes based on Endevo templates. All of these alternatives are based on native LabVIEW object-oriented programming. Actually Endevo GDS allows users to create and add their own class templates that meet OpenG class template specifications.

GOOP Development Suite comes in two editions, limited functionality free Community Edition and in Professional Edition. Both versions of GOOP Development Suite can be downloaded directly from Endevo web site.

Conclusions

OpenG Class Templates together with Endevo GOOP Development Suite have a lot of potential to change the way LabVIEW object-oriented programming is beign used. I’ll keep blogging on the usage the templates. Subscribe to the feed not to miss any of these future articles.

Scala is my favorite non-visual or text-based programming language. Scala is a functional object-oriented programming language has succeeded to combine almost all features I’d like to see in a programming language except the visual way of coding. Scala compiles to Java Virtual Machine and is fully interoperable with Java code. There was a nice introductory article on Artima a few days ago First Steps to Scala by Bill Venners, Martin Odersky and Lex Spoon. If you are into text-based programming, you should seriously take a look at this article.

I was giving a talk on LabVIEW object-oriented programming a few week ago in the local LabVIEW user group in Helsinki. For the talk I did some research on the roots of dataflow programming and the roots of object-oriented programming. According to a Wikipedia article I found, dataflow programming was introduced in Bert Sutherland‘s Ph.D. thesis, The On-line Graphical Specification of Computer Procedures in 1966. Coincidentially the first object-oriented programming language Simula 67 was introduced around the same time.

Now these two different programming paradigms are merging and giving birth to a new paradigm object-oriented visual programming or should I call it object-flow programming. I believe this to be just the beginning of a new phase in the evolution of visual programming; we’ll see a lot of innovation in this field for the years to come.

Multi-core processors force the software industry to seek solutions to the development of parallel application. Object-flow programming makes developing parallel programs easy. Text based programming languages are bug-prone; visual software development is much less so. Object-flow programming has all the means of doing the same for programming as what Microsoft Windows did for operating systems -making programming so easy and intuitive that it’s no longer a privilege of few.

What do you think? Do you agree with me on the future opportunities of object-flow programming? What do you see to be the greatest obstacles? Could National Instruments get object-flow programming to Forbes cover page or do we need some other company to take the lead? I’d love to hear you comments!