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.

Two-dimensional code organization

Since LabVIEW is a graphical programming language, its code is two-dimensional. This fact highly affects the way we code in LabVIEW in comparison with text programming languages.

Professional coders in general try to make their code look clear to other coders. It usually amongst others consists of putting code lines in clear order, using appropriate line spacing and separating some particular code parts. All of it in linear manner, from top to bottom lines of a text file. These are good programming practices (GPP). Graphical coding enables us to apply way more GPP to our code, and actually requires it, to make code clear enough. There are more ways to organize graphical code than text code, so there is more good programming practices too. For (trivial) example, one should not cross wires and no text programming equivalent comes to my mind. That means bigger effort, but it is worth putting to.

Another thing affected by two-dimensionality of code are comments and decorations. The differences are analogous to the GPP case. In text programming you use text to comment and decorate code. In LabVIEW we use graphical elements for that purpose. We can put text comments anywhere in a diagram, border them and even link them to associated code with arrows. You can use lines, arrows, frames and labels, you can color them and also inserting images is possible.

I don’t always decorate and comment this way

If someone wants very hard or just can’t program in LV, it is possible to produce very wide and long code which will occupy an equivalent of tens of computer screens. But it’s not the way one should program in LabVIEW. We always try to make code visually smaller than one computer screen. For that purpose, code should be divided into subVIs and should be used structures such as Case or Event. These structures show only one part of code at a time. Those tools let us compact code and actually make it multi-layered. This feature let us better see which code parts are alternative to others. When talking about architectures in LabVIEW, we usually think about how the main VI looks like and how it works, which is very easy to define, thanks to the natural potential of code clarity in LabVIEW.

Very simple architecture

Hardware support

LabVIEW can integrate with very wide range of hardware, out of the box or after installing additional packages. It supports many sensors, instruments and buses. Protocols supported without any add-ons are for example serial port, IrDA, Bluetooth, VISA, GPIB. At Carl Zeiss IQS Software R&D Center we particularly value support  for vision protocols, which are USB3 Vision, GigE Vision and Camera Link. Support for them is included in NI Vision Acquisition Software module. Another widely appreciated hardware associated feature of LabVIEW is its FPGA interface. It allows to develop code and deploy software to FPGA chips with hardly any effort when comparing to traditional VHDL approach.

Community

LabVIEW has small but robust community which is supported by National Instruments. When looking for a problem solution, search engines show us links to a few forums managed by community, but also to NI’s official support forum. These are: labview.pl (polish community), lavag.org (global community), forums.ni.com (official). NI supports LabVIEW community also by publishing some educational documents, organizing online courses, webcasts, conference-type events, but also paid thorough courses and certifications which allow you to make some professional progress.

To sum up

To the “why LabVIEW” list we can now add code clarity, hardware support and good community support. That’s all, that’s why we use LabVIEW.

Sławek