ibrd seems to quit when hitting "00"

[PS1]

When using the Measurement & Automation Explorer, I can issue a command to read back a GIF file stored in a Spectrum Analyzer, and I can see that it reads the binary content of the entire file.  I turned on the NI Spy and monitored the GPIB activity of the bus.  It sends down the command ":MMEM:DATA? 'C:PICTURE.GIF' using ibwrt and then reads back the data using ibrd.  When the Communicator does this, it continues reading until it has read all the data until it runs into an "ff".  At this time it stops and kicks out.  When I run my program which does the same thing, my program stops and kicks out when it hits the first "00".  How can I make my program emulate what the 488.2 Communicator does in Measurement & Automation.  I am guessing that this may be a software configuration issue, but I do not know it is.

Thank you in advance

   Phil Spratt

   Agilent Tech

[TobyHex]

Hey Phil,
I want to clarify a few things so that we can get to the bottom of your situation. When you refer to your "program", what program are you referring to and what are you using to write this program? I am assuming you mean a program you are constructing in LabVIEW and if this is the case would you mind attaching a screenshot of your block diagram, that is simplified down to your specific question, that way no extraneous items have to be dealt with. One quick sub note on your question that refers to your program, does your code look for items dealing in HEX values or Decimal values? I am assuming that if it is stopping at a “00” due to a misrepresentation of data flow. I look forward to hearing your response so that we can get you up and running. Thanks and have a great day!

Regards,

Nicholas K

[PS1]

Hi Nicholas

   I wrote my program in CVI 5.01.  I am using NI SPY to monitor the GPIB bus activity.  I am executing  a SCPI command a couple different ways and getting two different results.  When I use your Measurement and Automation Communicator and send the SCPI querry to the instrument,  and read back the results of the querry, I get the entire length of the data being sent back.  This includes a bunch of "00" that is part of the data.  This "data" is actually a GIF file that I am trying to extract from a Spectrum Analyzer.  When I send the same querry using my program, I get the same results up until the first "00".  This seems to cause the data transfer to stop so the file transfer is incomplete.  I did some further playing with your Communicator.  If I check the "Teminate Read on EOS", I get something very similiar to what I get when running in my program.  When I uncheck this box again, the whole file seems to transfer correctly.  I noticed that when I check this box and click OK, 5 ibconfig's are sent to the PSA.  I then replicted these 5 ibconfigs in my program, but it did not do the samething.  I still think I am not configring the bus correctly to handle this large transfer, but I do not know what it is.  Below is a snippet of code I use.  Hope this better explains my situation.

Thank you Phil

          // Reconfigure the GPIB port not to NOT terminate read on EOS.
          ibconfig(device3, IbcEOT, 1);
          ibconfig(device3, IbcEOSrd, 1);
          ibconfig(device3, IbcEOSwrt, 0);
          ibconfig(device3, IbcEOScmp, 0);
          ibconfig(device3, IbcEOSchar, 0);
         
          // Grab the screen image file from the PSA.
        strcpy(tempBuffer, ":MMEM:DATA? 'C:PICTURE.GIF'");
        statusResult = gpibWrite(tempBuffer,device3, FALSE);
        if (statusResult != 0)
        {
           SetCtrlVal(panelHandle, PANEL_MESSAGEBOX,"\n GPIB command -> FAILED");
           return -1;
          }
         
          // Clear read_buffer
          memset(read_buffer, '\0',strlen(read_buffer)-1);
       
          // Get querry result and display.
          statusResult=gpibRead(read_buffer, device3, FALSE);
          bufLen = strlen(read_buffer);
       
          // Open file to put trace data.
          strcpy (resultsDirectory,"PICTURE.GIF");
          if ((fp = fopen(resultsDirectory,"a")) == NULL)
          {
            sprintf(message, "PICTURE.GIF could not be opened.");
            MessagePopup ("Message Window", message);
            ProcessDrawEvents();
            fclose(fp); 
            return -1;
          }
       
          // Break up string containing PICTURE.GIF contents.
          for (i=0; i<bufLen; i++)
          {
            binaryInput=read_buffer[i];
            binaryInput = binaryInput & 0xFF;
            Fmt (str, "%s<%x",binaryInput);
           InsertTextBoxLine (panelHandle, PANEL_MESSAGEBOX, 0, str);
          }
         
          // Reconfigure the GPIB port not to terminate read on EOS.
          ibconfig(device3, IbcEOT, 1);
          ibconfig(device3, IbcEOSrd, 0);
          ibconfig(device3, IbcEOSwrt, 0);
          ibconfig(device3, IbcEOScmp, 0);
          ibconfig(device3, IbcEOSchar, 0);
       }
             

[markus kossmann]

    // Get querry result and display.
          statusResult=gpibRead(read_buffer, device3, FALSE);
          bufLen = strlen(read_buffer);

This code is problematic. C uses \0 as termination character for strings and if your data contains a \0 character you will get a wrong  bufLen. You have use another method to get the number of bytes here, maybe by modifying gpibRead() to return the number of chars.

Message Edited by markus kossmann on 05-27-2008 07:23 AM

[PS1]

Hi Markus, Nicholas

  I forgot to add in the gpibRead function in the previous message.   See below.   All it does is call ibrd w/ a # of bytes to read.  I checked the string in the debugger and it is terminating at the 1st "00".  I replicated this test using the Communicator in the Measurement & Automation explorer tool by NI ,however, when they send the ibrd, it continues reading throgh all the "00" s as verified by monitoring the GPIB port via NI Spy.  So they are able to read extract out the entire contents of the readback, where as my program returns prior to finishing the data transfer process. 

int gpibRead (char read_buffer[20000], int device, int opcEnable)
{
  static int func, numToRead = 19000;
  int bufLen=0;
  int i;

  // Read back ID querry results
  // Display results.
  ibrd (device, read_buffer, numToRead);
  bufLen=strlen(read_buffer);
  return 0;
}

All it does is send a ibrd and grab the result. 

[markus kossmann]

Did you enable the option "display entire buffer" when viewing read_buffer in the variable window ?  Without that option it defaults to show only the data until the first \0 character.

The return value of  ThreadIbcnt () should give you the number of bytes actually read by ibrd() .

[Micho]

I have an old piece of hardware that requires that use a special character to read and write to it. I can use the NI Measurement & Automation Explorer to communicate with it after configuring the following EOS settings:

Send EOI at end of write (on)

Terminate read on EOS (on)

EOS Byte = 10

But I can not get it to work with my software ... What are the equivelent viSetAttribute that I should use to set these? I've tried the following and I still can not get it to read correctly

viSetAttribute(instrHandle, VI_ATTR_TERMCHAR, terminationChar);

viSetAttribute(instrHandle, VI_ATTR_TERMCHAR_EN, VI_TRUE);

viSetAttribute(instrHandle, VI_ATTR_SEND_END_EN, VI_FALSE);

Thanks in advance.

[markus kossmann]

I would set

viSetAttribute(instrHandle, VI_ATTR_TERMCHAR, 10); // set the termination character (EOS)

viSetAttribute(instrHandle, VI_ATTR_TERMCHAR_EN, VI_TRUE);  // Terminate read on EOS (on)

viSetAttribute(instrHandle, VI_ATTR_SEND_END_EN, VI_TRUE); //Send EOI at end of write (on)

viSetAttribute(instrHandle, VI_ATTR_WR_BUF_OPER_MODE, VI_FLUSH_ON_ACCESS); /* sned command when termination character is appended */

And don't forget  appending thr Linefeed character before sending the command to the device 

[Micho]

Thanks! I just had to add one other line:

viSetAttribute(instrHandle, VI_ATTR_RD_BUF_OPER_MODE, VI_FLUSH_ON_ACCESS);

It seems to be working great.