Start/end a sub-vi with vi-reference in a Build (*.exe)

[Eisbein]

With the correct sub-vi-settings (load and hold) in the main vi and the right window-settings within the sub-vi (open FP at start and close if closed before loading) this works.

Attached as example.

I'll let you know if this works with the original main/sub vi.

Thanks

Ralf

[GerdW]

Hi Ralf,

---

@Eisbein wrote:

With the correct sub-vi-settings (load and hold) in the main vi and the right window-settings within the sub-vi (open FP at start and close if closed before loading) this works.

---

It also works correctly when the subVI is called as an ordinary subVI instead of "call by reference" - as suggested before several times…

The subVI may also look like this:

[daveTW]

Hello Ralf,

I understand that your SubVI is a very big file on disc. What size is it? Why is it so big? Do you store default data in Controls or in constants? Could this data be stored in an external binary file?

With " I call a sub-vi as a file" do you mean using VI-Server?

If the Sub-VI is an non-reentrant VI, then you don't have to worry about multiple calls, it will remain only once in memory. With that in mind, is it really better to have the big VI besides the .exe than having it included?

OK, and your problem with the communication between the VIs would be very easy solved, if you use a simple text file on file system. This is true, if it's not time critical.

[Eisbein]

Hi Gerd,

thanks, and that's how I did it in the end.

However, one problem solved, the next one stepping up.

Not in a while-loop this seems to be a walk in the park.

However, in another VI I need to call the sub-vi within a while loop, and this seems to be more tricky.

Basically when measurements are taken in the while loop I need to call and end the sub-vi by pushing a button.

It seems that the process is stuck in the T/F case and doesn't go to the next loop. Tried without the event structure (with a control bool), but didn't get anywhere. Can start, but after the sub-vi has started the main vi is frozen and seems to wait for something to end the T/F case.

It's clear, once in the while loo Labview would first finish the loop and ignore anything around.

Any idea how to start/end a sub-vi in a while loop?

Best Regards

Ralf

[GerdW]

Hi Ralf,

---

@Eisbein wrote:

Can start, but after the sub-vi has started the main vi is frozen and seems to wait for something to end the T/F case.

It's clear, once in the while loo Labview would first finish the loop and ignore anything around.

Any idea how to start/end a sub-vi in a while loop?

---

So on one hand you pretend to under stand the "THINK DATAFLOW!" mantra, but on the other hand you ask how to solve your problem with a VI ignoring the "THINK DATAFLOW!" mantra!

1. The while loop can only iterate once all code within has been finished. When your subVI is executed it will stall this while loop! Simple solution: run your subVI in its own loop! (Again: this will work without using an VIServer functions!)
2. Additionally you use an event structure: FP elements are blocked until the event case is finished (default event case behaviour)! There is no way (right now) to even press that switch as long as the subVI is still executing…

Btw.:

• Why do you still use a local variable in the subVI?
• Why don't you put the notifier reference in the upper left corner of the subVI connector pane as recommended by StyleGuide?
• Why do you need to branch the notifier reference wire before the loop?

[Eisbein]

Hi Gerd,

the sub-vi loop and replacing the event structure was my first attempt. As I said, didn't work either. See attached.

Don't know why, but it's stuck in the T/F case and won't close the sub-vi after it's started.

The local variable I have only used just to make sure that it's going to work later in the main vi (where I have to use a local variable).

I'll go for a run now, maybe after this I'll be less confused.

Ralf

[Eisbein]

Hi Dave,

I like the idea of a temporary text file that both vi's share. That would be a nice work around if I can't get the sub-vi call and ending from/to the main vi's. Simlutaneous R/W might become an issue, but this is worth the shot.

I would have another question. 

As I have learned....

.... is different in a build (*.exe) as it is in the development environment. Means, I would need to add the "exename"\ of the build to get the right sub-vi when working with VI-Server.

Do you by any chance know how I can get around this issue and detect (automatically) if the program is being ran in the development environment or as a build (exe)? Otherwise I would need to add a hidden switch that switches from one to the other.

Best Regards

Ralf

[GerdW]

Hi Ralf,

---

@Eisbein wrote:

Don't know why, but it's stuck in the T/F case and won't close the sub-vi after it's started.

---

Because of "THINK DATAFLOW!"

The lower loop will not iterate as long as the subVI is being executed (DATAFLOW!) and so you cannot send the notification (DATAFLOW!). And because there is no notification the subVI will not stop: a classic deadlock!

It might be so simple:

And to make this even more reliable:

What about implementing a QMH scheme instead?

• Run the subVI immediately in parallel to your mainVI.
• Send commands from main to sub using a queue.
• Commands can include "show frontpanel", "hide frontpanel", "quit", and whatever else you might need.

You can also call the same subVI easily from different mainVIs: they all just need to place commands into the same queue…

[Eisbein]

Hi Gerd,

thanks for your effort and the examples. I guess I didn't express myself correctly.

In the sub-vi itself you actually don't have the option to end the sub-vi. The user can use, but not end it. This is only determined by the main vi. The start/end button in the main-vi for the sub-vi is just a simple example. In the actual main-vi there are conditions that end the sub-vi. That's why in your example you end up with the same issue.....you can start the sub-vi from the main-vi, but not end it without also ending the main-loop. So let's assume the main loop runs forever and that the start/end button is to start and end the sub-vi.

I have modified your vi's to make clear what I mean.

It would appear this a dead stop. I need to look into the queue option....of which I don't have any clue where to start.

Thanks anyway

Ralf

[Bob_Schor]

---

@Eisbein wrote:

I would have another question. 

As I have learned....

.... is different in a build (*.exe) as it is in the development environment. Means, I would need to add the "exename"\ of the build to get the right sub-vi when working with VI-Server.

Do you by any chance know how I can get around this issue and detect (automatically) if the program is being ran in the development environment or as a build (exe)? Otherwise I would need to add a hidden switch that switches from one to the other.

Best Regards

Ralf

---

Hello, Ralf.

     Here's how I do it.  There is a Property Node for Applications, called "Application.Kind", that returns an Enum that will evaluate to "Development System" if you are running from LabVIEW.exe (i.e. if you are developing and testing your code in LabVIEW, itself) and "Run Time System" if you are in the Run Time System.  [Actually, you don't really need to use this -- I do because at one point, I got some other value that I wanted to exclude -- who remembers why I wrote the code this way a decade ago?].  What I do is to open this Reference (which points to the Folder holding either the LabVIEW Project, if you are developing using LabVIEW Project, which, of course, you are since you need Project to build executables, and whereever you have your Run Time Executable if you are in Run Time mode), use Build Path to locate a folder I call "Data" (where I want to put Data Files) as a sub-folder of the Project or Run-Time Folder, and use an Open-G function, shown in Green, called "Create Dir if Non-Existant", which does what the name implies.

     All of this code is "wrapped" in a VIG (VI Global, an old LabVIEW construct that, here, executes defining the Data Folder only once, when first called, and then saves the results in a Shift Register for use with all subsequent calls).  Note that I "manually" create the Data folder at the top level of my LabVIEW Project and include the Folder in the Project File (just in case I need to reference files stored there during Development), but you can skip this step.

     Anyway, here is the code as a LabVIEW 2019 Snippet.  If you are unable to open it (or are running an earlier version of LabVIEW), you can recreate it by creating what you see, and doing the following for the "missing cases":

• The outer False Case simply brings the Path Reference from the left Tunnel to the right Tunnel.
• Similarly, the right-most False Case does the same thing.
• The middle Enum Case has a Development System entry that duplicates the Run Time System entry, and a Default that has a Not a Path constant.

 Bob Schor

P.S. -- you can download and install the OpenG Toolkit using VIPM, which you should have installed when you installed LabVIEW.  Look for "OpenG Toolkit", which installs most of the OpenG Tools that have been around (and useful!) for at least (I'm guessing here) 15 years.