GPIB buffer size limitations?

[JockeR]

Hi

I'm using the example in Calling NI-488.2 Functions Directly in Excel to read data from an instruments internal memory (Keithley 6517B) directly to an Excel sheet. But no matter how much memory I preallocate for the data I can't get more than 2160 bytes of data. I've tried both Excel 2003 and 2010 with the same results.

Snippet:

sBuffer = Space$(65536) ' string buffer may have to be larger
Call ibrd(udDevice, sBuffer) 'read response and store in sBuffer

Also, the NI-488.2 Communicator tool in MAX seems to have a similar limitation in that it doesn't read more than 2000 bytes (ibcntl: 2000).

When I use the exact same command string (":trace:data?") in LabView all 3240 bytes available in the instruments memory is received without any problems.

I wanted to use Excel since it's such a simple application and my LabView license doesn't include the LabView builder.

Any suggestions on how to solve this?

Regards,

Jocke

[Dennis_Knutson]

It sounds like your read is terminating when a termination character is detected. The data is hex isn't it?

Why not use VISA functions? GPIB is so last century.

[JockeR]

The data is ASCII.

If I'm getting a termination character, shouldn't my VBA-program and the NI Communicator stop at the same character? Now they don't.

I'll try using VISA instead, using this example. 

Do you have any other relevant resources?

Thanks!

[VintageWillis]

Hi Joker

I agree with Dennis_Knutson I would have a go with VISA and have a look at the drivers created for it. They will be for LabVIEW but may be of help to you

http://sine.ni.com/apps/utf8/niid_web_display.download_page?p_id_guid=E3B19B3E921E659CE034080020E74861#seeBelow 

[Dennis_Knutson]

Since you say that LabVIEW code returns the correct data, use I/O Trace to capture the commands of both programs. Compare the differences.