01-16-2019 04:55 AM
I'm glad you eventually find your way into it.
I just want to comment that I normally use the opposite approach: I spawn threads for data acquisition and test control and want them to be responsive (so I set them to no sleep) and leave in SLEEP_SOME the main thread (which handles the user interface and is normally less important to me).
01-24-2019 07:03 PM
Hi Robert, I looked at your approach as I got sometime to improvise the system, but I have few questions regarding your approach of creating a Win32 event to sync process and EveryNSamplesCallback setting the event and wait for it in the thread loop approach. I am assuming all your task creation, event creation and setting event call backs (EveryNSamplesCallback ) will be running from main thread? If it is true, how are you prioritizing setting the event if you have SLEEP_SOME/MORE in main thread? In my case, the sample rate of each module is close to 1 msec so main thread is becoming un responsive with this approach.
01-25-2019 01:59 AM
The whole stuff regarding data acquisition in my framework is handled in separate threads: the thread function prepares tasks, channels, events and so on, starts the task and sits in a loop simply waiting for events to be fired either by a timeout or by EveryNCallback function.
This way I can configure threads with NO SLEEP, have them responsive but consuming very little system resources and have the main thread (set to SLEEP MORE) handle the UI with little or no delay.