GPIB wait

[L_K]

Hi
I have a problem of long wait at

my_device.wait(CNi4882::EventServiceRequest|CNi4882EventTimeOut); //my_device is CNi4882Device

I use wait after I write something to GPIB (using my_device.write(...)). I kinda copy some example code and use it without knowing what CNi4882Device.wait(CNi4882::EventServiceRequest|CNi4882EventTimeOut) really means. Can u explain me what it really does, when (what case) is the best to use it. That way I can think about what might be the cause. I looked at the help, but it doesn't have much explaination.

Thanks

[Glenn Burnside]

This method causes the current thread to wait on the GPIB events you specify with the mask parameter. In the case of the code you have, you are telling your program to wait until either a ServiceRequest event or a timeout event occurs. If you have not configured your device to generate a service request to notify you of something, then you will likely just wait for the timeout, which will be equal to the value you set in the SetTimeout method. If you do not explicitly set the timeout, the default is 10 seconds - which would explain the long wait. There are lots of possible events to wait on, which you can see in the documentation for the Wait method. Best use of the method would depend on what you're trying to do in your application - if you need to be sure that a specific event has occured before your app should progress past a certain point, then you should wait on that event. If you do not plan on processing a particular event, there's not much reason to perform the wait.

[L_K]

Does the *WAI also slow down the instrument? I send *WAI after every write command.

[Glenn Burnside]

*WAI causes the instrument to not return control from the Write command until it is done processing any previous commands, but not all commands you send the instrument are going to require a *WAI after them. Can you give some more detail about what kind of device you're using, what you're doing with it, and why you're injecting wait commands into your IO?

[L_K]

I am modifying someone else's code for interfacing with a spectrum analyzer. The *WAI command follows commands such as setting VDO bandwidth, setting resolution bandwidth, finding the maximum value of the displayed graph. I guess the person who programmed this before wants to wait until the spectrum analyzer has done with the task then continue on the next command.

Here is some of the command sent thru GPIB to the spectrum analyzer
clear device (send ibclr)
*SRE 32 //enable service request
*ESE 1 //set event enable bit for operation complete bit (enable the device to request a control)
preset the instrument
set timeout to 10s
inp:att 10;*wai //set attenuation, then wai
wait // my_device.wait(CNi4882::EventServiceRequest|CNi4882EventTimeOut

I attached the capture of what's sent thru GPIB in case you want to see more detail. If u do not have NI spy to open the file, please let me know so I will attach the .txt file. The Spectrum analyzer that is slow is UD5.
By the way, I am so lost about selecting the way to synchronize the commands. I read manuals and tutorial on the internet, but I cannot find the one that really explains what the possible ways to synchronize are, when is the best to do each of those ways, and how do u do it. Do u have any document that explains from concept down to how to do it?

[L_K]

I forget to show u the c code for doing this

try
{
my_device->write("freq:span 50 MHz;*wai"); //set the frequency span of the spectrum analyzer
my_device->wait((CNi4882::EventServiceRequest|CNi4882EventTimeOut); //wait until the spectrum analyzer is done with the frequency span setting
}
catch
{
.....
}

if I want to use the OPC, how should I do it?

[Glenn Burnside]

I think the place you probably want to start is with the manual for the device itself - Agilent's manuals are usually pretty good about explaining the use of OPC, WAI, and SRQ's for controlling the device, and typically provide some HP-BASIC examples that would show you typically patterns of IO, including wait commands.

In general, straightforward configuration commands should not require waits between them - the device itself is going to buffer those commands and process them as it finishes prior operations. Where it becomes more important to get synchronization correct is first not taking measurements until the device's configuration is fully settled, and second in not trying to pull data from the device until the device is ready. For the first case you might use a WAI command, assuming that the device actually performs a wait on time-expensive configuration. For the second case, you might set the device to raise a service request when data is ready. Again, the instrument manual should explain exactly which bits in the status register you need to enable and query for in order to set up SRQ polling.