When you upgrade to LabVIEW 2013, refer to the upgrade and compatibility issues for the version of LabVIEW from which you are upgrading:
Refer to the readme.html file in the labview directory for information about known issues in the new version of LabVIEW, additional compatibility issues, and information about late-addition features in LabVIEW 2013.
Refer to the National Instruments website at ni.com to access upgrade and compatibility issues you might encounter when upgrading from LabVIEW 8.6 or earlier to the current version. Also refer to all sections of this topic for information about other upgrade issues you might encounter.
You might encounter the following compatibility issues when you upgrade to LabVIEW 2013 from LabVIEW 2009. Refer to the Upgrading from LabVIEW 2010, Upgrading from LabVIEW 2011, and Upgrading from LabVIEW 2012 sections of this topic for information about other upgrade issues you might encounter.
The following VIs use a higher attenuation than the value of the stopband attenuation input to design an elliptic filter when the filter order is high:
In LabVIEW 2010 and later, the VISA Find Resource function returns error code –1073807343 if the system does not locate any devices.
LabVIEW 2010 and later do not support the following VIs, functions, and nodes:
Due to changes to the LabVIEW compiler, the results of several mathematical operations performed using floating-point numbers might differ from results returned in previous versions of LabVIEW. The accuracy of algorithms written in LabVIEW using floating-point numbers is the same and in many cases improved in LabVIEW 2010 and later. However, in a few operations the results might be less accurate than in previous versions. LabVIEW 2010 and later implement functions internally with the same numeric precision as the input data types, whereas previous versions implemented functions with a higher numeric precision than the input data types. The acceptable error for the results of these operations is still appropriate for the data types of the inputs.
|Note Refer to the National Instruments website at ni.com for more information about mathematical operations using floating-point numbers.|
In LabVIEW 2009 and earlier, you can create a class with a strictly typed VI refnum that includes itself or a child class in the connector pane of the VI. In LabVIEW 2010 and later, the class breaks unless you use a VI refnum that is not strictly typed or remove the VI refnum from the private data control.
In LabVIEW 2010 and later, if you load a project with an installer that requires Windows 2000 or later, LabVIEW updates the system requirements to Windows XP or later. After you install LabVIEW 2010 and later, you cannot use a previous version of LabVIEW on the computer to build installers that run on Windows 2000.
In LabVIEW 8.5, LabVIEW 8.6, and LabVIEW 2009, when you specify an incorrect calling convention for a Call Library Function Node, LabVIEW recovers from the error and uses the correct calling convention. LabVIEW 2010 and LabVIEW 2011 do not perform this check, which requires you to select the correct calling convention yourself. Therefore, if you convert VIs that contain Call Library Function Nodes from LabVIEW 8.5, LabVIEW 8.6, or LabVIEW 2009 to LabVIEW 2010 or later, the VIs will crash if they have the incorrect calling convention selected.
Complete the following steps to prepare a VI that contains Call Library Function Nodes to be converted to LabVIEW 2010 or later:
After you resolve all calling convention errors, you can convert the VI to LabVIEW 2010 or later.
LabVIEW 2010 and later has known compatibility issues with TestStand 4.2.1 and earlier versions. Refer to the National Instruments website at ni.com to access the KnowledgeBase article that details these issues.
Refer to the Readme.html file for the version of NI TestStand you use, located on the TestStand installation media and in the <TestStand>\Doc directory, for additional information about LabVIEW and TestStand issues.
You might encounter the following compatibility issues when you upgrade to LabVIEW 2013 from LabVIEW 2010. Refer to the Upgrading from LabVIEW 2011 and Upgrading from LabVIEW 2012 sections of this topic for information about other upgrade issues you might encounter.
In LabVIEW 2011 and later, the multicast addr input of the UDP Multicast Open VI is a required input. Also, the port output is renamed port out.
In LabVIEW 2011 and later, the Zero Phase Filter VI no longer has the init/cont input in any of its polymorphic instances. To use the new version of the VI, replace instances of the Zero Phase Filter VI from previous versions of LabVIEW with the VI of the same name from the Filters palette.
The behavior of the following properties, methods, and events changed in LabVIEW 2011 and later:
LabVIEW 2011 and later do not support the Subsystem From Selection method of the SimDiagram class.
To migrate a build specification for a target that does not support SSE2 instructions to LabVIEW 2011 or later, you must disable the SSE2 optimizations for the build specification. If you do not disable the optimizations, LabVIEW still allows you to build the associated application, but the application cannot run on the intended target.
In LabVIEW 2011 and earlier, you transfer data between versions of LabVIEW using the Flatten To String and Unflatten From String functions. In LabVIEW 2012, use the VariantFlattenExp VI in the labview\vi.lib\Utility directory to transfer this data. The VariantFlattenExp VI accepts a hex integer of the target version of LabVIEW to which you want to transfer data.
In LabVIEW 2011 and later, if you wire extended-precision numeric data to the terminal of a polymorphic VI that supports both the double-precision numeric and 64-bit integer data types, LabVIEW coerces the extended-precision numeric data to double-precision data.
This behavior matches the behavior in LabVIEW 8.5 and 8.6. However, in LabVIEW 8.0, 8.2, 2009, and 2010, LabVIEW selects the 64-bit integer data type instead of the double-precision data type.
When you call a LabVIEW shared library with the Call Library Function Node in previous versions of LabVIEW, the shared library fails to execute on target computers that do not have required resources installed. However, in those situations, the shared libraries do not automatically return an error or otherwise indicate that execution failed. In LabVIEW 2011 and later, when the Call Library Function Node calls these shared libraries, LabVIEW returns an error to indicate the failure. Therefore, affected LabVIEW shared libraries that misleadingly do not return an error in LabVIEW 2010 and earlier do return an error in LabVIEW 2011 and later.
This error-reporting enhancement affects, but is not limited to, VIs that call LabVIEW shared libraries with any of the following characteristics:
LabVIEW 2011 and later search for NI Example Finder data files (.bin3) in fewer locations than previous versions of LabVIEW. To ensure LabVIEW finds example VIs you create for the NI Example Finder, you must place the .bin3 files in one of the following directories:
You must use NI Spy 2.3 or later or NI I/O Trace 3.0 in LabVIEW 2011. NI Spy was renamed NI I/O Trace after NI Spy 2.7.2. NI I/O Trace is available on the NI Device Drivers media.
LabVIEW 2011 supports Measurement Studio 8.0 and later. Refer to the National Instruments website at ni.com to access the Upgrade Advisor and purchase Measurement Studio 8.0 or later.
You might encounter the following compatibility issues when you upgrade to LabVIEW 2013 from LabVIEW 2011. Refer to the Upgrading from LabVIEW 2012 section of this topic for information about other upgrade issues you might encounter.
LabVIEW 2012 and later do not support the following VIs, functions, and nodes:
LabVIEW 2012 and later do not support the following properties, methods, and events:
The following properties, methods, and events are renamed in LabVIEW 2012 and later.
|Class||LabVIEW 2011 Name||LabVIEW 2012 and Later Name||Type|
|LVClassLibrary||AncestorControlRefs||Ancestor Restricts Reference Creation||Property|
The behavior of the following VIs and functions changed in LabVIEW 2013.
The following VIs on the Web Services palette are rewritten in LabVIEW 2013. The VIs include a LabVIEW Web Service Request input, which replaces the httpRequestID input. To use the new functionality, replace the deprecated VIs with VIs of the same name from the Web Services palette.
In LabVIEW 2012 and earlier, when you dynamically register for events, any event you do not configure the Event structure to handle can reset the timeout terminal when that event occurs. For example, if you use the Register For Events function to register for the Mouse Up, Mouse Down, and Mouse Move events but configure an Event structure to handle only the Mouse Up and Mouse Down events, the timeout terminal resets when the Mouse Move event occurs.
|Note The timeout terminal resets only if you wire a value to that terminal.|
In LabVIEW 2013, non-handled, dynamically registered events do not reset the Event structure timeout terminal.
In LabVIEW 2013, creating and communicating with .NET objects requires the .NET Framework 4.0. The .NET Framework 4.0 allows you to load pure managed assemblies built in any version of the .NET Framework and mixed-mode assemblies built in .NET 4.0. The LabVIEW 2013 installer includes the .NET Framework 4.0. However, if you uninstall the .NET Framework 4.0 or attempt to load assemblies that target a different version of the .NET Framework, LabVIEW may return an error when you attempt to create or communicate with .NET objects.
LabVIEW 2013 loads the Common Language Runtime (CLR) 4.0 by default. However, you can force LabVIEW to load .NET mixed-mode assemblies that target the CLR 2.0.
In LabVIEW 2012 and earlier, when you add the system button to the front panel from the System palette, the return key toggles the value by default. In LabVIEW 2013, LabVIEW does not provide default key binding for the system button.
In LabVIEW 2012 and earlier, if you set the value of a latched Boolean control with the Value or Value (Signaling) property, LabVIEW returns an error. However, if you change the latched Boolean control to a type definition, LabVIEW no longer returns an error. In LabVIEW 2013, to avoid race conditions, the Value and Value (Signaling) properties always return an error if you attempt to set the value of a latched Boolean control.
In LabVIEW 2012, you can use the Conditional tunnel option to include only the values you specify in each output tunnel of a loop, but National Instruments recommends you consider alternatives to the conditional tunnel in parts of the application where performance is critical. In LabVIEW 2013, performance improvements to conditional tunnels reduce memory allocations for the Conditional tunnel option.
LabVIEW returns an error if you wire a custom control to the Insert VI method in the SubPanel class. To wire a custom control to a subpanel, add the control to the front panel of a VI and wire that VI to the subpanel.
In LabVIEW 2012 and earlier, you view and edit Secure Sockets Layer (SSL) certificates and Signing Requests (CSRs) from the NI Distributed System Manager. The Distributed System Manager no longer supports this functionality.
You now can create, edit, view, and remove SSL certificates and CSRs from NI Web-based Configuration & Monitoring. From the NI Web-based Configuration & Monitoring utility, navigate to the Web Server Configuration page and display the SSL Certificate Management tab to manage your SSL certificates and CSRs.
In LabVIEW 2013, you no longer use RESTful Web Service build specifications to create Web services or to configure properties, such as URL mappings, for Web services. You can continue to use build specifications you created in LabVIEW 2012 or earlier, or you can convert them to Web service project items. To download a tool that performs the conversion, visit the National Instruments website.
If you convert a Web service to the LabVIEW 2013 format, you can access most of the options from LabVIEW 2012 and earlier for configuring a Web service build specification by right-clicking the Web service project item in a project and selecting Properties. However, the following table describes Web service behaviors and options available in LabVIEW 2012 and earlier that are changed or removed in LabVIEW 2013.
|LabVIEW 2012 and Earlier||LabVIEW 2013|
|The term Web method VI refers to the VIs that receive HTTP requests from clients and return data to clients.||The concept of Web method VIs is renamed HTTP method VIs.|
|You can define service aliases for the Web service name, which customize the URL clients use to access the service.||Use the exact service name to access the Web service.|
|You can map multiple URLs to a Web method VI.||You can map only a single URL to an HTTP method VI. To allow multiple URLs to invoke the same VI, use it as a subVI in multiple HTTP method VIs, each of which has its own URL mapping.|
|You can specify values that override the default values of connector pane terminals of the VI.||This option is removed because you cannot map multiple URLs to an HTTP method VI. Thus you cannot create alternate URL mappings that rely on the override behavior.|
|You can mark VIs in the project as auxiliary VIs, meaning they exchange data with Web method VIs but are not exposed to clients.||The concept of auxiliary VIs is renamed startup VIs. LabVIEW considers all VIs you place under the Startup VIs project item in the project to be startup VIs.|
|You can disable "stand-alone" deployment for a Web service, which means the Web service is only deployed when the LabVIEW development system is open.||This option is removed.|
|You can set VIs to run as pre- and post-build steps that run when you build the Web service.||This feature is not available because you do not build Web services from build specifications.|