Archived: LabVIEW 2011 C Generator Known Issues

Publish Date: Jul 22, 2018 | 1 Ratings | 5.00 out of 5 | Print

Overview

This document has been archived and is no longer updated by National Instruments.

This document contains the known issues that were discovered before and since the release of LabVIEW 2011 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 2011 C Generator sorted by Category.

Building and Distributing LabVIEW Applications
214201 LabVIEW datatype definitions can conflict with those in external C code
223962 Leading or trailing white spaces in the Build Specification name might cause C generation to fail
228110 LabVIEW generated Makefile compiles all object (.obj) files when creating a DLL
231443 LabVIEW does not check Entry/Exit action VIs for syntax when using the Statechart Module
231779 Control References and Property Nodes do not report a warning when used in an exported VI
242492 "clean" rule in generated Makefile does not clean all old object (.obj) files
External Code
214201 LabVIEW datatype definitions can conflict with those in external C code
Functions, VIs, and Express VIs
231443 LabVIEW does not check Entry/Exit action VIs for syntax when using the Statechart Module
231779 Control References and Property Nodes do not report a warning when used in an exported VI



ID Known 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 redefine 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
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
242492

Return
"clean" rule in generated Makefile does not clean all old object (.obj) files
You can use the "make clean" on the command line to delete existing object (.obj) files before a new build. However, the clean rule in the LabVIEW generated Makefile only deletes object files created in the last build. If there are older files remaining from one of the previous builds, they will stay in the obj directory. These old object files 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. Alternatively, you can modify the clean rule in the Makefile to do this for you. Replace clean: dummy @del /f/s/q $(OBJS) @del /f/s/q $(LIBSRCOBJS) with clean: dummy @del /f/s/q $(OBJDIR)\*.obj @del /f/s/q $(LIBSRCOBJS)

Reported Version: 2010    Resolved Version: N/A    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 redefine 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
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/29/2011

Back to Top

Bookmark & Share


Ratings

Rate this document

Answered Your Question?
Yes No

Submit