This content provides support for older products and technology, so you may notice outdated links or obsolete information about operating systems or other relevant products.
The LabVIEW 2013 SP1 f6 Patch is available for LabVIEW 2013 SP1 (32-bit and 64-bit) for Windows and the LabVIEW 2013 SP1 Run-Time Engine (32-bit and 64-bit) for Windows.
This patch fixes the issues listed in the table below. NI strongly recommends this patch for all LabVIEW 2013 SP1 installations.
Issues Fixed in LabVIEW 2013 SP1 f6
Under certain conditions, the LabVIEW Digital Waveform Graph appears blank even with valid data present.
The SMTP client could potentially not send an email or return errors when using cURL 7.34.0 or higher.
LabVIEW-built applications with a large number of UI elements may encounter a DAbort condition referencing eventq.cpp
Issues Fixed in LabVIEW 2013 SP1 f5
LabVIEW is unable to return to the calling VI when debugging a reentrant VI with the "Suspend when called" execution setting enabled.
Reentrant VIs set to "Suspend when called" do not execute when using "Step Into" button while debugging.
The method App.Get VI.Qualified Name does not return the correct qualified name for VIs in a LabVIEW source distribution when the source distribution is in a LabVIEW library.
The 64-bit TestStand Deployment Utility may fail to start or immediately crash when used with LabVIEW.
In certain cases, the Start Asynchronous Call VI paired with an Open VI Reference VI set to "Enable simultaneous calls on reentrant VIs" (0x40) and "Prepare to call and forget" (0x80) can result in a memory leak.
Issues Fixed in LabVIEW 2013 SP1 f4
Launching an executable that calls a control in a packed project library can result in an error dialog "The VI is not executable. The full development version of LabVIEW is required to fix the errors. VI has an error of type 302208."
TestStand ActiveX invoke nodes may not return the expected error 97 ("LabVIEW: A null or previously deleted refnum was passed in as an input.") when a null reference is used.
Reordering diagram objects from front/back and then creating a subVI that includes selected controls may cause LabVIEW to crash. This is due to the VI becoming corrupt from front/back reordering of diagram objects.
Calling a child class VI through Dynamic Dispatch from TestStand can initialize the child incorrectly and cause incorrect data to be passed.
Calling multiple LabVIEW built .NET assemblies from a .NET language will cause the second assembly to fail with Error 1.
Note: In order to apply the change for CAR 473514 you need to recompile affected code.
This can be accomplished by force recompiling the affected VI hierarchy: <Ctrl+Shift> + Run Button or by mass compiling.
Issues Fixed in LabVIEW 2013 SP1 f3
LabVIEW Packed Project Libraries loaded from outside a LabVIEW project can sometimes load broken.
Wiring a cluster into a Bundle node inside an In Place Element Structure sometimes causes an extra memory allocation.
Replacing controls can cause a crash if Property Nodes are not updated to accept the correct data type.
Note: The LabVIEW 2013 SP1 f3 Patch may cause an error when running certain executables built with TestStand. If you see the following error message when running your EXE, you may need to uninstall the LabVIEW 2013 SP1 Runtime Engine and then reinstall the Runtime Engine along with any dependencies: The VI is not executable. The full development version of LabVIEW is Required to fix the errors. Vi has and error of type 302208.
Issues Fixed in LabVIEW 2013 SP1 f2
Executing a TestStand sequence with LabVIEW VIs in a user interface running in LabVIEW 2013 causes delays at the beginning of execution.
LabVIEW Class VIs loaded from an unexpected path can sometimes load broken.
Calling a LabVIEW Web Service repeatedly causes a memory leak.
In LabVIEW 2013 SP1, removing a file from a class and then adding that file back to the same class can crash LabVIEW.
Error message encountered during TestStand Deployment Utility build process may show incorrect list of VIs.
Issues Fixed in LabVIEW 2013 SP1 f1
Under certain conditions, LabVIEW cannot create a functional .NET interop assembly if the assembly contains LabVIEW Class.
Cutting text from a Free Label with the Auto Tool disabled can crash LabVIEW.
Custom ActiveX Control, which returns uInt64 data in LabVIEW, results in a memory leak.
PostScript printing of graphical elements in LabVIEW does not work correctly.