Raport generation toolkit bolcks execution

[pawhan11]

Hello,

In my aplication I use Report Generation Toolkit to generate some excel files. It takes up to 10 minutes depending on file size. Proces takes no memory and procesor power but blocks my whole application.  All other loops just "freeze" all my DAQ task get buffer overflows and so on. 

Why is this happening? I have strong 4core processor and 8GB of RAM. I am using windows 7.

Best regards,

pawhan11

[sabri.jatlaoui]

Hi pawhan11,

Could you send us your code please?

Regards.

[Sam_Sharp]

Are you writing to the Excel files in the same loop as your DAQ task? I'm hoping the answer is No, but if it is Yes, then you should look at using the producer/consumer architecture so that your slow file writing doesn't happen in the same loop as your data acquisition. I'm also not a fan of using the RGT for saving measurement data (it's too easy for a user to interact with Excel and break your saving of data), you would be better off using a CSV / TDMS file and then generating your Excel report afterwards.

[Bob_Schor]

Many of us use the RGT without encountering the problems you report, suggesting your problem is probably embedded in your code, which we cannot see.  Attach your VI (or, if you have multiple VIs, compress the surrounding folder/Project and attach the .zip file -- do not attach a non-executable Image of your code) and we will try to locate the problem.

Bob Schor

[pawhan11]

Thanks for reply.

There is no problem with architecture - raport loop just blocks execution of all others without reason. Looks just like Excel blocks labview while raport is created...

I cannot share whole project. I have extracted part that is responsible for raport generation. I got rid of all typedef dependeicies so code can be executed.

[rolfk]

The Report Generation Toolkit is using the Office ActiveX interface. Unfortunately Active X servers are usually implemented as single threaded components, eventhough it's theoretically possible to implement them with fullmultithreading capabilities. Unless the Active X component supports full multithreading, LabVIEW has to invoke it always from the same thread, and the only one in LabVIEW that is guaranteed to be always single threaded is the UI thread.

Basically if you want to execute lengthy ActiveX operations you should never do that while a measurement is active, or you need to make sure that the measurement loop itself is entirely independent of UI thread interaction. That means among other things in the whole hierarchy of your measurement task:

1) No UI VI Server property and methods at all

2) No ActiveX calls

3) No Call Library Nodes set to not run reentrent

4) No calls to non-reentrant VIs that are shared with UI related tasks and could be somehow blocking while being called in such contex

5) No UI VIs (popups, dialogs, etc)

Basically your measurement VI has to be a self contained VI that only communicates through queues, notifiers or events with the rest of your application, and if you really know what you are doing also with non-reentrant intelligent global VIs (uninitialized shift registers), but non of the methods of such an intelligent global may ever block.

[pawhan11]

Thanks, this points me to right direction. 

I made simple test, I have added simple watchdog Thread, it is as single as possible, has no interface, no globals only the simplest NI functions.

When raport is generated it still hangs and watchdog expires.

The simplest solution would be to stop ACQ and WD while raport generates...  Or moving report generattion to another aplication

[Bob_Schor]

Rolf,

     Thanks for the explanation and description of the RGT and Excel.  I think we "get away with" using Excel (so far) without problems by several fortuitous design choices:

• We're running LabVIEW RT, and all of the time-critical stuff takes place in the RT Target which doesn't do anything with Excel.
• Our task executes a series of "Trials".  When the Experiment starts, we open the Workbook and read in two Worksheets.  Before each Trial, we read a single row from a third Worksheet, and after the Trial, we update that row.  When the Experiment ends, we save the Workbook and close Excel.  During the Trial (when data are being acquired and control is being exercised), no calls are made to the RGT.

     I've written other LabVIEW routines that use the RGT, but they tend to either be of the "Open Excel/Read Excel/Close Excel/Run rest of the program" or "Run Program and generate data/Open Excel/Write Excel/Close Excel/Exit Program" variety.

Bob Schor