RS232 - No data read when VISA port is not reconfigured before each Read/Write

[bluespacetiger]

Hi, before I begin let me say that I am relatively new to labview and to the world of intrument control.

I have an RS-232 device that accepts ascii messages. I find that I can send commands and recieve the expected responses, but once I try to do this multiple times (write, wait, read, write, wait, read etc), I often do not recieve responses.

The only way I have found to solve this issue is to perform a VISA configure serial port and VISA port close before and after (respectively) every write/read combination. Having tried to find a solution to this it seems that this is not good practice at all and I would love to know what is wrong and how to rectify the problem. I have tried everything I can think of (various delays before new read/write combinations for example) but to no avail.

I have included an example of one such send/recieve combination written in labview. The idea is to run the subVI here in a loop or one after another, but I find I get the described problem. I will upload an example of such a scenario if anyone thinks it would be helpful.

The command sent in the example has the following information in the device manual:

GPV,

response: 2 Bytes

(1)00hex .. FFhex high byte of SGH temperature

(2)00hex .. FFhex low byte

Other potentially useful information: I was having this problem even whilst opening and closing ports each time. Removing all "VISA clear" operations fixed the issue.

Below is the information I have about the "RS232 Parameters" for the device that I have done my best to understand, included unless there is some obvious information here that I have missed.

"

Baud Rate: 9600 ... 230400

Data bits: 8

Parity: no

Stop bits: 1

Handshake: DTR-CTS

Interface cable requirements: 9pin Sub-D wired 1:1

ControllerPC

2 TDXRXD 2

3 RXDTXD 3

5 GNDGND 5

1 DCDDCD 1

6 DSRDSR 6

7 RTSRTS 7

4 DTRDTR 4

8 CTSCTS 8

"

It is possible I have uploaded the wrong VIs as I don't have labview on the computer on which I am writing this so if they don't make sense, please say.

Hopefully someone here can help me with this.

[nyc_(is_out_of_here)]

Since it appears this instrument is using hardware handshake you need to wire the correct constant to the Flow Control input on the VISA Configure Serial Port. The default is None which is how your VI is set up.

[bluespacetiger]

Thanks for the reply.

I tried flow the flow control for another problem*, but I'll definitely have another look at it. Which should I pick though? There's RTS/CTS and DTR/DSR options for the flow control input, but the device says it uses "DTR-CTS". Any thoughts?

*The other problem was the same behavior even when opening and closing the serial port each time, which was resolved by removing all clearing of the port.

[nyc_(is_out_of_here)]

No clue. You might want to contact the instrument manufacturer.

[bluespacetiger]

I've tried all the flow control options for the VISA Configure Serial Port VI, but none make any difference to the problem. Any other ideas?

I've attached an example of an attempt perform multiple reads and writes, in case I've done something obviously wrong.

I've tried running with and without the shift registers for the VISA resource name and error wires; with the shift registers I started getting "Error 1073807253 occured at VISA Read" which I got rid of by adding the 100ms wait and flush buffer as detailed here.

I've also tried adding waits of various lengths in sequence structures at every part of the program, which has no effect on the problem. In the included file I get results that follow this sort of pattern: 280 (expected value), 0, 1.8612 (not expected), 0, 1.84159 (not expected), 0, 1.8153, 0, etc... When I get expected or unexpected reads is not consistent (I think it's probably to do with how I'm extracting the numbers), but every other read is always a zero.

I fear I'm just going to have to open and close the serial port each time. Are there any serious problems with doing this? The final program will have to run for quite long periods of time (up to a few hours) with only occasional readouts from the instrument. I suspect I may just have to deal with this problem and include checks for wierd responses...

[nyc_(is_out_of_here)]

Maybe it is time to take a step back and take VISA and LabVIEW out of the picture.

Are you able to communicate with the instrument using a program like Hyperterminal?

[johnsold]

Please post the GPV.vi as the actual communications is done inside that and we cannot tell what is happening without it.

Typically when 0 shows up it indicates that the read terminated without actually getting any data or that the remote device sent 0 (and possibly the other unexpected values) because it had not yet acquired the next reading.

Lynn

[bluespacetiger]

Hi, thanks for replying. GVP.vi should be attached to my original post.

Also, I haven't tried using other programs, but will definitely give hyperterminal a go and report back.

Thanks again.

[johnsold]

I have not used VISA events so my comments are not based on experience.

1. You have enabled a Serial Character event. If the event fires on the first character, it seems possible that you might miss later characters.

2. After you read the string from the port, you search it for a carriage return.  The protocol you described in the first post does not mention the carriage return.

3. You have handshaking turned off although you said the device uses (non-standard) handshaking.

First, I would find out whether the device sends a carriage return at the end of each message.  This makes a HUGE difference in how you program the communications.

Second, you need to determine how may characters are being sent in response to the command.  Can it vary?

Third, contact the vendor of the device and find out what kind of handshaking they are really using.  Most handshaking is handled at the hardware (UART) level and the non-standard handshaking may not work with some ports.

Let me make a set of assumptions:

1. You shut off the handshaking.

2. The device (a) sends a carriage return at the end of each message or (b) you know the exact number of characters in the response.

Under these assumptions you do not need the VISA events. You do not need Bytes at Port.  You do not need a long delay. You do not need the sequence structure.

For 2(a) Enable Termination Character at configuration and set the termination character to carriage return. Then set byte count on VISA Read to a constant larger than the maximum number of characters in the message (including the carriage return).

For 2(b) Disable Termination Character at configuration. Set byte count to the exact number of chracters in the response.

Of course if my assumptions are not correct, then some other approach may be needed. Regardless, I think you are making it too complicated.

Lynn

[bluespacetiger]

Thanks for your lengthy reply Lynn.

If I may explain a bit, I'm coming to this without any background in instrument control and have been using another person’s code for this instrument (that I was assured had worked, although seemed to also suffer the inconsistencies I described) as my starting point. The search for the carriage return was his way of getting the 2 bytes of information from the read string and seems to work. I don't have any evidence that the device gives a carriage return at the end of each response but given this gives the correct numbers it presumably does?

Your set of assumptions is correct apart from me shutting off the handshaking. I can't see any way to do that on the device, is it something that can be done from the computer? (As I said, I'm rather new to this.) Will having the handshaking set to none in LabVIEW make the program more unstable?

I know the number of bytes that the response consists of and have removed the "VISA Bytes at serial port" VI, instead wiring the required number of bytes (2) directly into VISA Read. This seems to solve the problem (hooray!), so thank you very much.

With regards to the other points:

I used VISA events as it was suggested by another user instead of setting a particular amount of time to wait between the write and read, as this time is apparently not consistent. Do you know of a better way to handle the time to wait between writing and reading? Should I just go back to using a set time period? Or perhaps I could use a loop that reads the number of bytes at the port and waits for that to be 2? I am wary of the latter as this experience seems to suggest that the "number of bytes at port" VI is a little temperamental with my setup (no doubt because of my ineptness).

What does disabling the termination character actually do? I've tried running with it both enabled and disabled and both seem to work.

Feel free to refer me to some article somewhere rather than replying directly, I am aware I'm asking quite a few rather fundamental questions! I really hope to understand this as there are other commands I have to send to the instrument, some of which give longer responses that I have to pick the correct bytes from.

Thanks again.