Is there a GPIB max message length (using C driver ni4882)?

[Bonf]

Hi all,

is there a Maximum message length for GPIB Messages?

I didn't find any Information on this but when I pass a buffer that has a length of 10k to ibrd, the Driver sometimes doesn't receive data any more. What happens is that all messages are received from the Instrument, but the data is either all 0's or all FF's - even when checking the responce in NI Spy). Sending data is fine. I can check the data leaving the Instrument and it is correct. When I reduce the size of the buffer that I pass to ibrd()  to 2k it all works fine.

char readBuffer1[10000+1]; // leave extra space for /0

char readBuffer2[2000+1]; // leave extra space for /0 

ibrd ( deviceDescriptor1, readBuffer1, 10000); // this sometimes goes wrong

ibrd ( deviceDescriptor2, readBuffer2, 2000); // this works

Yours,

Marc.

[Chr15]

HI Marc,

there is a max size you can store in the buffer. It is 2GB as you can see in the snippet i posted below. A char is as far as i know is 8bit large. I assume you need for you 10001 char buffer 80kB and thats way under the specified limits.

source (page52)

---

Anyhow you can figure out the exact size of your buffer by calling the function 'sizeof' from the library 'string.h'. You can see an example below.

char string[32] = "hello, world";
sizeof (string)
    ⇒ 32
strlen (string)
    ⇒ 12

could you read out the ibsta and the iberr status and post the return value here? (pdf page 52)

[Bonf]

Thank you very much for the link to the documentation. I was using the NI-488.2 Function Reference
Manual for Windows (June 1999 Edition) which does not describe the buffer limit. 

As you said the buffer is way under the maximum limit. ibsta is 0x2100 and iberr is 0 - regardless of whether data is received correctly or not. For example when reading the coordinates using "Q\r\n" the answer from the machine will be

"QY001X006\r\n" ibsta: 0x2100   iberr: 0x0000

but with a large buffer it will be

"..........."  ibsta: 0x2100   iberr: 0x0000 (with the "." being 0xFF characters or 0x00 characters). The number of characters will be identical to the number of characters sent, and the low-level debug function on the machine shows that the data sent was correct ("QY001X006\r\n"). But on the receiving computer all the characters are all 0xFF (or 0x00) - also when viewed in NI Spy. 

As this runs on an embedded system I don't know what version of GPIB DLL is being used (the OS is Windows Server 2003, the development environment is Visual Studio 6.0), so it might be an old problem. 

[Chr15 · Accepted solution]

What about if you make your packages smaller to fit the maximum size you can transfer without error? its a bit of a workaround but I think that’s the solution with the least effort for you.

[Bonf]

The problem is that I have written an abstraction layer that is used for many things, some of which I have no influence over. 

But your suggestion does seem like the only solution. Thank you very much for your help.

Marc.