LabVIEW NXG Community Edition: Post 1 - Review

20 Oct 2020

Introduction

Earlier this year I started a project to design and build a control board. Whilst waiting for a prototype PCB to be manufactured and for the result of a roadtest application to be announced, I started looking at LabVIEW NXG with the intention of automating testing of that board. Undertaking the characterisation of 16-bit ADCs and DACs with 65,536 possible values each and coordinating with I2C signals from an Arduino, by hand, didn't appeal (funny that!) Jan Cumps has produced some useful posts showing automated testing with LabVIEW and National Instruments (NI) recently released Community Edition versions of the LabVIEW products.

This review is specifically about LabVIEW NXG 5.0 Community Edition. Really, I can only scratch the surface here, but in another blog I will cover a testing framework that I created which will give a much better idea of the power of the product.

LabVIEW Products

NI's product range breaks down as:

LabVIEW 2020 - nominally, 'Current Generation' (LabVIEW CG), a very mature version of the LabVIEW product. NI's roadmap is to eventually switch from CG to NXG (Next Generation) but NXG is not yet ready to do that. Many industrial users of LabVIEW can not yet make the switch: the feature set is not yet anywhere near comparable, the conversion routines for CG to NXG code aren't mature, nor is NXG stable enough to risk the transition.

LabVIEW NXG 5.0 - 'Next Generation'. This is a ground-up rewrite of the LabView product to support better graphics and a maintainable architecture for future change. As it stands, features are evolving in NXG version releases to bring it closer to the functionality of CG but it's still some way off. Personally, I don't have any experience of CG to compare so this is a reported viewpoint rather than a personally experienced viewpoint.
LabVIEW 2020 Community Edition and LabVIEW NXG 5.0 Community Edition: These are freely available, fully featured (more on which later!) versions of the products for non-commercial use. They are distinct downloads to the non-community edition versions rather than just being a licensing option.

Assuming that hobbyists ask the question "Which one should I be using?" then the answer is as more a judgement call than a straightforward answer:

Forget the commercial versions, you can't afford the licence. I didn't even have to ask NI that question because I saw the price of their 'training' videos!
LabVIEW CG has more features and supported test instruments than LabVIEW NXG but is on the roadmap for deprecation and discontinuation at some as-yet unspecified future date. This version might be useful if you already use it for work; or work is thinking about investing in LabVIEW; or you are thinking of getting to grips with LabVIEW to improve your CV. I have the impression that whilst fundamentally the products work similarly, the look-and-feel are different and a transition from home-learnt NXG to workplace CG won't be that easy so if you have a work-oriented outlook then CG is your choice.
LabView NXG is NI's stated future so the community edition is the one you'll want to use from a hobbyist perspective. Bear in mind: this version isn't as widely used so support is harder to come by and you will need to do a fair bit of translation from CG answers to NXG solutions. And in some cases, they don't exist because the feature-set isn't comparable yet. However, I have found that on the whole, NXG 5.0 functionality is more than sufficient for the types of uses we have as hobbyists and thus I would recommend this as the version to use.
If you take one-off, or small number of measurements, have no need for programmatic testing etc then don't bother with LabVIEW as it's not worth losing the disk space or learning the complexity of the tool. Really, you want to be using a tool like this for automated, repeatable testing where you want to capture output data and undertake version comparisons.

Note that it is possible to install both versions and they will coexist.

Either version can be downloaded from https://www.ni.com/en-gb/shop/labview/select-edition/labview-community-edition.html

A note on Community Editions

I don't have any experience with LabVIEW CG Community Edition so the points I make here are for LabVIEW NXG Community Edition. I have the impression that whilst NI say these are fully featured versions of the products they are talking about the base products. Building on the base products are Instrument Drivers that 'wrap' base functionality for communicating with test instruments into user-friendly interfaces, hiding any underlying complexity, as well as providing example applications showing their usage. I have found that:

Instrument Drivers that exist for CG (probably) don't yet exist for NXG.
Instrument Drivers that do exist for NXG, don't always work with the Community Edition, e.g. I can't get the driver for my Keithley DMM6500 to be recognised by my install of NXG Community Edition even though it has been built for NXG. NI themselves promote LINX as a toolkit plugin for NXG Community Edition to communicate with serial devices like Arduino: it isn't available for, and doesn't work with, the Community Edition (at least yet.)
Instrument Drivers are supported by Instrument manufacturers so require them to port the code over to NXG - CG and NXG are not code compatible - and that doesn't appear to be something high on their radar. They may also not work, as they were created for older versions. For example, although Siglent have provided Instrument Drivers for my scope and AWG, I have not been able to get them to work at all.

So, out of four potentially programmable instruments I own, I have been unable to find, or get working, any Instrument Drivers with LabView NXG Community Edition. Instead I've had to go it alone!

What is LabVIEW?

LabVIEW is a visual programming tool that can, but doesn't have to, interact with test instruments - DMMs, PSU, Scopes etc - to automate their use in applications. These may be test applications where a new prototype is being driven and monitored but there's no reason why it couldn't be used to create production applications that, say, are used for environment monitoring by pulling sample data from sensors with data graphing and warning triggers for out-of-bounds alarms.

Automation of tests means they are repeatable and less prone to manual error which is ideal where large operating ranges are used or regression testing through a product lifecycle is required. In reality, it is no different to software testing except LabVIEW simplifies the communication with test instruments and hardware.

As mentioned, LabVIEW is purely visual, no lines of code are written. Instead 'widgets' called VIs (Virtual Instrument) are dropped onto a design panel and connected with Data Flows:

This shows a VI, created in LabVIEW NXG, to calculate a factorial. There are input values, constants, a case structure, a while loop, maths operations and boolean operations with blue data flow connections between them. There are no lines of code that you would understand in a traditional programming language context, everything is 'visual'. Clearly code, implemented by LabVIEW itself, operates under the cover, for example to implement the equals comparison, but that is completely hidden away from the programmer.

This is just a simple example. As you would expect, you are able to build fairly complex UIs, have access to a wide range of mathematical, string, flow control VIs; build applications modularly, reuse a VI across other VIs where it becomes a sub-VI and so on. Its strength lies in the VIs it provides for interacting with test instruments that are attached to the PC running LabView. These simplify, at least at the connection and interaction level, sending commands to a test instrument and receiving a result back. These are not geared to a specific standard - e.g. you don't have to use SCPI - so you can interact with the instrument as it expects. Obviously many test instruments support the SCPI standard so that's the likely use case, but you could attach an Arduino that is listening for specific commands on its serial port and responding to those.

NI position LabVIEW, rather optimistically in my opinion, as a tool for non-programmers: given the simple example above I'm sure most of you can work out what it is doing to calculate the factorial. I go into more detail about visual programming below, the programming model and, as you may suspect, I give a less optimistic opinion on the likelihood of non-programmers developing in this tool.

Hardware Requirements and Installation

LabVIEW (all versions and editions) is Windows only and as far as I can tell there is no intention to create a Linux or MacOS version of any edition. I run it on my MacBook Pro using a Parallels VM running Windows 10 Pro and it works very well. It is resource intensive at startup but during normal operation is not too bad - I run the VM with 2 processors and 8GB of ram and it works well with GitKraken, Visual Studio code, Arduino IDE, Edge all running as well. I wouldn't run it with less ram.

The download is large and a LOT of NI applications are installed. Once installed, the whole kit-and-kaboodle takes up just under 8.7GB. As well as LabVIEW NXG, of the twenty or so additional applications the following prove useful:

NI Package Manager: for installing Instrument Drivers and other tools. LabVIEW NXG Community Edition is not installed via Package Manager and any reference to NXG within it is to the commercial version.
NI Max: a tool for enumerating devices connected to your PC over the network, USB, Serial and Thunderbolt ports (and I suppose other ports that your PC may support.) Using this tool you can configure the devices with useful names and connection attributes. For example, it may find an Arduino on COM8 but referring to it as COM8 in your code isn't that great: rename it to ArduinoUnoR3 and set up the baud rate to 115200 etc. NI Max can also be used to test the connection to ensure that LabView can connect and send commands. Note that LabVIEW NXG has a built in tool called System Designer which does, essentially, the same thing.
NI IO Trace: a tool that captures the traffic flowing between LabVIEW and a test instrument to help analyse any comms problems.

Using LabVIEW NXG

Launching LabVIEW NXG, you are presented with a home page from where you can create a new project using an existing template or take a look at lessons and examples to get to grips with the tool.

(Templates to choose as the basis of your own projects)

(Built in lessons and examples for learning how to use the tool and program with LabVIEW)

I'm not going into detail for any of these as it's way beyond the scope of this review. Suffice to say, the lessons and examples are worth following if you are new to LabVIEW NXG - especially given the frankly outrageous price of NI's underwhelming tutorial videos - as they go through many aspects of programming and interacting with test instruments. The templates give excellent starting points for your own applications although many of them I would categorise as 'advanced' so shouldn't be used until you have a better grasp of developing your own VIs.

Most work is undertaken on a VI (a .gvi file), and you will flip back-and-forth between the Panel View and Diagram View (and possibly the Icon View) panes:

Panel View

This view of the project shows the 'Panel' of the VI that you have open, in this case the Calculate Factorial VI. The panel nominally represents the front panel of an instrument (the above doesn't) and might consist of a variety of UI components, including data values, buttons, dials, switches and so on. It's a bit of an obtuse metaphor really as it really represents the data and interaction elements for your VI. This example is very simple, consisting of just an Unsigned 32-bit integer that a user can enter a Starting Value into, and an Unsigned 32-bit integer that can display a calculated factorial. More complex panels will consist of booleans, arrays, constants, switches (actually, just boolean data types) and so on.

The UI component tray is used to drag elements onto the Panel - when you click on one of the symbols a 'drawer' opens given you access to elements. The properties tray on the right is used to configure an element - in this case, you could select a Double, Float, Signed Integer etc, give it a default value, max and min values and so on. At face value, this is similar to how you might create a UI with something like Visual Basic but these elements not only represent a possible UI they are also the 'variables' and 'constants' you might use in your program. To clarify further, look at the Boolean options which are represented as buttons:

(Buttons - boolean data types - available to place on the UI)

These represent a type of physical button that can be pressed but all are essentially boolean variables to your program: on/off, ticked/unticked, lit/not lit etc. LabView may also give these additional functionality under the covers - e.g. a button may be configured to operate as a momentary switch, or to be 'true' when released etc.

It's pretty clever really, works well in terms of not only creating a UI but representing those elements as variables which operate in a way you may find on an instrument's front panel, and available elements are comprehensive enough. It's possible to create reasonably complex UIs:

Diagram View

The detail view is where you write your code. Elements dropped on the Panel View can be dragged onto the workspace to be used in your program:

Here, you can see I've dropped the two Panel elements onto the workspace and have created the factorial calculation by accessing code elements from the left-side tray. Some elements can be configured further using the panel on the right - here, the Case structure shows two options - False and True - but I could add more.

By convention, programs are 'written' left to right but it's LabView that controls the actual execution based on data flows - when data can flow, it does so! This is a fairly simple VI and I'll explain the elements:

The Starting Value panel element plus a constant '1' is connected to a > comparator element (is Starting Value > 1). The blue lines are integer data flows: in fact, in this VI they are all blue but they are coloured by data type and have different appearances depending upon data type as well. An array of Integers would be a thick blue line rather than the thin blue line seen here.
Starting Value is also connected to the 'square' labelled True at the top, as is the result of the comparator. This square is actually a Case structure (selected from the tray on the left and drawn onto the workspace.) You'll notice the blocks at the end of the data flow - these are called tunnels as the data values are passed (tunnelled) into the structure. Because this is visual programming, it's perfectly possible to draw a data flow straight across that structure without it passing in which will be obvious because there are no tunnel blocks. The comparator output connects to a tunnel marked with a '?': this represents the Case structure options - True and False for a boolean, but, say, for an enumerated data type it would generate case options for each possible enumerated value.
The Starting Value passes straight into a While Loop structure which will execute until an exit condition is reached, represented by the Red circle on the right side. This is connected to the output of an equals comparator which will output true when a decremented value equals 1.
The tunnels that are marked with a triangle just represent data passed around the While loop: the output of the multiplication element loops around to become the input on the next iteration as does the output of the decrement.
When the While loop terminates, the final calculated value passed out to the Factorial Panel element.

I think this is simple enough for you to get the idea even if the explanation isn't that clear (sorry.) As LabVIEW NXG is a visual programming language, then you'd be right in thinking that there are lots and lots of these programming constructs. To put it into some better context - think of the keywords available when writing a Java, C, Basic etc program: each of these has its own visual element in LabVIEW NXG (as well as library VIs.)

Like more traditional programs which may reuse other programs, subroutines etc, VIs can be used in other VIs by dropping them onto the Diagram workspace. Typically, they would have inputs and outputs so that they can be incorporated into the data flow. This is achieved using the Icon View.

Icon View

This view is used to configure how the VI is interacted with when used as a sub-VI (i.e. embedded in another VI.) Like the elements you saw in the Diagram View, such as decrement, it has a visual look, points to connect inputs and points to connect outputs. Here, the Calculate Factorial VI has been defined with the Starting Value as an input and the Factorial as an output. If I was to drop this onto, say, a calculator VI as a function, then the value entered on the calculator could pass in to this VI when the calculator's '!' button was pressed and the Factorial passed to the calculator's display value.

Again, I'm sure you get the idea. This is quite a plain icon but the facility exists to jazz them up and the icon can be sized to have any number of inputs and outputs.

Running Applications

VIs are run by clicking on the green triangle above the Views (refer back to the Panel View.) Being a green triangle the VI can run: if it is a black, broken triangle there are errors to fix in the VI execution chain somewhere:

Like any other programming IDE, LabVIEW NXG allows the debugging of VIs using breakpoints, stepping, data inspection and so on.

What else?

It's been a bit of a whistle-stop tour through the LabVIEW NXG programming environment but what else does it provide for? It's not the same as a more typical IDE as it isn't a typical programming model! The LabVIEW NXG IDE - if I can call it that - is sufficient for the programming model it supports. Help isn't too bad and can be contextual: select an element and click on the Contextual Help button in the properties panel and as you hover the element, its inputs and its output it will explain what these are. There's a pretty comprehensive online manual accessible directly from the tool.

You won't find colour highlighting, mass find-and-replace, go to definition, autocomplete, etc etc as those are concepts that are just not applicable. You won't find complex compiler or execution options either as they aren't needed. That means the interface is simple and once you have your head around programming visually then it's pretty intuitive.

Walkthrough of Creating a Simple Test Program

The main reason for using LabVIEW NXG is of course to create test programs that interface to a Test Instrument to instruct it 'do something' and, if required, read one or more results back. For the purposes of this review, I'll just create something simple - ask an Instrument for its Identity. This will be through a SCPI command, *IDN?. The steps to create the program are:

Create a new, blank project
Use System Designer to ensure that the required test instrument is available, and add it if not
Create a new VI
On the Panel View, add in a Session Control and a String Indicator
On the Design View, create the program: open a VISA connection to the Instrument selected in the Session Control, write a command, read a response and load it into the String indicator, and then close the session.
Run the Application

I've created a video, for which I'll apologise in advance being no Spielberg, going through these steps:

The final result:

Obviously, you'll likely be creating a much more involved test rather than just ask an instrument for its identity, but the principle will always be the same using the same VISA VIs as shown above. A session only needs opening and closing once per app (as long as you can pass the session data into the write and read.) In the Hardware Abstraction Framework post I describe in more detail a framework approach to creating test programs which covers much more involved testing with instruments.

Visual Programming in Detail and the Execution Model

I have been used to Visual Programming in the past using IBM's VisualAge IDEs for Smalltalk and Java and I would guess many readers will be familiar with Microsoft Visual Basic. These are visual programming in the sense that you create a UI with components and then write logic for events and behaviour behind that screen. As I've already mentioned, you don't 'write' code in the typical sense of programming you may be used to. Everything is done visually by wiring up visual representations of logic with only minimal amounts of property configuration. So this is visual programming to the max!

Again, as previously mentioned, this means that language keywords are all represented through visual components:

(Programming elements for Numeric data types)

(Programming elements for program flow of execution - to the extent that LabVIEW NXG allows that!)

These are just dragged out of the tray and then wired up with data flows.

Yes, you'd be right in thinking there must be lots of these. There are. In 90% of cases, they are easy to find in the tray on the left and can be searched for (if you know the name of course!) Sometimes they can be frustratingly elusive; favourites or often used can be remembered/bookmarked for quick access. In any event, I have to say that I've not failed to find a programming element that I've needed so what is available is comprehensive enough for anything I've attempted to create.

Visual programming, though, can be extremely tedious. Anyone familiar with the keyboard can very rapidly type in lines of code: here, you are programming by opening the tray on the left, dragging out the needed element, dropping it onto the workspace, then wiring up its inputs and outputs - lots of mouse clicking and dragging. It can get tedious to the extreme. Admittedly, typing in realms of code isn't exactly exciting but at least its quick! Take an example familiar to everyone: 'If ... then ... else if ... then .... else if ... then ... ' - a nested IF statement. In LabVIEW NXG you can't do this, you have to use nested case structures and that becomes a real pain because of the amount of time to set it up and lay it out. I've found myself trying to work out convoluted code to try and avoid it!

You soon get used to 'reading' a program by looking at its visual representation but personally I've found that easier with my programs than with someone else's programs. I don't know why, but I suspect it's something to do with years of muscle memory reading written code in the order it's written, rather than trying to figure it out by 'looking at a picture.' I suspect that as more familiarity with the paradigm is gained, so the ability to read visual programs will also improve; I also suspect that if someone doesn't follow the 'left-to-right, top-to-bottom convention' it will be harder still. I've not come across any program that doesn't follow that convention so I would assume that authors are all adherents.

NI say that LabVIEW (any edition) is great for non-programmers to use because it's visual. I don't buy it. Ultimately being able to program is not about the syntax, nor about the IDE nor how you write a program (pictures or text); it's about getting your head around logic and breaking down what you need to achieve into the logical steps to get there. Inherently, it's about understanding the sequential, iterative, and selection logic, and stitching it together, which is non-intuitive. That requires learning to program, and thus becoming a programmer, and making it visual rather than textual doesn't obviate that need nor does it make it easier. Nobody will load LabVIEW and be able to string together an application using their PSU or DMM unless they have experience in creating programs.

If NI said that LabVIEW is great for programmers because it makes writing programs easier as syntax is less encumbering because it's visualised, would I buy that? To a certain extent, yes: from a programmer's perspective, LabVIEW NXG is not difficult to pick up as a language: the keywords, if you like, are all laid out to see in the tray on the left side of the Diagram View, and the syntax is constructed by wiring the inputs and outputs of elements together. It becomes intuitive for programmers quite quickly. Certainly a lot of complexity is encapsulated in those visual elements.

Following that 'easier' logic further, LabVIEW (all editions) has an execution model that is inherently parallelised - it executes parts of the program as soon as it can based on data availability on the inputs and no guarantee is offered on the order of that execution; most languages tend to run in quite a defined order (e.g. start at main() and follow it on from there), even when interrupts are involved. This can be confusing until you get used to it, as execution doesn't always happen in the order you expect. However, as it does guarantee data integrity it's very easy to write programs that are parallelised without having to put much thought into it: no worry on race conditions for example. Once you understand that, which does come quite quickly, the visual programming and the execution model are very complementary.

Debugging

LabVIEW NXG has the ability to debug applications as they run in a similar fashion to any other IDE. It is possible to:

Set breakpoints and then step-in, step-through and resume execution
Set watch points (called Probes) on data flows that will display the value that passes along it
Watch the execution flow without breakpoints, highlighting the data values as the program executes. This gives an excellent view of how LabVIEW NXG is running your application and the order of execution
Set the execution to remember values on data flows so you can add probes later to see what happened.

Let's demo this with the test application created above, again apologies for the quality:

Another common approach to debugging is to insert System output commands into the source. You could do this with LabVIEW NXG but only by writing data to, say, a file or data type you can probe or look at afterwards. Clunky!

It's also not-uncommon to comment out bits of code so that you can try and narrow down a problem. How does LabVIEW NXG handle that? Well, really it doesn't, but you can achieve something similar with what it calls a 'Disable Structure? To LabVIEW NXG, this is like a Case structure with a 'Disabled' and 'Enabled' option: any code within the Disabled option won't run; any code in the Enabled option will run. Metaphorically, it's a little like compiler directives. Drag this structure around the code you want to 'comment' out and ensure it is in the Disabled option. Code in these options can be swapped easily enough so it's useful for trying alternate bits of code as well as commenting out. However, it's a bit of a pain: when you've finished with it, the only way to 'uncomment' is to delete the structure and that also deletes the contained code which must, therefore, be dragged out first. You'll get a taste for the clunkiness in this demonstration:

Object Oriented Programming in LabVIEW NXG

LabVIEW NXG allows the creation of Classes with associated attributes and methods (VIs.) Attributes on a class are always Private to that class, thus encapsulated and not visible outside the class, even to subclasses, but usefully it can auto-generate fully implemented Read and Write methods for that data which can be set Private, Protected, Friends or Public. Methods, likewise, can have the same access restrictions. 'Friends' are other classes that are defined as such against the class and this allows access to otherwise protected methods from non-inheriting classes. Methods can be set as requiring overriding (i.e. implementing) by subclasses.

From the description so far, it's obvious that LabVIEW NXG allows for inheritance of classes. Once that inheritance is established, a subclass can override parent methods and create its own.

Once a class is defined, it can be 'dragged' onto the Panel or Design view where it is becomes an instance of that class with default values for any attributes. This then allows the instance to be used as inputs and outputs to other VIs; for a class' method, an instance of that class is required to be passed in as one of the inputs and is recommended to be passed out as an output. Defining it as an input allows you to say whether it should be statically called - i.e. with an instance of that specific class - or dynamically called - i.e. with an instance of that class or subclass (or friend, I think!)

So far, so OO: the above describes encapsulation, inheritance and polymorphism. However, it isn't all plain sailing:

Due to the nature of LabVIEW NXG's execution model (highly parallel, guaranteed data integrity) all use of an instance's data is By-Value**. This means, whenever a data flow containing an instance forks or tunnels (into a Case Structure, Loop etc), a copy of that instance is taken and any changes to it are on that copied instance. If those changes need to be reflected on the original instance, they must be separately written to it, the need for which happens more often than you might think.
There is no concept of NULL, so no code such as 'if NULL then ...'. It's not possible to tell if an instance has been initialised with, say, zero value for an attribute or purposefully set at zero - at least, not without additional code. Again, the requirement for NULL crops up more often than you may think.
There is no reflection in LabVIEW NXG. Whilst not used a lot in most applications, it is useful when you would like to externally configure how an application runs by getting it to create instances based on a configuration file or read data. The alternative is to read these values and use a Case statement to interpret the 'String name' and output a 'Class instance' based on it. That case statement is not readily maintainable and could be of quite some size! My understanding is that LabVIEW CG does have reflection available and so I would expect that this would appear in LabVIEW NXG in some future release.
There is no overloading of methods, all methods must have a unique name and any inputs and/or outputs don't form part of the method's identity.

** It is possible to use an instance by-reference but it's not recommended as it removes the data integrity guarantee and could result in race conditions given the execution model. LabVIEW NXG does provide Program Flow elements to assist with this but they are all execution blocking (all other threads are stopped.) Basically, you need to know exactly what you are doing, and the potential outcomes, to go down this route and the VI complexity grows accordingly.

So, not perfect then - and the by-value still bites me! - but it is sufficient to allow for very modular applications to be created. I've found it to be good enough for my purposes and would expect that most of my applications that I create will be strongly OO based.

Packaging and Reuse

This is a strange one. LabVIEW NXG allows you to create packaged binaries of functionality that, in theory, means you can refer to them in other projects as standardised, version controlled units of functionality. I say 'in theory' because for some bizarre reason, whilst you can create them, you can't actually use them in other LabVIEW NXG projects! That feature is not supported - presumably it will appear at some point in the future. You can package a project (or parts of the project) as a library of code that can be imported into another project. It is then, of course, a copy of the original source so you'd need discipline to avoid unwanted changes and 'forks' of base functionality. Note that it is possible to create the library without the 'source code' so that would help to some extent.

I've got nothing more to add on this: it's only supported in the basic sense, but would be really useful when you want to share pre-built functions for test instruments across a development base.

Documentation

The documentation is, generally, pretty good. There's an online manual accessible directly from LabVIEW NXG which can be launched at the section you are interested in - press 'help' with a specific element selected. There are some parts of the manual that are a bit lightweight: for example, you may be interested in how 'ABC' works so you press help, the manual launches to the section on 'ABC' and it tells you to 'Use ABC component to do an ABC'. I hate that in a help manual, but fortunately it isn't too prevalent.

Contextual help is available directly in the tool. Select an element and click on 'Contextual Help' and a small dialog is opened describing the element; as you move the mouse over, say, an input it will then describe that input. Generally I have found this to give useful information. You can see this in one of the videos above.

The tool itself, as seen above, has multiple built in learning and example projects that are definitely worth investigating. I have found these to be excellent.

NI's learning portal has quite a number of training videos intended to walk you through using LabVIEW NXG to build applications, including exercises and so on. These are ok for what they are - I was lucky, they offered access to them all for free throughout June because of the lockdown (for future readers: remember the nightmare that was 2020?!!) - but they are very expensive (> £500 +vat IIRC) and they definitely aren't worth that sort of money! There are a few videos on YouTube as well. For some usages of the tool, you could get away with reading about or watching videos about LabVIEW CG but you will need to make the necessary translation and these may describe an approach not actually possible in LabVIEW NXG.

In summation, I'd say the documentation isn't too bad. With all the above resources, I've built some fairly complex test applications. I've got a lot of development experience under my belt so have a good idea of how to pick up a new language and what I need to do or find out to fix problems - this may skew my impression of how easy it is to pick up so any contrary views could be noted in the comments please.

Problems and Support

I've come across a few bugs using the tool. The real biggie is in the way LabVIEW NXG manages its files: each project file is an XML file in its own right and the Project is an XML file that 'binds' them all together. The problem is, that if you save a code file (VI), the project file isn't automatically saved if it changed: if LabVIEW NXG crashes and burns (and it does) then, when you reload the project, it is in an inconsistent state and there are no tools or options available to you to fix it (worse, it tells you where the inconsistencies are but gives you no options to resolve!) At that point it becomes a manual operation to rebuild the project and it's a major PITA.

I can't stress this enough: CTRL+S to save a file is going to leave you in distress; CTRL+SHIFT+S to save all is your lifeline to sanity and you MUST become intimately familiar with it - develop the muscle memory.

I think the way it manages its files is a big problem for NI and they need to rethink it (I suspect they won't.) LabVIEW NXG has crashed on occasion for unknown reasons, but it also crashes under a specific circumstance: cast your eyes back to when I discussed 'broken VI'. An application won't run if a VI is broken, or a VI in the determined calling path is broken. However, I have found on many occasions that it doesn't always pick up broken VIs in the calling path so it allows you to run your start VI: when it hits that broken one, LabVIEW NXG will crash and burn immediately. You'd better have CTRL+SHIFT+S'd that project!

Other problems I've had have really been about understanding how to achieve things for which I've turned to the support forums (the community edition has no formal support as you'd expect.) My experience has been good but on occasion I've had to wait a few days. The forums are not highly active (in, say, the way that Element 14 is) but there are knowledgeable people and NI engineers frequent as well. There's not a lot of answers on Google unfortunately - you may be able to adapt advice about LabVIEW CG to your problem - so you will need to use the forum.

Summary

Whilst a long post, this has been a bit of a whistle-stop review of LabVIEW NXG, it would be impossible to describe all the features and possibilities available: ask me questions below and I will endeavour to investigate and answer.

Personally, I've found it a mixed bag that ultimately I've decided is 'very useful especially as it's free': it can be somewhat tedious to develop with, but it does provide a really simplified way to interact with your test instruments and the execution model is really useful in creating parallelised applications. To that end, it does exactly what I expected and I think I will stick with it. I did wonder whether it would be worth investing time in learning Python and using PI-VISA (rather than NI-VISA built into LabVIEW NXG) and the answer is: I don't know. I have never developed in Python so I don't know how much easier it may be to create usable test applications with funky UIs, traceable debugging and captured and reviewable data results. If I'd started with that instead of LabVIEW NXG would I be saying the same in reverse? It would be interesting to know the views from anyone familiar with using both for interacting with test instruments. Obviously, Python is more generalised so is useful in other scenarios whereas LabVIEW NXG is very focussed on Instrument Testing. That's no bad thing, as it's good at what it does.

I do wish that the Community Edition was better supported with Instrument Drivers (or Instrument Drivers that work!). Whilst not strictly necessary, these drivers cut down some of the boilerplate code needed and usually provide examples of how to use them. In LabVIEW parlance a 'Driver' is a suite of VIs that provide functional access to an Instrument's features that can dropped straight into your application (it isn't the low level interfacing code that sits in an OS which is the more familiar usage of the term.)

l don't want to put you off with my comments under 'Problems' above: it's criminal really for LabVIEW NXG to leave a project inconsistent, but I think it's worth persevering with and once you've got the correct save approach stuck in your muscle memory, it becomes much, much less of an issue. It doesn't crash often enough for it to be an issue with the right approach to saving.

Finally, I'm no expert with LabVIEW NXG yet as I've only been using it a few months and have no experienced with LabVIEW CG: if you find any mistakes in this review, please let us know in comments so we can all benefit.