bug? gpib read Windows 7

[fdinoff]

I am using the gpib read to read from an Oxford Instrument IPS 120-10.

I have the read configured to mode 1 which according to the help is supposed to stop reading from the buffer after the first Carriage Return (\r). However on Windows 7 using LabVIEW 2010 SP1 and NI 488.2 3.0 The read occasionally returns the full 80 bytes instead of stopping at the carriage return. I have the first few bytes of the output shown below in the string constant (set to display \ codes and the rest is \00 or null).

I do not think this was the inteded behavior because using the same version of LabVIEW on Windows XP (with the same code) did not cause these problems.

Can anyone confirm this?

I do not have any code that easily shows this and the code that I have that replicates this behavior takes between 30 and 60 minutes to show the problem.

[ColdenR]

Hello fdinoff,

I haven't found anyone else with a similar issue, so I'll look into replicating this issue. This might take some time, and there might not be an easy work-around. One question: When the read does not stop at the carriage return, does the string you read in from the IPS 120-10 include a carriage return? As in, does LabVIEW read in a carriage return and then not stop, or does the carriage return somehow not get received correctly?

For now, you can fix the issue with some post-processing. You can use the Match Pattern VI from the functions palette under Programming-->String. Then you can just match the string pattern for the carriage return and return from "before substring".

[fdinoff]

Yes there is a carriage return in the string that is returned. It is shown above in the orginal string right before all the null bytes.

[Albert.Geven]

Is it always the same block of code (I mean inside a subvi) or are there duplicates?

And I would check the error!

I suggest also to use visa instead of the gpib functions. It is a bit higher layer that also supports gpib and serial and tcpip and usb. So future proof.

[fdinoff]

I used a driver the ni site which was written in LabVIEW 5.0. (I think it was thrid party though)

It had a subvi which handled the the commands sent and read from the bus which is where I grabbed the settings for this gpib read. If I were to rewrite the driver right now I would use the VISA functions, However at the time I did not think it was nessasary because this driver already existed.

I will now go try and find the error code if there is one.

[fdinoff]

Found the error code.

Error 0 occurred at GPIB Read in (VI call heiarchy)

Possible reason(s):

LabVIEW:  Error connecting to GPIB driver or device.
=========================
NI-488:  Error connecting to driver or device.
=========================
VISA:  (Hex 0x0) Operation completed successfully.

Okay so the GPIB read just returned garbage when there was an error.

How come the program losses connection with the devices? (This never happended when this same unmodified program ran on Windows XP)

[Lars_L]

Could you post an NI-Spy (now known at NI IO Trace) capture of this issue occurring? You can find this by going to Start>>All Programs>>National Instruments>>NI Spy (or NI IO Trace). If you could provide two captures, one on XP and one of Win7 then we should hopefully be able to compare them and get a better idea of what might be happening.

Lars L