AnsweredAssumed Answered

E8257D Frequency Setting is intermittent

Question asked by miyamky on Oct 9, 2012
Latest reply on Oct 11, 2012 by miyamky

Like • Show 0 Likes0
Comment • 7

Our code currently does the following:

FREQ xHZ;
FREQ?

We then compare the returned value w/ the set value (and we give a +/- 3Hz window even though we're setting to a MHz step size). Intermittently, the return value does not match the set value. Looking at the PSG, it did NOT error, neither the WRITE SCPI or the READ SCPI failed, and the frequency is the previous frequency. We also tried inserting a *OPC in-between the commands to, hopefully, insure that the first command finished prior to the 2nd but that had no effect.

This hasn't happened when we set both the frequency and power (prior to reading) or just setting the power.

Is there something we should be doing to insure that the FREQ command works?

Our firmware is currently at C.06.15 and hopefully this is okay since it takes an act of god to upgrade here.

No one else has this question

Outcomes

Spacecase69 Nov 1, 2013 9:10 AM

You don't specify what frequency and format you are using to set and read the frequencies. At some point you are converting it to binary and this is causing floating point precision issues, due to machine epsilon.

Just realized I misread the post, the +/- 3Hz threw me:

What is the sequence leading up to these commands? You mentioned Steps, what Frequency Mode are you in? Did you set it to List Mode?

Spacecase

Edited by: Spacecase on Oct 10, 2012 3:36 AM

Actions

miyamky @ Spacecase69 on Oct 10, 2012 9:38 AM

I can't go over the frequencies we use but the step size is 1MHz. We start w/ PRESET, then RF power ON, then set a static power value, then we loop on frequency stepping. I have no idea what LIST mode is.

Actions

Spacecase69 @ miyamky on Nov 1, 2013 9:10 AM

> {quote:title=miyamky wrote:}{quote}
> I can't go over the frequencies we use but the step size is 1MHz. We start w/ PRESET, then RF power ON, then set a static power value, then we loop on frequency stepping. I have no idea what LIST mode is.

First find out what mode you are in with:
:FREQ:MODE?

Are These the commands you are using?
:FREQ[:CW] nxHz ' This sets the output frequency to CW (or Fixed), you could also use (:FREQ:FIX nxHz)
:FREQ[:CW]:STEP nxHz ' This sets the Step size, but does NOT change the frequency
:FREQ[:CW] UP ' This increments the frequency by the step size, :FREQ[:CW] DOWN decrements by step size

List Mode would be something like one of these

:FREQ:MODE LIST
:LIST:TYPE LIST
:LIST:FREQ 1GHZ,2GHZ,4GHZ,8GHZ ' example of an arbitrary list
:LIST:DIR UP
:SWE:DWEL n
:SWE:POIN n ' This must match number of frequencies in list

or

:FREQ:MODE LIST
:LIST:TYPE STEP
:FREQ:STAR nxHZ
:FREQ:STOP nxHZ
:LIST:DIR DOWN ' Reverse the generator step sweep direction, if you want
:SWE:POIN n ' This sets the step size based on, (stop-start)/(npoints-1)
:SWE:DWEL n

These should get you started, I don't use list mode that often, but it the top one is very useful.

Spacecase

Actions

miyamky @ Spacecase69 on Oct 10, 2012 12:43 PM

We don't set the mode so it's likely CW (if that's the default). We're not using the step command (see above for exactly what we're doing). We're just setting the frequency as a number (the step size is irrelavent).

My concern is that the SG is not setting the frequency I told it to and there's NO error reported.

Actions

miyamky @ miyamky on Oct 10, 2012 5:50 PM

So it appears that I'm stuck in a call to *STB. Shouldn't that always return right away w/ whatever's in the status byte? Are there reasons that would cause that command not to complete (it does eventually timeout)?

Actions

Spacecase69 @ miyamky on Nov 1, 2013 9:10 AM

> {quote:title=miyamky wrote:}{quote}
> So it appears that I'm stuck in a call to *STB. Shouldn't that always return right away w/ whatever's in the status byte? Are there reasons that would cause that command not to complete (it does eventually timeout)?

You really aren't giving much to go on, but it sounds like you have a GPIB problem. First, disconnect all other instruments from the bus and see if you still have the problem with *STB? and :FREQ commands. If not, reconnect the instruments one at a time (and check all the settings) until the symptoms reappear (or you find a loose/damaged cable). Also, what is the Sig Gen Language set to, and what is the Timeout?

Spacecase

Actions

miyamky @ Spacecase69 on Oct 11, 2012 12:56 PM

We use SCPI from LabView. The timeout is 50 seconds. This happens on all of our test sets so I highly doubt it's a cable problem. It's certainly not a loose cable.

So as far as you know *STB should ALWAYS return immediately correct?

Actions

7 Replies

Spacecase69 Nov 1, 2013 9:10 AM
Mark Correct
Correct Answer
You don't specify what frequency and format you are using to set and read the frequencies. At some point you are converting it to binary and this is causing floating point precision issues, due to machine epsilon.

Just realized I misread the post, the +/- 3Hz threw me:

What is the sequence leading up to these commands? You mentioned Steps, what Frequency Mode are you in? Did you set it to List Mode?

Spacecase

Edited by: Spacecase on Oct 10, 2012 3:36 AM
Like • Show 0 Likes0
Actions
- miyamky @ Spacecase69 on Oct 10, 2012 9:38 AM
  Mark Correct
  Correct Answer
  I can't go over the frequencies we use but the step size is 1MHz. We start w/ PRESET, then RF power ON, then set a static power value, then we loop on frequency stepping. I have no idea what LIST mode is.
  Like • Show 0 Likes0
  Actions
  - Spacecase69 @ miyamky on Nov 1, 2013 9:10 AM
    Mark Correct
    Correct Answer
    > {quote:title=miyamky wrote:}{quote}
    > I can't go over the frequencies we use but the step size is 1MHz. We start w/ PRESET, then RF power ON, then set a static power value, then we loop on frequency stepping. I have no idea what LIST mode is.
    
    First find out what mode you are in with:
    :FREQ:MODE?
    
    Are These the commands you are using?
    :FREQ[:CW] nxHz ' This sets the output frequency to CW (or Fixed), you could also use (:FREQ:FIX nxHz)
    :FREQ[:CW]:STEP nxHz ' This sets the Step size, but does NOT change the frequency
    :FREQ[:CW] UP ' This increments the frequency by the step size, :FREQ[:CW] DOWN decrements by step size
    
    List Mode would be something like one of these
    
    :FREQ:MODE LIST
    :LIST:TYPE LIST
    :LIST:FREQ 1GHZ,2GHZ,4GHZ,8GHZ ' example of an arbitrary list
    :LIST:DIR UP
    :SWE:DWEL n
    :SWE:POIN n ' This must match number of frequencies in list
    
    or
    
    :FREQ:MODE LIST
    :LIST:TYPE STEP
    :FREQ:STAR nxHZ
    :FREQ:STOP nxHZ
    :LIST:DIR DOWN ' Reverse the generator step sweep direction, if you want
    :SWE:POIN n ' This sets the step size based on, (stop-start)/(npoints-1)
    :SWE:DWEL n
    
    These should get you started, I don't use list mode that often, but it the top one is very useful.
    
    Spacecase
    Like • Show 0 Likes0
    Actions
    - miyamky @ Spacecase69 on Oct 10, 2012 12:43 PM
      Mark Correct
      Correct Answer
      We don't set the mode so it's likely CW (if that's the default). We're not using the step command (see above for exactly what we're doing). We're just setting the frequency as a number (the step size is irrelavent).
      
      My concern is that the SG is not setting the frequency I told it to and there's NO error reported.
      Like • Show 0 Likes0
      Actions
      - miyamky @ miyamky on Oct 10, 2012 5:50 PM
        Mark Correct
        Correct Answer
        So it appears that I'm stuck in a call to *STB. Shouldn't that always return right away w/ whatever's in the status byte? Are there reasons that would cause that command not to complete (it does eventually timeout)?
        Like • Show 0 Likes0
        Actions
        Spacecase69 @ miyamky on Nov 1, 2013 9:10 AM
        Mark Correct
        Correct Answer
        > {quote:title=miyamky wrote:}{quote}
        > So it appears that I'm stuck in a call to *STB. Shouldn't that always return right away w/ whatever's in the status byte? Are there reasons that would cause that command not to complete (it does eventually timeout)?
        
        You really aren't giving much to go on, but it sounds like you have a GPIB problem. First, disconnect all other instruments from the bus and see if you still have the problem with *STB? and :FREQ commands. If not, reconnect the instruments one at a time (and check all the settings) until the symptoms reappear (or you find a loose/damaged cable). Also, what is the Sig Gen Language set to, and what is the Timeout?
        
        Spacecase
        Like • Show 0 Likes0
        Actions
        miyamky @ Spacecase69 on Oct 11, 2012 12:56 PM
        Mark Correct
        Correct Answer
        We use SCPI from LabView. The timeout is 50 seconds. This happens on all of our test sets so I highly doubt it's a cable problem. It's certainly not a loose cable.
        
        So as far as you know *STB should ALWAYS return immediately correct?
        Like • Show 0 Likes0
        Actions

E8257D Frequency Setting is intermittent

Outcomes

Related Content

Recommended Content