Error Saving File with MS Office Report Express VI

[ryancam]

Development PC:  Windows 10, LabView 2016, Office 365

Lab PC (where built program is deployed): Windows 10, LabView Runtime Engine, Office 2016

I have been using the MS Office Report Express VI for a while to import data generated by LabView 2016 into an Excel Template to create a report, and as such, I know that all of the runtime engines and necessary support to run a standalone LabView program are properly installed on the Lab PC.  As for the MS Office Report Express VI, I have already performed the patch for the known issue with LabView 2016 discussed here.  It was working fine, as intended, but recently, we had to change the version of Office on the Lab PC from Office 365 to Office 2016.  Since doing so, when the Report Generation Express VI runs, the LabView program crashes and closes with the pop up window attached to this post (I've also included the crash report).  If I then go to open the Excel Template location on the Lab PC, Office opens two instances of the file, one blank (the intended action if attempting to open the template), and one that is fully populated with the data from the most recent test, so in other words, a complete report.  This leads me to believe that the Express VI is having no trouble importing the data into the template, but is having trouble saving the file once it is done doing its thing.  However, I am pretty sure it is not an access issue to the location where a save is being attempted, because the program is able to write simple .csv files to this location without issue at an earlier point in operation of the program.  I have also attempted the save to the Lab PC desktop and experienced a similar issue.  Because this is an Express VI, I cannot go in and try to debug it (the subVI to save the file is working as intended on the development PC anyways), and I am not experienced with interpreting the crash reports.  Only thing I could think of is that the Build Specifications (screenshot of Always Included items with items unrelated to Office redacted) need to change to account for the version of Office on the Development PC being different than the Lab PC, but I am not sure what would need to change to accommodate that.  CT_Summary_Template.xltx is the template the program uses to generate the report.  Any suggestions on troubleshooting to try would be much appreciated.

[Bob_Schor]

Without seeing the code, it is difficult to "guess" where you made your mistake.  I've used Excel with LabVIEW for a half-dozen years, and for most of that time have never had to place anything specific in the Build Spec.  I've certainly never included a "data file" (such as CT_Summary_Template.xltx) in Always Included -- I kept it inside the Project and used relative paths to find it.

Bob Schor

[ryancam]

The excel file that I listed is an Excel Template (.xltx) that the Express VI calls for when setting it up, not necessarily a data file.  Am I understanding you correct that it just needs to be internally referenced, like I have it, not necessarily included explicitly?

What would you like me to provide here that would help with ideas for troubleshooting? I can't provide the full code due to proprietary reasons, and I can't provide a stripped down code that reproduces the issue (like I usually do on these forums) because the issue does not exist on my development machine.  I know that without the code, you cannot solve the issue any more than I can, but suggestions of why this crash may have occurred so I can gain direction of what to look into are what I am searching for with this post.  I would like to learn more effective troubleshooting methods, particularly with fatal crash errors such as this one.

[ryancam]

Not sure what the proper method of bringing an unresolved topic back to the top of the forum.  If re-posting like this is incorrect, then I apologize to the moderators.  https://forums.ni.com/t5/LabVIEW/Error-Saving-File-with-MS-Office-Report-Express-VI/m-p/3935837#M111...Slight updates to the body of the post have been made to include troubleshooting tried since the last post and additional clarification.

Development PC:  Windows 10, LabView 2016, Office 365

Lab PC (where built program is deployed): Windows 10, Office 2016

I have been using the MS Office Report Express VI for approximately 6 months to import data generated by a deployed LabView program into an Excel Template to create a report.  It was working as intended, but recently, we had to change the version of Office on the Lab PC from Office 365 to Office 2016.  Since doing so, when the program reaches the point where the Report Generation Express VI is called, the LabView program crashes and closes with the pop up window attached to this post (I've also included the crash report).  To re-iterate, nothing has changed with the LabView code, just the version of Office has changed since the program was successfully working last.  If I then go to open the Excel Template location on the Lab PC, Office opens two instances of the file, one blank (the intended action if attempting to open the template), and one that is fully populated with the data from the most recent test, so in other words, a complete report.  This leads me to believe that the Express VI is having no trouble importing the data into the template, but is having trouble saving the file once it is done doing its thing.  Based on my Googling, it appears that the error code is an access error, however, the program is able to write simple .csv files to the same location as the attempted save of the Excel report without issue at an earlier point in operation of the program, and the same crash occurs when attempting to save to the Lab PC desktop, which obviously shouldn't have any access permissions issues.  If I disable the Express VI, the program works as intended, so I know that the error is occurring at this point in the code.  This only occurs on the Lab PC where the deployed standalone code lives, I am not able to replicate the error on my PC.  I am looking for suggestions of maybe some PC settings that could be interfering with the Express VI saving the completed report. 

[Bob_Schor]

Here are some comments and suggestions (sort of "How I Do It" and things you might try):

• To be honest, I'm not 100% certain I understand the difference (to Excel) of an Excel Template (.xltx) and an Excel Spreadsheet (.xlsx).  I do not use Excel Templates -- if I want to read an Excel Spreadsheet (.xlsx) file, getting data from rows and columns, I wire the .xlsx file into the New/Create Report "Template" input.  If I'm "updating" a file (both reading and writing the same file), I need to wire the Path to the Save Report function, as well.  It has always worked for me.  You might try using a Spreadsheet File as your Input file and see if that makes any difference.
• You are correct that I don't need to do anything "fancy" with "Always Included" when using the RGT.  I've included a screen shot of my Build Spec for a Support routine that lets me view Excel Spreadsheet data (there are some waveforms saved to Excel).  You can see that only the Top Level VI, SUPPORT View ToF Data, is included in Source Files.
• When you build an Executable, you get a Data folder placed at the same level as your .EXE.  I use this as the starting location for any Data Files I need to read or write in my Application.  Here's a Snippet of code that I use to find the path to the Data Folder in my Executable:  The Green folder is an OpenG utility that creates the Folder if it is not present (you probably don't need this, I'm just being Super-Careful) (I think that such a function, to create a possibly-nested directory, may have been included in LabVIEW 2019 -- yes, there's now Create File and Containing Folders, and Create Directory Recursive).
• The trick to making this work is to also have a Data Folder as a "top-level Folder" in your Project Folder.  When you are in Development Mode, the Application Directory is the Project Folder, and when you are in Execution Mode, it is the folder you specify on the first page of the Build Spec (I like to use the Public Documents folder as the place LabVIEW puts its LabVIEW Builds folder, as all the Users can access it, but it is not, by default, "visible").
• Here's a technique that has worked for me when I've had a LabVIEW bug I couldn't find -- find a colleague, or a student, or (if all else fails) a Rubber Ducky, and show them the problem.  Try to walk them through the code, explaining what you are doing and some of how you are doing it.  It helps if they know something about computers and programming (it doesn't need to be LabVIEW, but if you can snag a LabVIEW Guru, so much the better).  What often happens is an "Aha!" Moment when the light bulb in your head suddenly turns on and you say "Oh, I forgot to wire ...".

Build Spec using RGT

I hope these suggestions and comments are helpful.

Bob Schor

[ryancam]

Ok, I will look into this solution, I realized that I should have included at least a screenshot of the file structure I have going in.  That is attached.

[GerdW]

Hi ryan,

Not sure what the proper method of bringing an unresolved topic back to the top of the forum.

The proper method is to post a new message in that thread!

(I moved your message #4 into this thread…)

[ryancam]

UPDATE: If I change the "Report Destination" from "Save to File" to "Open in Microsoft Office", the program will open a complete report as intended, so a workaround would be to open the report in Excel and have the operator manually save it to the proper location.  It appears that it is just the background save action that this express VI attempts to do that is causing the fatal crash.  This aligns with the error code being a permissions issue, but as I mentioned, the program is able to write a .csv to the same location earlier in program operation, so I know the LabView program has write permissions.  The same crash error also occurs when attempting to save to just the C: drive, which shouldn't have permissions issues.

I am getting more and more confident that this is some issue with Excel 2016 not being able to save when called in the background, and maybe not a LabView issue at all...

[BertMcMahan]

This may help your debugging. Right click on the ExpressVI and click "Open front panel". It'll convert the ExpressVI into a regular VI. You can't use the Express wizard stuff anymore, but it should work just the same. If you want to keep the Express stuff, try converting it into a regular VI for debugging purposes, then figure out which specific function call is causing you trouble. Once you've figured it out you can replace it with your ExpressVI.

Edit: Forgot to add, any chance there's a 32 vs 64 bit compatibility issue with your dev machine vs. the lab machine? I believe the new versions of Office are all 64 bit, and the Report Generation Toolkit only does 32 bit (if I remember right... they may have updated it).

[ryancam]

Both the dev PC and the lab PC are Windows 10 - 64 bit systems.  Also, the LabView deployed program was working on the Lab PC before the required change to Office 2016, so I am assuming that the Report Generation Toolkit is compatible with 64 bit systems.

As for converting the ExpressVI into a regular VI, This crash only occurs on the lab PC with the deployed program, so viewing the block diagram on the dev machine would just show a working VI.  I have run the program on the dev PC (both the standalone deployed version and within LabView) and did not have any errors.  This issue is isolated to just the Lab PC, and I'm not sure of a good way to debug a built program, as I can't do any debugging by viewing the block diagram.