History of Autonomous Graphing Widgets, is there a way to disable

[joeqsmith]

With graphs/plots and a few other widgets, with a VI not running you are still able to manipulate the widget.  For example, say you plot some data, stop the application, you can then zoom into the data.

I started using LV in 4.x and remember it being like this in 3.x.  I suspect it has always been this way.   I wonder why the designers chose to add some intelligence into the graphs.  Maybe it was common for users to run and collect the data but wanted to zoom after the fact because it was faster? 

If you set the deferpanupdts, the graph will still respond to some panel commands, like zoom.   Most other widgets will not.  

In the later versions of LV, I wonder if there is a way to make ALL of the widgets behave the same. 

[drjdpowell]

It's not clear what you are asking.  What are you trying to do?

[joeqsmith]

I am asking if anyone knows the history of Labview on their decision to have the graphs behave differently by including some intelligence that allows them to function on their own, without a running VI.   

I am also interested in knowing if there are ways to disable it.   Because they will run autonomously,  I would expect it to be handled in the Labview settings, if there even is a way to change their behavior.

[ng1902]

Without knowing what goes on under the hood of a front panel, I assume it's because graphs and charts work the exact same as all the other available controls and indicators... Numeric controls and indicators don't change values when a VI stops, tables don't empty, and timestamps don't change, so graphs don't either. 

Within the development environment, this is really useful. You can run a subVI and see if the output makes sense. If you ran a VI and all the indicators reset back to default values when the VI finished, you'd get pretty frustrated.

Why wouldn't you want indicators to retain their values?

---

@joeqsmith wrote:

Maybe it was common for users to run and collect the data but wanted to zoom after the fact because it was faster? 

---

It's common in development, yes. When you deploy your application to production, your users probably shouldn't be halting the application to view data...

I don't understand the possible use case for wanting indicators to reset when a VI stops. 

[drjdpowell]

All LabVIEW Controls/Indicators are "widgets" running in the UI thread independently of their owning VI, not just Graphs.  It's a core original design principle of LabVIEW, I believe.

[joeqsmith]

I was hoping that the my comment about setting deferpanupdts would have helped explain what I am asking.  

I am not asking why values stay the same when a VI stops running but rather I would like to be able to disable the autonomous operations. Let me explain a use case.

I am attempting to graph several large data sets and would like to utilize the graph pallet.  Because of the amount of data, I work only on the section of data being displayed.   An event is triggered when an attribute is changed on the graph, for example, the user changes the range.  This event calculates the new display data then sends it to the graph.  Because the graph is autonomous, it will first redraw when the user selects the area to display using the graph pallet.   It will then redraw a second time when the actual data is available and sent to the graph.  

While setting deferpanupdts will stop the graph from updating when data is passed to it from the VI, it will not prevent the autonomous redraw. 

These redraws take a fair amount of time.   The other quirk is the autonomous redraw works with data that is not yet been calculated.  So you get a graph of invalid data, followed by the actual data.

In the past, I have handled large data sets a little different where I don't use the graph pallet.   Rather I use the cursors and other widgets to control the graph.  It's a lot more flexible and there are some other benefits, however using the pallet would be much cleaner.

In the vast majority of cases, this is not a problem as it's rare I am working with multiple large data sets, so execution times are not a problem. 

I'm sure this is still as clear as mud. 

[ng1902]

I think I'm following a bit closer.

So you have a graph with a huge data set. The user changes the range, which causes the graph to redraw automatically. But since the range changed, you need to redo your calculations to match what's now shown in the graph. Once that processing is done, it causes the graph to redraw again, but this time with the right data.

If you call DeferPanelUpdates right away after updating the range does it ignore the Defer, since the graph is already redrawing?

I've noticed that with really large data sets, turning off anti-aliasing can have a huge boost in draw time. If you have anti-aliasing enabled for plots turning that off would probably help. I also just found a property called "Smooth Updates" which defaults to True. The descriptions says that it draws the graphs with less flicker, but slower. Setting that to False might speed up drawing as well. You can set it through a property node or right clicking the graph, and it's under Advanced.

[joeqsmith]

It sounds like we are now on the same page. 

If I call DeferPanelUpdates during the event, it's too late as the graph on it's own will redraw.  Even if the VI is stopped, the graph will still redraw on it's own if the user selects it.  It's built into the widget. 

I have anti-aliasing and smooth updates disabled, plus the other tricks I have mentioned to try and improve the refresh times. 

Using the other technique I previously mentioned, I will use the pixel size of the graph, then do a min/max on segments of the data set to further limit the amount of data sent to the graph. It's a bit of an oddball UI vs using the graph pallet and the codes more complex but yields some of the best results as far as the update rates are concerned.

I would like to use the standard pallet and turn off that autonomous mode when the VI is running.  So when the user changes the range, the widget doesn't automatically refresh the graph but instead only creates the event with updated information on the new ranges. The software then updates the graph once the data is ready. 

So, I am looking for a way disable that auto refresh that is built into the widget, when the VI is running.  Once the VI is halted, the autonomous refresh would be active.  

Using the DeferPanelUpdates does help speed things up in some cases.  For example, if I want to say deselect all of the plots.  Doing the deselect in a tight loop, even with the Synchronous display disabled will still cause the graph to redraw for every call.   In this case the defer will greatly speed up the process.  

I should mention that using a parallel loop (I leverage that feature a fair amount), when setting properties like enabling a plot, will have no effect as far as the graph updating on each write to the property node. 

[rolfk]

That about the parallel loop having no effect when using property nodes to change (and read) UI control attributes is to be expected. These property nodes always execute in the UI thread and therefore can’t be parallelized in any way.

[joeqsmith]

I am not suggesting enabling parallel has no effect.  "....  will have no effect as far as the graph updating on each write to the property node. "  

When working with large data sets, it's slow enough that without the parallel enabled I can watch the operation happen sequentially.  When parallel is enabled, it will skip around as expected. So, to be clear there is some effect but it doesn't net any performance gains.  The problem is that the graph is refreshed on every call to the property node, even when Synchronous is disabled.

I am not sure if there are gains when using parallel with the property nodes when used in conjunction with DeferPanelUpdates.

***

I tried testing with parallel and DeferPanelUpdates enabled.   It degrades the performance.