timeout during receiving data

[hrohmer]

In our application (C#) we read a PCI GPIP interface (with software version 2.3 and NationalInstruments.NI4882.dll) cyclic to get a result from an other device. Unfortunately this other devices are black boxes for us. The only thing we know they are GPIB 488.2. This works perfect with most of the 'other' devices. But with one device we have a problem. Normally the gpib device reports an error (timeout) if the other device does not send a string within the given timeout and we try to read again until the other device is sending a string. If we receive the string we handle it and start the read operation again.

...
while(true) {
    try {
        String s = ieeeDevice.ReadString();
        if (s != null && s.Length > 0) {
          ...
       }
    } catch (Exception e) {
       ...
    }
}
....

In this special device we receive a timeout during the ReadString() method receives a string and so we receive only parts of the string. E.g. we should receive a 'A MES 23 \r\n' but we sometimes (not all the time) get a timeout before we receive the '\n' (NI Spy shows us a 'A MES 23 \r' and the next string has only a '\n' in it). The iberr is EABO. I increased the timeout a lot which did not help. This error shows up again. Also if we disable the timeout or set it up to a high amount of seconds all the other devices (which worked perfect) do not work any more.

Does anyone has an idea what the cause of this timeout could be?

[hrohmer]

If the Exception is thrown I can call the property
ieeeDevice.LastCont
that shows me a '6'. So the data are read but I cannot access it because the Exception it thrown before the data are passed to my String. I think in the C library where I call ibrd(...) directly with a pointer on my buffer the buffer is filled and I can read the 6 characters at least.
Wouldn't it make sense to add an other method to the C# library where I can pass a StringBuilder object to the ReadString() method and the n character which are read before the timeout would be appended to the StringBuilder before the Exception is thrown?

[ScottieB]

It sounds like your device is not terminating its data with the EOI line that usually signifies "end of data" for GPIB communication.  If this is the case, it probably has some other mechanism for saying "that's the end of this string", like a termination character (perhaps the '\n' you spoke about?).  You can setup NI-488.2 to wait for this termination character, so that when a complete string is received, no exception is thrown.  You should set the timeout value to something high enough to where if you hit that value, you know that something is really wrong (1000s?).

As far as other devices not working when you set the timeout really high, that's very odd.  What happens when they "don't work"?  The timeout shouldn't affect working instruments at all...

Hope this helps.

Scott B.

GPIB Software

National Instruments

Message Edited by ScottieB on 07-25-2005 09:18 AM

[hrohmer]

Hi Scott,

thanks for your reply.

I set up the device to listen for both, the EOI line and a '\n' character also. This works most of the time, but sometimes the read operation stopped and a TIMO error is reported. The strange thing is: If this error happens the read stops always before the '\n'. The next read operation will read the missing '\n' character.

Is it possible the other device sets the EOI line to early? So my device stops the read after the '\r' and miss the '\n' because the EOI line is already set. And since my device know there are one character missing it throws an error. (Just an idea...)

What do you think?

[Glenn Burnside]

Thanks for the feedback - I have added this idea to our list of features to consider for future revisions of the NI-488.2 .NET API.

[ScottieB]

Just to be clear, I understand that you're getting EABO with a Timeout error on your GPIB reads from a certain device using the .NET Language Interface.

This still seems like something is going on with your setup.  Let me explain how a read is normally terminated.

(EOI Asserted) OR (Timeout Reached) OR (Byte count reached)

That's the expression used to terminate a read.  In addition, if you're setting EndOfStringCharacter and TerminateReadOnEndOfString, another input is added to the OR:

(EOI Asserted) OR (Timeout Reached) OR (Byte count reached) OR (Termination Character found)

You're getting a timeout error, so that means that however long your timeout is, that period of time is elapsing before (EOI Asserted) OR (Byte count reached) OR (Termination Character found).  So what I'm deducing is that your instrument takes a really long time to send its string, and the \n doesn't make it in time.  This is really odd and doesn't make any sense.  It doesn't sound like your instrument is asserting EOI early because if it did, then you wouldn't see a timeout (because EOI assertion would end the read).

It's possible that your instrument isn't fully complying to IEEE 488.1, but let's hope not.  If you can get an ni-spy capture of the failure, it may shed some light on the issue for us. 

Scott B.

GPIB Software

National Instruments

[hrohmer]

Hi Scott,

thanks for your support on this problem!

The only spy I have is 29 MB and I don't know how to cut it, so I tried to attach some screen shots...

[hrohmer]

the details no. 1

[hrohmer]

If I can provide you more information please let me know...

[ScottieB]

What is your timeout setting for this device?  And what C# code are you using to set this timeout?  It seem like it's pretty low judging by your spy captures.  Perhaps your device really isn't able to respond that quickly?

Scott B.
GPIB Software
National Instruments