Architecture suggestions for serial comms based instrument control application

Question

I have just started a project to control an industrial instrument that communicates via RS-232 serial port. Baud rate is limited to 9600...fairly slow.

This instrument can operate in two modes - polled, where the PC sends a request, and the instrument replies with the data; or continuous, where the instrument sends a constant stream data. The data needs to be converted from ASCII to floating point numbers, and plotted.

My initial experiments with sample programs that use the SerialPort DataRecieved event were not auspicious...it was very easy to get the user interface to become non-responsive under continuous transmission from the instrument.

I've looked at other sample projects that spawn separate tasks, etc, but they all seemed quite complicated, and I'm wondering if there is a better way, especially with the capabilities of the newest .NET runtimes (4.5.1 as I write this).

Things like the Async API, and Dataflow look especially promising for this type of application. I've started experimenting with the Async API for receiving data. Code is very simple, but am having some issues with making it robust (exception handling).

Simplest approach seems to be to use async methods to parse the data into some kind of thread safe queue, which raises events to the UI for plotting. But I'm still working out the details.

Looking for suggestions on the best way to approach this.

Answer 1

Since you don't have very much processing to do, I suggest using the Rx (Reactive) framework which is built on top of TPL-Dataflow. Rx gives you much more flexibility in terms of processing streams of data (think of it as Linq for event streams) whereas DataFlow is better suited for setting up data pipelines where you want fine control over concurrency.

Having recently faced a similar problem, connecting up a GPS reader, I would suggest the following architecture....

• Set up a standalone thread to interface to the instrument.
• You can expose new readings via an event handler from this thread.
• You can then use the Observable.FromEventPattern method to construct an Rx Observable stream
• Subscribers to this stream can mutate the raw data into any form they like; in fact different subscribers could mutate it into completely different forms if it suits their needs.
• Since you're ultimately ending up at the UI, you'll need to use ObserveOnDispatcher at the point a subscriber wants to interact with the UI.

For further details, I would strongly recommend this document... http://go.microsoft.com/fwlink/?LinkId=208528