Empty string returned after gpib receive

[cmseguin]

Does anyone know why I would periodically get an empty string returned after issuing a receive().  This is causing a large delay in my program that I really cant afford to have. The delay occurs while the receive is handling the empty string. This sequence works correctly most of the time.

VB Code:

Public Function GetData(GPIBAddress, SendString) As String
    Dim ReadThis As String, spr As Integer, ReadTemp As String
reread:
    
    Call Send(0, GPIBAddress, SendString, NLend)
       Wait (500)
    Call ReadStatusByte(0, GPIBAddress, spr%)
    
    ReadThis = Space$(140)
    
    Call Receive(0, GPIBAddress, ReadThis, STOPend) I get an empty string here, not always.
    
    If Trim(ReadThis) = "" Then  To correct it i issue this sequence.
        Call DevClear(0, 26)
        GoTo reread
    End If
    
    GetData = ReadThis
 End Function

NI SPY:

See attachment.

I'm talking to a Keithley 2612A.

I'm using NI488.2 2.73

[Henrik_Volkers]

Once I had (due to low Q cables and lot of EMI) erratic EndOfMessage events that leads to empty input strings. 

[Anna_K.]

Do you have duplicate cards, cables or instruments? If yes you could systematically swap out each to determine which may be causing the issue.

[gpibtester · Accepted solution]

In your code snippet, I see where you are doing a ReadStatusByte, but the result is not checked. When reviewing the Spy capture file, where the Receive works, the ReadStatusByte returned the result of "0x04", as highlighted in the attached bitmap, ReadStatusByteWithMAV.gif. This result is known as the MAV bit (Message Available). If Bit 4 (MAV bit) is set, then that indicates that there is something in the Output Queue that can be read. Information about the bit settings for a Keithley 2612A can be found starting on Page 655 with the section called, Status byte and service request (SRQ) in the Reference Manual. Below is a link to the Reference Manual:

http://www.keithley.com/data?asset=52057

In the case where the Receive fails (line 63 in the capture file), the preceeding ReadStatusByte call's result was "0x00" (as highlighted in the attached bitmap, ReadStatusByteNoMAV.gif), which means it did not have anything in the Output Queue to read.

After doing a ReadStatusByte, you should check the result to see if there is anything in the Output Queue to be read. If the result is "0x00", then you can probably do something like add a delay and keep checking the ReadStatusByte again until the ReadStatusByte returns with Bit 4 set. When Bit 4 is set, then you can do a Receive to read the Output Queue.

Hope this information is helpful.

[cmseguin]

Thanks for the readstatusbyte information. GPIB statuses is something new to me. I will begin implementing status checks in my software on a regular basis from here on out. It is a great way to verify events prior to proceeding at runtime of sequential code. Any additional tutorials or learning vehicles would be appreciated. My current development environment is .net 4.0, Visual Basic 2010. 

FYI...This issue has been solved. In a nutshell, I was trying to talk to a device that would get stuck in a loop upon execution of the "send()" command. I tried to receive the response that never made it to the output queue because the polled device was busy.

Thanks to all who have responded to this issue. Hopefully this may help others with similar issue signatures.

Thanks,

Chris

[gpibtester]

Chris,

By default, GPIB programming examples are installed. There are a couple of Visual Basic examples that you might want to look at. You can find them at Start->Programs->National Instruments->NI-488.2->Examples. From there, go to the Visual Basic directory for either DMMSerialPoll or ScopeSerialPoll to examine the source code. While they are written using 488.1 calls, it is similar to how you would make the equivalent 488.2 calls. For instance, ibwrt is similar to Send, ibrsp is similar to ReadStatusByte, and ibrd is similar to Receive. But it gives one a general idea of how to deal with Serial Polling and the Reading of the Status Byte.

Also, there is a document was originally written for the original BASIC that is a little outdated, but it contains an overview of Serial Polling that is still relevant:

http://zone.ni.com/devzone/cda/tut/p/id/4054

Hope this clears up some of the mystery about Serial Polling and Reading Status Bytes.

gpibtester

[cmseguin]

Thanks Gpibtester

[cmseguin]

Gpibtester,

Maybe you can give this issue a shot at solving-

http://forums.ni.com/t5/Instrument-Control-GPIB-Serial/While-running-a-net-3-5-application-it-always...