LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Notifying the end of an Asynchronous call

Solved!
Go to solution

I'm doing a complicated program and I've encountered strange behavior.
I attach the simplest model.
One function calls the other via an asynchronous call and passes several parameters. Including referring to events.
In the subVI, the event is registered and processed.
The problem is that if I call the subVI statically, then everything works, but I need to run the subVI dynamically, I'll embed it in the sub-panel.
In the attached archive _loader.vi - the start function.
In it, you can switch two types of calls.
To verify that the event is work, use the OK button.
Where is my mistake?

loader.pngrunby.pngmain.png

0 Kudos
Message 1 of 9
(2,652 Views)

Hi Artem, the diagram disable case you have labeled "this case not works" runs without error for me. What is the problem you are seeing?

0 Kudos
Message 2 of 9
(2,623 Views)

Hi, Gregoryj!

The OK button generates the modeSel event. Then it is processed in the same structure.
When I run the function statically, I see the number +2 (button + user event).
When I run the same function dynamically, the number +1, the event does not return to the structure. But no one error message.

0 Kudos
Message 3 of 9
(2,606 Views)

Your code does not use the "Wait on Asynchronous Call" function - is there another VI in your program? It would be better to use that than using the Exit function to stop the LabVIEW run-time. You are also Destroying your User Events when the dynamic VI finishes. Instead you should use them in your parent VI to detect the closing of the dynamic VI and then use the "Wait on Asynchronous Call" function in that Event handler (or subsequent code).

0 Kudos
Message 4 of 9
(2,603 Views)

I do not need to wait for the function to finish, which is why I'm using the x80 option.
I use the Exit function only in run-time, so that the program window is completely closed, and not left to hang in the non-working state.
The parent function has already completed its work by the time the dynamic completes, see here.

RUN.PNG

 

That's why I delete events in a dynamic function.

This is a simplified example, the program, of course, has many more functions.
But you are now talking to me about how to finish the work at the end, and I say that the function does not work correctly in the middle.

0 Kudos
Message 5 of 9
(2,596 Views)
Solution
Accepted by topic author Artem.SPb

@Artem.SPb wrote:

Hi, Gregoryj!

The OK button generates the modeSel event. Then it is processed in the same structure.
When I run the function statically, I see the number +2 (button + user event).
When I run the same function dynamically, the number +1, the event does not return to the structure. But no one error message.


The event lifetime is cut short by the death of the top level calling VI.......

 

http://zone.ni.com/reference/en-XX/help/371361P-01/glang/register_events/

 

If the loader was to stay alive your code will work as expected.

 

0xDEAD

 

 

Message 6 of 9
(2,595 Views)

Yes you are right. I just came upon it myself.
Thank you.

0 Kudos
Message 7 of 9
(2,589 Views)

That one has bitten me once before 😉

 

Ideally you want the communication owned by (created in) the VI that's going to stay alive the longest. Sometimes you have to do some weird and wonderful things to make that happen.

 

0xDEAD

0 Kudos
Message 8 of 9
(2,578 Views)

@deceased wrote:

Ideally you want the communication owned by (created in) the VI that's going to stay alive the longest.


Slight alteration here:

Ideally you want the communication owned by (created in) the VI that's going to be reading the data.

 

This is obvious when dealing with Queues (since you should only ever have 1 reader of a queue).  It is less obvious who should create it when using User Events where multiple VIs could be reading the message.  At that point, it becomes whichever reader will live the longest or a higher level VI that directly calls these VIs and cannot close until all of its subVIs are complete.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
Message 9 of 9
(2,559 Views)