Serial configuration

[MartinManscher]

I have a hardware device that communicates using the RS232 protocol. If test it using Windows' HyperTerminal program (with settings 115200 bps, 8 data bits, no parity, 1 stop bit, no flow control), communication with the hardware device works fine (I can write commands and get a correct response immediately). I have been trying to implement this in LabView using "VISA Open" to open the port (works fine), "VISA write" to write the commands (seems to work fine), and "VISA Read" to read the commands. However, "VISA Read" times out most times (even with long timeout), and in rare cases I get part of the correct response (the first few bytes out of ten, it seems). I have tried all conceivable serial port settings, termination character settings, etc., but to no avail.

Does anyone know what the correct port settings are (that would make the serial protocol as in HyperTerminal). Or could it be something else, like asynchronous/synchronous i/o?

Martin

[Dennis_Knutson]

Often this type of problem is that you are not sending the correct termination character on your writes. VISA Configure Serial Port only sets a termination character for reads. It can be modified or you can simply use concantenate string to add the termination character. Use the constants on the string palette. You can also do this directly on your string control where you enter your commands but you must first turn on '\' Codes display and then enter either \r or \n (or maybe both - check the instrument manual). Another common cause for serial read timeouts is incorrectly setting the number of bytes to read. Instead of specifying a number, use VISA Bytes at Serial Port to determine exactly how many bytes are present. Wire the result of this to your VISA Read.

[MartinManscher]

Your suggestions seem to have helped me along the right path. "Bytes at serial port" reports zero bytes most of the time, but 12 bytes some times, which could be correct, but is different from the 10 I expected. In a test, I got a correct number of bytes 56 out of 813 times. There does not seem to be any difference whether I do I/O sychronously or asynchronously.

The specification from the hardware manufacturer specifies one start bit, which I can't find in the serial config. I suppose this is standard?

But I have a feeling that we're getting closer. Any other ideas?

Martin

[LuI]

Martin,

you wrote:
> "Bytes at serial port" reports zero bytes most of the time, but 12 bytes some times, which could be correct, but is different from the 10 I expected.
Could the overdue 2 bytes & , e.g. 0x0d & 0x0a? Serial comm with external devices often uses a kind of basic teletype-like protocol, which means to control the cursor position like in a typewriter.

> In a test, I got a correct number of bytes 56 out of 813 times. There does not seem to be any difference whether I do I/O sychronously or asynchronously.
In this kind of app this should not give a difference. Asynchronous I/O means nothing than that other task can perform while the I/O is happening.

I did not really get your point '56 out of 813 times'. Does this mean your communication is working just roughly in 7% of the attempts? This would not be OK!
You may estimate, how long it takes to transfer your command to the device, how long the device operates on it and how long the answer needs back. Wait that period and maybe some few extra ms until you check for "Bytes at serial port". Otherwise you may check for an answer when it is just on its way, but has not yet arrived.

> The specification from the hardware manufacturer specifies one start bit, which I can't find in the serial config. I suppose this is standard?
AFAIK this is standard.
AND I have searched for this in the VISa serial comm support VIs, with no success.
AND I can't remember having accessed this ever (and I have done serial comm with Lv since > 10 years now).

HTH and
Greetings from Germany!
--
Uwe

[MartinManscher]

Uwe,

Unfortunately, your interpretation is correct. About 7% of the time I get a correct answer using Labview communication, but it always works in HyperTerminal. Delays between reads and writes don't seem to help. The correct reads seem to come at random.

The extra characters seem to fit with the protocol (are not terminal control characters), but this does not fit with the specification I got.

Martin

[MartinManscher]

I now found out that the hardware device does not send a termination character. Does anyone have experience in communicating without termination characters?

I have turned off the option in VISA Configure Serial Port, but now VISA read just times out.

Martin

Message Edited by MartinManscher on 03-03-2005 09:10 AM

[Dennis_Knutson]

The fix for instruments that don't send a termination character is usually just using VISA Bytes at Serial Port. What you may need to do is put a small delay after the write in order to give the instrument time to process the command and transmit it. That might be the reason you often see 0 bytes. As a quick check, you can set a breakpoint on the VISA Bytes and manually wait before executing it.

[LuI]

Martin,
as Dennis already pointed out, when the device is not sending a termination character, you have to go one step back, relying on 'Bytes at serial port' and your own protocol handling. What you can do is some BASIC-like statements):
Open & Configure your serial port as requiered
Create a While loop and a shift register, that is initialised with an empty string
Create another While loop with a shift register inside the first one
While not done (outer while loop)
send a command to your device
connect the shift registers of the outer while with that of the inner one
While not a complete answer received (inner while loop)
Wait -say- 5 ms
Get 'Bytes at serial port'
If that is >0 than
Read those Bytes, append 'em to the content of the inner loop shift register
EndIf
Check if the inner shift register now contains a complete answer
If yes, remove it from the shift register and return it by ending the inner While
(You may also add some timeout capabilities here)
WhileEnd
If a timeout occured than
Create an error cluster, maybe do some error handling when apropriate
Else
Display the answer,
process the answer or even better send it (with a queue or so) to an independend process for processing
EndIf
bring any remaining bytes in the inner shift register to the outer one
WhileEnd
Close your serial port

This is quite robust style. It can be capsulated into just a single SubVI 'mµ serial comm VI'.

HTH and
Greetings from Germany!
--
Uwe

[MartinManscher]

Dear Dennis and Uwe,

I have tried waiting and then reading the number of bytes at the serial port, but to avail. Still, the help from both of you has been very much appreciated. Thank you very much or your time.

I will of course continue working on the problem and post the solution if I find one.

Martin