LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

LabVIEW Crash after Graph mapping and Plot line_style have been changed

Solved!
Go to solution

Hello Everybody,

 

I got a very special problem which occurred to me mainly by "luck". But the error is reproducable every single time I tried it.

 

I am running LabVIEW 2012,(German) on a Lenovo PC with Windows 7.

The VI that produces the error adapts the appearance of a graph according to the type of data that should be plotted.

I attached the blockdiagram of the VI as a picture.

The graph is part of a VI that is inserted into another VI as a subpanel.

 

 

The problematic VI performes the following steps:

1) Take the Data as an array of waveforms.

2) Check which type of data it is and take the style information form a type definition .

3) Set the Graph style for both X and Y Axis: Autoscale?, Inverted?,Grid_Colors, Mapping(Linear/logarithmic),Boundaries, Axis_Style, Offset and Factor

4) Put the Waveforms into the Graph to ensure the correct number of plots for step 5 ( also the data needs to be put in anyways.)

5) Iterate over the plots and set: Line width, Line color,Line style, Dot Style,Visibility

6) Force a redraw.

 

If I perform all the above steps the VI crashes between step 4 and 5. This leads to a crash of LabVIEW in 100% of the time, LabVIEW need to be terminated by taskmanager. In about 5 % of the cases my whole operating system crashes, too.

 

The error will NOT occur if I do only one of these:

1) Use "empty" Waveforms . This means the Y array contains no data points.

2) Do not change the mapping of any axis. ( linear to logarithmic or  vice versa)

3) Do not change the line style of any plot.

 

In case of the mapping it makes no difference if the change is not done or if the new mapping is the old mapping. In both cases the error will not occur.

 

For me the solution was to remove the Line Style change. I can live with that.

My Question is now: Does anybody know why this happens?

 

Regards,

Sebastian

 

0 Kudos
Message 1 of 3
(2,634 Views)
Solution
Accepted by topic author SBach

Hi Sebastian,

 

This doesn't seem like a common problem. The behaviour you see in your application is probably due to a lot of load on one element in a really short amount of time. Did you try to do it a little slower, maybe with a wait in between?

 

A refresh of a graph element, espescially if there are a lot of data points allready in it, takes a lot of load on the system, that's probably why the system doesn't crash if there are no data points in it.

 

You should not change all of the properties of a live graph element in one cycle.

 

Regards,

0 Kudos
Message 2 of 3
(2,575 Views)

Hi FrankLp,

 

Thank you for your answer. I'll try to spread the changes over more than one cycle of my QSM.

 

Nevertheless I am not sure if this is really a load issue because in my test scenario the plot element was fed 3 plots with 5 elements each. So there were only 15 points of data.

 

 

Regards,

 

Sebastian

0 Kudos
Message 3 of 3
(2,553 Views)