rs232 send and receive data

[raj129*]

Hi,

i am facing problem in sending and receiving data through rs232 interface.

In my case,Whenever my device is connected to COM port, device starts sending some messages contionusly.I need to read the message coming from my device, also dont know how many bytes it will transfer.
Based on the response coming from device, i need to send some bytes of data as request to the device.Again device will respond back based on my request and it goes on...
how can i perform this operation? pls help me out.

i am using ComRd() and ComWrt() to read and write data through RS232.
I am getting some error response from the device shown the attached picture.
assigned read_cnt to 100 where we dont know how many bytes device will transfer..

Thanks in advance.

[Wolfgang]

Hi,

no answer, just a suggestion: Usually, the most basic communication problems concerning serial ports can be solved faster using MAX. Once you are sure about parity bits, termination character and timeout period and are able to receive data using MAX, it is quite simple to do the same in CVI.

PS: Obviously your eyes are superior to mine; I could not decipher anything in the picture provided ...

[raj129*]

Hi Wolfgang,

thanks for your suggestion.

my setting will be like no parity bits, temination character as C0, and time period as some 2000ms. i dont understand MAX(defining any values to MAX???).

also have one question in this, i am receving so many messages from RS232 and i need to extract required messages alone from it...it is possbile by having any interrupts function something like that........

attached picture for clear view(response coming out from my device)

[RobertoBozzolo]

Since I read you have a termination character, using ComRdTerm can help you in keeping read from the serial port syncronized with the transmission.

[menchar]

Raj -

Roberto is onto it, ComRdTerm is the key to implementing logic that can pick a particular message out of a serial data stream.

It is a bit harder to do though than you might imagine at first.

You have to think through how to "catch" the required message - obviously there must be some identifying characteristic to it so that you can identify the message type.  If you have a common termination character you can ComRdTerm on that, then look "backwards" in the InQ for your message, BUT you also have to implement some sort of queue management so that you ensure you have the entire message you're looing for in the InQ in front of the term character.  This takes some clear thinking to implement, since the InQ will be continuously filling if you have continuously streaming messages, you need to periodically drain it somehow without clobbering the message you're after.  I don't believe you're guaranteed that the InQ throws out oldest data if it overflows.  It also matters if the message is transient (appears in the stream only once) or if it is periodic and you only need to get one them.  If it turns out that the scheme is such that incoming messages appear only in response to a sent message, and there's no other messages in the stream that need to be ignored, then it's a much simpler affair - a simple ComReadTerm on the terminator will work.

I can help you more if you can tell us more about the message format and how the messages are emitted by the sender.

Menchar

[menchar]

Thinking about this some more:

If your PC is fast enough to handle all of the serial messages (and it likely is with todays micros unless you're running a very fast bit rate on the serial comm), you can just read the serial port continuously, parsing and dispatching messages until you find the one of interest.  ComRdByte does a busy wait though if there's no byte ready in the InQ, so not very clever, but if your PC has plenty of cores then maybe you don't care if one of them is locked up with a spin-locking serial port reader.

You could sync up with the message stream by using ComRdTerm until you get the message termination byte, then you know the next byte is the start of the next message and you can do another ComRdTerm on the message termination character and you'd have a message and moreover you'd know that the next byte must be the start of the next message, etc. 

This wouldn't work if you had a perfectly intact message that you needed as the very first thing in the InQ, you'd wind up skipping over it to get synced up.  You could look at the start of the InQ to see if that was the case I suppose.

Some message schemes ensure that the message ID is a unique character in the data stream.  For example, a measurement data message might start with an 'M' and 'M' never appears anywhere in the character stream but as the start of that message type.  If this is the case, you can simply look for the unique message ID with ComRdTerm, then read the next bytes as the message with ComRdTerm set to the message termination character.

Menchar