|Download Help (Windows Only)|
The Idea Exchange icon denotes a new feature idea that originates from a product feedback suggestion on the NI Idea Exchange discussion forums at ni.com.
Refer to the LabVIEW 2017 Upgrade Notes for a complete list of new features and changes, for information about upgrade and compatibility issues specific to different versions of LabVIEW, and for upgrading instructions.
Refer to the readme.html file in the labview directory for known issues, a partial list of bugs fixed, additional compatibility issues, and information about late-addition features in LabVIEW 2017.
(Windows) For LabVIEW 2017, NI upgraded to a more aggressive compiler for building both the LabVIEW development environment and the LabVIEW Run-Time Engine. This upgrade reduced aggregate VI load time and VI compile time.
LabVIEW 2017 automatically maintains wire connectivity when you move objects in and out of structures on the block diagram. When an object moving in or out of a structure is connected to an object in the structure, LabVIEW creates or removes tunnels to maintain wire connectivity. You can toggle automatic wire connectivity when moving objects by pressing the <W> key.
LabVIEW 2017 includes malleable VIs (.vim) that are inlined into their calling VIs and can adapt each terminal to its corresponding input data type. With malleable VIs, you create a VI to perform the same operation on any acceptable data type instead of saving a separate copy of the VI for each data type.
A malleable VI is similar to a polymorphic VI but is more flexible when determining which data types are acceptable. A polymorphic VI uses a predefined list of acceptable data types. A malleable VI computes whether a data type is acceptable by implementation.
Malleable VIs use the .vim file extension. You can create a malleable VI by selecting File»New and selecting Malleable VI from the New dialog box. You can convert an existing VI into a malleable VI by saving the file with the .vim file extension.
|Note You can convert only standard VIs into malleable VIs. You cannot convert polymorphic VIs, global VIs, or XControl abilities into malleable VIs.|
LabVIEW provides the following malleable VIs for use in your applications. The icons of the built-in malleable VIs have orange backgrounds.
Refer to the labview\examples\Malleable VIs\Basics\Malleable VIs Basics.lvproj for an example of using malleable VIs.
[Idea submitted by NI Discussion Forums member DanyAllard.]
LabVIEW 2017 includes the following new and changed VIs and function:
The Data Value Reference Read / Write Element border node of the In Place Element structure can allow read-only access to a data value reference. Right-click the border node on the right of the structure and select Allow Parallel Read-Only Access. When the border node on the right is unwired, LabVIEW allows multiple, concurrent read-only operations and does not modify the data value reference.
LabVIEW 2017 includes the Event Messenger channel template. Use this channel to transfer data from multiple writers to one or more Event structures. Each write operation to the channel triggers an event. The Event Messenger channel allows the channel syntax to combine with the event syntax that controls your user interface events and generated events. Refer to the labview\examples\Channels\Event Messenger\Channel - Event Messenger.lvproj for an example of using the Event Messenger channel.
LabVIEW 2017 includes changes to the Get VI Dependencies (Names and Paths) method. The Keep Express VIs? parameter is renamed to Keep Express and Malleable VIs?. If Keep Express and Malleable VIs? is FALSE (default), LabVIEW returns the names of the hidden instance VIs that underlie the Express VIs and malleable VIs. If TRUE, LabVIEW returns the Express VIs and malleable VIs as dependencies. If you want edit-time dependencies, set Keep Express and Malleable VIs? to TRUE. If you want run-time dependencies, set Keep Express and Malleable VIs? to FALSE. Regardless of this setting, LabVIEW includes the subVIs of the instance VIs as dependencies of the referenced VI.
LabVIEW 2017 includes the following enhancements to the LabVIEW Application Builder and build specifications:
In previous versions of LabVIEW, you cannot load and run binaries and VIs built in older versions of LabVIEW without recompilation. Starting from 2017, LabVIEW supports backward compatibility for the LabVIEW Run-Time Engine. For example, versions of LabVIEW later than 2017 can load binaries and VIs built with LabVIEW 2017 without recompiling. This improvement applies to stand-alone applications (EXEs), shared libraries (DLLs), and packed project libraries.
To enable binaries to be backward compatible, place a checkmark in the following checkbox on the Advanced page of the specific dialog box depending on your build specification:
|Build Specification||Dialog Box||Checkbox|
|Stand-alone application (EXE)||Application Properties||Allow future versions of the LabVIEW Runtime to run this application|
|Packed project library||Packed Library Properties||Allow future versions of LabVIEW to load this packed library|
|Shared library (DLL)||Shared Library Properties||Allow future versions of LabVIEW to load this shared library|
LabVIEW enables these options by default for build specifications you create in LabVIEW 2017 and later. You can disable these options to bind a build specification to a specific version of LabVIEW. Disabling these options prevents any changes to the performance profiles and helps you avoid unexpected problems resulting from compiler upgrades. For real-time applications, these options do not appear in the dialog boxes but the functionality is enabled by default.
In LabVIEW 2017, the performance and stability of LabVIEW-built shared libraries (DLLs) are improved significantly, specifically for calls to LabVIEW-built DLLs from LabVIEW and other languages. For example, calls to LabVIEW-built DLLs from a C-language application now run in a multithreaded execution system. The improvements also prevent some potential deadlocks and atomicity violations while calling LabVIEW-built DLLs from LabVIEW.
To use this functionality, place a checkmark in the Execute VIs in private execution system checkbox on the Advanced page of the Shared Library Properties dialog box. By default, this option is enabled for new build specifications. This option is disabled for build specifications migrated from LabVIEW 2016 and earlier to prevent unintended changes in behavior. For example, disabling this option prevents shared libraries that rely on single-threaded execution to execute in a multithreaded execution system, when LabVIEW-built shared libraries are called from a non-LabVIEW application. (NI Linux Real-Time) This option is disabled by default for Linux RT targets because of potential performance jitters.