LabVIEW bug ? Dynamic display of Y-axis on XY graphs.

[chilly_charly]

This is an already ancient problem, since I have been obliged to deal with the first time with LV 5 (may be older, but my memories are fading�), and still exists in LV 7.1.
The 10/06/04, Whatsthis posted a question about this problem that has received no answer, and I think that we have to insist somehow on this issue.
The problem is easy to reproduce :
Step 1 - On a XY graph, try to show/hide programmatically the Y-axis. Use a property node, and wire a boolean control to the Yscale.visible attribute. Put this in a loop. Run, and play with the boolean to show/hide the axis scale. Everything is working fine. So far, so good�
Step 2 - Repeat the same operation while changing the scale range. This is not a fancy i
dea, and can happen sometimes during real operating conditions when autoscaling is on, and always when switching the display of different data. Add a Yscale.max item to the property node, add a shift register to the loop, connected to an inverter, and switch back and forth the Y scale maximum between say 1 and 10 at each loop iteration, using a select function wired to the inverter.
Depending on the moment at witch you press the show/hide button (and on the rate at which your loop is running - a delay of 100 mS is nice) the Y scale will be moved away of its original place, either out of the graph bounds, or under the graph area. The graph area itself shrinks or expands unexpectedly, and may disappear completely.
The problem is not related to the order used to modify the scale properties, and exists both on Window and Mac platforms.
A partial work around is to read the Yscale.Position attribute before modifying the scale range and display, then to reset the scale position. However,
this works only when the scale is on the graph left side, and may give unexpected results when the graph size is modified by the user (changing the window size, with "Scale object with panel" enabled).
May be somebody at NI could give an answer to this problem?

[Ben]

Hi CC,

I think the attached zip should demonstrate this undesirable behaviour.

In the zip you will find two VIs (in LV 7.1) and a jpg of the diagram that demonstrates this issue.

Thank you for the morning entertainment!

The Vi labeled "show n hide1.vi" is my imppesion of your description. It is a slight variation because I was curious if this behaviour was intermitant or predicatble.

It is predicatable! (I believe...)

In my variation, I track the Y-left position and the state of the show/hide and range. The history is then plotted.

If you carefully examine the history plot, you will see that if the Y-scale is visable when the range is changed, the Y-Left values is constant.

If the Y-scale is not visable, the Y-left will shift back
and forth to adapt to the range changes. I think this is a bug.

The history shows that if there were an even number of scale shifts while the plot is invisable, it will appear at the same Y-left value as when was last visable.

If there was an odd number of scale changes, the Y-left retains a new value.

If you time it right the plot can walk right off to never never land.

So...

After observing that the Y-left value did not shift when the Yscale.visable was true I tried forcing the visable property to true prior to the range change and then invoked the Yscale.visable property again, this time using the stae of my FP boolean.

This is shown in "Show n Hide2.vi".

Surprisingly, this apears to be a work-around.

I did not notice the scale flickering while I was testing so it appears the XY graph is only being updated after the entire property node completes.

By setting the visable property true before the scale change, the code that positions the Y-left value seems
to work without a problem.

This test also implies a fix (provided this goes un-explained and warrents a CAR).

I will watch to see hese guesses withstand time.

Go eye CC!

Trying to help,

Ben

[Ben]

Auto scaling may still be an issue not addresed directly byt my above answer.

This may have to be handled by explicitly auto-scaling?...?

Always interested in the limits of my world....

Ben

[chilly_charly]

Hi Ben!
I really enjoy this kind of experimental programming!
The problem may be triggered by any change (redrawing) of the scale, and is amplified by variations of the scale width. It is even worse when the scale is on the right hand side.
You are right: Setting the scale.visible to true before modifying the scale solves the problem (almost).
And you are right again, autoscaling can create problems: any change to the scale while invisible result in a damaged display when the scale is made visible again.
A (poor) solution is to disable autoscaling while the scale is invisible. But of course, the data will not fit on the graph.
A (messy) solution is to make the visible and autoscaling properties true and false at each loop iteratio
n. That way, the data are displayed full scale, but the Y-axis is flickering. The funny thing here is that the flickering is induced by the setting of the autoscaling attribute. So you were wrong (sorry � :-))) when assuming that the graph was updated only after completion of the property node�
An improved solution is to defer panel updates while doing all the scale manipulations. Doesn't look to be a recommendable method for beginners!
Well, this workaround remind me the difficulties I have to change the graph background colour (see what I mean here.
Since LabVIEW is obviously a reference about graphic conceptualisation and programming ease, we have here some kind of dirty spot, and I expect some answer from NI soon� 🙂

The attached example vi is an illustration where two sets of data are displayed alternatively.

[Ben]

The defer FP updates is a good apraoch to handle the flicker.

I will watch to what happens.

Thank you CC!

Ben

[Ben]

Two more thoughts.

I did not see the flicker in my example. I am using win XP proffesional.

I either read or heard a quote attributed to to Jeff Kodosky saying he "forsaw the dat whn LV will be devoped in LV". This adventure used LV to trouble shoot LV.

Ben

[djs_at_eaton]

Is this related to a problem I had with a Waveform Chart crashing after less than 24 hours of operation? I put in code to clear the chart history (which resets X scale to 0) every 10 hours. The program now runs for days without a problem. I attached both versions. Version 2 has the problem, Version 3 doesn't.

[chilly_charly]

Hi Ben !

" did not see the flicker in my example. I am using win XP proffesional."
Since I developed the example under MacOS (has evident from the archive content...), I have just verified that under W2000 the scale was also flickering. Did you try with my example ?

"This adventure used LV to trouble shoot LV"
Bootstrap is much easier in the other direction... :-))

[Ben]

I just ran your example and it does flicker if not using defer FP updates.

Ben

[Ben]

I have reported this to support (req#=620037).

I will update this thread if I learn more.

Ben