DQMH Consortium Toolkits Discussions

cancel
Showing results for 
Search instead for 
Did you mean: 

Delayed Update to UI

Solved!
Go to solution

I am dealing with a problem of a delayed update of my data to my UI.

 

Currently I have my data acquisition sending a request event to update display each time data is acquired. I am using the DAQmx Read function in a helper loop acquiring data and sends the data through the request event. I have a helper loop in my UI module which is registered to the request event and only handles displaying data to the user. This is used to separate user interaction from the update of the display.

 

The test user has noticed after about 10 minutes of test time, acquiring samples at 10 S/sec, there is a slight delay in updating values on the UI.

 

My first thought is that the event queue is building up, and causing a delay. I tried to send the update display event at half the speed of the sample rate. So if the user was sampling at 10 S/sec only 5 events/sec were sent. I still logged at the 10 S/sec rate. But the user noted that it actually caused the update to the display to delay even longer.

 

I know that a broadcast event is popular for updating data on a UI, but I do not believe there is a way to control how often the UI modules listen for broadcasted data. I would like to separate the UI update rate from the other data acquisition functions. I figure update the display faster than about 5 S/sec is overkill for the user.

 

Any recommendations or tips on improving the communication between modules? 

 

Attached photos are of:

Data Acquisition Helper Loop

UI Helper Loop

 

Data Acquisition Helper LoopData Acquisition Helper LoopUI Helper LoopUI Helper Loop

0 Kudos
Message 1 of 10
(3,969 Views)

Ryan, what do you mean when you say „I do not believe there is a way to control how often the UI modules listen for broadcasted data“?

 

If you want to reduce the display update rate, you could ignore every second broadcast‘s date in the UI module helper loop. 

 

Where does the „Main application request event“ come from? Is it from the DAQ helper loop?




DSH Pragmatic Software Development Workshops (Fab, Steve, Brian and me)
Release Automation Tools for LabVIEW (CI/CD integration with LabVIEW)
HSE Discord Server (Discuss our free and commercial tools and services)
DQMH® (The Future of Team-Based LabVIEW Development)


0 Kudos
Message 2 of 10
(3,950 Views)

@joerg.hampel wrote:

Ryan, what do you mean when you say „I do not believe there is a way to control how often the UI modules listen for broadcasted data“?

 

If you want to reduce the display update rate, you could ignore every second broadcast‘s date in the UI module helper loop. 

 

Where does the „Main application request event“ come from? Is it from the DAQ helper loop?


That's my thought, either send less requests if using the request event. Or reduce the "listening" rate of the helper loop in the UI. But I am not sure how to make a helper ignore a broadcast. I used the iteration terminal to send less requests, sending every other iteration. I was just surprised after sending half the requests I saw a worse delay in the UI. It makes me wonder if the event queue is not the root of the problem.

 

Yes the Main App. request event comes from the DAQ helper loop. I am using it instead of the broadcast currently.

0 Kudos
Message 3 of 10
(3,947 Views)

It‘s highly unlikely that the event queue itself is the limiting element. Also, both request and broadcast events are just LabVIEW user events at their core. If you don‘t route a request via queue from the EHL to the MHL but process it directly at the helper loop, there isn‘t much difference between request and broadcast at all. 

 

You cannot reduce the „listening rate“ itself, but you could choose to process only every second event‘s data (eg have a case structure inside the event case in the helper loop)...

 

Can you share your code?




DSH Pragmatic Software Development Workshops (Fab, Steve, Brian and me)
Release Automation Tools for LabVIEW (CI/CD integration with LabVIEW)
HSE Discord Server (Discuss our free and commercial tools and services)
DQMH® (The Future of Team-Based LabVIEW Development)


0 Kudos
Message 4 of 10
(3,945 Views)
Solution
Accepted by topic author ryan_sheppard

From the images I would suspect you are throwing enough points at your xy graph to make it a long time to redraw, possibly combined with your use of value property nodes which will block while the UI thread is redrawing the graph.

Message 5 of 10
(3,939 Views)

What other events is the UI helper loop registered to listen to?

For an opportunity to learn from experienced developers / entrepeneurs (Steve, Joerg, and Brian amongst them):
Check out DSH Pragmatic Software Development Workshop!

DQMH Lead Architect * DQMH Trusted Advisor * Certified LabVIEW Architect * Certified LabVIEW Embedded Developer * Certified Professional Instructor * LabVIEW Champion * Code Janitor

Have you been nice to future you?
0 Kudos
Message 6 of 10
(3,930 Views)

@joerg.hampel wrote:

It‘s highly unlikely that the event queue itself is the limiting element. Also, both request and broadcast events are just LabVIEW user events at their core. If you don‘t route a request via queue from the EHL to the MHL but process it directly at the helper loop, there isn‘t much difference between request and broadcast at all. 

 

You cannot reduce the „listening rate“ itself, but you could choose to process only every second event‘s data (eg have a case structure inside the event case in the helper loop)...

 

Can you share your code?


I figured it that the request event was not much more different than the broadcast.

 

So this solution is similar to my first attempt of a solution to only send half the amount of request. I suspect that I will run into the same problem, because the root of my problem isn't the event queue like you said. I may give it a shot though. As for sharing my code, I will probably need to confirm that with my company.

0 Kudos
Message 7 of 10
(3,913 Views)

@FabiolaDelaCueva wrote:

What other events is the UI helper loop registered to listen to?


The helper loop is registered to the Stop Module request event and Display Data request event. 

0 Kudos
Message 8 of 10
(3,912 Views)

@drjdpowell wrote:

From the images I would suspect you are throwing enough points at your xy graph to make it a long time to redraw, possibly combined with your use of value property nodes which will block while the UI thread is redrawing the graph.


I second Dr. James Powell on this one. 

On further inspection, it looks like removing the Value Property node would help. 

 

More information on the difference between Value Property Node and Local Variable, check out this thread: https://forums.ni.com/t5/LabVIEW/local-vs-property-node/td-p/321755

 

If you are still having trouble after removing that property node, see if you can share the code with us, there might be other road bumps in the subVIs that are processing the data.

 

Let us know how it goes,

Fab

For an opportunity to learn from experienced developers / entrepeneurs (Steve, Joerg, and Brian amongst them):
Check out DSH Pragmatic Software Development Workshop!

DQMH Lead Architect * DQMH Trusted Advisor * Certified LabVIEW Architect * Certified LabVIEW Embedded Developer * Certified Professional Instructor * LabVIEW Champion * Code Janitor

Have you been nice to future you?
0 Kudos
Message 9 of 10
(3,896 Views)

@FabiolaDelaCueva wrote:

@drjdpowell wrote:

From the images I would suspect you are throwing enough points at your xy graph to make it a long time to redraw, possibly combined with your use of value property nodes which will block while the UI thread is redrawing the graph.


I second Dr. James Powell on this one. 

On further inspection, it looks like removing the Value Property node would help. 

 

More information on the difference between Value Property Node and Local Variable, check out this thread: https://forums.ni.com/t5/LabVIEW/local-vs-property-node/td-p/321755

 

If you are still having trouble after removing that property node, see if you can share the code with us, there might be other road bumps in the subVIs that are processing the data.

 

Let us know how it goes,

Fab


Thanks for the information on the performance issues with property nodes. It looks like if I would have used VI analyzer on my VI I would have caught it also. 

 

We are no longer seeing the delay on the UI after removing the value property nodes. Thanks for the help everybody.

 

Ryan

Message 10 of 10
(3,883 Views)