Strategy for polling device on separate thread [Updated]
-
I have an Ethernet connected motion controller that I need to get information from. I'm using WPF (C# flavor) for the project. The goal is to get data from the device as fast as possible so the UI doesn't seem sluggish. My thought was to spin off a background task that constantly polled the device for information as fast as it could run. It would fire events when certain groups of data were updated. Another class would monitor for these events and then set dependency properties that would update the UI. I have a couple questions: 1) What is the best way of starting the background task? I want it to close when the main thread is closed and not stop the main thread from being closed. 2) Any helpful advice as to how data can be retrieved on one thread that will eventually be displayed on a different thread. I have only toyed with multi-threaded applications up to this point. I'd rather ask and do it right than to find out later there was a better way. [UPDATES] This is on a closed network on the machine. It is not going over a corporate network. The device does not fire events. It has an API that allows data to be requested and then it replies. Right now I am using a DispatchTimer to request updates at a regular interval. It is running at 25ms without any issues. I was looking at trying to free my UI from my polling routine in case the device locks up or stops responding.
Brad If you think you can, you will. If you think you can't, you won't. Either way, you're right.
-
I have an Ethernet connected motion controller that I need to get information from. I'm using WPF (C# flavor) for the project. The goal is to get data from the device as fast as possible so the UI doesn't seem sluggish. My thought was to spin off a background task that constantly polled the device for information as fast as it could run. It would fire events when certain groups of data were updated. Another class would monitor for these events and then set dependency properties that would update the UI. I have a couple questions: 1) What is the best way of starting the background task? I want it to close when the main thread is closed and not stop the main thread from being closed. 2) Any helpful advice as to how data can be retrieved on one thread that will eventually be displayed on a different thread. I have only toyed with multi-threaded applications up to this point. I'd rather ask and do it right than to find out later there was a better way. [UPDATES] This is on a closed network on the machine. It is not going over a corporate network. The device does not fire events. It has an API that allows data to be requested and then it replies. Right now I am using a DispatchTimer to request updates at a regular interval. It is running at 25ms without any issues. I was looking at trying to free my UI from my polling routine in case the device locks up or stops responding.
Brad If you think you can, you will. If you think you can't, you won't. Either way, you're right.
BRShroyer wrote:
My thought was to spin off a background task that constantly polled the device for information as fast as it could run
This is a very bad idea resulting in a very high system and network load. You should check if the motion controller provides some kind of notification messages (sending data to an established network connection). Using a worker thread for such network communications is the common and best way. To stop such a worker thread, it is usally listening for a terminate event (besides the communication events) that can be signaled when your application terminates. To pass data from the worker thread to the main (GUI) thread and vice-versa you must implement some kind of inter-thread communication. How to implement threads and inter-thread communication depends on the used language.
-
BRShroyer wrote:
My thought was to spin off a background task that constantly polled the device for information as fast as it could run
This is a very bad idea resulting in a very high system and network load. You should check if the motion controller provides some kind of notification messages (sending data to an established network connection). Using a worker thread for such network communications is the common and best way. To stop such a worker thread, it is usally listening for a terminate event (besides the communication events) that can be signaled when your application terminates. To pass data from the worker thread to the main (GUI) thread and vice-versa you must implement some kind of inter-thread communication. How to implement threads and inter-thread communication depends on the used language.
I've updated my post with some more information. Basically, this is on a closed network. There aren't any other devices connected. Also, this will be in C#. Thanks for the advice.
Brad If you think you can, you will. If you think you can't, you won't. Either way, you're right.
-
I have an Ethernet connected motion controller that I need to get information from. I'm using WPF (C# flavor) for the project. The goal is to get data from the device as fast as possible so the UI doesn't seem sluggish. My thought was to spin off a background task that constantly polled the device for information as fast as it could run. It would fire events when certain groups of data were updated. Another class would monitor for these events and then set dependency properties that would update the UI. I have a couple questions: 1) What is the best way of starting the background task? I want it to close when the main thread is closed and not stop the main thread from being closed. 2) Any helpful advice as to how data can be retrieved on one thread that will eventually be displayed on a different thread. I have only toyed with multi-threaded applications up to this point. I'd rather ask and do it right than to find out later there was a better way. [UPDATES] This is on a closed network on the machine. It is not going over a corporate network. The device does not fire events. It has an API that allows data to be requested and then it replies. Right now I am using a DispatchTimer to request updates at a regular interval. It is running at 25ms without any issues. I was looking at trying to free my UI from my polling routine in case the device locks up or stops responding.
Brad If you think you can, you will. If you think you can't, you won't. Either way, you're right.
The System.Threading.Timer can help you: its callback function does not run in the thread the timer was created.