Decoupling Modules, References created inside FGV become invalid when calling VI is closed

[LLindenbauer]

Dear all!

While trying to decouple a module from a host program, I have encountered an unexpected behaviour that invalidated Event and Queue refrerences inside a Functional Gloval Variable (FGV, Action Engine, ...). I would be grateful for any comments on this - I suspect that there may be an easier solution for what I am trying to do, which would also be good to know.

I have attached three files, representing three components:

• A Guest VI that represents some module that I want to use in multiple Host VIs. It should have no knowledge about what Host VI it is running in. It should be able to meaningfully react to a shutdown of the Host VI, even if the Host is stopped forcefully. The Guest should handle graceful startup and shutdown of the module and offer some interfaces via Queues and Events for data and commands to travel into and out of the module (not included in the example).
• A Host VI that starts the Guest and loads its Front Panel into a subpanel.
• An Interface that is part of the same module as the Guest. The Interface monitors the Host to check if the Guest needs to shut down. In the example, I have designed the Interface as an FGV that is initialized by the Host and Guest in turn. It is then switched over to continuously poll the status of the host (In an implementation, it would listen for an event sent by the Host in case of a regular shutdown, and poll the Host's execution state to catch irregular shutdowns, which I have not included in the example).

The Guest is executed in reentrant mode. This adds comfort during development by allowing me to keep the front panel open and enables the simultaneus use of more than one instance of the module.

Now, the issue: When the FGV is initialized from the Host, the FGV creates references to an event and a queue and saves these refrences. I would now expect these references to stay valid during the lifetime of the FGV. When the FGV enters its polling mode, called from within the Guest, the references indeed stay valid (as indicated by "NotARefNum?"-Tests). When the Host VI is closed, I would expect these refnums to remain valid. They have been created inside the FGV, after all.

However, after stopping the main VI, the references to the Event and Queue created by the call from the Host stop being valid, but the references created from the call by the Guest remain valid.

Tested on: LabVIEW 2016, 32bit, Win10

I believe that this is unexpected behaviour. Is there an alternative way or best practice to achieve what I am trying to do, which is passing events to decoupled submodules and detecting unexpected shutdowns?

Best Regards,

Leopold

[crossrulz · Accepted solution]

Nope, this is totally expected.  It has been discussed many times in this forum.  The heart of your issue is that the references are tied to the process/VI that created it.  Since you created the queue in the host, the queue is tied to the host VI.  So when the host VI closes (ie leaves memory), all of the references tied to it are also closed, making them invalid for other VIs/processes.  My rule of thumb is a queue should be created and maintained by its consumer.

[wiebe@CARYA · Accepted solution]

---

@LLindenbauer wrote:

Is there an alternative way or best practice to achieve what I am trying to do, which is passing events to decoupled submodules and detecting unexpected shutdowns?

---

Create the references in the host, pass reference values to the guests... If the guests create references, pass them over a reference (queue, user event, DVR, control reference) created by the host.

References live in the top level VI's data space of the VI that created the reference. This can be unexpected the first ~5 times you run into it, but it is documented and by design. Note that the VI that created the reference might not have stopped running! The VI can be used in more than one hierarchy. Each hierarchy will have it's own top level data space that keeps the references created in it.

[LLindenbauer]

Thank You both! That explains what went wrong.

wiebe@CARYA wrote:
[...] it is documented and by design.

---

---

---

---

@crossrulz wrote:

It has been discussed many times in this forum.

---

I have tried to look for documentation before. In light of this new information, Point (8) in https://zone.ni.com/reference/en-XX/help/371361R-01/lvhowto/creating_user_events/ seems to come close to this behaviour. Do You have a link to the documents?

Best,

L

[wiebe@CARYA]

---

@LLindenbauer wrote:

Thank You both! That explains what went wrong.

wiebe@CARYA wrote:
[...] it is documented and by design.

---

---

---

---

@crossrulz wrote:

It has been discussed many times in this forum.

---

I have tried to look for documentation before. In light of this new information, Point (8) in https://zone.ni.com/reference/en-XX/help/371361R-01/lvhowto/creating_user_events/ seems to come close to this behaviour. Do You have a link to the documents?

---

Good point.

Haven't found any documentation yet... Guess an online knowledgebase or forum post is as good as it gets.

It might be "common" knowledge, that is simply a black corner in the official documentation...