XY Graph scale increments changing arbitrarily

[camerond]

Well, this may be a yeoman's mistake with a simple fix, but I don't think so. I've dug down as deep as I can see to go.

To put it simply, I have an XY graph to which I add data in increments, say 50 points at a time. I programmatically set all the properties of the X and Y scales, setting Autoscale to "Off" both in the BD and on the FP, but there are times when LV just ignores me and sets its increment spacing to what it thinks best. Now, I'm not talking about it using larger increments (due to space limitations, all that stuff), but smaller ones. When I use real data in the graph, this just doesn't look professional, grid lines switching back and forth.

I have attached a simple VI which shows this behavior with canned data. The graph is updated, adding 50 points at a time, every 2 seconds. The X and Y scale properties which I have entered via the BD (which are dependent on the current data points) are also shown as indicators on the FP left. AFAICT, each time that the scale min or max change, LV uses its own default scale increment spacing, then upon the next iteration my values are used (unless the scale changes again).

I have also tried including a duplicate property node for X and/or Y scale increment (and minor increment) outside the FOR loop at the upper-left corner for initialization, to no avail.

Someone about a year ago described a similar problem for a waveform graph in this thread, but the OP "got it figured out on [his/her] own" but didn't say how. Boo.

Thank you all for your help. And for excusing my long-windedness.

Cameron

[RavensFan]

Property nodes execute in order.

You have the order of Xscale.incrment, them Xscale. max, X.scale.min, then Xscale.minor increment.

Try rearranging your elements so that max and min are set first, then the increments.

[camerond]

---

@RavensFan wrote:

Property nodes execute in order.

You have the order of Xscale.incrment, them Xscale. max, X.scale.min, then Xscale.minor increment.

Try rearranging your elements so that max and min are set first, then the increments.

---

Well, nice thought, but no change in behavior (either X or Y scales).

BTW, I'm using LV 2012 SP1 (version 12.0.1f5). on both WinXP and Win7.

Cameron

[camerond]

Just checked on a Win7 PC with LV2013, same behavior.

Cameron

[RavensFan]

I'm using LV 12f3 on Win XP.

I modified the VI to do both methods back to back to be able to compare them.  It seemed to me that the 2nd method did not have the jumps that the first method saw.  Maybe I'm mistaken, because legitmate changes in scales can be confused with the illegitmate ones.

See the attached file.

I also put in some indicators to show when the values (max, min, or increment) changed from the last run.  So if you see a change in the graph, and the corresponding LED did not light up, then it shows there was an issue with the order of drawing.  I see this happen a couple times with the first method, not with the second.  Maybe one time near the beginning with the second, but definitely less.

[camerond]

I can see where your logic about the order of property values is coming from. I also ran my VI again, changed the "custom" gridlines to values that would not ever show up as LV defaults (numbers like 3, 13, 17, etc.) and saw you're right - except for the original X gridlines and one time after the seventh segment. Better, certainly, but not quite there for the customer. There's got to be a way to ensure consistency, especially since the glitch is gone from the Y axis gridlines.

Maybe if I shout it must be a BUG, someone from NI can give us the final word on this.

Thanks, RavensFan. BTW, how are they doing? The Steelers are not making anybody in Pgh happy these days.

Cameron

[RavensFan]

The only other thing I can think of that might help is to defer panel updates before writing to the property nodes, then re-enabling them after.  This might force everything to be drawn at once.

As for the Ravens, we're hanging in there.  The game against the Bengals this Sunday will determine our season.  If we lose, we're all but done.  It would be too big of a hole to crawl out of.  If we win, then we're a bit better off and still in it.  But we still need to win far more games the rest of the way out, and our final game of the season against the Bengals would be critical.

We're glad we aren't the Steelers (but that is the truth all the time).  But we are having pretty much the same problems as the Steelers.

[camerond]

Well, deferring panel updates (with a convoluted error path) didn't do anything, either.

You want to hear something just nuts? The reversion to LV default gridlines happens consistently on and only on passes 1 (original graph), 7, 31, 96, and 318. I'm not obsessive enough to go any further than that (if whatever pattern this is holds up, the next one should be between 1000 and 1200, I guess).

Too late today to do anything else about it, I guess I'll file a BUG (anyone out there at NI listening?) report on Monday. The weekend awaits.

Cameron

[johnsold]

I wonder if it is an OS thing.  I do not see anything that seems strange with either Cameron's or Ravens Fan's VIs on my Mac (OS X 10.8.5 and LV 2013 32-bit).

Have you tried using a sequence frame to force the write of data to the graph to occur after the scale changes?

Lynn

[camerond]

---

@johnsold wrote:

I wonder if it is an OS thing.  I do not see anything that seems strange with either Cameron's or Ravens Fan's VIs on my Mac (OS X 10.8.5 and LV 2013 32-bit).

Have you tried using a sequence frame to force the write of data to the graph to occur after the scale changes?

Lynn

---

Well, I didn't use a sequence frame, but I did the same thing with an error wire, pulling it through the property nodes on the way to the graph indicator. No effect.

Cameron