Why LabVIEW? Part 3

By | LabVIEW | No Comments

Code clarity and hardware support in LabVIEW


In this article I will continue with the programming aspects of our tool of choice, which is code clarity, and with hardware support. I will also highlight some non-programming extra benefits of using LabVIEW. This is going to be the last part of the series.

Read More

Why LabVIEW? Part 2

By | LabVIEW | No Comments

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 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

LabVIEW filters palette


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.


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

Two for loops executed in parallel


To sum up, LabVIEW supports what we do at OptiNav with its speed of coding, the concept of palettes, clarity of code, our-domain-specific functions and the way it supports multithreading.



Why LabVIEW? Part 1

By | LabVIEW | No Comments

Add-ons and 3rd party software


In this series of articles I will describe some positive aspects of LabVIEW which let us use it as a primary programming environment and get us our things done. It is totally incomplete and subjective, but still an entertaining piece of reading, I hope. In this part I will depict how fun is extending LabVIEW functionality.

Let’s start with some matters which matter before we actually begin any application. We hardly ever use LabVIEW base capabilities only and usually need some extra hardware support and libraries related to a specific field of engineering or programming. So we install LabVIEW modules and toolkits. I had wondered what is the exact difference between a module and a toolkit since the beginning of my LabVIEW career, because on NI sites there is no clear distinction between them and all of them are called add-ons. Now from my observations I can shortly say that module is a big add-on made and licensed only by NI, not available in JKI’s VI Package Manager and toolkit is a small one made and licensed by anyone, available in VIPM.

LabVIEW Modules

I usually install them together with LabVIEW, because the set of modules we use is constituted, in contrary to our workstations. For everyone in our developer team a must-install are machine vision modules – Vision Acquisition Software and Vision Development Module. It gives us ability to acquire and process images from any camera fast and conveniently. Vision is our main domain, so they happen to be quite useful for us. There is also a decent set of modules suitable for other modern engineering fields, including Real-Time Module or Robotics Module.


There are also add-ons which can be made by anyone. In other programming languages 3rd party software usually means putting some effort in getting it working. Enough effort to make tutorials on how to install software, like in the case of OpenCV. Quite easy but still someone may need a tutorial. In LabVIEW we don’t need that, because there is only one IDE in which you can use LabVIEW 3rd party software and it’s LabVIEW. There is also only one proper source of such extensions and it’s LabVIEW Tools Network accessible through VIPM (which is by the way the best way, if not only, of installing toolkits). So, we just open VI Package Manager, select an extension, click install and it works. Out of the box, you may say, packages made by anyone are no problem. Another thing is that we have a good selection of the toolkits. Don’t reinvent the wheel, look for it first. One of our must-install tools in toolkits category is OpenG – a great extension for basic programming aspects – arrays, strings, etc. Developed by community. It’s like boost for C++. Independent and acclaimed.

JKI's VI Package Manager

Someone is about to install a database toolkit with VI Package Manager

Other 3rd party code

During our online search for solutions we can also come across some pieces of code which are not distributed as toolkits (with palette menus, documentation, etc.). Just VIs. No problem. If we have all needed dependencies and version of LabVIEW which is not lower than the version in which it was written, it will (just) work by selecting a VI through Functions Palette.

3rd party binaries

You can also run dynamic link libraries and executables in LabVIEW. To run exe files you just need to use System Exec VI. A few first uses demand some struggling with inputs, but then it becomes nice. With C-style dlls, to call their functions, we can manually select functions and define inputs and outputs with Call Library Function Node or try automatic dll wrapper creation with Import Shared Library option. Finally there are .NET libraries and they are quite magical. To import, all you have to do is to select a library file and a method using .NET Palette VIs.

Parameters tab in LabVIEW's Call Library Function Node

Call Library Function Node – call configuration


LabVIEW lets us overcome almost all of our engineering challenges involving programming. It offers good hardware support and wide enough choice of extensions. Everything just works without any environment configuration, which saves our time. It also gives us a convenient way of reusing external binary code.