AnsweredAssumed Answered

Timeout when making measurement using N5531

Question asked by Superbrew on Jan 9, 2008
Latest reply on Mar 17, 2008 by jborges3

Like • Show 0 Likes0
Comment • 6

I am trying to make some RFP measurements over GPIB with the N5531. I am using a N1911 for the power meter. My program will work fine for most measuremnts but I get timeout error messages at random times when trying to read back the data from the N5531. For example, using this code in C#:

for (; testfreq <= 2.4; testfreq += .2)
                {
                    freqset = "CW" + Convert.ToString(testfreq) + "GZ";

                    if (testfreq < .1)
                    {
                        testfreq = 0;
                    }

                    GPIB.SwpOsc.WriteString(freqset);
                    while (msmrmnt < 10)
                    {
                        pwrset = "PL" + Convert.ToString(testpower) + "DM";
                        GPIB.SwpOsc.WriteString(pwrset);
                        Thread.Sleep(4000);
                        GPIB.Specan.WriteString("READ:RFP?");
                        Thread.Sleep(500);
                        msmrmntStr = GPIB.Specan.ReadString(128);
                        msmrmntStr = msmrmntStr.Remove(16);
                        msmrmnt = Convert.ToDouble(msmrmntStr);
                        testpower += .3;

I get the timeout error at random frequencies. What am I doing wrong? I am not sure how to properly implement *OPC, if I can get some help with that I would appreciate it. Thanks

No one else has this question

Outcomes

6 Replies

jborges3 Mar 14, 2008 3:11 PM
Mark Correct
Correct Answer
Hello Superbrew,

SLEEP statements are not recommended for instrument specific timing for this very reason. Use of the *OPC? command that you asked about is a good alternative to using a hard coded delays.

*OPC? (operation complete) is a system-level control command that can inform your control software that the current operation is complete.

*OPC? tells the instrument to return a +1 in response to the query as soon as the previous instrument command has finished executing. Then your software can execute the next command in the program sequence without any unnecessary delay.

To make use of this command initiate the measurement, check if the operation is complete, then fetch your data.

In pseudo code it would be

send INIT
send *OPC?
read the operation complete string
send FETCH?
read your data

Here is an example of how you might change your code to make use of *OPC?

for (; testfreq <= 2.4; testfreq += .2)
                {
                    freqset = "CW" + Convert.ToString(testfreq) + "GZ";

                    if (testfreq < .1)
                    {
                        testfreq = 0;
                    }

                    GPIB.SwpOsc.WriteString(freqset);
                    while (msmrmnt < 10)
                    {
                        pwrset = "PL" + Convert.ToString(testpower) + "DM";
                        GPIB.SwpOsc.WriteString(pwrset);

changed ->               GPIB.SwpOsc.WriteString("*OPC?");
changed ->               GPIB.SwpOsc.ReadString(128);

changed ->               GPIB.Specan.WriteString("INIT:RFP;*OPC?");
changed ->               GPIB.Specan.ReadString(128);
changed ->               GPIB.Specan.WriteString("FETCH:RFP");

                        msmrmntStr = GPIB.Specan.ReadString(128);
                        msmrmntStr = msmrmntStr.Remove(16);
                        msmrmnt = Convert.ToDouble(msmrmntStr);
                        testpower += .3;

I'm not able to try this code out, so please view it as an example with no warranty and not a cut and paste solution.

This solution will not only avoid timeouts, it will also speed up your code!

Best regards,
Like • Show 0 Likes0
Actions
Superbrew Jan 10, 2008 2:26 PM
Mark Correct
Correct Answer
Thanks, I will have to wait until tomorrow to test it out. I was trying to use *OPC after the 'READ?' command and was getting back bogus results. Thank you for taking the time to explain it to me.

**EDIT: I tried running the code that you gave me and I got a timeout error again. After some trial and error this is what I came up with:

            GPIB.Specan.WriteString("CAL:PMET:ZCAL");

            GPIB.Specan.WriteString("*OPC?");
            while (opc)
            {
                int i = GPIB.Specan.ReadSTB();
                if (i != 0)
                {
                    opc = false;
                }
                else
                {
                    opc = true;
                }
                Thread.Sleep(200);
            }

But I think there is a better way to do this. I am sorry if these questions are silly, thanks for taking the time to answer.
Like • Show 0 Likes0
Actions
Superbrew Jan 17, 2008 6:08 AM
Mark Correct
Correct Answer
I am still having a problem making measurements in the MRECEIVE mode. The code above works perfect for the SA mode. It seems as though if there is no measurement displayed, ie '---', sending the init command and *OPC? does not work. It does work if there is a number displayed. Is there a way to check if the reciever is ready to make a measurement? I am using the default RFP configuration.
Like • Show 0 Likes0
Actions
jborges3 Mar 14, 2008 3:31 PM
Mark Correct
Correct Answer
Hi Superbrew,

Sorry for the delayed reply, for some reason the forum didn't set me to automatically watch this thread after my last reply.

"
I tried running the code that you gave me and I got a timeout error again
"

The time out itself isn't the behavior of the instrument, it is the behavior of your test system giving up on waiting for a reply. You can adjust your test system to wait longer before giving a time out error. Then you can remove the sleep statement

The idea is that the *OPC? query stops new commands from being processed until the current processing is complete. Then it returns a â€œ1â€ when the current operation is complete. Your program can read this "1" and after it is received your program can continue.

A powerful part of using *OPC? to to be able to remove sleep commands from your code. Sleep commands cause your program to wait longer than is necessary, especially because when you select a sleep time you are likely to make it much longer than it needs to be.

So, first initiate a sweep, then ask *OPC? then wait patiently for an answer of "1" it might take a long time depending on what you are doing, set your computer to not "timeout" until a time longer than this part takes. Once the "1" is returned, then query the trace data.

I think the example I gave will work as long as you extend your computer's timeout time.

Best regards,
Like • Show 0 Likes0
Actions
Superbrew Mar 14, 2008 8:04 PM
Mark Correct
Correct Answer
Thank you for the response. I actually figured it out, and it was the timeouts that I had set in my program. I did not realize at the time that querying the instrument does not start the time over.

I have been able to get rid of almost all the sleep commands with the exception of those required for readings to settle.
Like • Show 0 Likes0
Actions
jborges3 Mar 17, 2008 12:14 PM
Mark Correct
Correct Answer
Hi Superbrew,

That's good news, you are on your way to greater code optimization.

"
I have been able to get rid of almost all the sleep commands with the exception of those required for readings to settle.
"

You mentioned the "--" that appears while you are waiting for a measurement result to be displayed in the measurement receiver personality?

Here is some pseudo code that shows a PSA trick you can try that should eliminate the need for a sleep statement there. The key to this idea is to *RST, go to single sweep and then abort the current measurement right after switching into the measurement personality you want. Then you can configure the measurement, initiate the measurement, *OPC to check when the measurement is done and then read the measurement with out any delay.

INST:SEL MRECEIVE
*RST;*CLS
INIT:CONT 0;:ABORT

FREQ:CENT <your frequency>
CONF:<measurement you want>
<any other measurement parameters>
INIT:<measurement that you want>
*OPC?
<read status result>
READ:<measurement that you want>?

What I think you may be running into is that if PSA is in continuous sweep when you first switch into the measurement personality then PSA is trying to immediately make some sort of measurement based on what ever settings it may have before it is able to respond to your commands.

Turning continuous sweep off and then aborting the current sweep can eliminate this initial measurement and any time delay associated with it.

If you would like to send me a snip of your code that shows the sleep statement I'd be glad to show you a more specific example if you would like.

Best regards,
Like • Show 0 Likes0
Actions

Timeout when making measurement using N5531

Outcomes

Related Content

Recommended Content