Event Loop Timeout Rate

[tpascaru]

A single iteration takes longer than 50ms. I haven't quantitatively measured the actual time under the two different scenarios. I presume the USB transaction is the major contributor to the time (although even that should take significantly less than 50 ms). There's also some processing that's done on the data.

I've done a good job connecting all the error-in and outs in my VIs, and I never see any errors when the response is improved.

Is it possible, that somehow windows is prioritizing the USB transactions because Labview is brought into a "focused" state? I'll try and put more metrics around different parts to isolate where the improvement is happening. It seems theres no magic bullet answer that I was hoping for 🙂 (i.e. set this property to xxx and performance is improved).

[Mark_Yedinak]

Why would you want your timeout event to be doing something that takes longer than the timeout itself? This doesn't make sense. You would be much better off simply reading the data from the device at a regular interval and post it to a parallel task to actually process and display it. If you use a notifier the parallel task will only process the latest data. Your gating factor than will be the processing time of the task, not the actual reading. You will be actually reading the data faster than you process it. If you need to process all of the data then you will need to use a queue. At that point you might want to only update the display at a slower interval since that will be one of the time consuming tasks. You could even do this is another parallel task.

The above suggestions may not answer or resolve why you are seeing the change in performance but it is a more robust architecture and will probably provide a consistent performance.

[Ben]

---

tpascaru wrote:

A single iteration takes longer than 50ms. I haven't quantitatively measured the actual time under the two different scenarios. I presume the USB transaction is the major contributor to the time (although even that should take significantly less than 50 ms). There's also some processing that's done on the data.

I've done a good job connecting all the error-in and outs in my VIs, and I never see any errors when the response is improved.

Is it possible, that somehow windows is prioritizing the USB transactions because Labview is brought into a "focused" state? I'll try and put more metrics around different parts to isolate where the improvement is happening. It seems theres no magic bullet answer that I was hoping for 🙂 (i.e. set this property to xxx and performance is improved).

---

Shot in the dark...

Check Start >>> Control panels >>> System >>> Advanced >>> Performance >>> Settings >>> Advanced

Process scheduling = Background Services

See here if that changes things.

Ben

[tpascaru · Accepted solution]

For Documentation purposes: Setting the Execution Priority to "Highest" from VI Properties seems to do the trick!