Extra bytes in data transfer when using VISA and C++ instead of LABVIEW

Question

Hello,
I've a problem when I try to download the capture buffer from a spectrum analyzer with C++Builder and VISA.
If I do that with LABVIEW (with VISA read and write) everything is fine. Instead, with C I get extra bytes in
the stream. In particular whenever there is a '0A' in the stream I get also a '0D' before it. I'm using a GPIB-USB-B card from National. I know I could easily get rid of those extra bytes in my code, but I'd like a cleaner solution.
Does anybody know the difference between the following code and LABVIEW VISA read and write routines?
Is there some attributes I have to set in C which is automatically set in LABVIEW?
Thanks a lot in advance!!
Simone
ViSession defaultRM, vi;
viOpenDefaultRM (&defaultRM);
viOpen (defaultRM, "GPIB0::10::INSTR", VI_NULL,VI_NULL, &vi);
ViStatus err = viSetAttribute(vi, VI_ATTR_IO_PROT, VI_NORMAL);
ViUInt32 retCount;
err = viWrite(vi, "CGET?0,0\n", strlen("CGET?0,0\n"), &retCount);
ViByte* buffer = new ViByte[100000];
err = viRead(vi, (ViByte*)buffer, 100000, &retCount);
FILE *fp;
fp = fopen("data", "w");
fwrite (buffer, retCount, sizeof(ViByte), fp);
fclose(fp);
viClose(defaultRM);
viClose(vi);
delete []buffer;

Answer 1

Simone,
this has to do with LabVIEW running on multiple platforms with different End-of-line signals.
With Windows this is usually 0x0d0a, which is the ASCII control code for . Other platforms use typically just one of those characters; I believe with MacOS there used to be just a 0x0a and with Unix this might have been 0x0d.
In order to avoid hazzles, the LabVIEW develloper decided to convert the platform-specific End-of-line signals into a LabVIEW-internal character (which is 0x0a) when reading strings and back when sending strings out of LabVIEW.
So, your device sends out 0xd0a and LabVIEW removes the 0x0d. Everything is OK.
Greetings from Germany!
Uwe