Windows OS determinism problem

[chris_1243]

Thank you for all the advice! If I want to periodically see the Encoder Count indicator, it is simple enough to write to a global variable and then place this global variable in my Event structure timeout state that updates every 250ms (that is what I am doing now for some indicators). I would prefer a more elegant way and you suggest using User-Defined events or even queues. However, I assume I should not send a user-defined event every 5ms either so would I need to have my loop control how often to send the user-defined event? If that were the case, then it seems like I might as well just control how often it writes to the Indicator directly and not use user-defined events at all. This is why creating an elegant dedicated UI thread has always been a mystery to me. If I use queues, I could dequeue the last element and then flush the queue or maybe configure it only ever keep one item in queue. 

[nathand]

For periodic updates, a global (I'd consider a functional global here) in the timeout case is a reasonable approach. You could also use a notifier (which is like a single-element queue where adding a new element overwrites the existing one). You can also put this in a separate loop, independent of the event structure, if you want more regular user interface updates (otherwise, if the user executes a series of actions in rapid succession, the timeout may not execute for a while), but that's rarely necessary. Depending on how your system is structured, you might even read the encoder directly in the timeout case, in addition to wherever else you read it. User events are better for updating indicators that get triggered infrequently or at irregular intervals.

[Ben]

nathand has been giving a lot of good info in this thread and I do not intend to preempt his good work. I am chiming in only to offer witness that I have run a hardware driven Timed Loop in a Windows environment at 2Khz and did not revieve any "Finished Late" indications.

The loop was;

configured to derive its clock from a hardware device,

ran as a sub-VI,

No messing with priorities required,

pushed updates to a queue that I had pre-allocated (filled then emptied prior to the loop running)

So it can be done.

The symptom of "mess with the UI and it slows down points to the UI thread bottleneck.

I now return you to your normally scheduled program.

Ben

[chris_1243]

I gave my subVIs high priority and reduced my UI to an subVI that only shows a couple of indicators that update once per second. I still ocassionally see that some of my loops run >150ms between iterations even though 99.9% of the time they run around 5-10ms per iteration. My main VI that had a lot of indicators on its FP is now "Hidden" at program startup because I only want my UI subVI FP to display to the user. If a VI FP is "hidden", can it still effect the UI thread and performance of the system? I assume not because it is not being redrawn as it is not displayed to a user. 

[Ben]

The Execution Trace Toolkit will answer all questions.

Admitedly, it will take some time to set-up and anlyze but it is a great eduatction tool that will give you insights and take-way lessons that you will be able to use aal of yout LV life.

If you can throttle to frequency of GUI updates and consolidate those updates to a sinlge place in the application then used the FP>>>Defer_Updat (defer front panel updates) when set true will prevent an update fo the GUI for each control but will consolidate all of the updates and only refresh again when the DeferUpdat is set false.

Defer before the updates.

Update all

Undefer

Ben