Showing results for 
Search instead for 
Did you mean: 

Labview Report Generation NI_Report.LV for excel does not work in deployed code

Go to solution



I developed a Labview code to do the following tasks using report generation toolkit. 

(1) Create a new report - (type) excel

(2) Append tables to excel sheet

(3) Append images to excel sheet

(4) Save excel to a location

(5) dispose report


This works well in source code on both the development laptop and deployment machine. But it does not work as exe file. The deployed code appears to run with no error but no files are generated. 


The file is attached. Any thoughts are appreciated. 






0 Kudos
Message 1 of 10

Try to make an extremely simple example into an executable and slowly add functionality in. It could be something simple like the path is not valid. You are not connecting many of your error wires so it is probably not that the code runs without error, just that you are not checking for the error.

Message 2 of 10

I'm not sure where your error is located, but I can certainly say that LabVIEW 2014 (which you are running) will certainly support creating Excel Workbooks in both Development and Run-Time Environments.  I don't have direct experience with attaching multiple Images to Reports, but would expect this to work, as well.


So here are some suggestions to finding out What Is Wrong:

  • Simplify.  Get rid of most of the extraneous code and leave yourself with a small subset of your code that only writes Excel (maybe not all of the data, but one table and two images).  See if that works.
  • Use the Error Line.  Every RGT function should "sit" on the same Error Line that originates with an "Error In" (or an Error Constant) on the left edge of your Block Diagram and ends with an Error Out that merges all the parallel track Error Lines.
  • You will make Debugging your code a whole lot easier if you wrote more compact code (lots of White Space is bad) and kept wires as straight as possible.  Good Style counts in LabVIEW.

Bob Schor

Message 3 of 10
Accepted by topic author FLiu

This help topic explains the extra step required when building an EXE that uses the Report Generation VIs:


Specifically, you need to add the Excel class to your project, then add it to your EXE build spec as an Always Included file.

Message 4 of 10

Far be it for me to contradict Darren, but at least since LabVIEW 2014, one does not need to make any special "Always Include" to a Build Spec involving Excel and the RGT.  I have several routines that write Excel, and that Read and Write Excel, and the only file in the Source Files section is the name of the Main VI in "StartUp VIs", with nothing specified in the "Always Included".


The Original Poster is using LabVIEW 2014, which (in my hands) does not require anything special for a Build Spec except specifying the StartUp VI.  I recommend the OP follow my suggestion of extracting the code to write the Excel Report (using made-up data, if necessary), utilize the Error Line appropriately, and test the behavior of the code under Development and Run-Time Environments.  If there is still a problem, post the simplified code and some of us will do further tests.  


Bob Schor

Message 5 of 10

I just tested it in LabVIEW 2017. I wrote a really simple VI that creates a new Excel report, appends text, saves to disk, and disposes the report. Runs fine in the IDE. I built it into an EXE all by itself. Running the EXE returns error 7 at New (which I'm guessing the OP would see as well if he added error handling). I added the NI_Excel.class to the project and added it as always included in the EXE and built again, everything runs fine.


The reason you (Bob) probably don't see the issue is because you're using Excel-specific VIs in your app, which have static references to the NI_Excel.lvclass, which means app builder will automatically pull in the class when building the EXE. The basic report VIs (new, append text, save, close, etc.) call all the Excel stuff dynamically, so there is no static reference to the class that App Builder will find and include in the EXE. Which is why I suggest always explicitly adding them in the build spec, just in case you modify your app at some point and those static class references in your hierarchy suddenly go away.

Message 6 of 10

Cool!  Good explanation.  I certainly use lots of functions from the Excel Specific Palette, like Excel Easy Table and Excel Get Data -- are those what you mean that have static references to the Excel Class?  Ah, I think I get it -- the functions you use, New Report, Append Text, Save Report, Dispose Report, all are (what's the term when it calls a "Class Ancestor", like "Report", but not the specific Class, like "Excel Report"?)(well, whatever the OOP name is), while any function that starts with "Excel" is explicitly for the Excel Class, hence forces the Class into memory as if it had been in "Always Included".


Bob "Live and Learn" Schor

Message 7 of 10

@Bob_Schor wrote:

what's the term when it calls a "Class Ancestor", like "Report", but not the specific Class, like "Excel Report"?)(well, whatever the OOP name is),

The parent class is NI_report.lvclass. All of the VIs in the top-level Report Generation palette are members of that class. But they also have overrides that are members of the child classes (NI_Excel.lvclass, NI_Word.lvclass, etc.). But since we don't want the parent class VIs to be broken if the Report Generation Toolkit isn't installed, we call all the Word and Excel VIs dynamically from the parent class VIs. The disadvantage of this is that there are no static links to the Word and Excel VIs in the parent class methods. Which is why we have to do the Always Included trick when building an builder has no way of knowing about those dynamically called VIs.


Another trick I didn't mention can get around the extra app builder work by dropping an NI_Excel.lvclass constant in the top-level diagram of your application. That should be enough of a clue to app builder to include that class in the EXE build.

Message 8 of 10

One thing to be aware of when using the Report Generation Toolkit to generate Excel files (though I don't know that it's the issue here) is the change that Microsoft made to the Excel Workbook "SaveAs" method, and how it makes software developed with newer versions of Excel break on older versions. See here for details:


Message 9 of 10

Thank you all for your feedback. I added the NI class it works now. 

0 Kudos
Message 10 of 10