Invalid VI references

[Simon Kelly]

I've been trying to write a module manager for an application i'm building. The idea is that the user decides what modules to run and then these modules are managed using the VI server. Their refernces are stored in an array and if the user wants to change what modules are running, then the module manger should shutdown or start the VI's.

This seems to work fine if you place the manager VI on the block diagram of the calling VI but if you call the VI using the VI server then somehow the references to the running modules become invalid.

I have attached a basic version of the system. If you run the 'CALL from diagram' VI the system works fine but if you run the 'CALL by reference' VI, it all goes horribly wrong.

The reason I want to call by refernce is that I don't want the calling VI to have to wait until the user has decided what modules to run before it can continue.

Please help, I don't know where to go from here.

Download File:post-2342-1121338478.zip

[m3nth]

While someone possibly may find a solution to your problem, your VI's won't run as-is because you didn't include them all. Open your main application(s) and select File > Save with Options, and select Development Distribution.

Keep in mind that not everyone has the files you do in various places for your development setup and that not everyone has OpenG.

[Simon Kelly]

Please find development distro here....

Download File:post-2342-1121413637.llb

[Rolf Kalbermatter]

I've been trying to write a module manager for an application i'm building. The idea is that the user decides what modules to run and then these modules are managed using the VI server. Their refernces are stored in an array and if the user wants to change what modules are running, then the module manger should shutdown or start the VI's.

This seems to work fine if you place the manager VI on the block diagram of the calling VI but if you call the VI using the VI server then somehow the references to the running modules become invalid.

I have attached a basic version of the system. If you run the 'CALL from diagram' VI the system works fine but if you run the 'CALL by reference' VI, it all goes horribly wrong.

The reason I want to call by refernce is that I don't want the calling VI to have to wait until the user has decided what modules to run before it can continue.

Please help, I don't know where to go from here.

5340[/snapback]

I have not looked at your VIs but this sounds like a familiar problem. LabVIEW does so called garbage collection on any and all refnums. The way this works is that as soon as the top level VI of a hierarchy, which created somewhere a refnum by opening an object, returns to its idle state, the refnum will be deallocated. So trying to store that refnum in a global to be used in another VI later on is simply bound to fail. By invoking your initialize routine over VI server from a separate VI you get in fact this situation. Another possibility is that by opening the refnum to your manager VI and closing it afterwards you really remove the entire manager hierarchy from memory and that should cause LabVIEW also to close refnums allocated by those VIs.

You will have to make probably some modifications to your architecture to create a deamon of some sorts which is both responsible to load/unload the managers and also relays the execution of those managers to the interested clients. Your deamon must be running in the background as long as you want to make use of those managers or refnum objects created by these managers.

Rolf Kalbermatter

[Simon Kelly]

Thanks for you reply Rolf. After much experimentation after my last post I discovered what you said about 'garbage collection' of refnums which is what has been happening. I think your idea of creating a deamon that runs in the background is a good one!

For anyone interested, I have attached 3 very simple VI's to illustrate the problem. It uses a queue to communicate between 2 VI's. The queue's refnum is stored in a LV2 global. If the VI that first initialized the refnum is closed, then the other VI generates an error caused by the invalid refnum.

I hope someone will find it useful.

Download File:post-2342-1123839106.llb