AnsweredAssumed Answered

E4426B - locks up during multiple *SAV operations

Question asked by aspiehler on Jun 11, 2010
Latest reply on Jun 14, 2010 by aspiehler
I have a test fixture with an E4426B. At the end of testing, the software is attempting to sanitize the instrument by presetting it and then saving the current state to all of the memory locations writable via "*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:

"

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

"


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. Can anyone offer some troubleshooting suggestions?

Thanks.  

Outcomes