Increasing Num Legend Rows crashes LV if Stacked Chart

[SteveP]

I received a reply from a NI Applications Engineer who relayed a response from the developers who say that although changing the number of plots seemed to work (in 8.5, I assume they mean), it actually corrupted the VI. To prevent this, any attempt to modify the number of plots is now blocked and error 1000 is given.

Steve

[coobery]

what??oh ,no!

in my case it seemed that the best way to achiece my vi function is to use this Property.

but now NI tell us it is blocked

can anybody show me any method to substitute this property?

thx  so much!

[SteveP]

The Applications Engineer suggested using VI Server to accomplish changes to the Number of Legend Rows.  This has been discussed here, but as far as I can see, no actual example has been posted.  I would appreciate being shown how to modify my example VI in the first post to use VI Server.  Thanks.

Steve

[coobery]

i am on the tiptoe of expectation.

[Spex]

This example uses VI server to update a stacked waveform chart within a subPanel.  The reason this works is the VI that is inserted in the subPanel is not running.  (It is legal to change the number of plots as long as the VI isn't running).  This method of updating an indicator via a property node (VI server) is not as efficient as writing data directly to the block diagram terminal of a chart.

Regards,

[SteveP]

Thanks Spex.  This example works to increase or decrease the number of displayed plots "live real time" while the vi is running.  I will try this approach in my programs. 

Is it necessary to have your Chart Refnum on the While Loop as a Shift Register ?  The program still runs after changing it to a Tunnel. 

Now - is there a way to toggle between Stacked and Overlay modes during run-time ?

Steve

Message Edited by SteveP on 05-13-2008 04:14 PM

[Spex]

It is not "necessary" to use a shift register for the waveform chart refnum, but I do consider it best practice.  I have a couple reasons...

Inplaceness:  When ever an item is connected to both sides of a loop (and the wire is not branched within the loop), a shift register forces the LabVIEW compiler to perform all actions on that data "in place", meaning LabVIEW doesn't copy the data in the wire if it modifies it.  LabVIEW is constantly trying to optimize for in-placeness on its own for efficiency, but a shift register helps reinforce a good optimization.

Data Integrity:  This is most important if I needed to use the wire after it passes through a loop.  A While Loop isn't a good example because it always runs at least once, but if later on in my application I decided to change a loop into a For loop, there is the possibility that a For Loop can run 0 times.  Most likely, I would want the data passed into the loop to be passed through the For loop, even if it ran 0 times.  When using Shift Registers, that data does propagate, if using tunnels, the For Loop outputs the default value for the data type. 



There is no way (that I know of) to programmatically changing the Stacked vs Overlay mode for a chart, other than having two charts and hiding/showing the appropriate one.  Here is an example.

Cheers,



Message Edited by Spex on 05-13-2008 04:27 PM

[SteveP]

As an aside but mentioned here because its behavior will be observed when changing the number of legend rows :  Any edited plot names shown in the legend will revert back to "Plot n" if the number of displayed plots is decreased and then increased back.  Take a Chart with Stack plots and wire a 2D array to it so it shows multiple plots.  Expand its legend to show its plot names for many plots. Change the plot name for one of the plots (say the third plot) in the legend using the text editing tool.  Resize the legend so the number of plots is smaller than the plot you renamed so that the renamed plot is no longer shown in the legend (so there are now only two plots shown).  Then resize the plot legend so the renamed plot is now shown again (so the third plot is visible again).  The renamed plot has been changed back to "Plot 2".  This does not happen with Ovelay mode and does not happen with a Graph.  It does not happen unless data has been wired to the chart so that it shows multiple plots.  This has been submitted to NI.

Steve

[SteveP]

Spex,

Your stacked_plot_workaround works while in edit mode.  When built to an executable using LV 8.5 the number of displayed plots no long changes.  The Number of Rows in the legend does change though.  The number of displayed plots remains whatever it was in the subpanel chart.vi.  If the Number of Plots control is made larger than the number of plots in subpanel chart.vi, those additional plots are all shown on plot0.  If the Number of Plots control is made less than the number of plots in subpanel chart.vi, the extra plots are shown as empty.  In edit mode, the number of displayed plots tracks the number of rows in the legend.  Is the problem with the built executable that what is actually being used to vary the number of displayed plots is indirectly the Number of Rows in legend property (which does change correctly).  Is there some issue with whatever link or action is used to indirectly cause the number of displayed plots to also change and track the Number of Legend Rows property ?

Steve

[Spex]

Steve,

I'm not sure what is causing it to behave differently in executable form.  I never thought to test the behavior as an executable.  Our best bet for investigating what is going wrong and how to work around it will be to get help from the Applications Engineers group.  They should see this post, but you could call in to get a quicker response.  The AE's have access to working directly with R&D to find out what is going on.

Good luck,