LabVIEW does not release GPIB bus.

[SparkyOne]

I'll break this out into another discussion, later....getting off-topic.

But, No,  The LabVIEW code just keeps executing, even with the "WAIT".    The dataflow paradigm is sequence structure as follows:

1)  Enter test loop routine (65-point For Loop).

2)  VNA processes a STEP sweep on the Unit Under Test (takes approx. 40 seconds).

3)  Delay all other LabVIEW processing 42 seconds, until the VNA finishes gathering the required data.

4)  Pull the output data off the VNA registers

5)  Process the datapoints & test Calcualtions

6)  Display data on VI front panel for the Test operator

7)  Write results to the Test Log.

😎  Repeat step 2-7 (64 more times).

I'm open to suggestions as to how to approach the delay....but this method works.

[billko]

I may have put the WAIT in the wrong place, but it is the concept that is important.  Consult to manual to see where it actually goes.  I can't tell from the (necessarily) simplified code where it goes.

I guess it goes without saying that this method could expose race conditions otherwise masked by the sequence structure.

[cstorey]

---

@billko wrote:

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. 

---

While using status event registers (http://www.ni.com/white-paper/4629/en/) is  good advice and best practice for modern instruments that support IEEE 488.2 (*WAI or *OPC are 488.2 not SCPI which is instrument instructions only)  the 8510C is old (1988?) and had its own status register arrangement.   What would need to investigate what command asserts a register when complete.  Since the 8510C was ubiquitous I'm sure that info is out there and might be in examples he could find.

[billko]

---

@cstorey wrote:

---

@billko wrote:

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. 

---

While using status event registers (http://www.ni.com/white-paper/4629/en/) is  good advice and best practice for modern instruments that support IEEE 488.2 (*WAI or *OPC are 488.2 not SCPI which is instrument instructions only)  the 8510C is old (1988?) and had its own status register arrangement.   What would need to investigate what command asserts a register when complete.  Since the 8510C was ubiquitous I'm sure that info is out there and might be in examples he could find.

---

Well, the 8510C actually has a WAIT command - just to compound the confusion.  (It's not the *WAI command.)  This command should work as advertised.

[billko]

---

@billko wrote:

---

@cstorey wrote:

---

@billko wrote:

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. 

---

While using status event registers (http://www.ni.com/white-paper/4629/en/) is  good advice and best practice for modern instruments that support IEEE 488.2 (*WAI or *OPC are 488.2 not SCPI which is instrument instructions only)  the 8510C is old (1988?) and had its own status register arrangement.   What would need to investigate what command asserts a register when complete.  Since the 8510C was ubiquitous I'm sure that info is out there and might be in examples he could find.

---

Well, the 8510C actually has a WAIT command - just to compound the confusion.  (It's not the *WAI command.)  This command should work as advertised.

---

I admit that it was poorly worded, but in mentioning that it was "comparable to the SCPI command..." I was trying to highlight that this was similar to, but not actually, a SCPI command.  This equipment has its own command set.

[cstorey]

Hi Bill,

The 8510C WAIT command is for the front panel display, not for bus communications AFAIK.  (p339 - http://literature.cdn.keysight.com/litweb/pdf/08510-90281.pdf)  I think the display was so slow that you could tell the 8510C to redraw the curve with a new scale but the next command might come along and clear it before it was on screen.  Its been awhile since I used the 8510C.

I wasn't trying to confuse the issue any further by bringing 488/SCPI into the discussion.  It just one of those things I come across a lot with measurement instrument automation.  I'm glad that most of my lab is finally 488.2 these days and I only rarely have to go back and remember all the complexity of automating a 488.1 instrument (with unique command syntax, unique status registers, partial remote/programming support of many features, etc..).  It was frustrating to deal with the unique quirks of every instrument, and yeah often to only way to work around some were include specific time delays.  

The one thing I did like about older instruments is the detailed manuals!  Page 337-338 details how to use the SRQ features.  The command to read the 2 byte status register is "OUTPSTAT;" and it can be setup for some commands.  It could help with making it closer to true dataflow programming.  

[billko]

Here - http://www.keysight.com/upload/cmc_upload/All/08510-90280_8510KeyWords.pdf - we have the 8510C
Network Analyzer System Keyword Dictionary that the manual mentions.  On Page 797:

HP manuals were pretty sketchy (pardon the pun) back then, and their descriptions were murky sometimes.  But this clearly shows that the WAIT command functions as I had explained earlier.

edit: LOL, I didn't read your opinion of the HP manuals from back then.

[billko]

On the other hand... clearly, the LabVIEW drivers (as far as I can tell) never use this command!

[cstorey]

Hi Bill,

Nice to see full documentation of WAIT.  Knew it had to be there somewhere. When you find the right manual, it gives complete info at least! 😉  

But you still can't use the WAIT command like *OPC to halt the program execution until the instrument finishes processing.  The WAIT command only prevents the instrument from executing the next command it receives, its doesn't hold the GPIB bus like *OPC and wait for the command to complete (halt data flow) and then respond allowing dataflow to proceed to the next step in the program.  You simply write WAIT and the instrument waits but the bus is free to continue sending commands and dataflow moves on.  If you need to wait for a command to complete you will need to look at setting the SRQs manually to get that effect.

Without the instrument anymore I can't write and test to demonstrate.  I tried looking up vintage code for other vintage instruments where I've used SRQs to get the data...but code is LabVIEW 4...not worth the effort to retrieve.  Besides, I think the OP has moved on and we're closing the bar - have a good weekend!

[cstorey]

Hi Bill,

Nice to see full documentation of WAIT.  Knew it had to be there somewhere. When you find the right manual, it gives complete info at least! 😉  

But you still can't use the WAIT command like *OPC to halt the program execution until the instrument finishes processing.  The WAIT command only prevents the instrument from executing the next command it receives, its doesn't hold the GPIB bus like *OPC and wait for the command to complete (halt data flow) and then respond allowing dataflow to proceed to the next step in the program.  You simply write WAIT and the instrument waits but the bus is free to continue sending commands and dataflow moves on.  If you need to wait for a command to complete you will need to look at setting the SRQs manually to get that effect.

Without the instrument anymore I can't write and test to demonstrate.  I tried looking up vintage code for other vintage instruments where I've used SRQs to get the data...but code is LabVIEW 4...not worth the effort to retrieve.  Besides, I think the OP has moved on and we're closing the bar - have a good weekend!