Clones stop but EXE does not close

[Furbs]

I've been trying to use inheritance for my front panel type stuff and ran into a very weird issue where the EXE does not close, but all the VI's exit. I've narrowed this issue down to a single VI that I'm trying to run as a clone. 

Here are the symptoms:

- Everything works fine when launching from the project. Only happens after you compile and run the EXE

- The main VI does actually finish completely, by evidence of a One Button Popup I added as well as the Abort/Run buttons changing.

- When I don't have it call for the PID Panel VI, it exits just fine

- The exe just sits there, still in memory for some reason. 

Here's the setup:

- It is common practice to have all the panels run in the background, but as Hidden. Clicking the open popup button doesn't actually start the VI but just shows the already running VI via properties. Closing the window, just hides it again. This is for better performance so we don't have to initialize each window after clicking. Has never been a problem in the past. The VI is finally closed when everything else is closed by an event that calls FP.Close.

- The Launch.VI that starts the whole thing sets itself to Hidden and then does a FP.Close at the end. Again, this is standard but I want to give a feel for how we normally use Hidden panels. 

- I've introduced Inheritance and with it, there's a few items that have to be Shared Clones to run in parallel. 

- Currently there are only two VIs that run as Shared Clones with inheritance.

   - Subpanel Run.VI : populates all the data on the screen from a database. Has existed for about a year and hasn't been a problem by itself

   - PID Popup.VI : Calls Subpanel Run.VI to populate it's data but also has some other run loops that will stop when Subpanel Run.VI stops

There are other panels that also call Subpanel Run.VI in parallel and don't cause issues. 

How I can make the issue go away:

1) Disable Subpanel Run.VI call from PID Popup.VI

2) Keep Subpanel Run.VI but change the PID Popup.VI to Nonreentrant. 

I've tried to include the relevant screenshots. The Schematic Panel.VI is included just to show that the SubPanel Run Is used in the same way without issue. The only difference is that the Schematic Panel is non-reentrant.

Is there some issue with a shared clone calling a shared clone? I've spent about a full day on this issue and narrowed it down quite specifically. It doesn't seem to be a "Still running" issue but actually a "still in memory" issue and the exe won't let go of it. 

Running LabVIEW 2021 32 bit. 

[mcduff]

Can't say I understand what's going on from your images but the fact that it only happens in an EXE is a clue.

When running a "Main/Launcher" in the LabVIEW IDE you can close the window and still have the VI be active and finish whatever it is doing. In an EXE when the Main Window closes, the OS basically aborts the process, that is, the VI window cannot be closed and still active. Are you sending messages out after the windows closes, if so, try sending them before and see what happens.

[wiebe@CARYA]

I've seen this happening without a good reason.

I've also seen this change somewhere between LV13 and LV20...

For some reason LV doesn't seem to close even though all VIs are closed and stopped running.

The only way I could resolve this was to make sure everything really stopped (tracking the clones) and use a Quit LabVIEW (conditional, only in RTE)...

[Furbs]

wiebe@CARYA,   

I've tried putting in an Abort and a Quit after the last part in the Launch. Neither affect the EXE, it still stays in memory. I think everything is done running, but some memory hasn't closed so the EXE sits there.  

[Furbs]

---

@mcduff wrote:

Can't say I understand what's going on from your images but the fact that it only happens in an EXE is a clue.

When running a "Main/Launcher" in the LabVIEW IDE you can close the window and still have the VI be active and finish whatever it is doing. In an EXE when the Main Window closes, the OS basically aborts the process, that is, the VI window cannot be closed and still active. Are you sending messages out after the windows closes, if so, try sending them before and see what happens.

---

I'm not sure what you mean exactly by the "OS basically aborts". As far as I can tell, the processes are all done running, but due to the clone, the memory isn't released. The One Button message I used was only after I had this issue, for diagnostic purposes, to confirm it was hitting the end of the code. 

It's also worth noting, that in Windows, the process shows a sub process for every window that is not Hidden. After everything closes, the sub process goes from "Home" to "CompiledEXEName" so even windows doesn't think there's a VI open or something. 

[Furbs]

UPDATE:

It is being caused by the Open Panel vi. This method style has been used by my coworker for years and even with shared clones. I added changing of the FP Title and the close of the reference afterwards. Removing the Close ref didn't fix it. 

The overall objective of this VI: Allow the panel to run, but hidden. Then move the panel to where the INI file says and either show or wait for user to request. There's also some complication so it doesn't hide when its in development mode and another VI at the end so it won't close when in development mode, as to not annoy the developer with VIs they had open closing after a test...

Any advice on this VI or accomplishing this goal in a different way? Or why it would matter if the calling vi of the calling vi was reentrant or shared?

[mcduff]

---

@Furbs wrote:

---

@I'm not sure what you mean exactly by the "OS basically aborts". As far as I can tell, the processes are all done running, but due to the clone, the memory isn't released. The One Button message I used was only after I had this issue, for diagnostic purposes, to confirm it was hitting the end of the code. 

---

When the following function is run in LabVIEW

the VI may not necessarily exit, the vi can still run and do stuff like sending out Exit message, cleaning up references, etc, with the Front Panel closed.

This does not occur in an EXE, when the Front Panel is closed, the VI is finished, no cleaning up of references, sending Exit messages, etc. This is what I was referring to.

[wiebe@CARYA]

---

@Furbs wrote:

wiebe@CARYA,   

I've tried putting in an Abort and a Quit after the last part in the Launch. Neither affect the EXE, it still stays in memory. I think everything is done running, but some memory hasn't closed so the EXE sits there.  

---

Hopefully you made sure the Abort didn't prevent the Quit from executing...?

[Furbs]

So what is the difference between Front Panel Close and Hiding the panel? If the block diagram can still run in either case?

I just concluded my best test yet. If I change Open Panel VI so the state is Minimized or Standard, the EXE will still close properly. 

So I've reduced the problem to "When setting a cloned VI to Hidden, FP.Close does not properly close it to let the EXE exit fully." I will make a dedicated VI test to confirm this fully. 

[wiebe@CARYA]

---

@Furbs wrote:

UPDATE:

It is being caused by the Open Panel vi. This method style has been used by my coworker for years and even with shared clones. I added changing of the FP Title and the close of the reference afterwards. Removing the Close ref didn't fix it. 

The overall objective of this VI: Allow the panel to run, but hidden. Then move the panel to where the INI file says and either show or wait for user to request. There's also some complication so it doesn't hide when its in development mode and another VI at the end so it won't close when in development mode, as to not annoy the developer with VIs they had open closing after a test...

Any advice on this VI or accomplishing this goal in a different way? Or why it would matter if the calling vi of the calling vi was reentrant or shared?

---

It depends on a lot of details.

You could simply not use Show Front Panel when called (if that is what you do), it won't show and you wouldn't need to close it.

If you have a reference, simply set the panel bounds (there are a few properties that can be used), before running the VI.

Showing, hiding\closing, changing position, showing it again sounds complicated.