Export Runtime Report to Excel

[bfrise]

I am working on my PC making a VI for an HMI. My PC is windows 10, 64-bit with excel 2019/21. The HMI is windows 7, 32-bit with excel 2013. So far, when I export my VI as a runtime executable, everything seems to work except for saving my test data. I am using the report generation tool to do this and it doesn't work on the HMI. On my laptop, I did try to install excel 2013 and when I tried to export the data, it gave me Error -41106. Is there a way to fix it, either by making it cross compatible where it works on 2013 and new versions, or just 2013. 

I checked the forums for people with similar problems, but was unable to find one with a solution or explanation that made sense. Also would active x or something else be the cause of this, or how my test data is being saved/file name? When I tried to run it on the HMI, I think excel opened but did not save a file or anything from what I can tell. I attached an image of what the block diagram for the save file looks like. I am also LabVIEW 2020 SP1, 32-bit.

[GerdW]

Hi bfrise,

Microsoft in its infinite wisdom may have decided to change the Save/SaveAs methods between those Excel versions.

My recommendation: try to stay at exactly one Office version an all your computers…

Other recommendation: check which ActiveX method is failing (by debugging). Then build version-specific VIs to handle the different Office versions…

[rolfk]

---

@GerdW wrote:

Hi bfrise,

Microsoft in its infinite wisdom may have decided to change the Save/SaveAs methods between those Excel versions.

Microsoft not only might have done that but for sure did. Almost with every new Office version. It would have been possible for NI to work around that problem if they would do dynamic dispatch by Name instead of methodID. But at that time it was not common to chance once released function signatures. And later the ActiveX interface used here was declared legacy by Microsoft and NI did not change anything about it. Nowadays ActiveX development is not even possible with recent Visual Studio versions so it’s definitely not going to change anymore.

[bfrise]

"Other recommendation: check which ActiveX method is failing (by debugging). Then build version-specific VIs to handle the different Office versions…"

Is there a page or place for that information on how to do that? To inspect ActiveX methods and either fix or replace them?

[rolfk]

---

@bfrise wrote:

Is there a page or place for that information on how to do that? To inspect ActiveX methods and either fix or replace them?

---

No, but the principle is "simple". Build for each version a variant of that VI and then another one that determines what ActiveX server version you communicate with and then loads the according VI by calling it through VI server.

The nasty thing is that you need to have the according version of your Office application installed on the development system in order to compile the VI to that version, then save it somewhere safe.

Repeat and rinse for every Office application version you want to support.

Most likely you will end up telling your users to simply make sure to use the single version you built your app with rather than (re)installing each individual version on your development system one by one.

[bfrise]

Do you have an example on how to do that? I do not understand how to do that.  Or is there a different way on making an excel worksheet with different sheets/pages

[rolfk]

Are you even prepared to install Excel in all the versions you want to support on your development machine? If this already out of question, there is no way to do this.

As you can't have multiple Office versions installed alongside this means that you need a complete development installation of Windows, LabVIEW and the according Excel version. Either as separate VMs or sequentially by installing and uninstalling each Excel version.

[bfrise]

I already have the versions of excel installed, both 2013 and the most recent version (I think 2021 ms365). I mainly need to prepare the VI for office 2013 since that is what the HMI uses.

[rolfk]

On the same machine?

Anyhow the principle is fairly simple. Make sure LabVIEW uses the right version of Excel. Open the Save VI and make it fix any broken arrows of they exist. Save that VI with the version postfix of Excel that you used. E.g. _2013.

Make LabVIEW use the next version, open the Save VI now and make it have no error again. save it with the according postfix e.g. _2018

Once you have a Vi for every version  you want to support, open the Save VI again, throw all the nodes away and put instead a node on there that queries the version number of the Excel server on that ActiveX refnum. Construct a path that uses the current VIs path and the correct postfix from the queried version and then load the correct VI through the VI Server, call it and then close the refnum. Save this Vi in the same folder as all the others with an according postfix and call this from now.

[bfrise]

My apologies, I am still lost on exactly what to do (I have not done this before). What do you mean by the "Save VI"? And where would I find it to change the excel version number? On the original picture I posted of the save configuration, it's part of the main VI with all the controls/LabVIEW stuff, not a standalone VI.

Do you happen to have pictures or examples? I