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.
12-03-2018 08:01 AM
Hi Paul,
It's embarrassing, but yes, your absolutely right with this 30 seconds, I just forget that I started with 30 seconds instead of 5 minutes we planned to use. I'm sorry about that.
I can't let the caller VI (VI A) running. VI A will be packed into an exe and then is called by an other application via cmd line. We have to work with Tecan lab robots and those are programmed via their own, super crappy, software that dies more often then succeed. When we program new routines on that robot, we want to call every one and then this VI A that resets VI B. But if the robot would die, then the timer in VI B would expire and send us an alarm. Because the robot is waiting for that exe-process to complete, it cannot continue running.
Is there no way to communicate between to VI's that are running independent? I mean, last thing, I can use files with state numbers 😞
Regards,
Urs
12-03-2018 08:09 AM
I am not sure I fully understand the design, or why you cannot keep the launcher running. Can you elaborate a bit more? Someone may be able to suggest a better design.
You could also use TCP based messaging, but you will need to put in the code that will reliably reconnect on disconnections.
12-03-2018 10:00 AM
@paul.r wrote:
wiebe@CARYA wrote:
@Sapiophile wrote:Can someone help me how I could have a VI starting another VI and then let the first one stops and the second continue to run?
When the main VI stops running, the reference to child VI is invalidated. That means there is now no more reference open to the child. So it will stop running. The child needs to open an explicit reference to itself. Not a "this VI" node, but an Open VI Reference. That reference needs to be not closed until the VI should stop.
Huh? Why would the child stop running just because the caller stopped? It was launched asynchronously, it will keep running unless the caller (or something else) explicitly stops it.
Pretty sure a VI will be removed from memory if it has no referee's. If it's started dynamically, it will be removed as soon as the caller closes it's reference. Unless it has an open front panel , or another open reference. A static VI reference does count, but if the caller stops running, that reference doesn't count.
12-03-2018 02:57 PM
I am on the same page as wiebe
Sounds like Daemon (see here.. it may work)
Now regarding the different references;
The Hex 80 switch does that.
Ben
12-16-2018 09:19 PM
Hi all,
Sorry for my late response. Based on Ben's statement, my final solution is calling Vi B using the Parameter x80 and I do not close the reference. In Vi B, the first thing it does is to create a queue and put its reference in an indicater. In Vi A, just after creating and launching the Vi B, I let Vi A wait in a loop until it reads a valid queue reference in the indicator of Vi B. With this, I can send commands to Vi B, works like a charm. The only thing I did not manage to design, is in the termination phase to let VI A wait until Vi B is closed first. Because I do not get another Vi ref to Vi B after I launched it and read the indicator. It also works without, but it certainly it would be better to know, whether Vi B closed successfully or not.
I added the whole project to this post. Thank you guys for your support,
Urs