The following items are notable issues fixed between the release of LabVIEW 2020 and LabVIEW 2020 SP1, including additional patches and service packs. If you have an issue ID, you can search this list to validate that the issue has been fixed. This is not an exhaustive list of issues fixed in the current version of LabVIEW.
Bug Number |
Legacy ID |
Description |
Details |
---|---|---|---|
1249120 |
Crash if Variant to Data Processes ActiveX Data and the Output Is Not WiredWorkaround: Fixed in the LabVIEW 2019 SP1 f4 Patch. Fixed in the LabVIEW 2020 SP1 f1 Patch.
|
Reported Version: N/A Resolved Version: LabVIEW 2020 SP1 f1 Added: Oct 14, 2021 |
|
1210828 |
Crash When Using Array Size Inside For Loop That Indexes a SetWhen running a VI that iterates over a Set of Arrays with a For Loop and uses the Array Size function on an element, LabVIEW will crash. If you save the VI, then LabVIEW will crash when loading the VI. For example: Workaround: Convert the set to an array before operating on the elements. Fixed in the LabVIEW 2019 SP1 f4 Patch. Fixed in the LabVIEW 2020 SP1 f1 Patch.
|
Reported Version: LabVIEW: 2019 Resolved Version: LabVIEW 2020 SP1 f1 Added: Oct 14, 2021 |
|
1182809 |
IMAQ Create Executes More Slowly with Additional Calls in Built ApplicationsWhen the IMAQ Create function is built into a LabVIEW application, the execution time increases non-linearly each time it is called.
Workaround: Fixed in the LabVIEW 2020 SP1 f1 Patch.
|
Reported Version: Vision Development Module: 2019 SP1 Resolved Version: LabVIEW 2020 SP1 f1 Added: Oct 14, 2021 |
|
1635734 |
LabVIEW Cannot Open VI Because SubVI Cannot Load Default DataLabVIEW returns the following error when opening VIs that use some hardware-related refnums in sets or maps: "LabVIEW load error code 15: Could not load default data."
Workaround: Fixed in the LabVIEW 2020 SP1 f1 Patch.
|
Reported Version: LabVIEW: 2020 Resolved Version: LabVIEW 2020 SP1 f1 Added: Oct 14, 2021 |
|
1355893 |
LabVIEW Crashes Due to Symbol Collision with zlib::inflate in CentOS 7An application may crash due to a symbol collision in zlib::inflate when calling a LabVIEW Shared Library if the following conditions are true:
Workaround: Fixed in the LabVIEW 2020 SP1 f1 Patch.
|
Reported Version: N/A Resolved Version: LabVIEW 2020 SP1 f1 Added: Oct 14, 2021 |
|
1336659 |
LabVIEW Crashes When Generating VI Comparison ImagesTools that generate VI comparison images crash when comparing VIs with certain combinations of added/removed functions and structures.
Workaround: Fixed in the LabVIEW 2020 SP1 f1 Patch.
|
Reported Version: LabVIEW: 2020 SP1 Resolved Version: LabVIEW 2020 SP1 f1 Added: Oct 14, 2021 |
|
1232314 |
LabVIEW Crashes When Loading a VI with a Corrupted Express VI InstanceWorkaround: Fixed in the LabVIEW 2020 SP1 f1 Patch.
|
Reported Version: LabVIEW: 2020 SP1 Resolved Version: LabVIEW 2020 SP1 f1 Added: Oct 14, 2021 |
|
1414594 |
LabVIEW Crashes When Multiple Threads Add or Remove .NET Class References in ParallelWorkaround: Load .Net classes in a single thread. Fixed in the LabVIEW 2020 SP1 f1 Patch.
|
Reported Version: LabVIEW: 2020 SP1 | STS Software Bundle: 20.0 Resolved Version: LabVIEW 2020 SP1 f1 Added: Oct 14, 2021 |
|
1500946 |
LabVIEW Runtime Libraries Sometimes Missing When Running LabVIEW-Built Binary on a Linux RT SystemWhen running a
LabVIEW-built binary on a Linux RT system, LabVIEW sometimes cannot find libNILVRuntimeManager.so and liblvrtdark.so which are
present at /usr/lib/x86_x64-linux-gnu. If you have a binary built against an older LabVIEW runtime with "Allow future versions of the LabVIEW runtime to run this application" enabled, you are more likely to
run into this issue. The fix
uses ld.so.cache mechanism to search for the runtime libraries.
Users must re-build their LabVIEW built-binaries against the
LabVIEW patch. Workaround: Add a symlink for liblvrtdark.so.18.0 and libNILVRuntimeManager.so to /usr/local/lib64. Also add it to ld.so.conf. Fixed in the LabVIEW 2020 SP1 f1 Patch.
|
Reported Version: LabVIEW: 2021 Resolved Version: LabVIEW 2020 SP1 f1 Added: Oct 14, 2021 |
|
1229501 |
Memory Leak When Using "Get Next Non-Text Sibling.vi"LabVIEW leaks memory when using "Get Next Non-Text Sibling.vi" from NI_XML.lvlib.
Workaround: Fixed in the LabVIEW 2019 SP1 f4 Patch. Fixed in the LabVIEW 2020 SP1 f1 Patch.
|
Reported Version: LabVIEW: 2020 Resolved Version: LabVIEW 2020 SP1 f1 Added: Oct 14, 2021 |
|
1534200 |
Session to Refnum Sometimes Returns Non-Unique RefnumsMultiple calls to the Session to Refnum function sometimes return the same refnum rather than unique ones.
Workaround: Fixed in the LabVIEW 2020 SP1 f1 Patch.
|
Reported Version: N/A Resolved Version: LabVIEW 2020 SP1 f1 Added: Oct 14, 2021 |
|
1500249 |
Sets and Maps Incorrectly Treat Some VI References as EqualInserting a VI reference as a key into a Set or Map can incorrectly fail and return True for "key already included?" when a different reference to the same VI already exists in the set or map, even if the existing reference was obtained separately and has a different reference value or refers to a different clone instance of the VI than the reference being inserted. Workaround: Use the "Clone Name" property or another unique attribute of the VI rather than a VI reference as the key to a set or map datatype when looking up values based on VI instances. Fixed in the LabVIEW 2020 SP1 f1 Patch.
|
Reported Version: LabVIEW: 2019 Resolved Version: LabVIEW 2020 SP1 f1 Added: Oct 14, 2021 |
|
1271213 |
Slow Execution of Comparison of Variants Containing Large DataLabVIEW makes unnecessary copies of data when doing comparison operations with Variants, which can result in slower performance in LabVIEW 2017 compared to earlier versions.
Workaround: Fixed in the LabVIEW 2019 SP1 f4 Patch. Fixed in the LabVIEW 2020 SP1 f1 Patch.
|
Reported Version: N/A Resolved Version: LabVIEW 2020 SP1 f1 Added: Oct 14, 2021 |
|
1510054 |
The Equals? Function Sometimes Returns Not Equal for Identical MapsWorkaround: Flatten the maps to strings before checking for equality. Fixed in the LabVIEW 2020 SP1 f1 Patch.
|
Reported Version: LabVIEW: 2020 Resolved Version: LabVIEW 2020 SP1 f1 Added: Oct 14, 2021 |
|
1246702 |
The Equals? Function Sometimes Returns Not Equal for Identical SetsWorkaround: Flatten the sets to strings before checking for equality. Fixed in the LabVIEW 2020 SP1 f1 Patch.
|
Reported Version: LabVIEW: 2020 Resolved Version: LabVIEW 2020 SP1 f1 Added: Oct 14, 2021 |
|
1392207 |
Unload Hierarchy Operation Unloads Other VIs that Share Type DefinitionIf you unload the hierarchy of a VI while calling VIs from a TestStand Sequence, any VIs that share the same type definition will also be unloaded. Workaround: Disconnect the type definition. Fixed in the LabVIEW 2020 SP1 f1 Patch. |
Reported Version: LabVIEW: 2020 Resolved Version: LabVIEW 2020 SP1 f1 Added: Oct 14, 2021 |
|
1446694 |
Valid Refnums Sometimes Reported as InvalidA validity check of a valid refnum can sometimes incorrectly return that the refnum is invalid when refnums are being created or destroyed by another thread in parallel.
Workaround: Fixed in the LabVIEW 2020 SP1 f1 Patch.
|
Reported Version: LabVIEW: 2020 Resolved Version: LabVIEW 2020 SP1 f1 Added: Oct 14, 2021 |
|
1707381 |
Some Callers Not Updated Correctly after "Replace With" Operation on a Library in a LabVIEW ProjectIn a LabVIEW project, the right-click "Replace with" operation on a library can fail to update some VIs in the project. This issue affects VIs that reference the original library only through a dynamic dispatch call to a class method that is inherited from a parent class and not overridden by the child class wired to the call.
Workaround: Fixed in the LabVIEW 2020 SP1 f1 Patch.
|
Reported Version: LabVIEW: 2020 Resolved Version: LabVIEW: 2021 SP1 f1 Added: Nov 2, 2021 |
|
1173469 |
Converting an LLB to a directory causes Error 7 in LabVIEW 2020LabVIEW 2020 throws error 7 when converting an LLB to a dictionary. Workaround: There is currently no known workaround for this issue. |
Reported Version: LabVIEW: 2020 Resolved Version: LabVIEW 2020 SP1 Added: Dec 2, 2020 |
|
991959 |
Performance degradation in Channel Wire generation timeGenerating Channel Wires causes performance degradation in LabVIEW 2020. Workaround: There is currently no known workaround for this issue. |
Reported Version: LabVIEW: 2020 Resolved Version: LabVIEW 2020 SP1 Added: Dec 2, 2020 |
|
1013965 |
Slow application build times for some projects in LabVIEW 2020Building large projects into applications or other distributables takes longer in LabVIEW 2020 compared to LabVIEW 2019 SP1. Workaround: There is currently no known workaround for this issue. |
Reported Version: LabVIEW: 2020 Resolved Version: LabVIEW 2020 SP1 Added: Dec 2, 2020 |
|
1027690 |
Upgrading LabVIEW 2019 source to LabVIEW 2020 results in some VIs appearing brokenUpgrading source from LabVIEW 2019 to LabVIEW 2020 breaks some VIs. Workaround: Mass compiling the broken VIs or making cosmetic changes and saving can help in some cases. |
Reported Version: LabVIEW: 2020 Resolved Version: LabVIEW 2020 SP1 Added: Dec 2, 2020 |
|
1004078 |
Unnecessary Compilation Occurs when a source distribution is set to remove object codeIf the Separate compiled code from all source files option is selected when creating a source distribution, LabVIEW compiles the project before saving the source files. Workaround: There is currently no known workaround for this issue. |
Reported Version: LabVIEW: 2017 Resolved Version: LabVIEW 2020 SP1 Added: Dec 2, 2020 |
|
1000943 |
Passing 1D and 2D arrays of strings between LabVIEW and TestStand is slowPassing 1D and 2D arrays of strings between LabVIEW 2020 and TestStand using LabVIEW Run-Time Engine causes slowdowns. Workaround: There is currently no known workaround for this issue. |
Reported Version: LabVIEW: 2020 Resolved Version: LabVIEW 2020 SP1 Added: Dec 2, 2020 |
|
1059425 |
Newly created class overrides of Interface methods will sometimes not saveSometimes LabVIEW silently fails to save and erases all edits to newly created class overrides of Interface methods. Workaround: There is currently no known workaround for this issue. |
Reported Version: LabVIEW: 2020 Resolved Version: LabVIEW 2020 SP1 Added: Dec 2, 2020 |
|
1079302 |
LabVIEW crashes when encountering a broken dynamic dispatch VI called from TestStandWhen a TestStand step calls a dynamic dispatch VI, the step is configured to call the base class version of the dynamic dispatch VI. If the dynamic dispatch member VI that corresponds to the class input is broken, LabVIEW may hang and crash. Workaround: There is currently no known workaround for this issue. |
Reported Version: LabVIEW: 2019 Resolved Version: LabVIEW 2020 SP1 Added: Dec 2, 2020 |
|
1054394 |
Restarting a BeagleBone Black using System Configuration causes crashConnecting to a BeagleBone Black target using the LINX toolkit that is connected to the host via USB LAN can cause the host system to hang and crash. Workaround: There is currently no known workaround for this issue. |
Reported Version: System Configuration: 20.0 Resolved Version: LabVIEW 2020 SP1 Added: Dec 2, 2020 |
|
1126029 |
LabVIEW 2020 doesn't display UI feedback correctly on macOS 11.0 (Big Sur)LabVIEW 2020 incorrectly displays selection rectangles, marching ants selection boundaries, dragged objects, and block diagram wiring feedback when run on Big Sur. Workaround: Run the following command from Terminal: |
Reported Version: LabVIEW: 2020 Resolved Version: LabVIEW 2020 SP1 Added: Dec 2, 2020 |
|
997357 |
Slowdown in loading PPLs in LabVIEW 2020 from TestStandCalling LabVIEW 2020 built PPLs from TestStand causes slowdowns if the PPLs are loaded dynamically into memory and unloaded after the step executes. Workaround: There is currently no known workaround for this issue. |
Reported Version: LabVIEW: 2020 Resolved Version: LabVIEW 2020 SP1 Added: Dec 2, 2020 |
|
1123769 |
LabVIEW 2020 may crash on launch on macOS 11.0 Big SurLabVIEW 2020 may crash on launch on macOS 11.0 due to a graphics stack issue. Workaround: Run the following commands from Terminal: |
Reported Version: LabVIEW: 2020 Resolved Version: LabVIEW 2020 SP1 Added: Dec 2, 2020 |
|
1166235 |
Mic/camera permissions on macOS may not associate properlyA VI requiring mic or camera permissions may not be able to access these system resources or prompt the user for permission. Workaround: There is currently no known workaround for this issue. |
Reported Version: LabVIEW: 2019 | LabVIEW: 2020 Resolved Version: LabVIEW 2020 SP1 Added: Dec 2, 2020 |
Installing some patches may require certain additional steps or considerations. Please refer to the following table for more information about patches for this release.
These patches currently do not have any special instructions.