Clones stop but EXE does not close

[wiebe@CARYA]

---

@mcduff wrote:

---

@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

---

I always use the Close method. Not sure if FP.State(Close) gives an error, but I think I had problems with that:

[mcduff]

---

wiebe@CARYA wrote:

---

@mcduff wrote:

---

@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

---

I always use the Close method. Not sure if FP.State(Close) gives an error, but I think I had problems with that:

---

The method has the same effect in EXE; in fact that is what I meant to include, not the property, as that is what I use in my VIs. VIs can run with the FP closed, EXEs cannot.

[Furbs]

I agree that ideally, you can set the position before running the VI. I haven't tried to tackle that because referencing VIs like this is not something I'm comfortable with. I think you could do it with Static VI reference but it hasn't been an issue worth tackling until maybe now. Our VIs don't show on run, so we are only opening as hidden, then moving, then showing on button click. 

I have created the simplest version of the problem in a VI (with a few exceptions of event regs to make it act like the others)

This VI is currently set to Shared Clones. If you change it to nonreentrant, you dont see the issue. If you change the Hidden to Standard, you don't see the issue. If you could try this on your machine and confirm, that would be amazing or better yet, tell me how any of the code is problematic. 

[wiebe@CARYA]

---

@Furbs wrote:

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. 

---

Close will close the panel, hiding hides it 😁.

A VI stops executing (is removed from memory) when nothing refers to it. If the panel is open, that's a references, and an open panel can keep the VI in memory.

That's how a normal VI (e.g. a loop with wait in it) acts when you run it: it runs, but when you close the Front Panel, it is removed from memory (in newer versions you get a warning asking if you want the VI to stop running).

So, if a VI has no references to it, closing the panel might remove it from memory.

Hiding doesn't. A Hidden VI isn't closed.

Another difference is when registering for dynamic events. This will fail if the front panel is closed. It will succeed if the panel is open or hidden. As people seem to think the register for events node always succeeds, the error out is often not wired. A big problem...

This is especially tricky when putting a FP in a SubPanel. Another place where close and hidden makes a difference.

The SubPanel needs the VI to be closed (not hidden or open), but the VI often wants to register dynamic events when it's started... A major pain... The trick is to make the VIs put themself in the SubPanel (passed to it). It can then hide itself, register for events, close itself, and put itself in the SubPanel... 

[Furbs]

I am closing the VI using FP.Close just as you said is the successful way. I only Hide the panel when the user clicks the X as I want it still running in the background in case they want it back. The Dynamic Events haven't been an issue yet but I was already creating a version without that for testing. We use User Events for most things instead of using a QDSM. So a User Stop Event is registered for by all loops in the application when its finally told to end, it'll send to everyone. I don't think those are relevant to the current situation.

In this version, the panel will reveal itself after 5 seconds, then you'll need to click the Stop button to actually close the panel properly (simulate the dynamic stop event). This VI works when Nonreentrant, but not when set to be a clone. 

The initial change of Hidden versus Standard before the Event loop isn't having an affect in this simple version, only the change of Reentrant. If we cannot come up with a solution here, I think this version is finally simple enough that I can open a ticket with NI.

[mcduff]

Below is image that may better explain what I was saying earlier.

1. User hits Exit or Windows closes program, an EXIT message is sent to all running modules.
2. Wait until modules return their "error out".
3. If modules are stuck, after 10s force close them using an occurrence. (One of my favorite LabVIEW features.)
4. If no force close is needed, then close FP window at the end.
5. Order is important because some references like User Events may "go bad" if the top calling VI is closed before calling VIs.

[Furbs]

I have not encountered Occurrences before. It seems like a decent way to ensure everything is closed as a failsafe, but definitely seems like a workaround / error handling rather than a resolution.

Although it may not help in this instance, since I'm not having a problem with all the Error Outs returning, the VI returns when told to, it just doesn't Close or something. I'm beginning to think that I have a legit NI issue here. 

(I'm trying to resolve this rather than change how we show/hide since I'm the new guy and will need good justification why this code works everywhere else but not for me)

[mcduff]

---

@Furbs wrote:

I have not encountered Occurrences before. It seems like a decent way to ensure everything is closed as a failsafe, but definitely seems like a workaround / error handling rather than a resolution.

---

It is definitely a work around; if for whatever reason the program hangs, which you try to avoid at costs, there is an out mechanism for the window to close and spare the user from hitting Crtl-Alt-Del to manually close a program. 99.99% of the time, the occurrence should fire and the program closes correctly, it is there for those 0.01% cases that are unpredictable.

---

@Furbs wrote:

Although it may not help in this instance, since I'm not having a problem with all the Error Outs returning, the VI returns when told to, it just doesn't Close or something. I'm beginning to think that I have a legit NI issue here. 

---

I am guessing a reference is going bad somewhere and an User Event is not being catched. I had a similar issue that took me awhile to debug and figure out. I closed the Main Window but wanted to keep another window opened; the event registration I generated in the Main Window for the other window went bad even though I did not close it. The other possible issue is a hang in your hardware loop, which I assume is the PID loop. Maybe it hangs sometimes when try to close the resource?

[Furbs]

---

@mcduff wrote:

---

I am guessing a reference is going bad somewhere and an User Event is not being catched. 

---

The Stop User Event? I know the code does exit though, just doesn't close, so I'm assuming it's a deeper CompSci type issue that I know nothing about.  Also it is a PID popup window, but only the GUI, the actual PID controller is on a real-time embedded controller. I found an example in our repo that uses reentrancy like this but uses Fire and Forget to just launch them asynchronously. I think that's the work around I will go with, however I'm still concerned that I have no idea why it's doing what it's doing for future work. 

[wiebe@CARYA]

---

@Furbs wrote:
I think that's the work around I will go with, however I'm still concerned that I have no idea why it's doing what it's doing for future work. 

---

I just gave up not knowing what's going on. Not happily, it keeps nagging...

It used to work just fine in the past. Now executables randomly don't close even when everything stopped running... Can't say for sure if it's LV or my applications. Both evolved.

My guess is there's some reference (SubPanel, clones, something else) preventing a close... Maybe even a live lock  or dead lock. I'm pretty sure my code stopped running.