Getting a parity error coming from VISA Read

[NewMachine]

Hello - I have a vi that uses VISA Write.vi then VISA Read.vi in a loop to read a meter but get a parity error during each iteration. When I put it in highlight execution mode I can see that it gets kind of stuck in the VISA Read until it just gives the temperature from the meter as well as the error. I have messed around and changed numerous configurations but it doesn't matter. Please advise!! thanks

[Dennis_Knutson]

The first thing to do is to check your communication settings in Hyperterminal or some other terminal emulator program and verify that your parity and data bits settings are correct. When VISA reports a parity error, you can usually assume that you have a mismatch between the instrument settings and the program. I'm also attaching a modified version of your VI. I eliminated the sequence structure because it's not necessary - you've got dataflow enforcing execution order. The VISA Clear does nothing with serial instruments. Lastly, you should only be doing a VISA Close once when you terminate the while loop.

[ScottieB]

Hyperterminal will certainly be helpful to make sure that you are getting valid data. You might also want to try VISA Interactive Control from Measurement and Automation Explorer under Tools...NI-VISA...Interactive Control. You will be able to exactly simulate the calls that are being made in your program such as writing and reading. Additionally, you will be able to see whether or not an error is returned from your read and what the error means. The basic problem here has got to be your stop bits, data bits, baud rate, or parity settings. VISA will not report a parity error unless the lower Windows API drivers do.

Scott B.
Applications Engineer
National Instruments

[NewMachine]

Hello - I checked the parity and stop bits and tried different configurations. I think it worked once but it wasn't stable, if I strayed from parity: odd and stop bits: 1. So I left it on that, and tried your program. The error I am getting now, seems to come from the exact place that all my problems with serial comm. come from: VISA Read. From your vi I get a timeout error at VISA Read and the second through fourth VISA Write after that. All my errors, whether it be a parity error, timeout error, etc all come from VISA Read. So, with your vi I can only read the first instrument, but then it seems to get stuck at read and is broken from there. Any suggestions? Thanks!

[ken.wan]

I get the same error before, when I try have a VISA communication with my instrument , it doesnt work at all. But it works on HyperTerminal. When I use the intercompatible serial read and write function, the error disappeared.

[NewMachine]

not only am i getting the errors but it does not return the temperature of the three remaining meters - i noticed that it gets very unhappy after the first set of write and read, and just dwells in the error. what seemed to be a work-around is that i wired the output of the visa read (resource name and error out) directly from the first visa write to the second visa write and i finally get no error. still i don't get the temperatures properly displayed. what is wrong with visa read?? thanks!

[NewMachine]

hello - i can't find "serial read" or "write". is this an example vi or something? thanks!

[ken.wan]

I can find it in 6.1,but can not find in 7.0.
I dont know which version you are using.

[ken.wan]

This is the icon of the read and write .

[rolfk]

NewMachine wrote:

> not only am i getting the errors but it does not return the
> temperature of the three remaining meters - i noticed that it gets
> very unhappy after the first set of write and read, and just dwells in
> the error. what seemed to be a work-around is that i wired the output
> of the visa read (resource name and error out) directly from the first
> visa write to the second visa write and i finally get no error. still
> i don't get the temperatures properly displayed. what is wrong with
> visa read?? thanks!

That is error cluster chaining. Once a LabVIEW function receives an
error on its error input it does nothing but simply passes that error
through. This can be used for error handling where you do for instance
not want to w
ait for an answer from an instrument with a 300 second
timeout when the command write already indicated that there was some
sort of error to communicate with the instrument.

Rolf Kalbermatter