NI does not actively maintain this document.
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.
This document contains the LabVIEW 2009 known issues that were discovered before and since the release of the LabVIEW 2009 Development System. Not every issue known to NI will appear on this list; it is intended to only show the severe and common issues.
The LabVIEW 2009 Platform Known Issues contains a full listing of known issues, including LabVIEW toolkits and modules.
There are two versions of the known issues list available:
Known Issues by Category
Known Issues by Date
Please refer to Developer Zone Article "LabVIEW Known Issues Categories Defined" for an explanation of the categories.
You can contact us by phone, email, or the discussion forums. Visit the NI Website to contact us. If you have feedback on this document, please contact NI on this NI Developer Zone post.
National Instruments is committed to maintaining compatibility with Microsoft Windows technology changes. However, NI has become aware of a number of issues of potential significance regarding Microsoft Windows 7. To learn how Windows 7 affects your use of NI products, visit ni.com/info and enter the Info Code windows7.
The following items are known issues in LabVIEW 2009 and 2009 SP1 sorted by Category.
| ID | Known Issue | |||||
|---|---|---|---|---|---|---|
| ActiveX and .NET | ||||||
| 187247 Return | ActiveX functions return error 1 if using a 64-bit integer LabVIEW invoke nodes can be configured to invoke functions containing 64-bit integers parameters, but when executing the invoke node it always fails with error 1. Workaround: N/A
| |||||
| 221992 Return | LabVIEW Constructor node cannot load dlls written in .net 4.0 LabVIEW supports the .NET Framework 2.0. It does not support the new features of .NET past 2.0. Many applications built with the .NET Framework 3.0 or 3.5 would still use mscorlib 2.0 which hadn't changed versions since .NET 2.0. With Visual Studio 2010 and .NET 4.0, Microsoft replaced mscorlib 2.0 with mscorlib 4.0. Because of this LabVIEW cannot load assemblies compile for the .NET Framework 4.0 Workaround: See this KnowledgeBase
| |||||
| Analysis and Math | ||||||
| 174929 Return | Repeated Loading & Unloading of the Analysis Library Generates Exception This problem has only been reproduced on Linux using the latest versions of MKL v10.x, and has been reported to Intel as 545399. Some analysis VIs in LabVIEW use Intel's Math Kernel Library (MKL) internally to compute results. Opening these VIs or using them on another VI's diagram loads the MKL library. When all references to these analysis VIs are closed, the MKL library is unloaded from memory. When working with a VI that use these analysis VIs, the following development patterns can lead to this problem: 1. Dynamically opening and closing references to the VI while no references to the analysis VIs are in memory. 2. Iteratively opening and closing the VI while no other analysis VIs are loaded in memory. 3. Using the File >> Close All operation in between editing one or more VIs that use the analysis VIs. Workaround: To avoid the exception, the MKL library must remain in memory during the entire LabVIEW session. You can achieve this in many ways: 1. Open the front panel of an analysis VI that loads MKL and keep it open until exiting LabVIEW. 2. Open a reference to an analysis function that loads MKL and close the reference before closing LabVIEW. The A x B.vi from the Mathematics >> Linear Algebra palette is an example of analysis function that serves this purpose.
| |||||
| 169840 Return | Large matrix operations that utilize the Intel MKL on Windows and Linux may crash LabVIEW When one or more matrix operations consumes most of the system resources, the Intel MKL library produces an unhandled exception that results in a LabVIEW application crashing. This Intel library is used to accelerate fundamental linear algebra operations performed under Windows and Linux operating systems. This issue has been reproduced outside the LabVIEW execution environment and a bug report has been submitted to Intel. Because the crash is tied to system resources, it can manifest itself in many ways. For example, we have reliably reproduced the problem by: 1. Decomposing a large matrix into multiple large matrices. Specific example: Computing the singular value decomposition (SVD) of a 2500-by-2500 matrix on a system with 256M RAM. 2. Simultaneously computing multiple matrix operations using relatively small matrices. Specific example: Computing 30 matrix expressions using 300 x 300 matrices on a system with 512M RAM. Workaround: If you have identified one or more matrix operations in your application that exhibit this behavior, you have multiple options to avoid crashing. 1. Serialize the matrix operations so that they are not consuming resources in parallel. 2. Replace affected matrix arithmetic functions using Basic Linear Algebra Subroutine (BLAS)functions found on the BLAS palette. 3. Structure your application so that these operations are not competing with other functions for system resources.
| |||||
| 222300 Return | Solve Linear Equations.vi executes slower on the first run The Solve Linear Equations.vi will execute slower the first time it is run. Subsequent executions will speed up dramatically. Workaround: Use a warm up iteration
| |||||
| 190852 Return | ActiveX container modifies the floating point control register Using ActiveX controls with LabVIEW 8.6.x may cause incorrect floating point results with certain math VI's. LabVIEW 2009 and the LabVIEW 2009 Run-Time engine install a shared component (nicont.dll) that can cause unexpected results with specific configurations. Workaround: Install the LabVIEW 2010 (or later) Run-Time engine. Any later version of LabVIEW or the LabVIEW Run-Time engine will upgrade the nicont.dll to a fixed version.
| |||||
| Building and Distributing LabVIEW Applications | ||||||
| 53817 4I6CKJ00 Return | Adding password protected VI to a library while building an application causes a password dialog to appear When building an application with "Add files to new project library" selected on the Destinations page, if the application includes any password protected vi.lib subVIs you will be prompted to enter these passwords. Workaround: You can cancel the prompt for the password, which may produce a Load Warning dialog. You can also cancel the Load Warning dialog and the operation will complete.
| |||||
| 51179 47B12U5U Return | Error 6 occurred at Create Folder in Create Directory Recursive.vi when building an application (EXE), shared library (DLL), source distribution or web service When building a Build Specification, the build process fails with Error 6 at Create Folder in Create Directory Recursive.vi. This usually happens if the path one of the files generated by the build (temporarily during the build process or as part of the output) is too long. The operating system requires paths for files to be less than 255 characters. Workaround: 1. Use a shorter path for your build destination (i.e. c:\build\) and if necessary copy the output to the final location you need. 2. A. For application (EXE) and shared library (DLL) build specifications, place a checkmark in the Use LabVIEW 8.x file layout checkbox on the Advanced page of the Properties dialog box. 2. B. For source distribution or web service build specifications, uncheck the Preserve disk hierarchy checkbox on the problem Destination on the Destinations page of the Properties dialog box.
| |||||
| 136989 Return | Executable can't find some VIs due to the General Error Handler On upgrading to LabVIEW 8.6, some executables do not run because they are missing VIs. These VIs include vi.lib\Utility\error.llb\Not Found Dialog.vi vi.lib\Utility\miscctls.llb\LVBoundsTypeDef.ctl vi.lib\picture\picture.llb\Get Text Rect.vi vi.lib\event_ctls.llb\eventvkey.ctl The missing VIs can be traced to the General Error Handler. Workaround: Perform a Force Compile (CTRL + Shift + Run Button) on the Top Level VI to recompile the entire hierarchy. If you still experience the problem, open the VIs which call the missing subVIs (e.g. General error Handler CORE.vi) and force compile those VIs. Check the following KnowledgeBase for more information about force compile.
| |||||
| 166337 Return | LabVIEW Interop Utility: Comma in control or indicator caption results in invalid member name The members of Type Definition/Cluster classes are derived from the captions of user's controls and indicators within those clusters. If these controls or indicators have an invalid name (for instance, contain a comma) they will build into a member that cannot be accessed from Visual Studio. Workaround: Ensure that none of your exported controls indicators, clusters, or members of clusters of any exported VI have any invalid characters (non-alphanumeric characters) prior to building an Interop Assembly.
| |||||
| 198987 Return | Invalid names are allowed for .NET assembly exported VI prototype names Workaround: Avoid using Invalid names in your assembly
| |||||
| 202662 Return | About dialog box VI must reside in the same folder as your top level VI The about.vi that is included in applications to overwrite the default LabVIEW dialog box will not be displayed unless it is in the same folder on disk as the top level VI. Workaround: 1. Place about.vi in the same folder as the top level VI. 2. Use the 8.x file layout in the build.
| |||||
| 200362 Return | .NET Interop Assembly can load the 64-bit version of the LabVIEW runtime engine If a 64-bit system has both the 32-bit and 64-bit LabVIEW runtime engine installed a .NET Exception can occur when trying to load a 32-bit LabVIEW built .NET Assembly. A possible error message is Invalid LV Client Workaround: Uninstall the 64-bit runtime if possible. If this is a development machine this would require removing the 64-bit development environment.
| |||||
| 208364 Return | LabVIEW built installers created on a 32-bit machine will not install most drivers when run on a 64-bit machine If you build an installer using LabVIEW on a 32-bit machine that contains National Instruments drivers, the corresponding drivers will not be installed if the installer is run on a 64-bit machine. Drivers such as NI-DAQ, NI-Sync etc. are affected by this issue. Installation on 32-bit machines are not affected by this bug. Workaround: On the deployment 64-bit machine, download and install the missing drivers from the ni.com Drivers and Updates page.
| |||||
| 220935 Return | PFX Certificates will work only if it's installed in the Personal Store PFX certificates will work only if it's installed in the Personal Store. Installing the digital certificate in the Root Store, or any of the intermediate Certificate Authorities will result in it not showing up in the LabVIEW Application Builder.
| |||||
| 201140 Return | Extracting or Unzipping LabVIEW built applications using Winrar or Winzip LabVIEW 2009 executables can be unzipped. The VI can be accessed but in most cases the front panels and block diagrams have been removed. Workaround: a) Remove Front Panels and Block Diagrams when building an exe. b) Password Protect VIs when distributing code. c) Default the front panel items of the main functional subVI transparent. Use the security VI to de-activate transparency using VI server d) Embed the password VIs within the main functional subVI e) Call VIs dynamically rather than dropping subVIs to the block diagram
| |||||
| 205665 Return | LLB distribution disappears from installer when Properties Window is closed An LLB source distribution that is included as a source file in an installer disappears when the build spec properties window is closed. Workaround: Add the llb to the project (or new project to avoid conflicts) and then include it as part of the installer.
| |||||
| 220887 Return | Calling LabVIEW 2009 built DLLs in previous versions of LabVIEW can cause a crash Workaround: N/A
| |||||
| 223244 Return | "File is not a resource file." popup on a built app If the startup VI of a built app does not have the ".vi" extension, this error might occur in the built application. Workaround: Change the startup VI to have a ".vi" extension.
| |||||
| 198955 Return | Default Parameters cannot be deleted from .NET assembly parameter list The .NET interop assembly utility's Define VI Prototype Dialog Box states that 'return value' is the only parameter that cannot be deleted, but any value connected to the connector pane is included by default, and none of these can be deleted. The X (delete) button is disabled. Workaround: None - building a wrapper around the built DLL to only expose the parameters desired, or not allowing the parameter to be default (disconnect from connector pane)
| |||||
| 199730 Return | LabVIEW RTE crashes when multiple calls to LabVIEW built assembly are made Multiple calls in one process to methods in LabVIEW built .NET assembly causes Fatal Internal Error: MemeoryManager.cpp line 547. Specific calls to methods within LabVIEW-built .NET assemblies work correctly the first time within a process (eg. running Visual Studio application, or TestStand execution). In that same process, if the same calls are made again, the LabVIEW runtime engine crashes Workaround: N/A
| |||||
| 201841 Return | Adding multiple source files as exported VIs at a time corrupts parameter lists in .NET Interop builder In the source files tab of the .NET Interop Assembly Build spec properties dialog, if multiple project files are added at once to the exported VIs list, it corrupts the parameter list for each entry if the define prototype dialog has not been opened for that entry. This is seen once the assembly is built, as the expected parameters and return type do not match the actual. The parameters are reversed, and one of the parameters is placed as the return value (VOID is the default). Workaround: Add files one at a time, or, after multiple have been added, look at their prototypes (double click on exported VI entry in list, or click define prototype...) and then click ok, so they are saved correctly.
| |||||
| 164604 Return | Calling LabVIEW built .NET Interop Assembly from same version of LabVIEW causes a hang If you build a .NET Interop Assembly and try to call it in the same version of LabVIEW, it will hang at the constructor node Workaround: Create the .NET Interop Assembly in a different version of LabVIEW.
| |||||
| 173991 Return | Web service fails to deploy if VI terminals contain special characters If terminals on a web service VI contain special characters such as [ or ], the web service will appear to deploy successfully, but it will not be possible to connect to the web service. Workaround: Do not use special characters in VI terminals for web services
| |||||
| 227609 Return | Statically linking a LabVIEW built DLL in a C++ project results in error 998 if the DLL is not added to the Delay Loaded DLLs list For more information see this KnowledgeBase Workaround: Go to the Project Property Pages, Configuration Properties»Linker»Input and add the name of your DLL to the Delay Loaded DLLs list.
| |||||
| 235764 Return | On a Mac, LabVIEW 2009 built shared libraries (.frameworks) fail to load when called from another program You can successfully build a shared library (.framework) in LabVIEW 2009 for Mac. However, the built library fails to load if it's called from a different version of LabVIEW or any other program (example: a C++ built exe). The library only works if it's called from LabVIEW 2009 itself. Workaround: N/A
| |||||
| 192280 Return | Open UFF58 VI will cause a hang if built into an application If you use the UFF58 functions and build them into an application the called DLL does not get pulled into the application. Workaround: Create an always included VI that specifically uses the UFF58 dll in a Call Library Function Node. This will cause application builder to pull in the dll.
| |||||
| 242600 Return | A search dialog can appear when building a source distribution where the main destination is a library Building a source distribution with the following options set will display a dialog searching for unused VIs in libraries in the original project: - Remove unused library members - Main destination is a library Workaround: N/A
| |||||
| 202900 Return | LabVIEW Built Applications Display Chinese Characters Occasionally after running an NI installer that updates a LabVIEW Run-time Engine, LabVIEW built applications will display Chinese characters. This includes Distributed System Manager, VeriStand and user built applications. The problem is that a resource file that is used for translation is not installed correctly. If you are on a deployment system and you haven't installed the Run-Time Engine Non-English Support you could receive "No Supported Languages Installed" when running the application. Workaround: Go to \Shared\LabVIEW Run-Time\2010\English. There should be a temporary file there named something like "TBMAE0D.tmp". Rename this file to lvapp.rsc. If there isn't this file you can copy it from another installation. This error can occur if you don't reboot your machine after installation.
| |||||
| 255617 Return | Error 1502 can occur if dependencies are placed in non executing case structures In previous versions of LabVIEW you could place VIs in a case structure with a constant wired the the case selector. This would load the VIs at runtime. If you have this pattern and attempt to build an executable you could receive error 1502 Workaround: Don't use unreachable code
| |||||
| 308464 Return | LabVIEW cannot build some large applications because it fills the image table. LabVIEW cannot build some large applications. If you try to build a large application it will fail. An internal warning is thrown during the build stating that the image table has been filled. Workaround: This issue has been fixed in the LabVIEW 2011 f2 Patch.
| |||||
| 187412 Return | Custom RTM will incorrectly link to the source location when built into an executable If you have a customer Run-Time Menu you can include it in an executable. When we build the executable we incorrectly link to the original location of the RTM file instead of the one being brought into the build. Workaround: Save the original RTM files in a location that you can distribute. For example if you save them in the "Data" directory that is next to where the executable will be saved this will work and create a package that isn't terrible to distribute.
| |||||
| Controls and Indicators | ||||||
| 219819 Return | Center justified tables display improperly when overlapping with the front panel origin When you add a table control to the front panel so that it overlaps with the vertical origin of the front panel, LabVIEW displays center justified columns off center when you type text. The cells appear to float or move horizontally until aligned with the vertical origin. Formerly tracked as 50061 and 42NAR8SA Workaround: Move the table away from the front panel's vertical origin.
| |||||
| 51311 477DKPBQ Return | LabVIEW does not maintain child-only item setting when dragging an item within a tree If you have a tree item with the child-only setting, and then drag it within the tree, LabVIEW loses the child-only setting. Workaround: Use tree events to (1) get the child-only flag setting when the user begins a drag, and (2) reset the child-only flag after completing a drop.
| |||||
| 52297 4AIFC0R0 Return | Internal error related to locked tab control at fpsane.cpp line 369 and line 367. If you lock a tab control that is already locked using Group»Lock, you might see two internal errors and LabVIEW may crash. Workaround: Do not lock a control that is already locked. After the fact: copy the Tab Control from the block diagram into a new VI. It will show up unlocked in the new VI.
| |||||
| 91672 477M7K00 Return | Large amounts of data in combo box can appear to hang LabVIEW. If you place a large amount of data in a combo box, on the order of megabytes, LabVIEW appears to hang by taking a long time to calculate wrapping. Workaround: N/A
| |||||
| 41148 4D1JQKJ7 Return | Unable to change the Display Format for Y-axis in a dynamic data type Waveform Chart/Graph The display format for the y-axis cannot be changed in a waveform chart/graph if it is configured to receive the dynamic datatype (i.e. it will be blue on the block diagram). Workaround: Configure the y-axis formatting when the graph is not in dynamic datatype mode by deleting any dynamic data wires and rewiring with a waveform. Then you can rewire with the dynamic data.
| |||||
| 37476 44H8J3ZP Return | Digital Display Legend Doesn't Adjust for Number of Plots in Executable In the LV Development environment, when the number of plots are changed dynamically, the Digital Display for each plot is dynamically added or removed from the legend. However, when run in an executable, the plot glyph is updated correctly, but the digital displays is not added or removed when the number of plots is changed dynamically.
| |||||
| 43109 4FRF0826 Return | Cannot customize plot legend with background image in LabVIEW You cannot configure a plot legend with a custom background image in LabVIEW. Workaround: Make the color of the plot legend transparent, and place the image behind it. This only works if your plot legend remains a fixed size in a fixed location.
| |||||
| 45133 4I0976O4 Return | The coercion of an enum through its digital display behaves differently in the development environment than in a LabVIEW executable. The coercion of an enum through its digital display behaves differently in the development environment than in a LabVIEW executable. Neither produce an out of range value, but one coerces to the last entry in the enum, the other leaves the enum unchanged. Workaround: Use an event structure to capture value change filter events and restore the enum to the value you choose. You can also disable the digital display for the enum.
| |||||
| 100580 Return | Dropping control references may cause Data Change event for XControl Dropping a control/indicator reference onto a VI that is hosting an XControl, whose data type is an array, will cause a Data Change event to be handled by the facade VI of the XControl. Workaround: N/A
| |||||
| 118949 Return | Tab control local variables generate value change events when you use a multi-column ListBox A value change event is generated when a Tab Control local variable's value is changed in an Event Structure that was triggered by a double-click/ value Change on a multi-column ListBox. Workaround: Use Value Property Node for the Tab Control instead of Local Variable to change the Tabs.
| |||||
| 45360 4I0EE2BQ Return | Localization Codes do not Function for Timestamp Controls According to the help, localization codes are available for format strings. They allow to specify the decimal separator and override the system decimal separator. However, this doesn't work for the Timestamp "advanced format" option. Workaround: If you would like to discuss this issue and possible workarounds, please visit the NI Discussion Forums
| |||||
| 164268 Return | Tab control incorrectly displays ComponentWorks 3D Graph when other tabs are selected "Page Labels Display" Tab Controls display remnants of ComponentWorks 3D graph when toggling through the pages using Page Labels Display. The issue does not occur when manually clicking on the Page names, or when changing the value of the tab with the tab's terminal, a local variable, or a Value property node. Workaround: Change the value of the tab directly on the terminal, with a local variable, or a Value property node.
| |||||
| 167056 Return | Wiring cluster of fixed point values to waveform chart causes a broken arrow Workaround: Change the representation of the number wired into the cluster to something like I64, then back to FXP
| |||||
| 174973 Return | Event mouse down for Tree Control Scrollbar returns coordinates for the root item The coordinates produced by a mouse down event on the scrollbar of a tree control are translated to the first item in the tree control. Workaround: Use the inBound property to filter these problems out
| |||||
| 121459 Return | 3D Picture controls render non-default font incorrectly in executables
| |||||
| 200308 Return | Charts display gaps in waveform data that has a very small dt When data is graphed at high sample rates and the data is added to a chart, LabVIEW incorrectly draws gaps in the chart. These gaps are not present in the data, there is nothing odd with the t0 or dt components of the waveform, and the gaps do not show when the data is returned as an array of DBL values. Workaround: Acquire the data as an array of DBL and timestamp the data manually. Not at all clean.
| |||||
| 208088 Return | Updating the Labels of a Cluster Written to a Chart Does Not Update the Cluster Used for Chart History Changing the Label of elements in a cluster written to the Waveform Chart does not update the label of the cluster when read from the Waveform Chart Data History Property. Workaround: Temporarily wire up a completely different data type to the Waveform chart indicator and then rewire the original cluster. The changes will now propagate to the Chart History.
| |||||
| 176286 Return | Programmatically changing FP.PanelBounds causes part of FP to go Blank Temporarily.
| |||||
| 185890 Return | Text on a VI can be mutated to appear as unicode After building a project into an executable, various text for controls and indicators changes languages. It appears that the text was interpreted as unicode. We have not been able to reproduce this in house to find a definite cause. Because of this we will leave this CAR open even though we have created code to recover from the corruption if it happens. Previously tracked as CAR 179683 Workaround: Upgrade the VI to LabVIEW 2011. In 2011 we put in code to only view text on VIs as unicode if the UseUnicode=True is in the LabVIEW .ini file. Previously this would only switch on the ability to change something to unicode. When the VI is upgraded to 2011 it should be saved and then saved for previous to return it to the original version.
| |||||
| 176848 Return | Picture Control Stops Updating After Setting Properties to Default. Once the picture control's values have reinitialized to default by selecting Data Operations»Reinitialize to Default or programmatically using the method Reinitialize to Default, the mouse position property node stops updating. Workaround: Replace the picture control with a new one from the palette.
| |||||
| 236377 Return | Droping XControl from public library breaks XControl When adding an X control from a public library into the controls palette, it become broken when dropped down to the front panel from the controls palette. Workaround: Include a merge VI in the functions palette
| |||||
| 248914 Return | Changing the order of controls or deleting controls in a type def cluster can change references When you create a reference for a control in a type defined cluster LabVIEW uses the cluster order to determine what control the reference is referring to. Say you have a type defined cluster with elements A, B, C and D with cluster order 1,2,3 and 4 respectively. On the block diagram of a VI you have control references to each of the controls. If you open the type def and delete control C the block diagram of the VI will only contain 3 references. Moreover, the reference that used to be for control C will now reference control D. This is because the control is based on cluster order Workaround: N/A
| |||||
| 250588 Return | Warning Generated in a Method or Property of an XControl Appears as an Error in the Top Level VI If you create a method or a property in an Xcontrol in which you have implemented code to generate a warning it is transformed into an error in the calling VI. Workaround: In the VI look for specific error and transform back to a warning
| |||||
| DataSocket | ||||||
| 46630 2VO0SF00 Return | DataSocket/OPC Leaks Memory when repeatedly using ActiveX VIs to perform open-write-close If you call the DataSocket Open, DataSocket Write, and DataSocket Close functions in succession repeatedly, LabVIEW leaks memory. Workaround: To correct this problem, call the DataSocket Open function once, use the DataSocket Write function to write multiple times, and then use the DataSocket Close function.
| |||||
| 206944 Return | Version in DataSocket Server About Box is incorrect The About Box of the Datsocket Server always displays version 4.5, regardless of the installed Datasocket Version (4.5/4.6/4.7). Workaround: N/A
| |||||
| 217733 Return | Datasocket Performance Slowdown from LabVIEW 8.6.1 to LabVIEW 2009 Workaround: Use Shared Variable API
| |||||
| External Code | ||||||
| 195026 Return | Out of Memory error from Call Library Function Node This error can occur if all of these 3 factors are present. 1) You specify a minimum size to a CLFN input X in terms of another input Y (i.e., not a constant like '4'). 2) The input Y is not a 32-bit parameter (e.g. a U16) 3) Something non-zero occupies the memory directly adjacent to Y, such that when the CLFN interprets the value as a 32-bit value, the resulting value is too large to be allocated. Workaround: Remove one of the three listed conditions
| |||||
| 186228 Return | Call Library Function Node cannot distinguish between case sensitive functions If you have a dll with two functions with the same name but different case, you can only select the first function Workaround: Use Import»Shared Library function
| |||||
| ID | Known Issue | |||||
|---|---|---|---|---|---|---|
| 284901 Return | Call Library Function Node cannot distinguish between case sensitive functions If you have a dll with two functions with the same name but different case, you can only select the first function Workaround: Use Import»Shared Library function
| |||||
| 207352 Return | Moving a .NET Assembly while LabVIEW is open will cause an error the next time it is called from LabVIEW. Changing the location of a .NET DLL causes the following error to occur when calling the DLL with a .NET constructor node: Error 3 occurred at Constructor Node in [VI name] Possible reason(s): LabVIEW: Internal error. Wrong memory zone accessed. Workaround: Close LabVIEW and then move the assembly. You will have to relocate it when opening LabVIEW. Note: It is always recommended to use a project when using .NET code in LabVIEW. You should only have the relocated the assembly in the project.
| |||||
| 153731 Return | Unhandled Exepction can occur if absolute path for system DLL used in CLFN If you use a specific path to a system DLL (C:\windows\system\user32.dll) and build your VI into an application it will create a copy of the DLL inside the application. This can cause an unhandled exception when running Workaround: LabVIEW searches in the system directory when looking for DLLs. If you are using a system DLL simply put the name in the in DLL Path box in the CLFN properties. In the example above you would simply put "user32.dll"
| |||||
| File I/O | ||||||
| 42700 4F869DST Return | Zip build provider and Zip VIs do not support multi-byte character encodings. The Zip build provider and the underlying Zip API provided in the File I/O palette do not support paths with multibyte character encodings. Some upper or lower bytes of multi-byte characters decode into disallowed ASCII characters when not configured correctly. Previously tracked as 47436 or 3IKBUP99 Workaround: N/A
| |||||
| 47819 3N68LE00 Return | 2GB file size limit of datalog files The maximum size of datalog files is 2 GB. Workaround: N/A
| |||||
| 168144 Return | Scan From File aborts the calling VI if it is pointed to a non-existing file The Scan From File VI throws an error dialog and aborts the VI if it's given a non-existing file instead of returning an error in its output and giving the option to continue. Even if wire error dialog the whole VI still aborts. Workaround: Check for the file existence before calling this VI.
| |||||
| 285210 Return | Read from Measurement File Express VI can read incorrect data If you use a Write to Measurement File Express VI to write an LVM file, the data can be misinterpreted from the Read from Measurement File Express VI if the LVM file has headers. The file is correctly written; however, it is just read incorrectly. Workaround: Don't write headers in the LVM file
| |||||
| 276334 Return | On VxWorks targets, the TDMS Defragment VI shows Error 6 and deletes the file it is operating on in the U:\ drive TDMS Defragment VI shows Error 6 and deletes the file it is operating on when told to operate on a TDMS file that is located on the U:\ drive of a VxWorks Real-Time target. (U:\ drive is a USB drive) Workaround: Use the TDMS Defragment VI on a TDMS file that is located on the C:\ drive. Then move the defragmented file to the U:\ drive. OR A copy of the degramented TDMS file from the U:\ drive can be found in the temp directory (for cRIO it's c:\temp). Note: The temp file gets overwritten every time the TDMS Deframent VI is used, so only the latest file is available in the temp folder
| |||||
| 112702 Return | Cannot read file that shows up as zero bytes. Linux, Unix and Macs can have files that show up on disk as zero bytes but actually have data that can be read. If you use a Read Binary File primitive on these files you will return an empty string. Workaround: Read a large number of bytes and handle the end of file error that you will receive.
| |||||
| Functions, VIs, and Express VIs | ||||||
| 37575 3PD8N0M8 Return | LabVIEW uses large amounts of memory when reading an entire wave file at once The Sound File Read VI uses large amounts of memory to read an entire .wav file. Workaround: Read the data from the .wav file in sections rather than in one large file.
| |||||
| 39161 401FEQTL Return | The device ID input of the Play Sound File VI does not work on Windows On Windows, LabVIEW ignores the device ID input of the Play Sound File VI. This VI plays sound only on the default sound card. Workaround: Use the Sound Output Configure VI and the Sound Output Write VI with the Sound File Open VI and the Sound File Read VI or the Sound File Simple Read VI. Refer to the Sound File to Sound Output example VI for an example of this workaround.
| |||||
| 39604 49UBP4LE Return | Write to Clipboard Method takes minutes and a lot of CPU If you try to copy a large amount of data from LabVIEW to the clipboard, LabVIEW slows significantly and might become unresponsive. This was previously tracked as CAR 90497 and 3YJ87JCM Workaround: N/A
| |||||
| 41530 4DJFJM00 Return | Advanced Storage VIs Do Not Work in a LabVIEW Development System with a Different Language If you move the Advanced Storage VIs to a LabVIEW development system with a different language, the VIs do not work because the object types and property names do not match the names in other languages. Workaround: To correct this problem, use the internal, language-independent object types and property names.
| |||||
| 47891 3NRGJTI7 Return | Sound Output Set Volume VI doesn't set the volume on a per-channel basis The Array instance of the Sound Output Set Volume VI does not use the volume input to set the volume on a per-channel basis. Instead, this VI uses the first element of the volume input as the sound level for all channels. Workaround: N/A
| |||||
| 48016 3P7CBB4Q Return | Unsigned int32 loses value in formula node when you write to the most significant bit If you wire a hex value greater than x7FFFFFFF as an unsigned, 32-bit integer to a Formula Node, LabVIEW coerces the value to 0. If you use a negative number for U32 input/output variable, LabVIEW will coerce the value to 0. Workaround: 1. Use the Mathscript node or LabVIEW code for the operation that involves an unsigned, 32-bit integer. 2. Use signed 32-bit integers instead of unsigned 32-bit integers in the formula node.
| |||||
| 50420 44CG88SN Return | Update the Pulse Transition Measurement Express VI The terminology and measurement definitions for the Transition Measurements VI comply with IEEE Standard 181-2003, IEEE Standard on Transitions, Pulses, and Related Waveforms. However, the Timing and Transition Measurements Express VI does not comply with this IEEE Standard. Workaround: The Slew rate refers to the transition slope. The Preshoot refers to the pre-transition undershoot (rising pulse) or the pre-transition overshoot (falling pulse). The Overshoot refers to the post-transition undershoot (rising pulse) or the post-transition overshoot (falling pulse).
| |||||
| 45802 4IDA53I0 Return | Using VI Server Get/Set [Variant] Control Values on Clusters with Fixed Size Arrays creates error 2 The VI Server get/set [variant] control values if used on a cluster with fixed sze arays, results in an error. This is expected as LabVIEW core does not support fixed size arrays. Fixed size arrays are meant to be used only with LabVIEW FPGA. Workaround: Pull the array outside the cluster for running on the development computer.
| |||||
| 118106 Return | Variant To Flattened String and Flattened String To Variant Do Not Support Fixed Point Data Type The Fixed Point data type is not supported by the Variant To Flattened String and Flattened String to Variant functions. You may see a crash when trying to unflatten this datatype in conjunction with an empty fixed point array. Workaround: Either use a supported datatype or do not use the Variant.
| |||||
| 120686 Return | Write to LabVIEW Measurement Files (LVM) using Express VIs takes up a lot of memory The "Write to Measurement File" Express VI consumes a large amount of memory when writing to a Text File (LVM). However, the memory usage is smaller when the same Express VI is used to write a TDM/TDMS File Workaround: Use general LabVIEW VIs (and not Express VIs) to perform an LVM write for large amounts of data. The other option would be to write in smaller chunks.
| |||||
| 122057 Return | Joining Numbers of Different Widths Produce Unexpected Values The Join Number VI produces different results when the inputs are of different widths/sizes. Workaround: Explicitly cast to same size before joining.
| |||||
| 155226 Return | LVM files saved by LabVIEW 8.6 cannot be read by SignalExpress 3.0 The LVM file format in LabVIEW 8.6 was changed to support localization of the decimal separator. This caused a version change to the file format. SignalExpress correctly determines that it cannot read the file, but returns an incorrect error. It should be a version error, not a file type error. Workaround: Open the file in a text editor. If the decimal separator is set to period, change the read and write versions to 1 and it will work. If the decimal separator is set to comma, replace all the commas with periods, replace the decimal separator field itself with a period, and change both versions to 1. SignalExpress will now read the file.
| |||||
| 152918 Return | Highlight execution for a Parallel For loop does not take place for first execution A parallel for loop when executed for the first time does not follow highlight execution outside the loop. Workaround: N/A
| |||||
| 156518 Return | Sensor Mapping Express VI cannot use model files that are saved in the binary format Workaround: See KB 4VQ9DURQ: Sensor Mapping Express VI does not specify that binary model files are not accepted for more details
| |||||
| 124783 Return | Sound Input Read VI does not return samples requested If the user inputs a value of "number of samples/ch" into the Sound Input Read VI and the waveform that this returned is only 75% of the samples. Workaround: N/A
| |||||
| 162800 Return | "Wait on Notification from Multiple" returns inconsistent results when multiple refnums refer to same named notifier When using the "Wait On Multiple Notifications" primitive, problems have been observed if two refnums in the input array refer to the same named notifier. These problems apply if the exact same refnum is included multiple times or if different refnums to the same notifier are included. If the Wait node executes and there is already a notification available then the output refnum array will include every refnum that refers to the underlying notifier (including multiple copies of the same refnum) and there will be N copies of the notification in the output notification array, one for each output refnum. If the Wait node does have to go to sleep, when Send Notification executes, the Wait will wake up but will return an array containing only a single refnum and one copy of the notification. Workaround: You can use Notifier Status function on each of the refnums passed as input to the Wait function in order to get the names of all those notifiers. When the Wait function returns its results, use the Notifier Status function to get the name of the returned notifier, then search the original list for all refnums that have the same name as the one returned. This allows you to identify the original refnums that should have been returned.
| |||||
| 177748 Return | MATLAB® Script Node does not allow Parallel Execution Workaround: Call the MATLAB Script Node dynamically using the Call by Reference node to enable parallelism.
| |||||
| 158446 Return | When comparing a sub array created through the Array Subset Function with an identical Array the result is false. Workaround: 1. Place after the "Array Subset" function a "Reshape Array" function. 2. Replace the "Array Subset" function through "Delete from Array" function 3. Turn off auto-preallocate arrays and strings.
| |||||
| 176856 Return | VI Snippet of a VI with Dynamic inputs results in a LabVIEW crash Previously tracked as CAR 182023 Workaround: N/A
| |||||
| 205735 Return | Set Permissions does not work the same in LabVIEW 2009 Workaround: Don't wire anything into owner
| |||||
| 200535 Return | T Test.vi Outputs are switched - T Value & Sample T Value Workaround: Switch the values in the cluster.
| |||||
| 204307 Return | Open App Ref in reentrant VI crashes Labview If you open an application reference to two separate instances of LabVIEW and try to run the same reentrant VI in each of them then LabVIEW will crash. Workaround: If you take up some time in between opening the application references, the problem seems to go away. Also you could just reuse the same application reference.
| |||||
| 231877 Return | Polymorphic VIs with "Adapt to Type" set can choose wrong instance VI With a polymorphic VI with instance VIs that take a floating point type and an integer type, the "Adapt to Type" mechanism may incorrectly choose the integer type instance VI when a floating point type with more precision is wired in. For example, if a polymorphic VI has one instance VI that takes an I32 and one that takes a Single Precision floating-point number, when wiring in a Double Precision floating-point number the polymorphic VI will choose the I32 version. Workaround: Coerce the input data type to correspond to the desired instance VI.
| |||||
| 227030 Return | Wait on Notification from Multiple function has unexpected behavior when ignoring previous input. Workaround: See KB
| |||||
| 196607 Return | DTbl Replace Subset VI behavior change between LabVIEW 8.6.1 and 2009 The start input indexes from the replacement data instead of the existing data Workaround: Set the index of data to replace from 0
| |||||
| 196742 Return | Load STL Geometry VI cannot load binary STL files Workaround: Use a different type of STL file.
| |||||
| 226840 Return | Formula VI does not execute pow(x,y) function Workaround: Use the formula node to use the pow(x,y) function. If you need to change this programmatically, use the Power of X function in G code.
| |||||
| 322914 Return | Formula VI does not execute pow(x,y) function Workaround: Use the formula node to use the pow(x,y) function. If you need to change this programmatically, use the Power of X function in G code.
| |||||
| 248421 Return | Bitshift does not work correctly in Expression Nodes and Formula Nodse with a data type smaller than I32 Workaround: N/A
| |||||
| 192804 Return | Error 91 occurred at the Variant To Data node Variant To Data sometimes throws an error 91 when running in a built executable in LV 2009 "Error 91 occurred at ... Possible reason(s): LabVIEW: The data type of the variant is not compatible with the data type wired to the type input." Workaround: 1) Update the variant type by generating a new one. (In an empty VI wire the typedef into the "data to variant" prim and run the VI. Then create a constant from the indicator and use this constant as the new type for the variant.) OR 2) Use a Flatten Variant to String and then an Unflatten from String (not the variant version). If you wire in the control you're trying to extract from the variant, it will work like a charm.
| |||||
| 289842 Return | Get Variant Attribute VI returns wrong value if attribute not found The default value that's returned by the Get Variant Attribute VI is not blank when nothing is wired to the default value terminal. The Get Variant Attribute instead seems to return the last/previous value it returned as the default value. Workaround: Use the Found? output and logic to return a blank variant if neccesary
| |||||
| 207144 Return | Erroneous "VI need more memory to compile" message when using a parallel FOR loop If you connect a wire to a parallel FOR loop via a tunnel and don't use the tunnel output, you could receive a "VI needs more memory to compile" message. Workaround: Use a sequence structure around the FOR loops and connect the wire to the sequence structure.
| |||||
| Installation and Activation | ||||||
| 166253 Return | LabVIEW.app does not show up after LabVIEW 2009 Installation Workaround: This is only an issue for customers who installed the LabVIEW 2009 Beta for Mac. Delete /Library/Receipts/LabVIEW*9.0.pkg before running the LabVIEW 2009 installer for Mac OS.
| |||||
| LabVIEW Environment | ||||||
| 47212 3EIB4MS5 Return | No prompt to add a comment in the revision history on close If you select the Prompt for a comment when the VI is closed option on the Revision History Properties page, LabVIEW does not prompt you to add a comment to the History window when you close the VI. Workaround: Select the Prompt for a comment when the VI is saved option on the Revision History Properties page
| |||||
| 47791 3MRDJ300 Return | Subpalettes need to be context aware, i.e., need to show/hide when owning library is locked/unlocked LabVIEW does not correctly hide subpalette menus that belong to locked project libraries. Workaround: N/A
| |||||
| 52615 4BMANBJ1 Return | Multi-frame structures do not switch frames on undo If you place a multi-frame structure (Event Structure, Case Structure, etc) on the block diagram, edit a frame in the structure, switch to a different structure and then press ctrl-z to undo the edit, LabVIEW does not switch to the frame that contains the change that you are undoing. Workaround: N/A
| |||||
| 36543 4039KEG8 Return | Edit-time crashes when many modules, drivers, and toolkits are installed Edit-time crashes during various operations (right-click menu selection, VI save, moving a VI from one block diagram to another, building an application [executable], shared library, or source distribution, etc.) can result from LabVIEW's image table overflowing from large amounts of palette icons being loaded in memory due to many installed modules, drivers, and toolkits. In this scenario, may receive LabVIEW error log files reporting "You filled the image table" in image.cpp. Workaround: In Tools->Options->Controls/Functions Palettes, change the Palette Loading from "Load palettes in background" (default behavior) to "Load palettes when needed" and restart LabVIEW. This workaround does not work if you: 1. Perform a palette search. 2. Click "place me on diagram/front panel" from the LabVIEW Help.
| |||||
| 105509 Return | The "do not save automatic changes" setting does not affect libraries The "do not save automatic changes" options setting does not affect any type of library, including classes. Workaround: N/A
| |||||
| 117209 Return | Bundle by Name does not break VI when fields from the input cluster's typedef are deleted Workaround: Change the data type (numeric to string, string to numeric) of the cluster element to be deleted to force breakage at all references to that member. Repair the broken VIs and then remove the cluster element. Or you can delete the cluster element, save (keeping the control open), then mass compile.
| |||||
| 42728 4FEAMCDP Return | Disabling or enabling breakpoints on a single reentrant clone VI is impossible When setting or clearing a breakpoint on a diagram, it is possible to set and clear the breakpoints on an individual reentrant clone without changing the breakpoints on all the other clones of the same VI. However, when you try to disable or enable the breakpoint (a new feature in LabVIEW 8.6), the breakpoint is enabled or disabled on all clones and the original VI. Workaround: N/A
| |||||
| 43671 4GID11F2 Return | Opening VI Properties Window takes a long time When I try to open the VI properites window of a VI it takes a very long time to open. This can occur when you are using a network shared printer (as printer default), and that printer is offline. Workaround: Set default printer to "Microsoft Office Document Image Writer" for example.
| |||||
| 141789 Return | Nodes not updated when moved in VI Hierarchy When a node is moved in the VI Hierarchy, only the last bend associated with the node moves. The whole edge is not rerouted. Workaround: N/A
| |||||
| 148149 Return | Event Structure Cases can Incorrectly Remap to Other Dynamic Events When deleting a user event refnum from a cluster which is input to a Register For Events Function, the associated Event Structure cases can be swapped. Workaround: N/A
| |||||
| 135276 Return | "Show front panel when loaded" option cannot be deselected in certain situations When a new VI is opened in a project, and its Reentrancy is set to Preallocate Clones for Each Instance, the "Show front panel when loaded" option cannot be deselected. Workaround: If you wish to deselect "Show front panel when loaded", do this before Reentrancy is set.
| |||||
| 173963 Return | Pressing "Stop" while dropping Snippet with SubVI that cannot be located hangs LabVIEW Workaround: Do not press Stop, use Ignore instead.
| |||||
| 180161 Return | Multiple icon layers are copied in reverse order and neither template nor text layer is considered at all The layer order is messed up if the user selects the entire icon and copies it. Furthermore, there is right now no way to copy the template or text layer. Workaround: To reverse order of user layers, merge layers before or select manually the user layers from bottom to top. To include the template/text layer, take a screenshot or drop the subvi on the blockdiagram, select it, press ctrl-c, open the Icon Editor and press ctrl-V.
| |||||
| 154260 Return | Context Help does not update for controls or indicators placed in a tab control on front panel Workaround: Right click on the item in the tab control and go to Properties»Documentation and add a custom Description for that item. Doing so will then allow the custom description and the data type to be shown in the context help when mousing over the item.
| |||||
| 95055 Return | Save for previous from LV 8.5 to 8.2 fails if file path is too long Workaround: Save the folder closest to the root directory.
| |||||
| 210394 Return | LabVIEW 2009 and/or LabVIEW 2009 Runtime may not launch on older CPUs A bug was found when trying to load information from older CPUs. The causes LabVIEW 2009 or the runtime to not launch. Known CPUs affected: EBox 3300 GenuineTMx86 Model Number: 20040614 Workaround: N/A
| |||||
| 185226 Return | FXP configuration diffs don't show up when comparing VIs Front panel type differences will be reported, but not node configurations Workaround: Manually Inspect
| |||||
| 170136 Return | Show Buffer Allocations displays a dot on the inside of a DVR border node There is not a copy made at this connection. Workaround: N/A
| |||||
| 256141 Return | Windows 7 often shows "(Not Responding)" and will bring other windows to the front during expensive operations If Windows 7 if a window is unresponsive to user input (e.g. mouse clicks) for five seconds it will ghost the window and display "(Not Responding)". Some operations in LabVIEW run in the UI thread. This is to prevent different operations from happening in parallel (e.g. compiling, edit operations, saving, drawing, etc.). Because large block diagrams can take longer than five seconds to compile or run clean up on Windows can tag LabVIEW as Not Responding. In some cases the ghosted window can move behind the other open windows when it finishes it task. Workaround: Wait until the expensive task as finished before trying to interact with the window.
| |||||
| 250119 Return | LabVIEW crashes if you delete a compound arithmetic primitive with a breakpoint Workaround: Remove breakpoint first, then delete.
| |||||
| 277283 Return | When creating a VI Snippet with code that contains a tab control, the snippet does not properly save the contents of each tab. Workaround: N/A
| |||||
| ID | Known Issue | |||||
|---|---|---|---|---|---|---|
| 276766 Return | Flat Sequence Structure leak GDI Objects, wasting memory and eventually crashing LabVIEW This leak occurs when the Flat Sequence Structure is moved. Using the keyboard create many different moves of a small distance. Using the mouse creates one move of a larger difference. Workaround: Use data flow and case structures to force execution order
| |||||
| 238713 Return | 3D Picture Controls can display tranparently or crash LabVIEW on certain graphics cards The 3D Picture Control is built on a OpenSceneGraph which uses OpenGL. Several reports of the 3D picture control crashing LabVIEW have been reported. In almost all cases it was an Intel integrated graphics card involved. This crash is caused by an incompatibility of the graphics hardware. Note: Many of the 3D Graphs use the 3D Picture Control Workaround: There have been several things that have worked for users:
| |||||
| 150730 Return | Chinese characters give an incorrect behaviour when not locked When typing chinese characters in LabVIEW, if you want to change the tool or the current window, the string will land onto the File menu item of LV. Workaround: To avoid this, the string must be locked by typing the space bar at the end of the string. Still, the string should not move if not locked.
| |||||
| 321876 Return | VI Password Protection can be defeated It is possible for an attacker to defeat a VIs password protection. Refer to KB: Security of LabVIEW VI Password Protection vs. Removing VI Block Diagrams. This issue will be marked as fixed when the information is in the LabVIEW Help. Workaround: Use Remove Block Diagram for maximum protection.
| |||||
| 329710 Return | VI Password Protection can be defeated It is possible for an attacker to defeat a VIs password protection. Refer to KB: Security of LabVIEW VI Password Protection vs. Removing VI Block Diagrams. This issue will be marked as fixed when the information is in the LabVIEW Help. Workaround: Use Remove Block Diagram for maximum protection.
| |||||
| LabVIEW Object Oriented Programming | ||||||
| 48855 3W6K2TMQ Return | Undo on a private data control can leave you in a state where File»Apply Changes is needed but disabled Editing a private data control and then undoing the edits removes the documentation modification on the class. However, while the owning class is broken and expects you to apply the changes you made, the File»Apply Changes menu option is disabled on the private data control. Workaround: Select File»Save or File»Close to save or close the private data control.
| |||||
| 50616 45ME5NJ1 Return | Cannot create an override member VI for both a child class and a grandchild class unless you first save the VI that contains the child class You cannot create a VI that overrides the functionality of a child class and then create another VI that overrides the functionality of a grandchild class unless you first save the VIs you want to override. Thus, if you right-click a LabVIEW class in the Project Explorer window and select New»VI for Override from the shortcut menu to create child:A.vi, you cannot select New»VI for Override for the grandchild class to create grandchild:A.vi until you save child:A.vi. This issue occurs because you cannot have two VIs in memory with the same filename that have never been saved. Workaround: Save the VI before you try to override any LabVIEW classes in that VI.
| |||||
| 52027 4A4GRP00 Return | Cannot use the 'New>>VI for Override...' dialog to create override of password-protected VI unless you have the password You use the 'New>>VI for Override...' dialog to override an ancestor VI in a LabVIEW class if the VI you want to override is password-protected. Workaround: Make a public VI which wraps the functionality of the the private VI, and instruct others to override the public VI.
| |||||
| 52753 4C08OCJ1 Return | Locking all classes in inheritance hierarchy does not hide protected member VIs When you lock a class, all the private member VIs are hidden in the project tree. According to the documentation, if all the classes in a class hierarchy are locked then the protected member VIs should also be hidden. They are not. This is strictly a display issue. Protected VIs are protected and cannot be accessed except within the class and its descendant classes. Workaround: N/A
| |||||
| 110152 Return | Error Creating Override VI for Dynamic Dispatch VI with No Block Diagram If you remove the block diagram from a dynamic dispatch VI then try to use the shortcut option New-> VI for Override, the action will fail with error 1012. Workaround: Create the override VI manually.
| |||||
| 112847 Return | Changing LV class inheritance does not always fix broken wires A child class wire can always connect to a parent class terminal. You may connect a class to another class and get a broken wire, if the wire's class does not inherit from the terminal's class. In the case where the class wire is used but there are no controls/indicators/constants of the class anywhere on the VI, the wire will still be broken. The bug exists if the class is an output wire from one subVI call and an input wire to another subVI call. The inverse problem also exists: Alpha.VI is saved when class A inherits from class B. Now, while Alpha.vi is not in memory, change A to not inherit from B. Load Alpha.vi. It should load broken, but it does not. Forcing a recompile will cause the VI to break. Workaround: Any action that causes LabVIEW to re-evaluate the wire will work to fix this problem. Some options include unloading and reloading the broken VI, deleting the broken wire and rewiring, force recompiling the VI (CTRL+Run Arrow). If you have many broken VIs that need to be fixed simultaneously, hold down Shift+Ctrl when clicking the run arrow to re-evaluate all VIs in memory.
| |||||
| 178273 Return | "Must Override" doesn't break descendant classes if ancestor implementation is renamed On a parent class, mark one dynamic dispatch VI as "Must Override". Now add an override VI in the child classes so that the hierarchy is not broken. Now do Save As:Rename on the parent VI. The child classes should be broken because they no longer have an override for the VI that changed its name, but they are not broken. Workaround: Unloading the classes and reloading them will correctly break the classes.
| |||||
| 180487 Return | "Must Override" setting still applies when VI changed to be static dispatch If you mark a dynamic dispatch VI as "Must Override" and then change the VI to be static dispatch, LabVIEW still breaks all child classes that do not override the VI, even though such overrides are illegal for static dispatch VIs. Workaround: Make the method dynamic dispatch again, adjust the class' setting (so that override is not required), and then make the method static.
| |||||
| 185059 Return | Member VIs of a class that is a member of a project library have a red X on them in the palettes Normally this red X only appears when you put private or unlicensed VIs into the palettes. VIs marked with this red X still drop on block diagrams successfully. Workaround: You can create a set of Merge VIs that are not part of the class that have just a single subVI on their block diagram that is the class VI you wanted to drop.
| |||||
| 193210 Return | XML parser error when unflattening a LabVIEW class owned by a library Suppose you have a LabVIEW class owned by a library. The Flatten To XML function can successfully flatten objects of that class into XML strings, but the Unflatten From XML function will return an error when trying to recreate the object. The error will claim that the class is not in memory even if it is in memory. Workaround: Move the class out of the library. If this is not an option, you will need to write a custom VI to translate the flattened XML into your class' data.
| |||||
| 103315 Return | Creating a circular link between an Xcontrol and a LVClass can crash LabVIEW. The circular load leads to VIs that are permanently broken and no matter what you do the run arrow will not become fixed. Workaround: Do not create a circular link from your XControl to your class. In other words, write your class completely and then write your XControl using the class. Do not put the XControl or any property/invoke node for the XControl into member VIs of the class.
| |||||
| 195168 Return | Password protected classes cannot be deployed to VxWorks target Deploying a VI that contains a member of a password protected class fails with the error "The VI is not in memory". The problem happens whether or not the password is in the cache. This will not affect classes built into an executable. Workaround: Remove the password protection from the class.
| |||||
| 185742 Return | Password protected classes with friends cannot be loaded in multiple contexts. A password protected class that has community scoped VIs and friends cannot be loaded in more than one application instance. When the class is loaded in a second context, the password prompt appears, and all VIs become broken if the prompt is cancelled. Workaround: Don't password protect classes with friends.
| |||||
| 200678 Return | System VIs Loaded by LVOOP Class Cause Unsaved Asterisk (dirty dot) in LabVIEW Project.
| |||||
| 205719 Return | Use of recursion slows loading VIs and editing of block diagram LV 2009 introduced VI recursion. LV 2009 detects recursion in the VI hierarchy and evaluates whether each recursive cycle is broken or not. The algorithm which detects recursion works, but slows down considerably as the number of recursive cycles in any single VI hierarchy increases. LV 2009 is not pruning the recursion detection tree as tightly as it should. This bug is new in LV 2009; it affects both newly written recursive VIs and recursion written with LV classes in 8.6 that are loaded in 2009. Workaround: Main workaround: To workaround the problem, reduce the number of recursive code paths through the VI hierarchy. In the particular VI hierarchy that identified this bug, much of the recursion was done using dynamic dispatch VIs. We were able to reduce the number of call paths by creating a static dispatch VI that wraps around the dynamic dispatch call and then instead of directly calling the dynamic dispatch subVI, callers use the static dispatch wrapper. This does not indicate a bug with LV classes -- it just happens to be one way of reducing code paths that works for this particular VI hierarchy. This technique may help many recursive applications; other techniques may be found for other VI hierarchies. Secondary workaround: If you cannot reduce the code paths in a hierarchy, consider replacing the direct recursion of LV 2009 with recursion using VI Server, which has been available since LV 5.0. Delete the direct subVI call and instead use Open VI Reference with the 0x8 flag to get a new reeentrant instance and then call the subVI using the Call By Reference node. There is more performance overhead associated with this method of recursion, but it does not create the compile time recursion detection problem. For many applications, use of this older style of recursion will perform sufficiently well to be considered a viable workaround.
| |||||
| 204973 Return | Various upgrade problems when using typedef of a LV class When you wire a child class wire to a parent class terminal of a subVI, the parent output of the subVI will often (when the content of the subVI allows it) convert to the child type. This is a feature called "automatic downcasting". If you wrap the child class in a typedef, automatic downcasting behaves erratically. Workaround: Open the typedef control and change its type from "Type Def." to "Custom". This will cause all uses of the typedef to be disconnected. This will fix all cases of the problem. If the typedef is truly needed in your application, you can disconnect the typedef on individual controls on caller VIs where the problem arises.
| |||||
| 194277 Return | Rare instability when dynamic loading classes in combination with static VI references This bug requires four elements to even have a chance of reproducing: 1. TopLevel.vi (or its subVIs) uses Parent.lvclass:Dyn.vi, which is a dynamic dispatch VI. 2. TopLevel.vi (or its subVIs) has a static VI reference to Second.vi. 3. Second.vi (or its subVIs) has any usage of Parent.lvclass, including a constant of the class, a call to a VI in the class, a typedef owned by the class, or any of these for a descendant class. 4. In the course of running TopLevel.vi, a descendant of Parent.lvclass (call it Descendant.lvclass) will be dynamically loaded into memory. If any of these four is not true, the bug does not arise. If these are true, you may see behavior including a dialog claiming that the descendant is not in memory (probable), a LabVIEW crash (common) or the wrong VI executing when the Dyn.vi method is invoked with Descendant.lvclass data (extremely rare). If Second.vi includes dynamic dispatch VI calls, those may have the same problems. This bug exists in LV8.6 and 2009. Workaround: Replace the static VI reference with a call to the Open VI Reference primitive. After making this modification, you will need to restart LabVIEW if you haven't already crashed.
| |||||
| 283943 Return | Many VI Server methods work across contexts and use variants, which can crash LabVIEW when provided with context sensitive data (such as LabVIEW Classes). Writing a VI which passes or returns variants with a VI Server method or property to interact with a VI open in another context can crash LabVIEW when using context sensitive data (such as LabVIEW Classes). Workaround: Make sure that any interaction with context sensitive data is performed by a VI loaded in the same context as the target. If you need to give commands to a target in another context, you may need to load a helper VI in the target's context and use simpler datatypes to instruct the helper VI how to interact with the target.
| |||||
| 284936 Return | Breaking one Override VI in LVOOP shows all siblings as broken but does not explain why When using OOP in LabVIEW, breaking the connector pane of a child class Override VI will make all of its sibling override VI's appear broken even though they are not broken. Hitting run on the broken Run Arrow of any child class Override VI will list all of the child class VIs in the list of "Items with Errors", but none of them will have an error associated with it except for the broken ones. Workaround: Use the red X in the errors window to find the actual broken VI
| |||||
| 179603 Return | Call Parent Node input must be the same as dynamic dispatch terminal. When using the call parent node in a VI with dynamic dispatch terminals, the data must flow from the terminal to the Call Parent Node. If not the VI should break. In LabVIEW 2010 and previous this doesn't break. However this will break in LabVIEW 2011 with the error message: "The data from the dynamic input must flow to the Call Parent Node; however, you can modify the data along the way. In this error, there is no wire path that leads from the dynamic input front panel terminal to the dynamic input of the Call Parent Node. Without such data flow, a child class may violate the functionality contract established by its parent class." Workaround: Turn off the output's "Dynamic Dispatch Output" option.
| |||||
| LabVIEW Project | ||||||
| 48100 3PCAD0J1 Return | Save As»Substitute Copy affects all projects in memory, not just the one that does the Save As operation. If you have Alpha.vi loaded into two separate projects, these are two independent VIs in memory. If you do Save As»Rename then, LabVIEW correctly renames the VI in both projects since the actual source on disk has changed. However, if you do Save As»Substitute Copy, only one project should change. Workaround: Close any projects that you want to contain the original VI before performing the Save As»Substitute Copy operation.
| |||||
| 117582 Return | Private scope has no effect on XControls or StateCharts Marking an XControl or a StateChart as private inside an owning library will not prevent VIs outside the owning library from using that XControl or StateChart. Workaround: No known workaround.
| |||||
| 163371 Return | "Save As:Copy" on a nested library breaks member VIs if use option to add copied library to owner library If you have a nested library, a library that is owned by another library, and you use Save As:Copy, there is an option to add the duplicate library to the original owner library. If you use this option, the member VIs of the duplicate library are all broken because they are not correctly named as members of the owning library. This bug affects all types of libraries, .lvlib, .lvclass, .xctl and .lvsc. Workaround: Option 1: Do not use the "add to owning library" option and instead add the duplicate library to the owner manually after the copy. Option 2: After the copy operation, move the duplicate library out of the owner library and then move it back into the owner library.
| |||||
| Menus | ||||||
| 104160 Return | Right Click Wire: Delay in Appearance of ShortCut Menu You may get a noticable delay the first time you right-clicki on a wire if LabVIEW has complex custom probes available. LabVIEW loads all custom probes in /LabVIEW Data/Probes/..., /_probes/..., and /_probes/... the first time it displays the right-click menu for a wire. Depending on the contents of the probe VIs, this delay could potentially grow very large. Workaround: Mass compile the contents of /LabVIEW Data/Probes/..., /_probes/..., and /_probes/... Delete unused probes from the directories listed above.
| |||||
| Miscellaneous | ||||||
| 39908 4AIBSAFF Return | When synchronous display is enabled, disconnecting and reconnecting to a LabVIEW Real-Time target performing image display in a loop causes the Real-Time target to hang If you enable synchronous display on an image display control and then update the control in a loop on a VI running on an Real-Time target, LabVIEW hangs after disconnecting and reconnecting to the target. This issue might occur when you want to run an application that can perform a headless operation, but you still want to perform image display in a loop. Workaround: Right-click the image display control and select Advanced»Synchronous Display from the shortcut menu to disable synchronous display.
| |||||
| Operating System Specific | ||||||
| 91250 453BD7Q6 Return | LabVIEW crashes on Japanese Vista if system locale is set to a Western European codepage If you have a user name that uses Japanese characters and change the system locale to something other than Japanese, LabVIEW crashes. Workaround: Make sure your locale and user name match.
| |||||
| 114264 Return | WebServer does not handle html file whose name contains Japanese characters. If an html file is created from VI which is under a project, "project name»Target Name»VI name.html" will be the default html file name. Most commonly, [Target Name] will be "My computer" in Japanese for any users using Japanese OS. If these characters are included in the html file name, you cannot open the html file through the LabVIEW Web Server. Note: Not all Japanese characters cause problems. Workaround: N/A
| |||||
| 157246 Return | The Property Node "Bring to Front" doesn't work in Windows Vista Workaround: N/A
| |||||
| 204314 Return | Building Shared Library Fails on 64-bit Linux Workaround: Create a shell script named "gcc" which does what you want and insert it into the PATH before launching LabVIEW.
| |||||
| 242799 Return | Code generation of DAQmx Assistant for Modular Instrument Express VIs fails on second attempt in LabVIEW 64-bit When dropping a DAQmx Assistant or or a Modular Instrument Express VI, everything, including code generation, works the first time, but if another Express VI is dropped, the config page appears, but no code is generated when the user presses [OK]. Workaround: For all versions of LabVIEW 32-bit on the 64-bit machine, disable the VI Server TCP/IP checkbox, exit, and try the code generation again in LabVIEW 64-bit.
| |||||
| 186575 Return | LabVIEW task bar icon pixelated in Windows 7 LabVIEW task bar icon pixelated in Windows 7. Looks nice for LabVIEW 2009. Workaround: N/A
| |||||
| 306797 Return | Cannot create indicator/control/constant for refnum datatypes from XML property and invoke nodes LabVIEW for Linux cannot create indicators, controls, or constants for refnum datatypes from the XML Parser property or invoke nodes Workaround: N/A
| |||||
| Performance | ||||||
| 48663 3ULGC6UX Return | Very Large Constant Arrays May Interfere with Constant Folding When looping through very large constant arrays, LabVIEW may run out of memory. In this case, no constant folding is executed in the code. Workaround: N/A
| |||||
| 184424 Return | VISA Property node can cause a Memory is Full Error Repeatedly running the VISA Property node for GPIB properties can lead to a LabVIEW: Memory is Full Error, LabVIEW crash, or hang. It is inconsistent and can crash within minutes or weeks. Workaround: Use a semaphore to guard all uses of the GPIB or Visa interface (reads, writes, properties, methods, etc.) to guarantee that only one is executing at a time.
| |||||
| Remote Panels | ||||||
| 46442 2BCDF100 Return | Remote Panel not correctly displaying hidden/disabled controls when server is a built app. Clients viewing a front panel remotely might see different behavior depending on whether the front panel they are connecting to is from a built application. Specifically, if the front panel is from a built application, any programmatic changes to the front panel made before the client connects to the front panel are not reflected on the client computer. For example, if a Property Node changes a caption on a control before a client connects to that front panel, the client will see the original caption of the control, not the changed caption.
| |||||
| 50165 4367OV4I Return | VI in web browser with top-level window or dialog window style does not draw. If you create a VI, select Top-level application window or Dialog options from the Window Appearance page in the VI Properties dialog box, and publish the VI to the web, when you view the VI, it uses the default window style instead of the style you selected. This issue was formerly documented as issue 51263/47MA31QO. Workaround: N/A
| |||||
| ID | Known Issue | |||||
|---|---|---|---|---|---|---|
| 97181 Return | On a Mac, a VI that writes waveform data to a chart on the Web Server crashes the Web browser when accessed from a PC When posting a VI that writes waveform data to a chart inside a loop on the Web Server for remote front panels on a Mac, accessing the remote front panel from a PC may crash the Web browser. Workaround: Use graphs instead of charts. If chart functionality is necessary, you can programmatically create a history of data that gets plotted to the graph on each plot.
| |||||
| 181687 Return | Web publishing tool fails without error The web publishing tool may fail to start the web server if the port is already reserved, yet not return an error. Workaround: Ensure that the port to be used by the web server is not in use.
| |||||
| 202702 Return | RT Remote Panel license is not released when tab or browser window is closed Attempting to connect to remote front panel on real-time target from multiple tabs or windows in a browser causes remote front panel to exceed the connections. Closing these tabs or windows does not release the license connection. Therefore the exceeded connection limit message persists until the target is rebooted. Workaround: Reboot the RT target to reconnect to the remote front panel.
| |||||
| 136677 Return | Remote panels do not work if Internet Explorer is embedded in an ActiveX or .NET Container If a remote panel is built in LabVIEW 8.6 and embedded in an ActiveX or .NET Container in a LabVIEW 8.6 VI it will not display correctly Workaround: Use a remote subpanel. This is actually the recommended way to accomplish this task
| |||||
| 251105 Return | S&V XControls built as Remote Panel crashes LabVIEW. Remote panels do not reliably support the Sound and Vibration XControls. Workaround: Use another mechanism for remote viewing.
| |||||
| Shared Variables | ||||||
| 52799 4C8E5500 Return | Variable Manager May Display the Incorrect Buffer Size When the ServerVariable or ServerVariableInfo class explicitly creates a network variable and configures the server-side buffer for the network variable, the value for the buffer size displayed by Variable Manager is incorrect. Workaround: Use the ServerVariable.GetItemCapacity() method or ServerVariableInfo.ItemCapacity property to retrieve the correct value.
| |||||
| 141699 Return | NI Distributed System Manager does not show deployed libraries if they contain non-Latin characters. If a library with non-Latin characters (such as Japanese, Chinese, or Korean) is deployed, it will not show up in the NI Distributed System Manager tree view. Workaround: Rename the library using only the Latin alphabet and re-deploy the library.
| |||||
| 128059 Return | Shared variable bindings in the same library are not updated properly when copying/renaming the library If you have shared variables in a library which are bound to I/O servers or other variables that are also in the same library, and you rename or save a copy of the library, the bindings still refer to the original library name. Workaround: Manually rebind the variables after copying or renaming the library.
| |||||
| 173080 Return | When a project that contains variables with binding is created in one language and opened in a different language, variables may fail to deploy Workaround: Open the project in the desired language, double-click on the variables with binding, and re-bind the variables.
| |||||
| 168005 Return | Dynamic Variable API Does Not Support I/O Servers that Use Ranges You cannot use the Variable classes, properties, and methods or the associated Shared Variable functions (Dynamic Variable API) to dynamically read and write PSP items published by an I/O Server that uses a Range item. For example, Modbus I/O Servers and Lookout Ranges are affected by this issue. Workaround: If you want to use the Dynamic Variable API to read or write one of these PSP items, you can create a network-published shared variable and bind it to the PSP item. Then you can use the Dynamic Variable API to read and write the bound shared variable.
| |||||
| 186808 Return | Shared Variable library on PC is undeployed if the a V in the same project is programmatically deployed to a Real-Time target When programmatically deploying a VI to a Real-Time target the Shared Variable library residing in the same project as the deployed VI will be undeployed. Workaround: Programmatically deploy the shared variable library on the PC after deploying the VI to the real-time controller.
| |||||
| Source Code Control | ||||||
| 107802 Return | When working with LabVIEW Libraries and their VIs outside of a LabVIEW Project environment, LabVIEW may display incorrect Source Code Control status for files. When working with LabVIEW Libraries and their VIs outside of a LabVIEW Project environment, LabVIEW may display incorrect Source Code Control status for files. For example, files may be checked out but LabVIEW will not reflect this. This problem also applies to LabVIEW XControls, Classes, and Statecharts Workaround: Work with your files inside of a LabVIEW project if you are using Source Code Control.
| |||||
| 123313 Return | Unnecessary IAK file checked into source code control When NI-FieldPoint is installed, and source code control is configured for LabVIEW, when you check in projects to source control the source code provider attempts to check in an IAK file for the project, even if one does not exist. Workaround: If a dialog appears when checking in file, do not check in the iak file if it is not necessary for that project.
| |||||
| 229641 Return | Hang can occur when deploying RT project that has not been check out of VSS When using VSS source code control for a real time project and trying to deploy code that has not been checked off the deployment window blocks a pop up from VSS saying that the code has not been checked out. The deployment status window is modal so it does not allow you to select to proceed in the VSS window. Workaround: In the LabVIEW project properties disable the prompts from source code control. Or you could make sure that the VIs are saved prior to deploying.
| |||||
| Toolkit - Report Generation | ||||||
| 188911 Return | Control image alignment incorrect when "new report page" VI is used When using the "append control image to report" VI, the alignment of some images is ignored when the "new report page" VI is used between appended images. This problem only exists with Office 2007. Other versions - Office 2003 and Office 2010 do not exhibit this behavior. Workaround: Place a "new report line" VI between appending the image and the "new page" VI
| |||||
| Upgrade - Behavior Change | ||||||
| 51185 47FGSQCS Return | Cannot save VI as the same name as missing library member VI If a library contains a VI and the VI is missing, you should be able to save a VI as the same name as the missing VI in order to rebuild the missing VI. Currently, LabVIEW does not allow this. Workaround: Delete the item from the library, save the new VI as the same name as the missing VI and then move the VI into the library.
| |||||
| 52263 4AJA41TQ Return | Some operations on integer waveforms lose dt value Some functions, such as Absolute Value and Logarithm Base 10 operate as you expect with DBL Waveforms, but when you apply the same functions to an I16 waveform, for example, the Absolute Value function works as you expect while the Logarithm Base 10 function loses the sampling interval dt value. LabVIEW resets the sampling interval dt value to 1.00. If the input waveform to the log function has a time stamp for t0, that value is also lost. Workaround: Extract the Y-array of the waveform and perform the needed operations on Y before re-building the waveform.
| |||||
| 41224 4DA24FXR Return | Cannot display extended types on intensity plots In LabVIEW 8.0 and newer, when you wire extended precision type numbers to an intensity graph or chart you get a different looking plot than with the same double-precision numbers. Workaround: Use the data type conversion functions to convert your data to double precision representation.
| |||||
| 119444 Return | Multi-column listbox format lost on upgrade A Multicolumn listbox created in LV 7.1 may lose its format when opened in LV 8.5 or later. Column headers lose their 3D appearance and font formatting might be lost. Workaround: Replace the Listbox and recreate all customizations
| |||||
| 119204 Return | Plot Legend Does Not Update When Using Property Nodes When the properties of a plot legend are changed by property node or by a reference and a property node, the legend does not redraw. Workaround: A redraw can be forced by changing the property node Plot.Name, changing the property node Legend.Visible, or a mouse movement over the plot legend.
| |||||
| 183979 Return | Case Structure with Many Cases and Contained Indicators Slow to Open A VI that has a case structure with many cases with many indicators inside of the Case Structure can take an unexpectedly long time to open and has high CPU usage. Workaround: Move indicators outside of case structure if possible and wait for VI to open.
| |||||
| 185220 Return | Certain Fonts Displayed Incorrectly If Language Package is Installed If you ask for a font that does not have support for the current OS language, LabVIEW will choose a supported font that will map the same as the selected font. Workaround: Set the current OS language to one that supports the font you want to use.
| |||||
| 192207 Return | Controls linked to the connector pane can no longer be changed when Suspend When Called is used. Workaround: Use Breakpoints and Step Into if possible.
| |||||
| 188998 Return | Upgrading Tab Controls from LabVIEW 8.2.1 to higher versions results in unexpected behaviors. Upgrading a VI containing a tab control from LabVIEW 8.2.1 to higher versions may result in unexpected changes to the way the tab control looks and works Workaround: Right click->replace the tab control with a new tab control.
| |||||
| 196125 Return | Error -4702 when running shipping example "instrument control parsing.vi" in LabVIEW 2009 The Example VI uses a Match Regular Expression primitive. The functionality of Match Regular Expression was changed in LabVIEW 2009 to not support NULL characters as it gave unexpected results in certain cases. See Doc CAR 200951 Workaround: Replace 'Match Regular Expression' with 'Match Pattern', which does support NULL characters Match Regular Expressions should not be used with this function for strings which contain a NULL character because it will give unexpected results.
| |||||
| 198717 Return | Unflatten From XML fails for cluster and arrays that consist of variants Creating a cluster that contains a variant or building an array of variants, and then trying to flatten it to XML using the Flatten To XML VI and then unflattening it using the Unflatten From XML VI will throw error 1106 Workaround: N/A
| |||||
| Upgrade - Migration | ||||||
| 99825 Return | Table Property Nodes Run Slow After Upgrade from 7.1 Property nodes that are used to update table controls on the front panel (such as Set Cell Value, Active Cell, CellBGcolor, CellFontColor) run about 7 times slower in LabVIEW 8.x versions than in 7.1 and prior. Workaround: Use defer front panel updates to avoid rapid updates of the UI which would probably not be noticed. This design pattern can speed up the program to levels much faster than 7.1 ran before the slowdown.
| |||||
| 45227 4I6EOTBK Return | VI with Several Timed Structures Takes Minutes to Load There is an issue in opening a VI written in a previous version of LabVIEW with many timed structures in LabVIEW 8.5 or later. This only occurs on the first load, once the VI is saved in the current version the load time will return to normal. Workaround: Wrap the Timed-Structures in SubVIs.
| |||||
| 138552 Return | Load VRML File.vi missing "error in" terminal In LabVIEW 8.6, the "error in" terminal was removed from the Load VRML File.vi. LabVIEW 8.2/8.5 has this terminal. Thus, if a VI that has the Load VRML File VI is upgraded to 8.6, the previously working VI will be broken. Workaround: Place a case structure around the Load VRML File VI to handle the error manually.
| |||||
| 147187 Return | Crash using Xscale Info or YScale Info graph properties Graph properties Xscale Info and YScale Info available in LabVIEW 6.0 are no longer available. Using these properties will cause your VI to crash when executed. Workaround: Use newer individual properties XScale.Range etc. to adjust your graph properties.
| |||||
Document last updated on 12/21/2011