Which references need to be "Closed"?

[rolfk]

Ben,

---

@Ben wrote:

And by the way;

It is a bad Idea to to close a VISA session in if you are using VISA 2.10 or earlier.

For that matter, closing a VISA references is now a NO-OP.

---

I'm not sure about the problem of closing VISA sessions in older VISA versions. My memory doesn't remember the issues.

But closing a VISA reference is NOT a NOP. For instance for the ASRL resource it also frees the associated port. This is important if you want to access a serial port from a different application without having to exit LabVIEW (or your LabVIEW executable) after having used that port in your LabVIEW program. The same would apply for TCP/IP VISA resources and I'm quite sure for GPIB as well.

Rolf Kalbermatter

[Darren]

Yeah, I'm gonna post to a 12-year old thread. So what? 😛

My feelings on reference closing have evolved somewhat since 2006. In my Brainless LabVIEW presentation, I talk about which references really need to be closed, and which ones are fine to let LabVIEW close for you. For reference (ha!), here are the applicable slides from that presentation:

[Matt7]

Reviewed your presentation and it made me think a lot and helped immensely with the project I am working on, so thank you very much.. So this post has 3 elements. 1) Did I do it right?, 2) Example for others (it does work), 3) Labview idea suggestion. The vi purpose is to copy ranges of cell from 2 separate excel source spreadsheets into a 3rd excel destination spreadsheet with 3 tabs. I found examples of within spreadsheet copies, but not workbook to workbook. One of the sources is the actual test result, the other is specification for the several products we test, the destination is a template to graph and analyze the results against the spec.

I attached both the VI and the VBA I based it off of (I've been programming Labview for a year, but Basic for 40 years). I used the error paths to control execution flow. I tried to keep it laid out fairly logical, and knowing that you need to follow the yellow line helps. I thought about paralleling the workbook.opens, but worried that somehow excel wouldn't deal with 3 concurrent file operations well.

1) So did I close all the references properly? Are any closures no-ops? Did I properly apply the principal of avoiding railroad tracks? If I understand properly how the references work, I believe it's correct, but much about references is still a black box to me (and apparently others as well). If anything is incorrect, then why?

2) I hope this is a good example, because people like myself who aren't familiar with all the details of Active X need a good example showing exactly what should be closed. Getting off the rails was actually helpful in keeping track of all the reference creations (so thanks for that suggestion), and I actually spotted one that wasn't closed in the example I ripped (the references created by Workbook.Sheets). And btw, what is with the sheets.Item NOT creating a reference like all the other ActiveX objects, requiring variant to data. And is the reference coming out of Variant to Data created by Labview and not active X, so do I need to close it?

3) My Labview suggestion is this: Why do I have to manually close any of these? Isn't this exactly the type of thing computers and compilers can excel at, whereas humans do poorly? I actually admire the VBA where you can get away without using the reference at all, although I suppose it would be a bit more elegant to have it so I can close the files without making a separate file name string. So my thought is that the Labview compiler should be keeping a list of all the Active X reference creations along with the parent/child dependencies. When the sub-vi exits, any references that are not routed out of the sub-vi are no longer needed and should be closed child to parent. Any reference that do exit are counted as being creating within the calling vi. It seems to me that this is bug of the Labview compiler, depending on humans to manually keep track of things better done by the compiler. All these closures adds a lot of needless clutter (if the compiler would clean it up for us), and we could still keep the ones in the loop if worried about execution speed. Actually, since the compiler knows that they don't leave the loop it could clean those up as we go too.

Thanks for the help.