poor performance with report generation toolkit

[rfriedr1]

Hello everybody,

I want to use the "report generation toolkit for Office" to log measured data from my LabView application to Excel,
because the toolkit provides a very good possibility to store the data in a good structured way to Excel, "ready to use"
for any further computations.

To do this I have to access Excel a lot of times.

That causes a high usage of system perfomance with a CPU-usage of 80-90% during datalogging (PC: AthlonXP 2200+)

Is there a way to reduce this high amount of system-usage or is the report generation tollkit not designed to log data in the
way I want to do it? Is there a better way to store data in a usefull synoptic way (different text colors...)?

Thanks for help.

Best regards.

Ronny

[pawel]

Hi Ronny

I think that Report Generation Toolkit has been designed to generate reports, not the on-line logging. It is using ActiveX to talk to Excel and it will be always slow and consume resources.

I would not reccomend using report generation for this. Instead you might want to log data to a text file, and in the end create a report. The toolkit will work perfect than.

If you really need to use toolkit for an on-line datalogging, you might check if you do not open and close the same document many times.

hope it help
Pawel

[rfriedr1]

Thanks for answering,

during data logging I keep the Excelfile open and write data to it. So there is only the datatransfer that uses that much resources.

But you are right: I should use only text files for logging and create the excel-file afterwards.

But I think its a pity that there is no way to use Excel in a faster way.

Thanks.

Perhaps anyone has an idea to use Excel in a faster way during logging.

Regards.

Ronny

[m3nth]

Logging straight to Excel sounds ludicrous... no wonder it's going slow. Why do you want to log directly to Excel? What advantages do you perceive that to have over logging to disk and then converting the data into an Excel report? And if you didn't want anything fancy in your spreadsheet anyway, you could always just log to a tab- or comma-separated data file--> No ActiveX, No Excel, data logged straight to disk--> No delays or high processor usage. Then these files would open directly in Excel and be automatically imported (columnized).

[rfriedr1]

You are completely right in the point of saving system resources.
Otherwise, why logging to a text-file and the creating an Excel-file when you can log directly to Excel.

An advantage of Excel-logging is that you can see whats going on during logging. I wanted to separate the data to different Excel-sheets to have a good overview to the logged data (creating plots during logging...)
Datalogging is perfomed during a long period of time and it would be nice to have always a look to the logged data as they are stored later.

I know this from an Visual C++ program that uses logging by Excel and it's working fine.

But, anyway, it makes no seens to spend that much system resources only by logging files, thats clear so far.

So I have to write a special VI that will show the logged data in a similar style Excel would do.

Thanks for you help. It's always nice and helpful to post questions in this forum 🙂

Best regards.

Ronny

[m3nth]

In that case (using separate worksheets for example) it still seems like you would be able to do what you want and have it pulled up in Excel. What about making an external program that can format all the data on disk to a spreadsheet even while you're still logging... it could take a 'snapshot' of the logged data, put it into Excel the way you want and the main program would keep on logging. Any information (separation of data sets etc) that would be used normally to start a new worksheet in Excel could also be written to disk as a separator or worksheet name that the report generator could read. The report generator could also launch Excel so it would be a one step process.

[rfriedr1]

Yes, that's exactly what im doing now.

But I'm interested in a look behind LabView. Why is a Visual C++ program that much faster than LabView with Excel. I think C++ is working with an ActiveX connection to Excel too, isn't it?

Thanks.

Ronny

[m3nth]

I see... so really you see a performance difference with a known VC++ program and trying to implement the same thing in LabVIEW. That seems entirely possible that you would see a performance difference, but not in my opinion because LabVIEW is less optimized. Probably the only way you could really find out what's going on is to look at the VC++ code and re-duplicate it--something you can't do obviously if you don't have the VC++ code.

I wonder if there is a solution for you somewhere in the middle by caching data either internally or to disk, then spawning a parallel process to transfer the cached data to Excel. That seems likely to improve your processor usage by minimizing the amount of transfers that take place, at the cost of not having the latest data in Excel if you opened your file--you would always have a chance that there are between 1 and n data points not logged yet, where n is the size of your cached data set.

Also, when logging to Excel, are you doing this immediately after your DAQ routine in the same loop? Have you tried running a queue to process data separately to Excel so that your DAQ loop puts data in the queue and another loop processes it and sends it to Excel? If you had this type of program architecture and performance was still poor it would be very easy to modify it like I said earlier... to test and see if caching the data would help improve performance. Parallel loops also seem to hold some possibility for not interfering with your DAQ operations to the point that they won't work right due to time delays.

[rfriedr1]

First I used logging directly after DAQ without queues, because it was a first test.
I think it makes no sense to follow up the idea of Excel logging.
The only way is to log to textfiles and after logging create an Excel-file for further computantions or whatever...

Thanks for help!!!

Regards.

Ronny