How to make sure plots in xy graph are present?

[Florian.Ludwig]

Hi community,

since updating to LabVIEW 2014 this week I have an issue with code that worked previously (or didn't but the problem was unnoticable).

As shown in the example llb I created to showcase the issue, I'm filling xy graphs with quiete some data and then programatically colour the plots.

The problem is that if there are too many plots then the property nodes that are to colour the plots thow errors as if the corresponding plots were not present in the graph yet - even though I used a single frame flat sequence structure to try to make sure data is written to the plot before trying to colour them.

Maybe this would have happened in LabVIEW 2013 too - but the threshold for the number of plots was higher. All I can say is that I observed this with data sets that worked fine in LabVIEW 2013.

To reproduce simply run "colour the graphs.vi" with sufficiently high values for "numerisch" and "numerisch 2" (50 on my machine may be more on yours). I left the error out terminals of the property nodes unwired so you get taken to the right position when the error occurs. 😉

Can I somehow check whether all plots are in the graphs yet? That way I could introduce a delay that makes sure I don't try to colour graphs that aren't there yet - regardless of the speed of the target PC.

Has xy graph behavior changed in LabVIEW 2014? Or maybe its performance?

Best regards

Florian

[Florian.Ludwig]

Hi,

a small update:

Introducing a small wait time of 200ms in the flat sequence "fixes" the issue for the specific number of plot on this machine.

This really makes it seem like the graph is still busy loading the plots when the error occurs.

I need a general solution though.

Additionally I was able to reproduce the issue on another mashine.

Best regards

Florian

[Norbert_B]

Florian,

i cannot run your example as it requires some VIs from a LAVA-library (which i dont have installed).

Nevertheless, there are some questions i am stumbling about:

1. Why do you use a local variable rather the terminal to pass all plots to the indicator?

2. If you place a wait function in the sequence frame which waits longer than the expected time for passing the data, does the error still occur?

3. Do you run into the error if you enable panel updates before coloring the plots in order to slow coloring down?

I can imagine that you have a race condition against the UI thread. The local variable (just like the terminal) has a buffer where the data is copied to. The UI thread will retrieve the data as soon as it is ready. I would expect the coloring to require the data be present in the UI thread already (in order to "acknowledge" the plot). So if, for any reason, the UI thread only cought 98% of all plots when you start recoloring, you race against the transfer of the last 2%.. depending on the UI thread execution speed, you can run into the error or maybe not.

That is the reason why i want you to test for waiting times or slowing down the coloring.

Norbert

[thoult]

Only using LV2013, so can't open your example, but...

You should be able to force the number of plots acceptable in a graph by using the LegNumRows property. Please ignore the code snippet tool's habit of changing implicit property nodes to references + explicit ones...

Edit - bah, it really makes it ugly when it does that! LegHt will be rounded to the next highest integer require to fit a plot in nicely. I added in the LegScrollVis property to make it easily scrollable for more than a few plots. You could easily wire LegNumRows with an array size instead of the random number of plots I'm generating.

[Norbert_B · Accepted solution]

Hm, your addendum somehow answered my question. So we indeed have a race condition against the UI thread.

Sadly, i dont know a method to wait for the UI thread to have access to all plots. Additionally, the wait time you would need depends on the system capacity, which is dynamic as you dont know about all background processes or parallel executing applciations.

That being said, i recommend a workaround:

1. Create the data for the plots

2. Query how many plots you have in the data

3. Write short dummy data to the terminal rather than the whole plot data

4. Recolor the plots

5. Write the correct plot data

Norbert

[Florian.Ludwig]

Norbert,

thanks for answering. To answer your questions:

1. This is just because of copy paste from my actual application. Eliminating the locals and using the graphs directly still causes the issue - the threshold of plots at which the error kicks in rises minimally though.
2. Waiting in the sequence "fixes" the issue. The problem is I don't know what delay to expect as this could be distibuted to any number of customers machines and they could be trying to display any nimber of plots.
3. Enabling panel updates also "fixes" the issue. This is not an option for the final application however - it's very slow and ugly in the process. Customers must not see this.

The racing against UI seems plausible. Can I somehow synchronise my code mith the UI thread?

Some kind of "wait till xy graph is idle"?

Best regards

Florian

[Florian.Ludwig]

Norbert,

you're fast! 🙂

That workaround is a nice idea. I'll implement that for the time being.

I'd still like to know if there is a synchorinsing solution, and why this didn't rear its head in 2013.

Thanks

Florian