"Dispose Report" for Excel is leaving orphaned application processes running in background

[mbayc]

I'm using the Report Generation Toolkit VIs to use excel to record and save on going collected data. I have multiple instances of this VI that all need to interact with excel at times that are not synced among each other. To handle this I use individual templates (though i don't think that's necessary), and overall things worked fine. However there are times that having multiple VI instances working with excel are still creating a conflict that leads to an error; in particular when one tries to start a new document while another is saving one. To overcome this i dug down into the sub-VIs of the "New Report" VI and added "T" to the option to use different instances of the "Automation Open" VI that creates the Excel application reference. Shown below.

This solved my Excel conflict with multiple VIs running data at the same time.

However, a new problem now exists. Even when the excel files are closed after each data set, labview or excel is leaving open a background process and these build up to dozens of orphaned processes that eventually eat all the memory.

The excel file and application are closed properly, but this remnant process is still there and i don't know how to get rid of it. When i exit the VI these processes go away, but i can find no way to look for them or force them to close while the application is running.

Digging into the "Dispose Report" VI, I found that "Close Application" is set to false by default and is not carried back to the top by a control, so i manually changed the close application option to "T". However, the orphan Excel processes are still showing up.

I cannot post my main VI, it's way too involved but it follows the correct design pattern of disposing of every report created using the given report generation VIs.

Does anyone know what is being missed in closing all excel references, or have a way i can check for these orphaned processes and clear them periodically? They really only become a problem when the computer runs out of memory, which is a lot of files, so i can deal with some waste if it's cleared once a day or so.

[Ben]

---

@mbayc wrote:

..."T" to the option to use different instances of the "Automation Open" VI that creates the Excel application reference. Shown below.

...

---

Are you closing the refs returned by the "Automation Open"?

Ben

[mbayc]

As far as i can tell i am, and the application and file windows always close and are removed from the "applications" section of the task manager, but this background process then appears in its place. Here is a snap shot of the opening and disposing reference probed and they are the same.

[Ben]

Hmmm....

LV does keep allocated resources open ( to prevent issues with attempts to use a closed ref and bad things happening) until the top-level-VI goes idle and it is safe.

Not knowing a better way you may want to consider a "Pool" of Excel references that you can re-cycle instead of creating new ones.

Waving my hands...

Open 10 at start up and cache them along with an associated flag indicating if they are used. When you WOULD have opened an instance check the cache of Excel refs to find one that is not being used. Only after you discover all instances are being used, create  a new one.

When you WOULD HAVE closed, mark the instance as available.

That is the best I can do off-hand.

Ben

[aputman]

See that VI with the While loop around an Excel icon inside the New Report VI? 

If I understand your question, I think this VI was an attempt to work around the error that you are seeing.  It will try to open Excel 10 times and if the error still appears, it will display the error and give up.  I wonder if changing that retry value to a larger number would help your situation (assuming you remove the True constant from the Automation Open). 

[mbayc]

That's a good thought, i don't actually need a new excel instance every time i create a new file. I can try closing the report and individual file references, but keep reusing the same application reference within the same top level VI instance and that should keep the conflicts from happening and not continue to add orphaned application processes.

I'll give that a try and return with the outcome.

by the way, how would one check if a reference was already being used or not in your approach? For just holding 1 excel app instance per VI instance i wouldn't need to do that, but to add to my toolbox, I'm curious how you would implement that part of what you described.

Thanks

[mbayc]

Hi aputman, are you saying this might eliminate the conflict that was my original problem when using only 1 excel application instance, leading me to move to using a new app instance for each new report? In which case i can turn new instances back to false and not have so many orphaned references. I can give that a try too.

[billko]

I little off-topic, but very important.  You didn't save that modified VI to the toolkit, did you?  That would be a very bad thing.  if you did, you just made your toolkit installation incompatible with everyone else's, and you've made your code non-portable.

[mbayc]

Hi Bill, I appreciate the feedback. I did save to the toolkit while i'm figuring things out. I'm aware of the consequences that brings and can revert my edits. I didn't see a quick way to do otherwise.

The "new report sub-VI" that i have to edit to set the automation open VI to use a new instance doesn't allow me to save as.

and if i copy paste everything it is broken because it unbundles a class which it won't allow in stand alone VIs.

If you have a recommended approach to editing sub-vis in that kind of state please let me know. When i get to the final solution i do want to put my standard VIs back into their universal state.

I usually build an installer and executable to distribute the VI for use. I don't know off the top of my head but i guess i could tell it to include my version of the toolkit if i have to keep my custom edits in the original. 

[mbayc]

CONCLUSION:

I was not able to manage the excel application reference and instance separately from the RGToolkit report VIs. I can create an instance of the excel application by itself, but i cannot explicitly make the RGT "New Report" VI use any given instance of excel application and conflicts were still happening in the executable form.

However, I was able to narrow down my conflict errors to be happening always at the save point so I was able to revert all of the toolkit VIs back to their original form (which means the "use new instance" option for the "Automation open" is left at the default "F") then add a retry loop that looks for the "ready" property of the application to be "T" before trying to save and also has an error catch loop for the error code I've identified "-2146827284", in which it will clear it and try again for a set period of time before accepting the error. I'm not sure the waiting for "ready" is doing anything, but until i have time to bother sussing that out, i'm going to leave it.

This seems to be working under the conditions that I had problems before.