Can Labview export to specific cells in excel in real time?

[randomguy77]

I've tried looking around for this, and haven't been able to find anything about exporting to specific cells. I have an excel document that I want to export all the collected data from the daq to. Since the excel file in formatted the data has to go into a specific spot in order for the data to be used correctly. If it matters I need it to start importing on sheet 3 cell A9. Is it possible to specify where you want the data to go, or will it always load it into a new workbook? 

[aputman]

Yes, you can export data to specific cells if you have the Report Generation Toolkit installed.  RGT is not necessary but, in that case, you will need a strong will, lots of Mountain Dew or coffee and a good knowledge of ActiveX.  I think there are other toolkits (not NI toolkits) that can accomplish this as well but I am not familiar with them.

Here is how to do it with RGT:

[randomguy77]

Thanks. Currently don't have access to that toolkit, but we may be upgrading soon so I'll wait and see what happens before going too crazy on it.

[Ben]

"... in real time?"

Excel is dog slow if you are doing one cell at a time so... your Real Time must be real slow.

Ben

[Bob_Schor]

---

@Ben wrote:

"... in real time?"

Excel is dog slow if you are doing one cell at a time so... your Real Time must be real slow.

---

While I agree with Ben that "real time" is probably the wrong choice of words here (I suspect the Poster meant "while data are being acquired"), several versions of LabVIEW ago I timed an application that used Excel -- a WorkSheet with about 160 columns (I'm guessing from memory) that contained 140 "Trial Parameters" and 20 "Trial Results", with a few hundred rows representing different Trials, was being used to control a Behavior Study.  The original LabVIEW 7 version of this code was dog-slow -- it took about a second to write cells in one line and read in the next line, but I re-wrote it in "more modern LabVIEW" (2012?) and wrote a test routine that "read a Trial, write dummy parameters, repeat until entire WorkSheet done".  I recall it did on the order of 25 Trials/second, meaning it took around 40 milliseconds to update one row (by writing new data -- we actually re-wrote the entire row) and read the next one.

This was plenty fast for us, as a Trial took 30-150 seconds ...

Bob Schor

[Ben]

---

@Bob_Schor wrote:

---

@Ben wrote:

"... in real time?"

Excel is dog slow if you are doing one cell at a time so... your Real Time must be real slow.

---

While I agree with Ben that "real time" is probably the wrong choice of words here (I suspect the Poster meant "while data are being acquired"), several versions of LabVIEW ago I timed an application that used Excel -- a WorkSheet with about 160 columns (I'm guessing from memory) that contained 140 "Trial Parameters" and 20 "Trial Results", with a few hundred rows representing different Trials, was being used to control a Behavior Study.  The original LabVIEW 7 version of this code was dog-slow -- it took about a second to write cells in one line and read in the next line, but I re-wrote it in "more modern LabVIEW" (2012?) and wrote a test routine that "read a Trial, write dummy parameters, repeat until entire WorkSheet done".  I recall it did on the order of 25 Trials/second, meaning it took around 40 milliseconds to update one row (by writing new data -- we actually re-wrote the entire row) and read the next one.

This was plenty fast for us, as a Trial took 30-150 seconds ...

Bob Schor

---

Apples and oranges?

Ben

[Bob_Schor]

Ben,

     You got me.  My test might not apply ...  Thanks for pointing this out.

Original Poster -- sorry about that!  I have to confess that I don't have a direct test of the speed of writing an individual cell as opposed to an entire row (my intuition says they'll be "same order of magnitude", but intuition is just a fancy word for "guess").  However, we also don't have a good idea of the data rates you need for "real time", nor the nature of your I/O process (I'm pretty sure that updating cells at random is significantly slower than appending rows to the end of the spreadsheet, but that's another "guess").

You might consider doing what I described in my earlier post -- write a tiny LabVIEW program that generates data similar to the data you are generating and writing it to Excel, and seeing how long it takes.  Try to mimic the writing pattern you anticipate.  See if it is fast enough for your needs.

Bob Schor

[Ben]

---

@Bob_Schor wrote:

...

---

Yup!

Or if speed is an issue, log as binary and use a post-processing step to convert to Excel....

Spoiler

A progress bar is highly recommended

Ben

[randomguy77]

Sorry for the confusion. Real time was a poor choice of words. All I want is after the data has been collected is for it to be exported to excel. The cells do not need to be updated as the data is collected. It can just be a one time dump at the end of the collection.

[Bob_Schor]

Aha!  Well, if you have the (wonderful) Report Generation Toolkit, go to the top of the Forum and in the Search bar, type the word "Revised", a space, and look what pops up.  Choose the Obvious One.  And if you do not have the Report Generation Toolkit, do this search anyway, as it will give you an impetus to get it.

Bob Schor

P.S. -- I trust the author of the above-referenced post ...