Talking to two devices, at the same time.

[MimiKLM]

Hi,

I wonder you could help me with my solution.

I'm using GPIB to talk to two devices. I need to reset and align one device A and control the device B. The process A can take up to 2 minutes. The process B is to cool off the DUT to demanded temperature and it can take up to 3 minutes to achieve the demanded temperature. To monitor these processes I use pull method and:

• for process A I use the STAT:OPER:COND? query (is it 1?)
• for process V I use TEMP? query (get temperature, is the answer within the limits to exit?)

Now, I do these processes one by one. But, because both the processes have to be done each time before DUT is tested (as a part of a setting up the test routine), I'd like to save some test time. Technically, both two processes are independent, I can trigger them almost at the same time and wait when the longer one finishes itself, and them move to the tests part.

However, the first attempt of doing go was unsuccessful. When I issued the STAT:OPER:COND? query within the connection to the device A it looks like all GPIB bus is blocked and I cannot issue the TEMP? query to the device B, as the bus seems to be waiting for the STAT:OPER:COND? command sent to the device A to finish.

Strange thing is that then I issue the STAT:OPER:COND? command for first time, the device is not able to accept any other commands.

Why?

What is proper approach to to this test time saving?

[Albert.Geven]

The test you perform waits until the status becomes ready (operation completed)

You also can check this bit by reading the statusbits via gpib and then see if your device is ready without blocking the bus.

When you mention the instruments I could give more precise answers

[MimiKLM]

Thanks Albert,

The device A is a signal analyser (SpecAn) Agilent PXA N9030A.

The device B is a thermostream Temptronic TP04300.

---

@Albert.Geven wrote:

The test you perform waits until the status becomes ready (operation completed)(...)

---

What I was expecting it was that I can continuously (let say with the 1s interval) sent that STAT:OPER:COND? command querying the SpecAn and receive the status word (string number); then I could decode this status and get the information about the status of the operation. However, the device behaves differently and not returning anything until the ALIGN:ALL operation will be completed. Moreover, it looks like whole bus is awaiting for this communication to finish.

---

@Albert.Geven wrote:

(...) You also can check this bit by reading the statusbits via gpib and then see if your device is ready without blocking the bus.(...)

---

Could you please extend this topic a bit?

Thanks

[Albert.Geven]

X-Series Signal Analyzer Spectrum Analyzer Mode User's and Programmer's Reference is to be downloaded from the web.

below are some exerpts from this manual

you can query and interpret the details with visa write and reads and a bit of bit analysing. I have no time to search for a working example.

How to Use the Status Registers
A program often needs to be able to detect and manage error conditions or changes in instrument status. There are two methods you can use to programmatically access the information in status registers:
• The polling method
• The service request (SRQ) method
In the polling method, the instrument has a passive role. It only tells the controller that conditions have changed when the controller asks the right question. The polling method works well if you do not need to know about changes the moment they occur. To detect a change using the polling method, the program must repeatedly read the registers.

To monitor a condition:
a.Determine which register contains the bit that reports the condition.
b.Send the unique SCPI query that reads that register.
c.Examine the bit to see if the condition has changed.

To query the status byte register, send the command *STB? The response will be the decimal sum of the bits which are set to 1. For example, if bit number 7 and bit number 3 are set to 1, the decimal sum of the 2 bits is 128 plus 8. So the decimal value 136 is returned. The *STB command does not clear the status register. In addition to the status byte register, the status byte group also contains the service request enable register. This register lets you choose which bits in the status byte register will trigger a service request.
Send the *SRE <integer> command where <integer> is the sum of the decimal values of the bits you want to enable plus the decimal value of bit 6. For example, assume that you want to enable bit 7 so that whenever the standard operation status register summary bit is set to 1 it will trigger a service request. Send the command

[MimiKLM]

Hi Albert,

Many thanks for your time.

I know this document. It doesn't answer my question.

What I'm expecting was that:

• the CAL:ALL command don't froze the GPIB interface
• even if the STAT:OPER:COND? cannot get reply, the *STB? - as it is a "*" command - able to do this

It looks like either I'm expectig to much, of the FW in the device has a bug.

My question still remains open: How to pull the information about is PXA status after CAL:ALL command was sent, not causing all GPIB bus being locked.

[Dennis_Knutson]

You can pull out your trusty GPIB analyzer (i.e. a + card from NI) or check with the vendor to see what the instrument is doing to the GPIB bus while the command is executing.

[MimiKLM]

This is the VI I'm executing:

That is the trace information

I'd like to draw you attention to the yellow field:

When I execute the VI I see that all the delay is between VISA Write VI (line 5 in the log above) and VISA Read VI (line 6 in the log above), whereas according to the log the delay is located between VISA Read VI (line 6) and VISA Close VI (line 7).

It looks like VISA Read has teh answer immediatelly but, I don't know why, the execution stops there till all aligment/calibration process is finished.

[Dennis_Knutson]

I don't think it shows any such thing. Isn't the time when the function starts?

[Albert.Geven · Accepted solution]

Asking for a statusbyte should not hang the system, because this should be handled in the outer peripherals of the GPIB chip.

So use the "VISA read STB" instead of *STB via the via write.

This function is in the VISA palette

[Albert.Geven]

The read will hang until data is available.

Use the function from my previous message.