LabVIEW with Excel

[LabVIEW_Enthusiast]

Dear LabVIEW Community,

I need help saving real-time data from LabVIEW to an Excel spreadsheet, specifically by integrating it into an existing Excel template. I am unfamiliar with connecting Excel templates to LabVIEW and would appreciate guidance on this. The current Excel sheet already automates measurements and calculations. Using a template would ensure a new file is generated for each test, maintaining consistent output and measurement results. Any advice would be greatly appreciated. Thank you.

Thank you!

[GerdW]

Hi LabVIEW,

---

@LabVIEW_Enthusiast wrote:

I need help saving real-time data from LabVIEW to an Excel spreadsheet, specifically by integrating it into an existing Excel template.

---

Using the RGT functions (Report Generation Toolkit) you can fill Excel-based templates with your data.

There are some example VIs in the example finder.

Additionally Bob Schor made a good Excel example available, search for "revised Generate Excel Report" in the forum…

[PalanivelThiruvenkadam]

If you are familiar with LabVIEW ActiveX you can try developing your own drivers using Automation Open/If you do a web search you should be able to find few Modules as well.

https://forums.ni.com/t5/LabVIEW/Excel-Worksheet-delete/m-p/4013077#M1147610 

[Bob_Schor]

Some comments:

     Are you planning to write data directly into an Excel .xlsx file, (probably) with the Report Generation Toolkit?  How much, and how fast?  If you are logging data at high rates and/or for a long time, you might consider using something other than Excel for saving the primary data (binary I/O is much faster, and other I/O formats, such as TDMS, are also quite fast), with a separate "Analysis" program (when you are not using your PC for acquisition) to read the compact non-Spreadsheet data into LabVIEW variables and then opening up the RGT/Excel, formatting the data as convenient, and produce an Excel .xlsx file for the User to look at and "analyze with Excel".

     I think you mis-understand the notion of a Template.  When talking about the RGT, the Template is an Excel File with a specific format, and you need to write your RGT code to "fill in the Blanks" of this "Template" file.  If you save every file produced from this Template and name the output file "My Overwritten Data", then after processing 10 Data files with the same template, you will be left with one "My Overwritten Data", all the preceding 9 having been overwritten.

     A trick I use when using Templates is to make the Template have a WorkSheet (I called it "Parameters") that has (in the A column) where some (named) piece of data goes, and in the corresponding B column the Excel coordinate (e.g. "D2") where that piece of data goes.  So you build a Template "that looks the way you want the data to look" and package it with an additional (named) Page that at "write time" you can read and know what goes where.  [Note you can also specify, if you have multiple WorkSheets, the Sheet to use.]

     What you need to do is to make certain that the Output Files all have different File Names.  There are some LabVIEW functions that can help with this (including one that allows an "auto-incrementing suffix" to the file name.

     Do read and try out "Revised Generate Revised Excel Example" -- when I typed "Revised Excel " in the Board Search, this Exampled popped up.  It still works (at least with LabVIEW 2024).

Bob Schor

[Kyle97330]

I have a few cautions for you before you start on this, if you haven't yet.

I've had similar requests at my company in the past, and initially they worked, but would then later break at weird times.  If Excel is the only place you store data and then it has any kind of problem at all, it's not a great solution.

Examples of why it broke include:

• Excel wasn't open, and trying to open it took so long on certain slow PCs that it timed out and gave up.
• Certain users didn't have an Excel license associated properly with their account
• Excel version changes meant that code written on old computers wouldn't work on ones with newer Excel versions, and vice versa
• The Excel file has issues that LabVIEW can't handle on its own (locked for editing by another user, for example)

In the end, we no longer attempt to save directly to Excel in any new code, and whenever we rev up old code we try to see if there's a way to remove it.  Alternate options include:

• Saving data as a CSV or other file, then using standard Excel functionality (macros or the "Get Data -> From file" selection on the Data ribbon)
• Creating a 2D string array that is then changed to a single string delimited by tabs, and copying that string to the clipboard programatically for pasting into Excel (which would have a special sheet for the data to be pasted into that all other sheets would link to)
  • This includes a "re-copy" button in LabVIEW that re-runs the code that populates the clipboard, either from memory or from loading from a file.  This is mostly just in case someone accidentally copies something else into the clipboard (and either doesn't have or doesn't know how to use clipboard history)
• LabVIEW saves to a local database, and Excel pulls from that database.
  • This is the most robust and reliable method of the options, but also the most work to set up.

[Gregory]

Kyle has given good advice, and summarized why I have gone away from using Excel files with LabVIEW.

I also wanted to add that you can open a text file (like comma or tab delimited) in Excel from LabVIEW pretty easily using System Exec.vi. I would make a temporary copy of the file before opening it, so that you don't lock the actual file up with Excel. This can be a handy way to quickly make sure your program is logging data as expected.