XY Graph multiplot not remembering properties for old data stored in array

[altenbach]

---

@JÞB wrote:

You do realize that the property node in the outer loop writes a 1 to each active plot line style property RIGHT?

---

I am not sure which post you are replying to, but the OP seems to want a plot without lines, just points. The problem was that some plots turn into lines at some later point for no obvious reason.

[JÞB]

---

@altenbach wrote:

---

@JÞB wrote:

You do realize that the property node in the outer loop writes a 1 to each active plot line style property RIGHT?

---

I am not sure which post you are replying to, but the OP seems to want a plot without lines, just points. The problem was that some plots turn into lines at some later point for no obvious reason.

---

I would think that writing the active plot line style property is an obvious reason for causing a change to the displayed active plot line style.  Perhaps it is just a bit more obfuscated than I thought?

[rwunderl]

---

@JÞB wrote:

You do realize that the property node in the outer loop writes a 1 to each active plot line style property RIGHT? 1 is a line with no points.

---

There is no "Line Style" property. Edit: I mean to say that the Line Style property is not what is called out in that example, it was Plot Interpolation. Setting the Plot Interpolation to 0 removes interpolating lines (points with no lines). Setting the Point Style to 1 gives you the big open circles for the data points.

[altenbach]

---

@JÞB wrote:
I would think that writing the active plot line style property is an obvious reason for causing a change to the displayed active plot line style.  Perhaps it is just a bit more obfuscated than I thought?

---

With each iteration, they are changing the active plot style for exactly one plot, but all earlier plots appear to change their style whenever a new plot is added. The problem is that the code is faulty (as was already pointed out by Defaphe ). If you look at the actual plot data, the plots containing data are shifted around all over the place (using plots that were never defined!) and most earlier plots are empty arrays. What a mess! 😄

[rwunderl]

---

@altenbach wrote:

Thanks. I haven't done any testing to see if LegPlotMin really does define a minimum number of plots data-wise, or is just a cosmetic property of the legend. The help is not really helpful here. 😄

---

LegPlotMin is not a "cosmetic" property at all. It determines how many plots' properties can be set before writing data to the Value of the control.

After you write data that contains N plots to a graph, you can access N plots worth of properties, even if you later reduce the number of plots in the graph to less than N. Note that writing N plots to the graph does NOT set LegPlotMin to N. There seems to be an internal property of the GraphChart child classes (at least WaveformChart and WaveformGraph) that cannot be changed other than by writing data to its Value OR setting LegPlotMin. It seems to always keep the maximum value ever seen as far as I can tell.

In other words, if a graph has EVER had its plot legend expanded beyond the initial 1 plot or EVER had more than 1 plot of data written to its Value, you can then forevermore write that many plots' worth of properties to the graph control. This internal number is a property that gets saved with the graph. This can actually lead to performance issues if that number gets too large. I've had to replace graphs with new ones when this has happened (someone saved the VI after the graph had been expanded to a ridiculous number of plots and performance was hit by this).

See the attached VI (taken from the linked post above and modified) for an example of setting the LegPlotMin value before writing to the Value for the first time. I had to replace the XY Graph with a fresh one to demonstrate the use of LegPlotMin.

[altenbach]

---

@rwunderl wrote:
LegPlotMin is not a "cosmetic" property at all. It determines how many plots' properties can be set before writing data to the Value of the control..

---

Good to know, thanks! No way to read that out from the help. 😄

Do you know what LabVIEW version introduced this?

[rwunderl]

---

@altenbach wrote:

No way to read that out from the help. 😄

---

Huh. I never read the help for that property. I guess that's what it's for. Perhaps the way I am using it is a backdoor to initializing the graph's internal data structure to hold properties for the number of plots specified. The front door being writing to the Value property (or terminal, etc.) to get it to set that "property cluster array" size internally.

To me, the most useful Legend properties are Legend.Number of Rows for sizing the legend and Legend.Scrollbar Visible set to True if the number of plots exceeds the number of rows.

I guess the primary purpose of LegPlotMin is to change the way "blank" plots appear in the legend if fewer plots are in the data than there are rows in the legend:

I have modified and attached a new version of the VI for playing with the LegPlotMin value. I output the LegPlotMin value before and after running the VI. Quite interesting (and seemingly unpredictable) how LabVIEW changes this property! You learn something new every day...