VISA resource vs. string

[Mikael_Garcia]

I know that it is possible to convert a string to a VISA resource (see image below). However, in a program where you will have many sub-VI's that talk to the same resource, it is possible to pass only the string, and do the conversion inside the sub-VI's, or does the resource type include extra information (reference ID etc) and one has to pass the VISA resource all the time to the subVI's?

I just want to add that I always perform a VISA open at the start of a program and a VISA close at the end even though it might not be needed in the newer versions of LabVIEW.

Thanks!

[santo_13 · Accepted solution]

You can pass the VISA resource as a string to the subVIs and convert it internally. As far as I have used VISA resources, they are forgiving if you use string and haven't come across a functional limitation of using string instead of a VISA resource data type. The advantage of using the VISA resource type is you can directly wire them to property nodes and access additional information from the VISA manager.

Initializing VISA resources once and closing at the very end is the correct way to implement.

[crossrulz]

I don't even do the conversion.  I just wire the string directly into the VISA Open or the VISA Configure Serial Port and have never had an issue.  You will see a coercion dot, but I don't consider that one a big deal.

As already stated, you really should only open the session once, pass that resource around, and then close it when you are finally done with it.

[Mikael_Garcia]

Thank you for the heads-up on this.

Below is an image that illustrates what I am asking about here. The VISA session to instrument A is opened at the start of the program and closed at the end. And in-between there is a set of sub-Vi's that call instrument A using a string as the only reference to do some measurements. Inside the instrument A sub-VI there is a conversion from string to VISA resource. I was worried about memory issues (multiple sessions) or any other low level problems that could occur. It sounds good that it will work fine.

Granted, it is not ideal to pass only the string but if this way works it will make it easier to modify legacy code.

Thanks again!

[santo_13 · Accepted solution]

I would not directly use the VISA resource name, instead use the opened VISA reference as shown below (I would not care about the coercion dot here)

[Mikael_Garcia]

Yes, I agree, that is the ideal situation and how I would do it normally too. The red coercion dot, while I don't like it due to OCD..., is no big deal. I know you can bypass the force type and wire a string directly to a VISA VI. 

However, the reason I asked this question is not about the best way, it is if it would work or not with memory etc. The background is this: I have legacy code that is written for instruments with GPIB control (not VISA). The reference to those instruments is simply the GPIB address which in my case happens to be a string. Thus, in my application it is easier if I can pass a string even to a newer instrument that is using VISA over LAN or USB.

[santo_13]

GPIB - of course passing the VISA resource string is good enough, I am not confident about the LXI or USB protocols under VISA.

[crossrulz]

---

@Mikael_Garcia wrote:

However, the reason I asked this question is not about the best way, it is if it would work or not with memory etc. The background is this: I have legacy code that is written for instruments with GPIB control (not VISA). The reference to those instruments is simply the GPIB address which in my case happens to be a string. Thus, in my application it is easier if I can pass a string even to a newer instrument that is using VISA over LAN or USB.

---

You may consider using something like an Action Engine to maintain your VISA session including opening, write and read, and close.  This would be a way to making it "wireless".

[rolfk]

One potential problem is that a VISA Resource is indeed more than just a glorified string. It also stores the underlying API handle (a ViSession datatype). If LabVIEW encounters a VISA Resource which contains an invalid ViSession (or has to convert a string into a VISA Resource) it will basically do the equivalent of VISA Open to create a new valid session. There might be some lookup mechanism that tries to reuse an already opened session for the same resource name but it may not be always guaranteed to do that.

For most applications this probably won't make a big difference since VISA sessions by default also fall under the standard LabVIEW refnum cleanup regime, where once the top level VI in whose hierarchy the refnum was created goes idle, the refnum is automatically collected and disposed of.

The only thing I could think where this could go wrong is if you refer to serial ports, USB resources and potentially PXI/VXI resources and close the actual session but not those intrinsically created sessions while your application keeps running and then try to open that hardware resource from a different program. Those intrinsic opened sessions might keep the resource reserved and locked and unavailable to other processes until you terminate the first application and the automatic cleanup disposes of those sessions too.

[Mikael_Garcia]

Excellent answer! I think it is best not to take any short-cuts here and do the right thing, to pass on the resource as a resource type. A bit more work up front but it will be worth it in the long run!

Thanks again all!!