Graph Properties Problem

[Steve.Briggs]

Hello all,

I am running into a problem where editing my waveform graph properties causes all of LabVIEW to freeze up and remain that way until I terminate the program.  All I am trying to do is edit the scalar factor and offset of the graph, but when I do this it tends to freeze up more times than not (roughly every 8 times out of 10).  Perhaps my flow of information is too high into the waveform graph from the cluster and the problem lies in that?  I am going to attach the VI, pay no attention to the messiness of the front panel but rather the two tabs, Integrated Area and Peak Power (the two graphs labeled Blue/Green/Red combined is where my problem is).

Any insight or help with this matter will be greatly appreciated,

[Steve.Briggs]

By taking the selected graph out of tab control and then editing it I am able to bipass any jam or freeze up.  Something with the tab control causes a large memory leak resulting in the program crashing.

[altenbach]

I cannot reproduce the problem. It never locks up if I edit the properties of the graph.

[TreyB_NI]

While your code does not freeze my 8.2.1 installation, what you describe is a recognized issue targeted for fix in a future release of LabVIEW.  And the VI that reproduces this problem does cause my system to go to 100% CPU utilization for a while.  I have attached this VI.  NI has noted that the wait progressively gets worse with more tabs and graphs until it can cause freezing.  The only workaround that we recommend right now is to use fewer graphs in tab controls.

Message Edited by Trey B on 06-05-2007 03:19 PM

[mikeporter]

Another good solution is simply not to use tab controls. What is the point of updating dozens of controls that you can't see? If you need a tab control to have room for all your controls the argument could be made that you have too many controls. At some point you get into a situation that there is so much data on the screen that you have a hard time finding the information that you need.

Mike...

[altenbach]

RIght!

It seems the graphs on the various tabs are basically duplicates except for e.g. the axis labels, etc.

You could use an ultra shallow tab control with nothing in it and place one set of graphs below it. Now simply switch the labels and datasets whenever the tab changes, re-using the same graphs for everything.

[Ben]

Mike questioned;

"What is the point of updating dozens of controls that you can't see? "

The tab control is a simple way of allowing multiple views of the same data. Prior to LV 8, updates of graphs and charts on non-visable pages, were not applied or processed until the tab page was viewed.

I sometimes think of the tab control as a way of grouping a set of objects to use a single "visable" property.

In another thread (that I can not find at the moment) I confirmed that the "defer FP updates" does not work as of LV 8 for (was it graphs charts or both). The work-around was;

1) Defer updates

2) set graph visable =F

3) apply updates

4) set graph visable

5) Un-defer updates.

One of my engineers reported this method reduce loading a chart from 15 minutes to 2 minutes.

Why am I going on about this?

If the graphs charts are failing to recognize that they are not on a viewed tab in the same way they are failing to see that the FP updates are defered....

Then we have a good idea were to look to fix this issue.

Just thinking out loud,

Ben

[Steve.Briggs]

---

mikeporter wrote:
What is the point of updating dozens of controls that you can't see?

Mike...

---

...because that's what the vendor asked for in handling of data.  I suggested a few alternatives but they were set on having tabbed control for "appeal".

Like I said before, I am able to alter the graph properties efficiently without locking up by taking the graph out of tabbed control, and then just placing it back in once I edited the appropriate section...a bit annoying, but nonetheless, workable.

Regards

[mikeporter]

So create an interface that looks like a tab control but really isn't. (Altenbach first suggested it...)

Mike...