MultiThread and Multi DC
-
My project is about data acquisition from 4 sensors through USB port and show the data on PC monitor in graph.The read data from each sensors is so fast(less than millisecond) So,I separate 4 thread for draw graph in each sensor. Because all thread use same device context, before each thread drawing it still waiting for each other. Please advise me some solution for make 4 thread and each thread has the private DC. I mean when the data occur the thread can draw without waiting for other thread.
-
My project is about data acquisition from 4 sensors through USB port and show the data on PC monitor in graph.The read data from each sensors is so fast(less than millisecond) So,I separate 4 thread for draw graph in each sensor. Because all thread use same device context, before each thread drawing it still waiting for each other. Please advise me some solution for make 4 thread and each thread has the private DC. I mean when the data occur the thread can draw without waiting for other thread.
I think you'll find you can only use a DC on the same thread on which the window was created. In general, the best method is to share the data with a UI thread, which will then draw it.
Max++ wrote:
The read data from each sensors is so fast(less than millisecond) So,I separate 4 thread for draw graph in each sensor.
Can you define what you mean by 'fast (less than millisecond)'? If you mean 'updates every millisecond, then you're not going to have too much luck just collecting it in threads in Windows - Windows isn't designed for those sorts of response times - unlike an RTOS.
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
-
My project is about data acquisition from 4 sensors through USB port and show the data on PC monitor in graph.The read data from each sensors is so fast(less than millisecond) So,I separate 4 thread for draw graph in each sensor. Because all thread use same device context, before each thread drawing it still waiting for each other. Please advise me some solution for make 4 thread and each thread has the private DC. I mean when the data occur the thread can draw without waiting for other thread.
Google for "mtgdi sample".
It is a crappy thing, but it's life -^ Carlo Pallini
-
My project is about data acquisition from 4 sensors through USB port and show the data on PC monitor in graph.The read data from each sensors is so fast(less than millisecond) So,I separate 4 thread for draw graph in each sensor. Because all thread use same device context, before each thread drawing it still waiting for each other. Please advise me some solution for make 4 thread and each thread has the private DC. I mean when the data occur the thread can draw without waiting for other thread.
As Stuart said you should only use a DC from the same thread as the window was created. But I consider that a minor problem as I believe that you don't need multiple threads for drawing the graphs. Read on... ;) I've written quite a few (>25) applications with similar functionality, so perhaps I can contribute with some thoughts. You have to distinguish between the different layers in your application. You have at least three layers here that should not be mixed up: the hardware layer, the data acquisition layer and the presentation layer.
Max++ wrote:
The read data from each sensors is so fast(less than millisecond) So,I separate 4 thread for draw graph in each sensor.
Here's the mix up. Even though your sensors can barf up measured data at that rate, it doesn't necessarily mean that the data should be presented to the user at the same rate, or in other words "in real-time". There's no point since the human eye cannot cope with that speed. You need to think about the requirements of your application; shall it e.g. be possible to save the sampled data and what is the sample frequency, or is it just for presentation? Perhaps the data acquisition layer should save every sample, but the presentation layer only need to ask for the current value of each sensor at e.g. 2Hz rate. You have to tell us more about the requirements of your application for us to be able to suggest a suitable design. But, based on my experience of common demands for such an application, I would suggest to have the following in mind:
- The main (UI) thread is responsible for drawing all the graphs that are supposed to be presented to the user and would update the graphs on timer based events with rather low frequency, e.g. 2Hz to 5Hz. This would be the presentation layer.
- The hardware layer continuously issues read requests in a "reading worker thread" with calls to
::ReadFile()that will return one or more data samples. They should probably be put in a queue from which the data acquisition layer can read them. In order to prevent immense memory allocation and deallocation I suggest using reference counting smart pointers as elements of the container. - If the gathered data needs some kind of interpretation, each sensor could have a thread that collects the data and save it in e.g. list in order to be able to save it later. When this thread runs it moves the data from the queue shared with the hardware layer into the its own
-
As Stuart said you should only use a DC from the same thread as the window was created. But I consider that a minor problem as I believe that you don't need multiple threads for drawing the graphs. Read on... ;) I've written quite a few (>25) applications with similar functionality, so perhaps I can contribute with some thoughts. You have to distinguish between the different layers in your application. You have at least three layers here that should not be mixed up: the hardware layer, the data acquisition layer and the presentation layer.
Max++ wrote:
The read data from each sensors is so fast(less than millisecond) So,I separate 4 thread for draw graph in each sensor.
Here's the mix up. Even though your sensors can barf up measured data at that rate, it doesn't necessarily mean that the data should be presented to the user at the same rate, or in other words "in real-time". There's no point since the human eye cannot cope with that speed. You need to think about the requirements of your application; shall it e.g. be possible to save the sampled data and what is the sample frequency, or is it just for presentation? Perhaps the data acquisition layer should save every sample, but the presentation layer only need to ask for the current value of each sensor at e.g. 2Hz rate. You have to tell us more about the requirements of your application for us to be able to suggest a suitable design. But, based on my experience of common demands for such an application, I would suggest to have the following in mind:
- The main (UI) thread is responsible for drawing all the graphs that are supposed to be presented to the user and would update the graphs on timer based events with rather low frequency, e.g. 2Hz to 5Hz. This would be the presentation layer.
- The hardware layer continuously issues read requests in a "reading worker thread" with calls to
::ReadFile()that will return one or more data samples. They should probably be put in a queue from which the data acquisition layer can read them. In order to prevent immense memory allocation and deallocation I suggest using reference counting smart pointers as elements of the container. - If the gathered data needs some kind of interpretation, each sensor could have a thread that collects the data and save it in e.g. list in order to be able to save it later. When this thread runs it moves the data from the queue shared with the hardware layer into the its own
Thanks a lot Roger. Your answer and solution very useful for me and also difficult for me to finish it. Actually, my sensor is A/D concept that some time need to measure AC voltage and show the data in real time, look like oscilloscope. if you have some link, book or example for this concept. Please advise me. Thanks
-
Thanks a lot Roger. Your answer and solution very useful for me and also difficult for me to finish it. Actually, my sensor is A/D concept that some time need to measure AC voltage and show the data in real time, look like oscilloscope. if you have some link, book or example for this concept. Please advise me. Thanks
Max++ wrote:
measure AC voltage and show the data in real time, look like oscilloscope.
I'm suspicious about this requirement. If you have an oscilloscope, connect it to an AC signal and let it run freely as in "real-time", all you'll see is a blur. To have it make sense you'd have to use the trigger functionality. You have to describe what the purpose is, as in "what will the user do with the graphs presented in front of him". My point is that you probably won't need to present every sample to the user as soon as it arrives. If this is for e.g. signal calibration it would probably do quite well if the graphs were updated twice per second. Perhaps every sample should presented in that case, but you can disregard from the "real-time" problem.
Max++ wrote:
if you have some link, book or example for this concept.
Regarding how to call
::ReadFile()and how get the data, you may find this article[^] to be useful. It's about serial port programming, but the concept of reading is the same."It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown -
Max++ wrote:
measure AC voltage and show the data in real time, look like oscilloscope.
I'm suspicious about this requirement. If you have an oscilloscope, connect it to an AC signal and let it run freely as in "real-time", all you'll see is a blur. To have it make sense you'd have to use the trigger functionality. You have to describe what the purpose is, as in "what will the user do with the graphs presented in front of him". My point is that you probably won't need to present every sample to the user as soon as it arrives. If this is for e.g. signal calibration it would probably do quite well if the graphs were updated twice per second. Perhaps every sample should presented in that case, but you can disregard from the "real-time" problem.
Max++ wrote:
if you have some link, book or example for this concept.
Regarding how to call
::ReadFile()and how get the data, you may find this article[^] to be useful. It's about serial port programming, but the concept of reading is the same."It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown -
if the data update every 1 millisecond.I get data and move it to some variable, after finish 1000 data I draw graph one time.That mean draw every 1 second. Can you tell me, Is this oscilloscope concept?
Max++ wrote:
if the data update every 1 millisecond.I get data and move it to some variable, after finish 1000 data I draw graph one time......Is this oscilloscope concept?
Well, 'yes' and 'no'. You can configure an oscilloscope to behave similarly (depending on the model of course). But you can also configure an oscilloscope to behave differently, it all depends on how you want to display the measured values in order to analyse them. If this is suitable for the purpose of your application, go ahead and implement it. You have at least removed your problem about all threads with different DCs drawing to the same window, which was your original issue. If you need a more specific answer you have to describe how your application is supposed to be used and for what purpose.
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown -
Max++ wrote:
if the data update every 1 millisecond.I get data and move it to some variable, after finish 1000 data I draw graph one time......Is this oscilloscope concept?
Well, 'yes' and 'no'. You can configure an oscilloscope to behave similarly (depending on the model of course). But you can also configure an oscilloscope to behave differently, it all depends on how you want to display the measured values in order to analyse them. If this is suitable for the purpose of your application, go ahead and implement it. You have at least removed your problem about all threads with different DCs drawing to the same window, which was your original issue. If you need a more specific answer you have to describe how your application is supposed to be used and for what purpose.
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknownAs I mention that I have 4 sensor in my project including temperature, Humidity, voltage and current. All one is encoded with FPGA from outside and then send the data through USB port. My application's job is that get the data from USB and decode for separate data of each sensor, keep it to database and show the result on monitor. For the temperature and humidity the data update every second these is not the the problem. The problem for now is voltage and current sensor that update every 10uS and 20uS respectively.I have to keep it to database and also show data in real time on monitor. The graph that application draw should according to the voltage that sensor get such as the sensor is measuring sine wave voltage, so on monitor should show sine wave too. The concept look like oscilloscope but the different is my application show only image no need to calculate the amplitude and frequency. Can you suggest the best way to manage these data.