This is a follow-up to the Developing a real-time data flow and control model with WCF post. My original plan was to write a full-fledged article on this. I've gotten some requests for the code, but it does not appear that I'm going to have time to complete the article in the near future. So I thought I'd just give a brief description here of what I've done so far and provide the code as is.
Please Note: The description provided is very brief and only meant as an overview. None of the implementation details are included here. It's not a very complicated project. If you have some VS2005 development experience and are willing to dig into the code, you shouldn't have a problem figuring it all out. Working through this code would provide a good first tutorial on developing with WCF. Some set-up is required (service installation) and is described below.
Motivation:
I originally conceived of this project because of some questions I'd heard from real-time C/C++ developers. They wanted to know about migrating from MFC/VC++ to .NET managed code. The primary concern was about the use of legacy device level code and how to manage future mixed development projects.
So my first thought was to demonstrate how easy straight forward it is to incorporate COM components into managed code with .NET wrappers. There are already many good articles on integrating old Win32 projects into .NET. e.g. Do you COM? Dealing with Legacy Projects. This project is a concrete example of how that can be done.
It also illustrates a model of the type of real-time data streaming and control typically required by a physiological monitor.
To extend that model, I wanted to show how WCF could be used as a network transport for that same data stream. Hence the previous post. The addition of a WCF client application that provided a real-time display of the data stream was only logical.
There are a number of directions that I had planned on taking this project, but that will have to wait for another day. I'm sure that you'll come up with your own ideas along with numerous improvements.
The Code:
The download (below) is a Visual Studio 2005 solution, called RealTimeTemplate, with 6 projects (one is C++, all the rest are C#). Here is a diagram of the projects and their relationship. The horizontal arrows show the data flow as described above.
The projects are:
- SineWaveGenerator: This is a C++ COM component that generates buffers of multi-channel sine waves.
- SineWaveGenerator.Test: The NUnit test functions for SineWaveGenerator
- SineWaveWCFLib: This is the WCF server component.
- SineWaveWCFServer: This the Windows service that hosts the WCF service (SineWaveWCFLib).
- SineWaveWCFService.Test: The NUnit tests functions for SineWaveWCFService.
- RealTimeDisplayWinForm: This is the Windows Form class, and WCF client, that controls and displays the sine wave data provided by the service. The graphical display is done using the ZedGraph library.
Here is what the Windows Form looks like when the application is running.
Service Installation:
In order to run the sine wave display application, you'll first have to install and start the SineWaveWCFService.
- Build the solution in Debug configuration.
- Execute the
InstallSineWaveWCFService.batin SineWaveWCFService\bin\Debug. The service can be un-installed with theUninstallSineWaveWCFService.batscript. - Run the Windows Services Manager (services.msc) and Start SineWaveWCFService.
- Run the RealTimeDisplayWinForm project. Use the Add button to add sine wave displays.
The source code can be downloaded here:
RealTimeTemplate_20070923.zip (210K)
Enjoy!
As my company, Full Spectrum Software, focuses on medical and scientific software, we’ve had the opportunity to build scads of data acquisition systems including neurodiagnostic, and other high-speed medical applications. There are a few critical aspects to doing this right and fortunately we’ve been at this a long time.
What we’ve found is that reducing friction within the system is absolutely critical. Friction points occur when threads compete for a common resource. The programming technique used to ensure data integrity is maintained is mutexing, a method of blocking access to a particular resource such as a FIFO buffer. This mutexing can cause contention between threads and therefore reduce data throughput. So you must mutex but do so for the shortest duration you can and only mutex when you must. There are several algorithms that work effectively here.
Another point of friction is calling through to unmanaged code from managed code. While the unmanaged code may be somewhat better performing, the marshalling and mode switch are often major performance hits. So use unmanaged if you must but weigh the cost first if you don’t and are working under the assumption that the performance will improve your system’s throughput.
sir , i did a zedgraph gravedyamic graph…… but nw i need a sine funtcion graph to be flow … continuous can u plz help in dis code
i need a code fr sine function grapg flow continuosly