Printing front panel of calling VI

[vinvan]

A problem came up where the calling VI front panel gets printed.  A subVI that contains a graph has the checkbox set to print front panel when closing and that works fine, I get a printout of the graph.  The calling VI does not have that checkbox set.  The computer is running a .exe file, using LV2015 with Win10.  After running for several days correctly, it just suddenly started printing the front panel of the calling VI in addition to printing the front panel of the subVI.  Why?  The program ran correctly for several years on an identical computer, using LV2015 with Win10, but running source code, not an .exe file.  Rebooting and restarting the .exe file seems to have solved the problem for now, but I am wondering if the problem will show up again?

[natasftw]

If I asked you this same question providing the information you've provided, what would you say?

You haven't attached any of the code.  You haven't provided even pictures (which are dreadful to help debug) for us to understand what else is going on.

If this is happening when the subVI closes and the main executable continues to run (as it sounds like from your description), the checkbox on the calling VI isn't really relevant.  The front panel isn't closing so I wouldn't expect that to be what's causing the behavior.

Are you able to share the code so we can take a look?  It sounds like you're running into some form of race condition.

[vinvan]

I am very sorry but I can not supply the source code because it is ITAR restricted and proprietary to my company.  I was wondering if any one else has run into this condition when running LV2015 .exe file on a  multi-core computer with Windows 10.  The confusing part is that the calling VI front panel prints before the subVI front panel prints, even though the calling VI still runs after the subVI closes.  The program ran successfully for several days before this problem showed up and rebooting the computer seems to have stopped the problem.  It may be a race condition given the multi-core processor in the computer or may be a bug in the runtime engine for 2015?

[aeastet]

Do you have the LabVIEW code to fix the problem if we tell you where we think the problem is? If not it really is a waste of time to even try to answer your questions.

My guess is that you have a chase or race condition. On the older system it wasn't apparent because every thing was slower. Now you have a newer machine that is faster and this problem now exists because something is executing faster and now you have a condition where the true value for the print does not get reset. I am not sure that you have many options to fix this with out the development code.

[vinvan]

I have all of the source code and I am the one who created the .exe from the project.  Any suggestion that you might have can be incorporated into the source code and a new .exe can be made and run.  The source code has run on a similar computer for over a year without this problem showing up and we recently started running the .exe on that computer without this problem showing up.  The two computers were purchased at the same time and are supposed to be identical.  If necessary, I can load the LV program on the second computer and run source code there also, but really don't want to do that.  The plan is to run .exe files on both computers and only access the source code on one when necessary.

[aeastet]

It is going to be very tough to answer your question with out looking at code. I would spend a lot of time looking at the mechanism that set the true\false state for the print. What is causing it to be true or false and why would it get stuck. Are you missing and event that gets thrown? Are the values not read before it clears for some reason (are you building an array in one loop that is causing it to slow down over time, as an example). How are you sending the true false? What is keeping track of this?

If you are reading the state from a local variable then I would go back to my original statement of a chase condition.