VISA viRead dropping bytes (Mac OS X, NI VISA 15.5)

[jpm1680]

I'm writing a command-line tool (Mac OS X, NI VISA 15.5) to pipe arbitrary data in and out of a GPIB device via an NI GPIB-USB-HS+ controller.

It seems to be working fine if I read the entire buffer at one time, but I'd like to make it more flexible and repeatedly read in smaller chunks until the read gets an end-of-transmission. When I do this, the last byte seems to be getting lost. If I do a 1-byte-at-a-time loop (as a proof-of-concept), every other byte is lost.

        ViUInt32 read_bytes;

        do

        {

            vi_status = viRead(device_session, s_data_buf, sizeof(s_data_buf), &read_bytes);

            if( vi_status != VI_SUCCESS && vi_status != VI_SUCCESS_MAX_CNT )

            {

                fprintf(stderr, "viRead returned error: 0x%08x\n", vi_status);

                return;

            }

            printf("%*s", read_bytes, s_data_buf);

        } while( vi_status == VI_SUCCESS_MAX_CNT );

        puts("");

If sizeof(s_data_buf) == 64, I get the following response to my *IDN? query:

ICS Electronics, 4867, S/N 1603049, Rev X0.00 Ver 11.08.16

If sizeof(s_data_buf) == 1, I get this response:

ISEetois 87 / 634,RvX.0Vr1.81

Stepping through the code and watching the status on the GPIB device, it looks like the GPIB device is only queried once, and the result is buffered in the GPIB-USB-HS+. Each call to viRead pulls data from the buffer. Is there an extra pointer increment going on somewhere in the VISA/488.2 chain?

[WestOfEden]

Hey there,

Have you tried with other buffer sizes in between to see what the result is? Does this happen with all sizes below 64?

[jpm1680]

Eden,

Thanks for the response. Yes, it happens at varying buffer sizes.

sizeof(s_data_buf) == 8:

ICS Elecronics, 867, S/N1603049,Rev X0.0 Ver 11.8.16
11.

sizeof(s_data_buf) == 4:

ICS lectonic, 487, SN 163049 RevX0.0 Ver11.0.16

sizeof(s_data_buf) == 2:

IC Eecroic, 86, /N16309,Re X.0 Vr 1.8.6

-Jason

[WestOfEden]

Hey,

I've been looking through the forums, old issues, and the documentation for that function and haven't yet found anything indicating what might be the cause or how we can get around it. I'm going to keep looking..

[jpm1680]

Thanks! Were you able to reproduce it? Would it help if I sent an executable or source code?

-Jason

[WestOfEden]

I haven't been able to reproduce this as I don't have  GPIB instrument to test it with. At the moment I'm searching through service requests, forums, and articles on our site for information on this. Do you have any other GPIB devices you can try it with, and see if you see the same behavior? I fully expect you would, but just curious. I would also recommend reading through some of the text based VISA documentation to see if anything in there shines some light on this. I didn't see anything when I looked through the documentation for viRead, but its possible I just missed it.

[jpm1680]

[double post]

[jpm1680]

Eden,

I found another (more established) GPIB device to test with. It does not seem to have the issue:

sizeof(s_data_buf) == 1:

HEWLETT-PACKARD,E3634A,0,2.3-6.1-2.1

sizeof(s_data_buf) == 256:

HEWLETT-PACKARD,E3634A,0,2.3-6.1-2.1

It looks like the manufacturer of the device is at fault here. Thank you for your assistance!

-Jason

[WestOfEden]

Well that's interesting. Hopefully they're able to provide some guidance on why that might be the case then.

Have a good week!