From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
07-23-2018 03:09 PM
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?
Solved! Go to Solution.
07-23-2018 06:12 PM
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?
07-24-2018 02:06 AM
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.
07-24-2018 02:15 AM
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).
07-24-2018 02:51 AM
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.
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.
07-24-2018 03:15 AM
@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
07-24-2018 03:33 AM
Yes you are right. I just came upon it myself.
Thank you.
07-24-2018 08:21 AM
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
07-24-2018 12:25 PM
@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.