7 replies to this topic

[Maite]

Hi!!
I'm new using LabView and I'm a bit lost with its behaviour sometimes!

I developed an application based on pluggins, due to I have different modules of functionality which don't need to be executed at the same time,all the pluggins are singletone classes. Also, I did a Main UI with a subpanel to manage the pluggins. Each pluggin has a Main vi which is loaded in the subpanel.
At the begining of the executing the app, the Main UI config the pluggins, registering the events they need, assingning the mains vi references to them, its names... So a singletone instance of each pluggin is created.

To load/unload a vi, the steps I follow are: First stop (sending an event to stop the vi and waiting for the idle state or aborting it) unload it from the subpanel, and run the indicated vi and loading it after in the subpanel.

Well, the first vi loaded in my application allows to create objects (simple Goop pattern) which are stored in another singletone class (acceding straight to its attributes due to is a singletone object i don't need more wires) which is also another plugging, and usually is the second funcionallity executed, but if I "stop" before unload the first vi these objects are lost, I can see the rigth references, but after unloading this vi from the subpanel Labview cannot find these objects anymore. I have inserted a breakpoint to the "destroy" and CleanUp vis but it is not being executed. So they are not being deleted by hand.

Do you have any idea why it is happening? It will be so bad if I don't "stop" the main vi's and just load / unload them to the subpanel?

Thanks in advance.

[Onno]

It's going to be really hard to help you out without seeing the code, I'm afraid. (Or maybe it's just me, and someone else is able to give some advice here?)

Do you think you could create a small example project that demonstrates the problem, and post it here?

[Ulf]

Hi!!
I'm new using LabView and I'm a bit lost with its behaviour sometimes!

I developed an application based on pluggins, due to I have different modules of functionality which don't need to be executed at the same time,all the pluggins are singletone classes. Also, I did a Main UI with a subpanel to manage the pluggins. Each pluggin has a Main vi which is loaded in the subpanel.
At the begining of the executing the app, the Main UI config the pluggins, registering the events they need, assingning the mains vi references to them, its names... So a singletone instance of each pluggin is created.

To load/unload a vi, the steps I follow are: First stop (sending an event to stop the vi and waiting for the idle state or aborting it) unload it from the subpanel, and run the indicated vi and loading it after in the subpanel.

Well, the first vi loaded in my application allows to create objects (simple Goop pattern) which are stored in another singletone class (acceding straight to its attributes due to is a singletone object i don't need more wires) which is also another plugging, and usually is the second funcionallity executed, but if I "stop" before unload the first vi these objects are lost, I can see the rigth references, but after unloading this vi from the subpanel Labview cannot find these objects anymore. I have inserted a breakpoint to the "destroy" and CleanUp vis but it is not being executed. So they are not being deleted by hand.

Do you have any idea why it is happening? It will be so bad if I don't "stop" the main vi's and just load / unload them to the subpanel?

Thanks in advance.

The object reference is probably destroyed by the "automatic" garbage collector, when the VI that created the object "stopped" running. You have to make sure that the creator of the objects is alive and running during the whole execution.

//Ulf

[Maite]

Sorry, I will be glad to offer you some code, but the project is huge and hardware dependent, as you say I should create a small project to show you the problem, but I'm running out of time, so I would try to move the creator of the objects and see if it works fine first.

Thanks both of you, I will let you know my progress.

[ShaunR]

The object reference is probably destroyed by the "automatic" garbage collector, when the VI that created the object "stopped" running. You have to make sure that the creator of the objects is alive and running during the whole execution. //Ulf

You may regret saying that

[Aristos Queue]

Ulf: There's no garbage collector in LabVIEW. GC is a technical term with specific meanings for programming languages. Say instead that LabVIEW has contracted times when the references will be automatically released.

Fernando: A reference -- any reference type -- in LabVIEW is automatically destroyed when the top level VI that created it goes idle. I'm not sure what you're using for your "singleton class" because that's a pretty ill-defined term in LabVIEW. I'm going to assume that you mean you have a Data Value Reference that contains an object and you only create one of those DVRs and just return the same DVR every time someone requests it. That DVR is only going to remain valid as long as the first top-level VI is running. You will need a different mechanism to share references between separate top-level VIs. If you are using DVRs, let me suggest you use a single-element queue instead... give the queue a name at Obtain Queue and that way you'll get a different refnum every time, but each refnum will refer to the same underlying queue. There are lots of comments on LAVA and on ni.com about single-element queues if you need further guidance.

You may regret saying that

He's a new guy... I take it easy on the new guys. :-)

[Maite]

Thanks Aristos for your reply!
As you wrote I'm using singletone as a class which can only create an instance. Your tip is a good one, I will keep in mind for the future.
I just finished solving the problem, you and Ulf were rigth, I changed the "creation" of the objects to a vi that is only released with the exit of the app, and it works fine.

Thanks again guys, you gave me the key

[Ulf]

He's a new guy... I take it easy on the new guys. :-)

Thank you...