Fast LabVIEW programming

Welcome to the 2nd part of the article in which I would like to inform you why we use LabVIEW in our company. This part describes some pure programming aspects. To be specific, speed of coding.

Coding in LabVIEW is fast which makes it a perfect environment for prototyping, testing ideas or just quick development. Here are some reasons why.

Clicking vs. typing

LabVIEW is a clicking language and clicking code is faster than typing it. To further increase your speed you can use Quick Drop, it’s actually typing, but only for searching purposes. It doesn’t really break the convention of graphical programming and graphical code. Just imagine coding a for loop in C++ and LV. A lot of non-letter characters and newlines to write. In LV I just select the loop. Amount of typing matters.

Palettes vs. libraries

Now something on programming without being familiar with used framework. In brief, functions you can use in your IDEs are stored in libraries. I often search for what I can get from a particular library to achieve a particular effect in my program, because I often use libs new to me. In, let’s say, .Net I would have to scan through a pop up showing me all class’ members or read a documentation. It feels like visiting a library in order to obtain information you need before the Internet came. In LabVIEW we get palettes. Like painter keeping currently used colors on his palette, LabVIEW shows us its functions categorized in palettes, one category at a time, which are actually entries in a complex pop up menu. Need more details on a particular color function? There’s context help. This combined with a search (for a palette) lets us quickly get to know what our environment is capable of.

LabVIEW palette of structures and context help

LabVIEW is very high-level

Another thing is that LabVIEW is a very high-level programming language for engineers. It means that it has in its base ready to use solutions for many technical and scientific problems – field-specific operations, apart from advanced operations on basic data types. For example, implementations of signal filters or curve fitting. LV also lets us make applications with simple and neat graphical user interfaces with its IDE out of a box. No need for installing extra packages or writing your own libraries.

LabVIEW filters palette

Clarity

The last thing is speed through transparency – you are faster when you understand a project, you understand it when its code is clear. It is especially important when joining already existing projects or forking applications. Most times you need only one glance through a main vi’s code to understand a well written application’s architecture and its general idea. Some experience is needed too, of course. It’s extremely easy and fast to get fully involved in a project when it incorporates a well known architectural framework, like JKI State Machine. That’s why companies use always the same architectures, developed on their own or by 3rd parties. Getting familiar with a code is not so easy in typing languages, where scanning through a project structure and many code files may by required.

Multi-threading

Developing multi-threaded applications is quick too. All loops and any other operations which are not forced to be consecutive are executed in parallel, if there’s enough free resources in a system. LV happens to support this concept with its graphical two-dimensional code. Looking at two loops, one under another, you may naturally assume that they will execute in parallel, especially when the code execution is dataflow driven, from left to right. It’s natural way of working for LabVIEW – multi-threading by default, with separate cores occupation and such. That’s how they boost speed through simplicity. Unfortunately, not everything is so rosy, the problem of communication between threads remains the same as in other languages.

Two for loops executed in parallel

Conclusion

To sum up, LabVIEW supports what we do at Carl Zeiss IQS Software R&D Center with its speed of coding, the concept of palettes, clarity of code, our-domain-specific functions and the way it supports multithreading.

Sławek