Passing graph data to a sub VI

[JimMarihew]

I have an application where it is desired that the front panels be dark so as to be gentle on the eyes, but when I save the graph data to an image it should be mostly white for better printing.  To do this i created a sub VI for saving purposes.  I pass the graph data to the sub, and print it.  This works with intermittent results.  It works more often than not in the development environment, but fails almost of the time in run time.

The code:

The result:

Note that the input cluster indicates that the graph X  range should be only ~67-77.  The data and cursor positions are correct.  And it is intermittent!  Anyone see what I am missing?

Using LV 2019

Jim 

[altenbach]

Can you also show the caller? How is the subVI configured? (e.g. does it open the panel when called, preferably minimized)?

(It typically would help to attach a minimally working example that show the problem. A picture never tells the full story.) 

[JimMarihew]

Quite true altenbach.  Looking at the configuration I apparently was running it to open originally, but when I unchecked that I still left things like show scroll bars and the abort button disabled.

[JimMarihew]

Sorry, forgot the caller.  It's 304MB so I can't upload it

[altenbach]

Does it work better if you apply the following VI properties:

• Window appearance...customize..."show front panel when called"
• Windows run time position: minimized. (If you don't want to see the panel).

[altenbach · Accepted solution]

Once you do the above property changes, all you need is the following:

Note that you only need one graph (i.e. the one that is currently an indicator. Delete the one that's a control), Then just right-click to change it to a control and assign the connector. You should also deal with the case where the file dialog is canceled by the user.

All your delays can go, because you are not dealing with a race condition, but with an optimization that typically does not update controls and indicators of closed front panels. (there are exceptions and other solutions, of course).

[JimMarihew]

Very interesting.  Results seem to vary, but it definitely works better when it is already open.  I tried several combinations between stay open, minimized, and close after.  Most, but not all of the time it worked when it was already open, minimized or not.

[altenbach]

Dumb guess, probably not important: I would also delete the "this VI" reference. Maybe if the method is unwired LabVIEW can be more certain that the VI is really dealing with it's own panel 

[JimMarihew]

Thanks altenbach, I think it's solved.  I ran it a dozen times both in the dev enviro and as a built application with no bad runs.  I'm running the sub as open and close as called with it open in the center when running.  I knew the delays and for loop made no sense but I was grasping at straws.  What do you think the root cause was?

Thank you again.

Jim

[altenbach]

For front panels to update, the panel cannot be closed. Most subVIs never show the front panel. Loading the entire front panel in memory and involving the UI in these cases would dramatically hurt performance!

My suggestion to open it minimized was your requirement for a relatively dark environment, so showing a glaringly white popup might not be appropriate (I sometimes work with light sensitive materials, so too much light is even dangerous for the experiment ;)) Unless the user needs to interact with the window, he does not need to see it.