Provide the ability to throttle (reduce update rate) of Indicators.

[Philbot]

I'd like a new property for an Indicator, which enables me to reduce its display-update rate to something less than the source-data update rate.

Reasoning:  When working with robotic systems, I often find myself adding large indicators to the Front Panel so I can get an easy to see indication of some new sensor's value (from across the room). 

This indicator is not necesarily needed on the final system so I don't want to spend a lot of time incorporating it into the BD.

The problem is that if a sensor is updating at 100Hz (like the ultrasonic sensor on the Robotic Starter Kit) you can burn a lot of CPU cycles trying to update a large bar graph with every data update.  In fact, on my system I just get a big flashing blob.  I invariably end up implementing some strategy to only display 1 in every 25 updates.  And in the process, I end up messing ip my neat BD layout.

It would be great if there was a built-in display property to take care of this for me.  See suggestion below:

The throttling property could be the minimum update interval, or the maximum update frequency, but the assumption would be that the GUI would just throw away any data updates that occured faster than the required display update rate.  In the example below I indicate that I only need 4 updates per second (ignoring the bulk of the 100Hz range updates)

I was considering submitting this in the Real-Time ideas forum, but it seemed applicable to any "fast" data acquisition system.

[JackDunaway]

Your reasoning is not quite correct. If you write the values to either the FP Indicator or a Write Local, Panel Updates (paints) are not synchronous. I think the refresh rate is about 30 FPS (someone confirm?) even if the underlying memory space of the indicator is being written at a faster rate. On the other hand, if you write to the Value PN, you're forcing a synchronous update which easily drags your app to its knees by railing out the CPU. Another way to force synchronous updates is by right-clicking on the Control/Indicator > Advanced > Synchronous Display.

I'm not saying this is a bad Idea, I'm on the verge of Kudos, I want to see where the conversation leads. My only reservation is I don't want to see this particular task being complicated by another setting, when it may suffice to know the "ins-and-outs" of graphics refreshing in LabVIEW.

*** EDIT: One qualifier: the reason I don't want to add this feature is because some people may incorrectly try to solve other problems by using this as a bandage. It's a helpful feature if used correctly, but could be easily abused to cover up more fundamental problems.***

[Philbot]

Good to know that there is already some limit put on display update rate (makes sense).

On that note, if display throttling was added, I'd see the advantage of an application-wide setting to throttle ALL the active indicators. 

Basically, be able to reduce all display updates from 30Hz to say 4 Hz on a fast data/control system.   

Even as a band-aid, the ability to offload CPU cycles from display to control would be very handy on slower systems.

(Yes, you could force the user to create an interlaced display/control structure... but I'm not sure that I'd know the best way to do that)

Phil.

[TCPlomp]

One way to lock the FP updating is set the 'Defer panel updates' to True on startup and periodically set this to 'True' again.

Setting this property to true forces labview to redraw the FP, but stop updating the FP until the next 'True'.

Ton

[JackDunaway]

A note on Ton's suggestion: I would recommend against using Defer Panel Updates in a loop - you're going to incur some crazy high CPU utilization. 250msec won't be too bad, but as with any Property or Invoke Node, stay away from placing these in loops.

[A-T-R]

A note to Jacks note:

Good comment! But you could (should!) place the PropertyNode in a case structure in that loop, to only be used e.g. every nth loop iteration (DeferPanelUpdates = F), and in the next iteration set DeferPanelUpdates = T, but only once, again with another case structure!

[TCPlomp]

ATR, no need to set Defer panel updates to false.

Setting this option to true forces a screen redraw at that very moment.

Ton

[A-T-R]

@ Ton:

Ahhhh...good to know! Thanks!

But then, don't forget to set it to false at the end of that application! Right?

[JackDunaway]

---

@TCPlomp wrote:

ATR, no need to set Defer panel updates to false.

Setting this option to true forces a screen redraw at that very moment.

---

... assuming you have no other paralell processes trying to update the Front Panel as well! But that's a good tip, Ton, I learned something new.

I'll go back and say this one more time, because it's worth hearing: Defer Panel Updates is an "intermediate level skill" for UI programmers. When I first learned of it, I thought it was the saviour of my graphics performance problems. As time progressed, I realized that in probably 95% of the cases, I could take a more fundamental approaches to solve graphics performance issues.

These include: always writing to the terminal or a local, never putting property/invoke nodes in a polling loop, use notifiers/user events to update panel draws in a parallel loop throttled to 50msec or 100msec (only when necessary, this requires a decent amount of extra syntax just to get better performance. I prefer synchronous dataflow for readability, but sometimes performance dictates messaging communication), watch for overlapping controls (this sometimes hurts, but most of the time does not... contrary to what others may tell you, it's OK probably 90% of the time to overlap controls), placing several individual indicators in a cluster in order to perform a "bulk update", don't ever use "Synchronous Display"...

The only time I use "Defer Panel Updates" now is when performing a bucketload of property/invoke node calls (such as formatting a tree) to speed execution (this can improve execution speeds by 2 or 3 orders of magnitude, yes, 100x or 1000x faster). Needing Defer Panel Updates in a loop I would argue points to a deeper problem.

[Darren]

Any idea that has received less than 2 kudos within 2 years after posting will be automatically declined.