LabVIEW 2017 – new features and changes

There’s left two weeks till NI Week 2017, and everyone is waiting for release of new LabVIEW 2017 (and, of course, some news regarding NextGen of LabVIEW). But – simple search and small trick with NI FTP server allows to download the official release of LabVIEW 2017 (32-bit and 64-bit installers are waiting for you)! If it’s there, so we can install it, and check – what new features are waiting for us in a near future?

The first change what you see – it’s a design. Maybe, black color looks interesting, but icon – as for me – in LV2015, LV2016 looked a bit better, then now…

So, let’s go to menu Help -> LabVIEW Help…, and see the “LabVIEW 2017 Features and Changes” list. Let’s go one-by-one.

1. Reduced VI Load and Compile Time.

So, for Windows, compiler was changed in a more aggressive way, so VI load time and VI compile time is reduced. Honestly, I didn’t check this point, but I believe, that this change will help in LV performance for sure.

2. Maintaining Wire Connections When Moving Objects

This one is quite interesting from usability point of view – now “LabVIEW 2017 automatically maintains wire connectivity when you move objects in and out of structures on the block diagram”. No repairing of broken wires are needed! But, if you don’t want to use this feature, you can move object in/out from the structure while pressing <W> key.

3. Malleable VIs

Malleable VIs, or as Jeff Kodosky named it on CLA-E in Vienna “LabVIEW macros” – is something almost completely new. Why “almost completely new”? This feature was possible to do in previous versions of LabVIEW, but it required scripting usage. Now, it’s much easier.

So, what is it? Malleable VIs (they have .vim extension) are inlined into their calling VIs, and they adapt each terminal to input data type. Sound like it’s polymorphic VIs, isn’t it? The benefit is, that it’s more flexible – unlike as polymorphic VI, you don’t need to create handler of all possible data types. This is done automatically – by computing whether data type is acceptable by implementation.

So, if you have Increment function, it will automatically accept numeric data types, arrays, etc. – but will ignore strings (so it’ll just pass data through).

LabVIEW 2017 contains already set of built-in Malleable VIs, and they are:

Array palette:

• Decrement Array Element;
• Increment Array Element;
• Shuffle 1D Array;
• Shuffle 2D Array;
• Sort 2D Array;

Comparison palette:

• Is Value Changed;

Conversion palette:

• Number To Enum;

Timing palette:

• Stall Data Flow.

Also, Malleable VIs use Type Specialization Structure, which basically decides, whether input data type is acceptable. But, as LabVEIW 2017 help says, this structure is not a public LabVIEW feature. It’s experimental, so maybe it contains some bugs, or something. When it’ll be “officially” released for usage – not clear.

By the way, Malleable VIs is possible to create in couple ways: one is standard, like New… -> Malleable VI; and second – just rename VI extension to .vim.

4. Read-Only Access for Data Value References

For In Place Element structure, while adding Data Value Reference Read / Write Element node, one can right-click on the write node, and select option “Allow Parallel Read-Only Access”. So when the border node on the right side is not connected, LabVIEW 2017 allows parallel read-only access to data without modification of the data value reference.

5. New Channel Template – Event Messanger

This channel – Event Messanger – allows to transfer data from multiple writes directly to one, ore more Event Structures.

6. Application Builder Enhancements

One of the most useful – is the Backward Compatibility of the LabVIEW Run-Time Engine. So, since LabVIEW 2017, LabVIEW supports backward compatibility for the LabVIEW Run-Time Engine. It’s time to forget about installing of all versions of Run-Time Engines on the machine, or recompiling the code! LabVIEW

This improvement is applied to exe, dlls and ppls. To enable the option, in Advanced tab of the build specification, option “Allow future versions of the LabVIEW Runtime to run this application” / “Allow future versions of LabVIEW to load this packed library” / “Allow future versions of LabVIEW to load this shared library” (depends on the build type) should be selected.

Also, dlls performance and stability are significantly improved. And not just calls of external dlls in LabVIEW, but also calls of LabVIEW dlls in other languages (does anyone doing it like this? Interesting…). For example, calls to LV-build dlls from C-code now can run in a multithreaded execution system.

So, have fun with this new, LabVIEW 2017 release!

P.S. Thanks to http://labviewportal.org/ and dadreamer for the inspiration to make this small summary review.