Not really, since the serial port simply receives characters; it doesn't do
anything special if one of the characters is a carriage return.
Your method of stringing many "match pattern"s together is horrible. What I
suggest doing is writing a VI that runs continuously and every so often,
depending on how fast data is coming in and how large your serial port
buffer is, read the data from the port and append it to a "buffer" string
inside your monitor VI. This VI then goes into a while loop where a "Match
Pattern" function scans the buffer string for a carriage return. If it finds
one, it splits out the string before the CR, dumps the CR itself, writes the
string before the CR to a queue and writes the rest of the string back to
the shift register. The loop goes round again and the process continues
until there are no more CRs left in the buffer, and what's left is either
nothing or is the first few characters of a new message. The loop
terminates, you do the serial port read again, the unfinished message is
completed along with grabbing any more messages and the process begins
again.
You'll need some way of signalling the program to quit when your main
application terminates; a simple way would be to have the monitor VI create
the queue, and before writing messages to it see if the queue still exists;
if not, quit. This way your main application can simply close down the queue
on completion and the serial port monitor will die.
Once this program is up and running, your main application simply checks the
queue every so often to see if any messages are waiting- if so, then each
queue entry you retrieve is a single, complete message.
The only way you can lose messages this way is if you have a serial buffer
overflow, in which case you need to decrease the loop delay in the monitor
VI.
Ed Dickens wrote in message
news:934kbn$fsk$1@nnrp1.deja.com...
> Greetz All,
>
> I'm building a function to read messages on the serial port that vary
> from 2 to 10 bits in length, and are separated by a carage return.
>
> What I would like to be able to do is look at the port and scan for the
> carrage return, then grab all the data before the CR and dump it into
> an array.
>
> What I have now is this. I grab all the data at the port in a 10ms
> scan, then run the string through a series of "Match Pattern" vi's that
> are daisy chained together. These look for the CR, then pass the bits
> before the CR out to the array, and pass the rest of the string on to
> the next "Match Pattern", and it looks for the next CR.....
>
> Is there a way to scan the port for the CR then do a read so I can grab
> one message at a time so I'm sure I don't miss any messages.