LabVIEW does not release GPIB bus.

[SparkyOne]

Ok, here is a simplified VI, which exhibits the same issues as my larger test program.

Quick note, the two LEDs do not function quite right.   I know this, and it doesn't really matter, as the problem is outside the main While Loop.

     1)  "Test Running" should indicate True when the large For Loop is running, then go False when it completes.

     2)  "Test Ready" should mimic the True-False case structure that contains the For Loop.

So with those two conditions set, my issues are outside the While Loop.   Basically, here is the sequence of events:

     1)  Run the VI

     2)  VI idles until the Test Operator clicks the Test Mode button.

     3)  VI enters True-False case structure and executes the For Loop 65 times @ 45 seconds each.  I have changed the structure to only delay 4 seconds each loop....to speed-up troubleshooting this.

      4)  For Loop completes, and the VI Idles....either waiting for another Test Sequence, or for the Close VI.

      5)  Close VI initiates

      6)   VI exits the While Loop, resets the VNA to a 2s Sweep (not working for some reason), and closes the Connection to the VNA.

In the past, this sequence would release the VNA, but I confirmed this morning that it is staying in REMOTE mode.....it should be returning to LOCAL mode.   I am looking into everything that was posted last night, to see if I can find a fix.......now that I know this is the issue.

[billko]

I can see some stuff right away that you can optimize (that don't really have anything to do with your problem, but should be addressed anyway).  Instead of waiting a hardcoded amount of time for your sweep to finish, there is a command called "WAIT" that is comparable to the SCPI command "*OPC?" in function in that it will wait until the command just before it completes before executing the one immediately after it.  Applied after your "STEP" command, it will wait exactly long enough to complete the sweep; no more, no less.  You probably programmed your delay for a worst-case delay where you know absolutely for sure that it will complete.  but imagine if you could shave two or three seconds off of each time through the loop.  With 65 steps, you could save maybe two or three MINUTES of test time.

And I thought you said you didn't use VISA to communicate?  Sure looks like VISA to me.  😉

[SparkyOne · Accepted solution]

Guys, I'm so sorry for bothering all of you.     I didn't plug all of this together last night, before sending-out the message.

Apparently, the Techs have been having this issue since the VNA went in for calibration.   I was not aware of this fact, but the VNA that I developed this with failed calibration, and they replaced it with one out of our "common" stock.    Anyway, the VNA I developed this LAbVIEW program with was a genuine 8510C from the factory.    What they replaced mine with is a converted 8510B.

So that said, cstorey is correct, pressing the LOCAL key on the front panel unlocks everything.   BUT, I was still looking for a more elegant solution....just didn't know the question to ask until now.   Here's what I found:

https://forums.ni.com/t5/LabVIEW/How-to-stop-GPIB-Instrument-lock/td-p/1128804

I added the function on the VISA Advanced palette named VISA GPIB Control REN in-line with my closing, using mode 6 "Go to Local".

mode specifies the state of the REN line and optionally the device remote/local state. This input accepts the following values.

0	Deassert REN—Deassert REN line.
1	Assert REN—Assert REN line.
2	Go To Local; Deassert REN—Send the Go To Local (GTL) command and deassert REN line.
3	Assert REN; Address Device—Assert REN line and address device.
4	Local Lockout (Addressed Devices)—Send LLO to any devices that are addressed to listen.
5	Local Lockout (This Device)—Address this device and send it LLO, putting it in RWLS.
6	Go To Local—Send the Go To Local command (GTL) to this device.

Everything is working as expected now, and I corrected a few other things in the process.    I have uploaded my modified structure.   Thanks for letting me talk through this....  🙂

[Blokk]

What I do not understand, why you do not use the "official" drivers which you can download from ni.com? I guess the VI which I mentioned earlier would do the same (go to local)?

edit: i had a look at that VI again...i am not sure if that can do the same as a second thought, the help info there is a bit vague for me...

[SparkyOne]

billko,

Will the "WAIT" command keep all other parts of the LabVIEW VI from executing, while the VNA is gathering its data?   

Blokk,

The "official" driver that you posted, sends the whole System bus to LOCAL....and does not release the VNA.    I did give that function a try, just did not post the results.   sorry....

[Blokk]

---

SparkyOne wrote:

Blokk,

The "official" driver that you posted, sends the whole System bus to LOCAL....and does not release the VNA.    I did give that function a try, just did not post the results.   sorry....

---

Ok, clear. But it is good that advanced palette function works for you!

[JÞB]

There is no replacement for "Diet Mode"  (Lo-Cal)  If you think about it, it makes some sort of sense.

WHERE are you when you need to hit the "Local" button?  Yep, right in front of the device you want to control from the front panel.

Spoiler

I did not mention anything that would get Lili to PM me.  (inside joke)

[billko]

---

@SparkyOne wrote:

billko,

Will the "WAIT" command keep all other parts of the LabVIEW VI from executing, while the VNA is gathering its data?   

Blokk,

The "official" driver that you posted, sends the whole System bus to LOCAL....and does not release the VNA.    I did give that function a try, just did not post the results.   sorry....

---

That question will have to be answered by dataflow paradigm.  By looking at the simplified code, it would exactly replace your hardcoded wait in both function and dataflow.  Technically, I guess it would allow a bit more freedom for LabVIEW to execute the way it wants to in that you could then be rid of the sequence structure, but nothing really interestingly different would happen, except you'd save some test time.  😉

[SparkyOne]

Yea...   Should have stepped-back and asked those questions yesterday....

but you know, the whole "AAAAAHHHHHH!!!!   FIRE!!!!!   The Test Set is not working like it used to!!!!!!!"   kinda caught my attention first....

You'd think I'd remember that, being that I work with these devices on a daily basis?    So, I'm going to stop throwing stones in this glass house, as both the Engineers and the Technicians forgot about the Lo-Cal diet.

[JÞB]

---

@SparkyOne wrote:

Yea...   Should have stepped-back and asked those questions yesterday....

but you know, the whole "AAAAAHHHHHH!!!!   FIRE!!!!!   The Test Set is not working like it used to!!!!!!!"   kinda caught my attention first....

You'd think I'd remember that, being that I work with these devices on a daily basis?    So, I'm going to stop throwing stones in this glass house, as both the Engineers and the Technicians forgot about the Lo-Cal diet.

---

AAAAAHHHHH!!!!- is probably best response I ever got

Ready..... Fire, Aim!

Most of us have made similar mistakes-  You do not want to see some of mine