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

[Albert.Geven]

if you need two characters ask for two characters and the default timeout of 10 seconds is more than long enough to cover a wait.

but maybe you have to specify all characters including the CR so maybe 3 or even 4 is the correct number of bytes to ask for.

[johnsold]

The Match Pattern function returns the entire input string in the Before Match output if no match is found. (Check the detailed help for the function). Since the VI does not verify that a match was found by checking the value of Offset Past Match, having the Match Pattern there essentially does nothing.

Turning off handshaking at the computer end will only cause a problem if the device at the other end tries to do some handshaking.  Typically in RS-232 systems handshaking is used to establish that a connection exists (DSR, DTR, DCD) and that buffers are available (RTS, CTS).  The connection handshaking came form modems operating over switched telephone lines. The buffer handshaking can occur on a byte by byte basis while communicating.  Most computers can communicate without buffer handshaking at modest rates. Your baud rate control has a default value of 15200.  This is not a standard rate.  Some computers and UARTs may not be able to manage non-standard rates.  Did you mean 19200 or 115200? If the remote device attempts to pause communication and the computer does not respond (due to handshaking being disabled), some data likely will be lost.  Whether you can disable handshaking in the device depends on the device.  There is no standard.

When Termination Characters are disabled at configuration, then the VISA Read will wait as long as necessary (up to the timeout) to get the specified number of characters. So if the device really does just send 2 bytes and no termination characters, then the Read will wait until 2 bytes have been received and return them.  No Wait (ms) required. And the function will wait exactly as long as is necessary to get the data and no longer.  Bytes at Port is useful when messages with unknown length and no termination characters occur.  This does not apper to be your situation.

When Termination Characters are enabled, the VISA Read will wait until the first of three things happens: A termination character appears in the string, the number of bytes at Byte Count has been received, or a timeout occurs.  You can tell which happend by looking at the Return Count and Error Out values.

The only problem you may see with wiring 2 to Byte Count is that if some characters have been sent as part of a previous message byt not read, they will show up first and you will get a partial message.  If the remote device is well behaved, this should not be a problem. I think Error Out carries a warning (but not an error) if more bytes are available than you read.

Note: Some of this may seem confusing. The "RS" in RS-232 stands for "Recommended Standard." But it only standardizes voltage levels and names of signals.  It does not standardize usage or the communications protocol. Any manufacturer of a device communicating via RS-232 is free to set it up however they want.  So this kind of trial end error and analysis of behavior of devices is unfortunately quite common. And of course there is nothing whih requires that manufacturer to document the communication protocol they actually implement.

Lynn

[Henrik_Volkers]

here is a test vi, it will send the write string if you hit write and read 2 characters wile reading all characters found at the COM and displaying them in '/' mode ...

do you see more characters than the two expected?

all handshaking and the termination character is turned off  since transmitted hex/byte values might match 😉

Also be careful when you continously requesting data. Since you get simple hex values, I assume only a simple controller that might not expect to much interrupts 😉

[bluespacetiger]

I stupidly forgot to mention I'm using labVIEW 7.1, so can't open your VI.

An update for you: I've tried all kinds of debugging I can think of. The manufacturer said to disable handshaking and that the termination character is a comma, although as far as I can tell this is merely needed at the end of commands to be written and isn't in any response strings. I shall queery this further with the manufacturer.

I've found that there are enormous inconsistencies in behaviour. Sometimes no bytes are written by VISA read. Sometimes after VISA read there are still bytes at port, which presumably is part of the cause of strange values being recieved. Switching between commands in particular seems to cause problems. The other two commands I am using are:

• "GSV" which responds with 8 bytes, the first two of which are the high and low bytes of the number I need.
• "SLYnnnn" (Set Lyot Filter), which responds with one byte, a number between 00hex and FFhex giving a status.

I've attached these too, and the VIs I'm using to test commands at the moment. I'm starting to wonder if part of this is a hardware issue, as I found just now that the manufacter's program seemed to be not working properly at the same time as my VIs weren't. Perhaps the RS232 cable needs replacing?

[bluespacetiger]

More attachments...

[johnsold]

I am away from my main computer so it will be a few days before I can respond more completely.

Comma is somewhat unusual as a termination character.  To try it you set the Termination Character Enable boolean input on Serial Config to True and wire a integer (U8) constant containing 44 decimal or 2C hex (the numeric values of the ASCII comma) to the temination character input.

See what that does.

Lynn

[bluespacetiger]

Thanks Lynn, I gave that a try already and it stopped things from working, hence me coming to the conclusion I did about it probably being just needed at the end of commands.

I may have found the route of the problem: restarting the device seemed to eliminate all problems. I shall talk to the manufacturer about firmware and see if more problems arise, but hopefully all will be well. Thank you again for all of your help thus far!