Sharing a VISA instrument handle

[carlos_camargo]

Hi All,

I have an instrument (Agilent N6700) which can host up to four separate power supplies or loads.  These are referred to as channels of the instrument but are for all practical purposes separate instruments.  They all share the same VISA address, however.  I want to handle these as a class and would like each channel to be an independent instrument. 

I don't know how to handle initializing the instrument, sharing the handle between what will probably be DQMH cloned modules and eventually closing the handle. 

I suspect I want to use a composite class that puts in the shared instrument part as another class (handle opening and closing really) into the part that does most of the work.  I don't understand the details on how to do this.

Is the best approach to instead initialize the instrument handle separately and share it through a global, FGV/AE or something similar?  Then I could close the handle when all the clones report they're closed.  This I would know how to do.

How have other people handled this type of situation?   I'm open to any ideas.  Shared code would be appreciated.

 I have a lot of LV experience but very little to none in GOOP but have been learning a lot about it and DQMH recently.

[crossrulz · Accepted solution]

What I do is have a class for the mainframe (I will call this the "Device") and another class for the power supply module (I will call this the "Instrument").  Yes, I know the mainframe can work with loads too, but I have not used those so I will ignore them to keep this simple.

So my initialization routine starts with the device which can then launch however many instruments are defined by whatever (I am now using JSON and XML files).  I pass into the instrument initializations a DVR for the device that are then stored in the instrument private data.  The instruments can then use that DVR to send commands to the device to do whatever.  The DVR is useful since it is good for locking out other instruments from interrupting series of commands and/or queries.

In the end, I close the device and as part of that the related instruments are also closed.

[JÞB]

Don't do that!

I know I know, I know

ACTUALLY I LIKE DQMH.

But what you have here is several different instruments all using the same Visa resource and you cannot split the Visa resource by that dang user information property. 

I know,  it could be better!  Just use the resources as separate resources.... don't try CLASSING them as objects of an object.. one is a supply... another is a load.

Mediocre design your coders should not try walking around without face planting themselves. 

Been There.   Done That!  Don't go there...the T-Shirt ain't worth it. 

[carlos_camargo]

---

@crossrulz wrote:

So my initialization routine starts with the device which can then launch however many instruments are defined by whatever (I am now using JSON and XML files).  I pass into the instrument initializations a DVR for the device that are then stored in the instrument private data.  The instruments can then use that DVR to send commands to the device to do whatever.  The DVR is useful since it is good for locking out other instruments from interrupting series of commands and/or queries.

---

I understand what you are saying and a DVR sounds like a good approach but since they'd all recover simultaneously if a reconnect were needed.  How would I handle a reconnect (from say a dropped connection) in this architecture?

I don't understand how in this context DVR locks out other instruments from interrupting a series of commands and queries.  That's probably because I can't visualize how you wrap your code so the DVR provides this protection.  Please clarify.

[JÞB]

A DVR to a VISA resource provides no protection in the way that you mean.

VISA either has a handle to or can get a handle on the physical hardware that you need to chat with your device.       ...

[crossrulz]

---

@carlos_camargo wrote:

I don't understand how in this context DVR locks out other instruments from interrupting a series of commands and queries.  That's probably because I can't visualize how you wrap your code so the DVR provides this protection.  Please clarify.

---

You have to use a In Place Element Structure to access the DVR.  So inside of the structure, the VISA Write and/or VISA Read happen.  The structure will lock out anybody else from using the DVR, therefore protecting the transaction.

The way I did this was the device has a method that accepts a command and the module number.  The method can then format the full command with the desired command and the module number.

[JÞB]

So then VISA itself protects the serialness of

 VISA is an example of virtual interchange.   BUT!  You have just so many physical busses...you get just that many tries to get all the electrons moving about the few Al or Cu connections. 

[carlos_camargo]

---

@crossrulz wrote:

---

@carlos_camargo wrote:

I don't understand how in this context DVR locks out other instruments from interrupting a series of commands and queries.  That's probably because I can't visualize how you wrap your code so the DVR provides this protection.  Please clarify.

---

You have to use a In Place Element Structure to access the DVR.  So inside of the structure, the VISA Write and/or VISA Read happen.  The structure will lock out anybody else from using the DVR, therefore protecting the transaction.

---

Oh, now I see.  That makes a lot of sense.  I knew about using the in-place element structure to lock out other accesses to variables but didn't think about doing my instrument communications inside it.  DVRs are also something I've never touched before but did see them in the now-very-dated "Advanced Architectures" course which I only watched recently.  This overall seems like a great approach to me.  If there are no challengers, you'll win the coveted "Accepted Solution" award.

[JÞB]

We all learn something every d:) I'll take the solution!

Yeah, I can do that <I am a Knight<

[richjoh]

---

@carlos_camargo wrote:

Hi All,

I have an instrument (Agilent N6700) which can host up to four separate power supplies or loads.  These are referred to as channels of the instrument but are for all practical purposes separate instruments.  They all share the same VISA address, however.  I want to handle these as a class and would like each channel to be an independent instrument. 

I don't know how to handle initializing the instrument, sharing the handle between what will probably be DQMH cloned modules and eventually closing the handle. 

I suspect I want to use a composite class that puts in the shared instrument part as another class (handle opening and closing really) into the part that does most of the work.  I don't understand the details on how to do this.

Is the best approach to instead initialize the instrument handle separately and share it through a global, FGV/AE or something similar?  Then I could close the handle when all the clones report they're closed.  This I would know how to do.

---

Your making the problem harder than it appears. Use 1 VISA handle, with 1-4 channels in your "separate instruments" object. Your private data would be VISA handle and channel number 1-4. 

Visa handles are usually not instrument shared (meaning 2 instruments using same handle). Software code though may want to use the handle (occurring at the same time) in different parts of the LV code. For this use "VISA Lock Async VI" and "VISA Unlock Async VI". When the resource is locked, the simultaneous VISA Lock will wait till becomes available, execute your LV code, then unlock the resource.