Agilent E4426B signal generator locks up during multiple GPIB *SAV operations

Question

I have a test fixture with an Agilent E4426B RF signal generator connected to a PC via a National Instrument Ethernet-to-GPIB bridge. My software is attempting to sanitize the instrument by presetting it and then saving the current state to all of the memory locations writable via the standard SCPI command "*SAV x,y".

The loop works to a point, but eventually the instrument responds with an error and continuously displays the "L" icon on the front display and a "Remote preset" message at the bottom. At that point it won't respond to any more remote commands and I have to either cycle power or press LOCAL, then PRESET at which point it takes about 3 minutes to finish presetting. At that point the "L" icon is still present and and the next GPIB command sent to the instrument causes it to report a -113 error (undefined header) in the instrument error queue.

I fired up NI spy to see what was happening, and found that the error was happening at the same point in the loop - "*SAV 6,2" in this case. From NI Spy:

Send (0, 0x0017, "*SAV 6,2", 8 (0x8), NLend (0,0x01))
Process ID: 0x00000520 Thread ID: 0x00000518
ibsta:0xc168 iberr: 6 ibcntl: 2(0x2)

And here's the code from the instrument driver:

int CHP_E4426b::Erase()
{
  if ((m_StatusCode = Initialize()) != GPIB_SUCCESS) // basically just sends "*RST"
    return m_StatusCode;

  m_SaveState = "*SAV %d, %d";

  for (int i=0; i < 10; i++)
    for (int j=0; j < 100; j++) {
      sprintf(m_CmdString, m_SaveState, j, i);
      if ((m_StatusCode = Send(m_CmdString, strlen(m_CmdString))) != GPIB_SUCCESS)
        return m_StatusCode;
    }

  return GPIB_SUCCESS; 
}

I tried putting a small Sleep() delay (10-20 ms) at the end of the inner loop, and to my surprise it caused the error to show up earlier rather than later. 10 ms caused the loop to error out at 44,1 and 20 ms was even sooner. I've already eliminated faulty cabling or the instrument as the culprit. This same type of sequence works without any error on a higher end signal generator, so I'm tempted to chalk this up to a bug in the instrument's firmware.

Have you tried to run the `Send()` line stepping in debug mode? If yes, you can see the error occurring at the very first one `Send()`, at every `Send()`, at some of them or what else? — j4x, Mar 23 '11 at 20:38
It wouldn't occur until the 150th or so `Send()` command. I put a counter in to tell me which one caused the lockup, then put a delay in the loop because I theorized that I was hitting the instrument faster than it could handle. That caused it to lock up on an _earlier_ `Send()` than having no delay. At that point we just removed the call to `Erase()` from our shutdown sequence and erase the instrument by hand on the rare occasion that it's actually necessary. — Andrew Spiehler, Mar 25 '11 at 16:29
If your goal is to just "sanitize" the instrument, then Agilent probably has a procedure for that. I know they do for Network Analyzers. — Mike, Jul 30 '11 at 21:01

Mike · Answer 1 · 2011-07-30T22:53:35.930

Try adding OPC?; to the string then do a read to wait for the OPC command to complete. This way your program won't "overload" the instrument.

int CHP_E4426b::Erase()
{
  if ((m_StatusCode = Initialize()) != GPIB_SUCCESS) // basically just sends "*RST"
    return m_StatusCode;

  m_SaveState = "*SAV %d, %d;OPC?;";

  for (int i=0; i < 10; i++)
    for (int j=0; j < 100; j++) {
      sprintf(m_CmdString, m_SaveState, j, i);
      if ((m_StatusCode = Send(m_CmdString, strlen(m_CmdString))) != GPIB_SUCCESS)
        return m_StatusCode;
      Receive(m_CmdString, sizeof(m_CmdString));
    }

  return GPIB_SUCCESS; 
}

Agilent E4426B signal generator locks up during multiple GPIB *SAV operations

1 Answers1