Top-left corner of the page saberrobotics.org Top-right corner of the page
HOME —> Labview G
The G Programming Language
The programming paradigm underlying LabVIEW
Layout: clear pixel
Click the Saber Robotics logo to return to the HOME Page
 
FIRST Logo
 
For
Inspiration and Recognition of Science and Technology
Layout: clear pixel
 

Awards & Certificates

2012 Wisconsin Regional Best Website Award
 
2010 Wisconsin Regional Best Website Award
 
Valid HTML 4.01 Transitional
 

This web site was accessed
4,332,317 times.
Thank you for your visit. Please, come again.
 

RSS Feed
 

The LabVIEW "G" Programming Language
By Andrew J. Wozniewicz
Originally published March 8, 2009

Updated January 10, 2010

National Instruments' Labview uses what sometimes is described as a “graphical programming language”, a.k.a. the "G" programming language. Instead of consisting of textual declarations and statements, it uses graphical components (called VIs, short for Virtual Instruments) and a kind of data-flow diagram to describe program logic.

The G programming language is a complete programming language (in the sense of being Turing-complete, i.e. you can program just about anything in it) that offers the usual selection of constructs, such as for and while loops, case structures for conditional execution, and sequences for linear execution. The usual operators used in expressions are present in the form of dedicated, built-in VIs for things like comparisons, logical (Boolean) operations, such as AND, OR, NOT, etc., arithmetics, and many more.

Programs are not so much “written” in Labview G, as they are “wired together”. Consequently, the “syntax” errors of a textual programming language are replaced with wiring errors, that is, instead of complaining that you missed a semicolon, Labview will complain that you missed a wire, or left an open connection.

Here is also where the expression "spaghetti code" enters the picture with a vengeance: nothing visually resembles a bowl of spaghetti more than a VI wired together by a beginner LabVIEW programmer. The age-old programmer expression finds its vivid embodiment with the help of LabVIEW block diagram editor.

Dropping an icon onto the programming surface known as the block diagram creates a VI. VIs can have inputs (entered via user interface controls), and outputs (displayed via a variety of indicators). A VI can also be included in other VIs simply by importing an existing VI as an icon into the current diagram and connecting its inputs and outputs with other elements. This is equivalent to reusing subroutines in a traditional programming language. Of course, existing spaghetti..., I mean code, can easily be converted into a sub-VI.

If you have programmed in a traditional, textual language before, the data-flow paradigm of Labview can be somewhat hard to embrace. The data-flow paradigm stipulates that it does not matter where on the 2D surface of the block diagram a particular component is placed in relation to other components, but what other components it is wired to. A particular component-node does not execute until all its inputs are available; it executes, however, as soon as all its inputs are available, regardless of what else might be executing at the same time, that is - in parallel with potentially many other things.

You need extensive experience with multi-threading programming in a traditional language, however, to truly appreciate how easy it is to achieve multi-threading with LabVIEW and how naturally the parallelism arises - whether intentionally, or not. While LabVIEW does not magically dissolve all the challenges related to parallel processing, it certainly makes it considerably simpler to get started with it. In fact, in contrast with the traditionally sequential textual programming languages, it is the sequential execution that comes at a price in LabVIEW - parallelism is almost free.

If you have programmed in a "visual" environment like Delphi, or Visual Basic before (no, contrary to its name, Visual Studio, does not qualify as "visual" until the .NET era), it would have made it much easier to understand LabVIEW, but there are important differences to observe. The big difference is that the individual components on a LabVIEW diagram are generally not referenced by name (although some can be), but there are actual colored wires connecting them together. So, instead of simply referring to another component by name, or assigning a textual property value to a component, you will be spending hours stitching your diagrams together with wires, re-routing those wires, breaking them, and then re-wiring the components over and over again.

The most fundamental element of a Labview-G program is a graphical node (a virtual instrument, or VI) that represents an operation or data value. A graphical block can be executed (or evaluated) only when all of its inputs are determined, but there can be multiple graphical blocks, each with its own set of inputs present. That means it is very easy to create a diagram with a few parallel branches, thus realizing simultaneous execution of numerous operations at the same time.

Data types are presented with different colors and different shapes of connecting lines. Blue color presents integer, orange - float, purple - character, green - Boolean, etc. User defined types are presented with some other colors.

LabVIEW also enables linking with external functions written in more traditional programming languages, such as C, so I suppose you can get the best of both worlds.

As a long-time programmer using traditional textual programming languages, as well as  an avid user of graphical Rapid Application Development tools such as Delphi, which are also based on traditional, textual and sequential programming languages, my initial impression of LabVIEW was that of a lame excuse for an engineer not to learn real programming. But I now admit that there is more to it than that.

LabVIEW programs (VIs) do carry more than a cursory resemblance to electronic circuits, but my initial impression has changed somewhat as I got more familiar with the intricacies of programming (or, I should say, "wiring") with LabVIEW. I no longer treat it with utter contempt and complete disdain of a typical "real" programmer, but I am still left wondering whether it really is well suited to creating complex business applications I spent all my professional life building.

In the end, I think, it really boils down to the type of application one wants to create. If you are creating a financial spreadsheet, or a database application such as an airline reservation system, LabVIEW is probably not a good choice. But if you are creating a control system for an embedded application, be it a robot controller, or an application gathering data from a host of physical instruments, LabVIEW seems to be able to compete really well with the traditional programming tools. And then, there is the huge gray area between the two, where neither LabVIEW nor C, C++, C#, Java, or Pascal have a definitive upper hand.

In summary, the more sophisticated the business logic and user presentation of an application, the less valuable LabVIEW seems to be as the development tool. It is however very easy to learn the basics of programming using LabVIEW.

For programming FRC robots, which is the primary concern here, LabVIEW can very effectively compete with C++ - it is much easier to wire the provided default VIs, than to figure out the intricacies of the C++ object hierarchy in the provided libraries.

It's just an initial impression of a hard-core coder (your truly) formed at a very early stage of my LabVIEW education, so beware of any bias towards the familiar and comfortable. LabVIEW programming requires a slightly different mindset than textual programming, but it accomplishes the same goal quite effectively.

Happy coding, or as the case may be, wiring!

Layout: clear pixel
Weekly Goal:

"Gearing up for special competition"








Google Play Store
Layout: clear pixel
HOME —> Labview G
Bottom-left corner of the page team2506.org Bottom-right corner of the page