Archived: LabVIEW 2010 C Generator Known Issues

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.

Overview



This document contains the known issues that were discovered before and since the release of LabVIEW 2010 C Generator. Not every issue known to NI will appear on this list; it is intended to only show the severe and more common issues that can be encountered.

Each Issue appears as a row in the table and includes these fields:
  • Issue ID
  • Legacy ID - The issue's legacy ID from NI's deprecated bug reporting database (if applicable)
  • Issue Title
  • Problem Description
  • Workaround
  • Reported Version - the earliest version of LabVIEW the issue was reported in
  • Resolved Version - version the issue was resolved or was no longer applicable
  • Date Added - the date the issue was added to the document (not reported date)

Document Organization

The Known Issues Document displays the issues by issue category.

Known Issues by Category

Please refer to Developer Zone Article " LabVIEW Known Issues Categories Defined" for an explanation of the categories and what types of issues are in each category.

Contacting NI

You can contact us by phone, email, or the discussion forums. Visit the NI Website to contact us. If you are contacting NI in regards to a specific issue, be sure to reference the ID number given in this document. If you have feedback on this specific document, please contact NI on this NI Developer Zone post.

Known Issues by Category

The following items are known issues in LabVIEW 2010 C Generator Known Issues sorted by Category.

Building and Distributing LabVIEW Applications
214201LabVIEW datatype definitions can conflict with those in external C code
223962Leading or trailing white spaces in the Build Specification name might cause C generation to fail
224349Libraries built from LabVIEW generated C code might not link if they use complex data types
233935Some unsupported Express VIs do not report a warning when used in an exported VI
222781VIs added to the Always Included list in the Build Specification are not checked for syntax
228110LabVIEW generated Makefile compiles all object (.obj) files when creating a DLL
231443LabVIEW does not check Entry/Exit action VIs for syntax when using the Statechart Module
231779Control References and Property Nodes do not report a warning when used in an exported VI
235810Contents of Virtual Folders that are added to the Always Included list might be ignored
239217C generation might fail if a Statechart is added to the Always Included list in the Build Specification
240267Password protected VIs in the exported VI hierarchy will cause C generation to fail
Compatibility
231444C Code Generation might fail is unsupported VIs are added to Entry and Exit actions in a Statechart
Documentation
226076Discrepancies in the "Including Generated C Code in External Applications" Help topic.
External Code
214201LabVIEW datatype definitions can conflict with those in external C code
Functions, VIs, and Express VIs
231444C Code Generation might fail is unsupported VIs are added to Entry and Exit actions in a Statechart
233935Some unsupported Express VIs do not report a warning when used in an exported VI
231443LabVIEW does not check Entry/Exit action VIs for syntax when using the Statechart Module
231779Control References and Property Nodes do not report a warning when used in an exported VI



IDKnown Issue
Building and Distributing LabVIEW Applications
214201

Return
LabVIEW datatype definitions can conflict with those in external C code
LabVIEW defines certain basic datatypes in the generated C code, viz. Boolean, float32, float64. When integrating the LabVIEW generated C code in a larger C application/code base, you should take precautions to avoid datatype definition conflicts. For eg, if the external code base also defines a 32-bit float as "float32", you will get a compiler error.

Workaround: There are multiple ways of avoiding type name conflicts: 1. You can use LabVIEW generated datatypes in your top-level C application. These types are defined in LVDefs_plat.h. This file can be found in labview\CCodeGen\inlcude\os, under the directory for your specific operating system. 2. You can redefined your datatypes with names that are different from those used in the LabVIEW generated C code.

Reported Version: 2010  Resolved Version: N/A  Added: 07/27/2010
223962

Return
Leading or trailing white spaces in the Build Specification name might cause C generation to fail
When using the LVCG.exe to generate C code from the command line, leading or trailing white spaces in the the Build Specification name might cause the C generation process to fail. LVCG.exe takes the Build Specification name as one of its input parameters and it cannot process leading or trailing white spaces.

Workaround: N/A

Reported Version: 2010  Resolved Version: N/A  Added: 07/27/2010
224349

Return
Libraries built from LabVIEW generated C code might not link if they use complex data types
LabVIEW generated complex data types, viz. cmplx64 and cmplx128 are defined in LVDefs.h. However, LV Defs.h is not included in the LabVIEW generated header for your exported VI. If your exported function uses the complex datatypes as parameters, your library will fail to link against calling C code.

Workaround: Include LVDefs.h manually into your external application. It can be found at labview\CCodeGen\include\blockdiagram. Alternatively, you can add LVCGenIncludes.h into all your top level C files, this will include all necessary runtime support.

Reported Version: 2010  Resolved Version: N/A  Added: 07/27/2010
233935

Return
Some unsupported Express VIs do not report a warning when used in an exported VI
When a top level VI is configured for export by adding it to a C Generator Build Specification, LabVIEW performs syntax checking on it to warn the user if unsupported VIs are used on the Block Diagram. However, the following VIs do not cause a warning: Group Digital Signals Set Dynamic Data Attributes Get Dynamic Data Attributes Spectral Measurements Report These VIs will cause the C Generation/Build step to fail.

Workaround: N/A

Reported Version: 2010  Resolved Version: 2010  Added: 07/27/2010
222781

Return
VIs added to the Always Included list in the Build Specification are not checked for syntax
You can check the syntax of your exported VI by right-clicking on your C Generator Build Specification and selecting "Check Syntax...". Doing this only checks the exported VI for syntax, VIs added to the Always Included list on the Source Files page of the Build Specification are not checked. If the VIs in the Always Included list contain unsupported elements, the C generating step will fail.

Workaround: N/A

Reported Version: 2010  Resolved Version: N/A  Added: 07/28/2010
228110

Return
LabVIEW generated Makefile compiles all object (.obj) files when creating a DLL
The LabVIEW generated Makefile compiles all object files present in the obj directory. If this directory contains object files for VIs that have been removed from your VI hierarchy, they might cause a linker error.

Workaround: You can manually delete the obj directory to ensure that all old object files are deleted. Running the make command after this will regenerate the obj directory and all necessary object files.

Reported Version: 2010  Resolved Version: N/A  Added: 07/28/2010
231443

Return
LabVIEW does not check Entry/Exit action VIs for syntax when using the Statechart Module
Statechart module lets you configure Entry and Exit actions for each state. LabVIEW does not check the VIs used in these actions for syntax. If you use unsupported VIs in the Entry/Exit actions, C generation might fail.

Workaround: N/A

Reported Version: 2010  Resolved Version: N/A  Added: 07/28/2010
231779

Return
Control References and Property Nodes do not report a warning when used in an exported VI
When a top level VI is configured for export by adding it to a C Generator Build Specification, LabVIEW performs syntax checking on it to warn the user if unsupported VIs are used on the Block Diagram. However, Control References and Property Nodes do not report a warning. While the C generation step may succeed, using the generated code in an application will cause compilation errors.

Workaround: N/A

Reported Version: 2010  Resolved Version: N/A  Added: 07/28/2010
235810

Return
Contents of Virtual Folders that are added to the Always Included list might be ignored
If a Virtual Folder is added to the Always Included list on the Source Files page of the Build Specification, the VIs contained in it might be ignored by the C Generation process.

Workaround: Add VIs directly to the Always Included list.

Reported Version: 2010  Resolved Version: N/A  Added: 07/28/2010
239217

Return
C generation might fail if a Statechart is added to the Always Included list in the Build Specification
C generation might fail if a Statechart (.lvsc) is added to the Always Included list in the Source Files page of the Build Specification.

Workaround: N/A

Reported Version: 2010  Resolved Version: N/A  Added: 07/28/2010
240267

Return
Password protected VIs in the exported VI hierarchy will cause C generation to fail
Having a password protected VI in the exported VI hierarchy will cause the C generation to fail.

Workaround: You have to manually find and open the Block Diagram of the password protected VI(s). You will need to enter the password to do this. Once the VI(s) is unlocked, C generation will succeed.

Reported Version: 2010  Resolved Version: N/A  Added: 07/28/2010
Compatibility
231444

Return
C Code Generation might fail is unsupported VIs are added to Entry and Exit actions in a Statechart
The Statechart Module lets you configure Entry and Exit actions for every state by adding LabVIEW VIs in an editor. LabVIEW does not warn you if unsupported functions are added to the editor. C Code generation might fail is such functions/VIs are present. For a list of all functions and VIs not supported by the LabVIEW C Generator, refer to Unsupported VIs and Functions (C Generator) in the LabVIEW Help

Workaround: N/A

Reported Version: 2010  Resolved Version: N/A  Added: 06/02/2010
Documentation
226076

Return
Discrepancies in the "Including Generated C Code in External Applications" Help topic.
1. Help states: All generated C files except DllMain.c. However, DLLMain.c is not a generated file. It is located in labview\CCodeGen\libsrc\platform\win. 2. The Build Specification output directory path should be added to the list of include directories to compile successfully. Help does not mention this explicitly.

Workaround: N/A

Reported Version: 2010  Resolved Version: 2010  Added: 07/28/2010
External Code
214201

Return
LabVIEW datatype definitions can conflict with those in external C code
LabVIEW defines certain basic datatypes in the generated C code, viz. Boolean, float32, float64. When integrating the LabVIEW generated C code in a larger C application/code base, you should take precautions to avoid datatype definition conflicts. For eg, if the external code base also defines a 32-bit float as "float32", you will get a compiler error.

Workaround: There are multiple ways of avoiding type name conflicts: 1. You can use LabVIEW generated datatypes in your top-level C application. These types are defined in LVDefs_plat.h. This file can be found in labview\CCodeGen\inlcude\os, under the directory for your specific operating system. 2. You can redefined your datatypes with names that are different from those used in the LabVIEW generated C code.

Reported Version: 2010  Resolved Version: N/A  Added: 07/27/2010
Functions, VIs, and Express VIs
231444

Return
C Code Generation might fail is unsupported VIs are added to Entry and Exit actions in a Statechart
The Statechart Module lets you configure Entry and Exit actions for every state by adding LabVIEW VIs in an editor. LabVIEW does not warn you if unsupported functions are added to the editor. C Code generation might fail is such functions/VIs are present. For a list of all functions and VIs not supported by the LabVIEW C Generator, refer to Unsupported VIs and Functions (C Generator) in the LabVIEW Help

Workaround: N/A

Reported Version: 2010  Resolved Version: N/A  Added: 06/02/2010
233935

Return
Some unsupported Express VIs do not report a warning when used in an exported VI
When a top level VI is configured for export by adding it to a C Generator Build Specification, LabVIEW performs syntax checking on it to warn the user if unsupported VIs are used on the Block Diagram. However, the following VIs do not cause a warning: Group Digital Signals Set Dynamic Data Attributes Get Dynamic Data Attributes Spectral Measurements Report These VIs will cause the C Generation/Build step to fail.

Workaround: N/A

Reported Version: 2010  Resolved Version: 2010  Added: 07/27/2010
231443

Return
LabVIEW does not check Entry/Exit action VIs for syntax when using the Statechart Module
Statechart module lets you configure Entry and Exit actions for each state. LabVIEW does not check the VIs used in these actions for syntax. If you use unsupported VIs in the Entry/Exit actions, C generation might fail.

Workaround: N/A

Reported Version: 2010  Resolved Version: N/A  Added: 07/28/2010
231779

Return
Control References and Property Nodes do not report a warning when used in an exported VI
When a top level VI is configured for export by adding it to a C Generator Build Specification, LabVIEW performs syntax checking on it to warn the user if unsupported VIs are used on the Block Diagram. However, Control References and Property Nodes do not report a warning. While the C generation step may succeed, using the generated code in an application will cause compilation errors.

Workaround: N/A

Reported Version: 2010  Resolved Version: N/A  Added: 07/28/2010

Document last updated on 7/30/2010

Glossary of Terms

 

  • Bug ID - When an issue is reported to NI, you may be given this ID or find it on ni.com.  You may also find IDs posted by NI on the discussion forums or in KnowledgeBase articles.
  • Legacy ID – An older issue ID that refers to the same issue.  You may instead find this issue ID in older known issues documents.
  • Description - A few sentences which describe the problem. The brief description given does not necessarily describe the problem in full detail.
  • Workaround - Possible ways to work around the problem.
  • Reported Version - The earliest version in which the issue was reported.
  • Resolved Version - Version in which the issue was resolved or was no longer applicable. "N/A" indicates that the issue has not been resolved.
  • Date Added - The date the issue was added to the document (not the reported date).