why does report generator open all my excel files?

[CharlieM]

I think Bob's solution wins as it doesn't involve changing any code!

[Sam_Sharp]

Hi Mark,

I inherited an application that uses the RGT and I had the problem that the operator was checking the files while the application was running and this caused the RGT to be unable to write to the file and all of the subsequent log data was lost - whoops!

I also had the same problem of Excel flashing up while the application was running (and I didn't think this was ideal...) and I did find a solution but it wasn't pretty!

Warning/Disclaimer: I really don't recommend modifying these files as changes made will be lost if someone else builds the code or if you need to reinstall LabVIEW! These VIs were locked - and probably for a good reason. If you're going to modify them - at least back them up beforehand!

1) Get the RGT to always open a new instance of Excel - this solved my problem of the operator maximising the Excel window and the RGT being unable to write to it.

In C:\Program Files (x86)\National Instruments\LabVIEW 2011\vi.lib\Utility\NIReport.llb\Excel\new report subVI.vi:

2) When it does open Excel, get it to open it minimised (I think this prevents it from even showing in the taskbar at all!)

In C:\Program Files (x86)\National Instruments\LabVIEW 2011\vi.lib\addons\_office\_exclsub.llb\Excel_Open.vi:

As you can see - in the original VI, the VI ignores the Window State input in this case. I havn't tested the other cases but for reference, the newly wired boolean is set to the following in the remaining cases in the bottom left diagram:

maximised = true

minimised = false

normal = true

no change = false

All of the other cases are unchanged.

3) I also used the Lock/Unlock File VIs to prevent the operator from modifying the file until the test had finished (otherwise LabVIEW might not be able to get a handle on the file)

I'm not sure if this was a bug in the RGT or if the fact that what I did to fix it works is just a fluke.

Lesson learnt: Don't use the RGT for logging data. Instead, I would log the raw data to CSV, TDMS, Binary (etc.) and then if you need to make a snazzy multi-sheet report at the end then use the RGT toolkit to import the data and produce your report at the end of the test/cycle etc.

[mark-san]

Hi Sam,

Thanks for your thoroughly detailed and excellent comments - sounds like you encountered very similar issues with your application.

The big concern we have is that since there are several different operators who will be exposed to this app (of varying skill/knowledge levels), we didn't want to run the risk of Excel being tampered with, thereby causing RGT to quit logging (same as your 'whoops!'). Also we need the app to basically run 24/7, and perhaps periodically view and/or process the (20MB ~ 30MB) log files into a more digestible format.

I will need to study your solution carefully, but it looks like if we can basically 'hide' the vulnerable XL files from casual access, that might work. But, as you say, it probably behooves us to get away from streaming with RGT and instead use TDMS, followed by an off-line app that takes the TDMS log file (or even a snapshot/read-only of one that is actively logging) and then converts it, with RGT even, to the desired Excel format - and with no worries/hassle.

Well done!

Mark

[deppSu]

Yes, you can open a TDMS file as read-only while it is being written in same process/program or in different programs.