How to read from RS232 in parallel with other procecces

[RunnerBoy]

I am developing an real-time DAQ-applikation that write a command and reads data from the RS232-port every second at the (overhelming 😉 speed of 2400 bits/s. The trouble is that every incomming string is over 70 bytes long so it takes about 1/4 of a second to receive. Parallel to this I am measuring 4 analogue signals with sample rate 1 kHz which I display in a chart with update every 100 ms. Blocking the GUI (and processor) for 1/4 s is not an option. So you see this will not work, unless I read the serial-port in some kind of parallel background process/thread.

I hope to awoid struggelig with multiple theads/overlapped I/O on my own, and have found that LV supports different mechanisms to support parallel tasks, but as a newbie I find this topic sparse documented.

1) Is it easy as defining a sub-VI with VISA-write and VISA-read as in the example finder and set the VI execution property "Execution System" like "Instrument IO" ? Or do LV offer better and easier options.

2) How do I signalize to the main-VI that a complete string is received, and how do I share the string ? Global variables ?

3) How do I use the "Bytes at serial Port" function ?

Other tips and tricks are welcomed.

My programming skills are a bit rusty and I am a newbie to LV and 32 bit Windows (and this forum) so I hope to get some well based answers.

Regards RunnerBoy

[tbob]

Parallel threads are easy in Labview.  You just create two loops where the output of either loop is not connected to the input of the other.  Without this data dependency, the two loops run in parallel.  See the attached vi, my producer-consumer template.  Replace the random number generator in the top loop with your serial port code.  Put your other processing code in the bottom loop.  Use the queue to pass info from one loop to the other.  You can signal the lower loop when the serial port receiving is done by putting something on the queue that signifies the completion (like a "done" string).  Your lower loop will constantly check the queue, looking for the "done" string.  You can use a boolean if you remove the string wires and replace them with boolean types.

Bytes at Port will look at the serial port buffer and report the number of bytes sitting there waiting to be read.  Call it before you read, and pass the number from bytes at port to the read function.  Search the LV examples for serial port and you will see how bytes at port is used.

Message Edited by tbob on 10-04-2005 03:51 PM

[Ben]

Hi Runner!

You wrote

"

My programming skills are a bit rusty and I am a newbie to LV and 32 bit Windows (and this forum) so I hope to get some well based answers.

"

Tbob has given you an excellent example to start out with. It demonstrates that multithreading is a natural spin off of the grphical nature of LV. Being rusty may work to your advantage. You probably have expected to surmount a learning curve, and that is good because switching to LV from other environments will take a little getting used to. Stick with it, keep posting new questions and give us time to answer. For the most part, we are volunteers and can only answer question in our spare time.

Now regarding not being experienced in 32-bit Windows...

I will not go into the history and why Windows is so stupid but, it is! Your stated expectation of being able to do anything reliably at 100 Hz in Windows is not realistic. Now if your application can tolerate interuptions now and then, then you are OK. But if your application is going to suffer because it has been more than 500ms since the code last executed, then other approaches need to be used. But this is not directly related to your posted question and Tbob has already done a great job of answering that so I will leave the indeterminism of Windows for another thread.

Welcome to the Exchange and have fun!

Ben

[RunnerBoy]

Thanks to both of you.
This brings me a big leap forward.

How will this look like if I put the loops in two different (sub-)VI's ?

RunnerBoy

[tbob]

If you put each loop into a subvi, both subvi's would have to run in parallel.  I see no advantage to doing it this way.  If you want to make your data processing code into a separate subvi, keep the two loops in the main vi, and call the subvi from inside the consumer loop.

[RunnerBoy]

Thanks again tbob for swift answer.

My LV 7.0 Eval version (21 days more to go) was not able to open your ProducerConsumer vi (LV 7.1?). So I tried the ProducerConsmer.vi template provided with LV 7.0 instead. But it seems from your explanations that the two vi's are different, and yours is may be better suited for my problem.

Can you please post a screenshot of your vi ? (or Save as 7.0 if possible)

Regards

Runner Boy

[tbob]

Here is the 7.0 version.