LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Asynchronous call: Checking if the sub-VI is running.

Try this; it is a non-blocking modification.   I added your "counter" to the info window, to show how to update the info itself.

 

2020-08-13 16_23_19-Producer_Consumer Design Pattern (Events) [Main 2.vi] Block Diagram.png

Download All
0 Kudos
Message 11 of 26
(1,076 Views)

@pjroland1121 wrote:

Use a "Static VI Reference" to the VI you wish to call Asynchronously.  Wire the reference to a property node for the "Execution State" (read).  The enum provided will tell you if the VI is idle, bad, running, or running as top level.

 

See "Execution:State Property" in the LabVIEW help.

 

If you are interested, i'd recommend you look in to the Delacor QMH (DQMH) toolkit (free on VI Package Manager and listed on NI's website as well).  It sounds like some of the things you are interested in trying are native features of DQMH.

It is an extension of the QMH architecture and has been presented at NI week a few times at least.  Their built-in project template for "Continuous Measure and Log" helps understand how it works quite a bit.  https://delacor.com/products/dqmh/  (they have documentation, videos, and even a youtube channel).


Yes I've heard of the DQMH, a friend of mine highly recommended it but I didn't have the time to try it yet.

However I didn't know it was free 🤔 Makes it even more interesting considering NI prices baseline.

 

I'll give it a try ASAP.

0 Kudos
Message 12 of 26
(1,056 Views)

Actually I've found a much easier (but also dumber) way to do it thanks to this thread

Just need to get rid of any controls, Tick "Open Front panel when called" and untick "Close afterward if originally closed" and statically call the VI.

 + Super easy and fast;

 + Manages "multiple execution" by itself (if the user click again while the VI was already running, it just brings to the front)

 - Works only to display some text and fixed images, nothing slightly more complex.

 - I don't learn much more about VI dynamic calls 😅

 

 

0 Kudos
Message 13 of 26
(1,045 Views)

@VinnyAstro wrote:

I've actually found a somehow easier solution: 

In the options when opening the VI reference, I used 0x100 ionstead of 0x80. 

This automatically closes my Info VI when closing the application.

VinnyLaTaupe_0-1597325653842.png

 

 

However, if the user clicks multiple times on the info button without closing the subVi in between, then the subvi will reopen the same number of time after every close. And I guess the only solution is to indeed use either a notification or a global variable.

 

I'm quite confused though why the "Exec.state" always show "running". Any explanations ? Because all of the solutions above sounds like random bodging to overkilling, rather than a clean solution, no ? 🤔


Instead of starting it every time you can e.g. start it minimized in the beginning and send Events or Queues instead and it can open itself. In this case extra "open info" would be processed and do nothing as it's already open. You just need to Catch the "window.Close"-event so you can ditch it and turn it into a minimize instead.

G# - Award winning reference based OOP for LV, for free! - Qestit VIPM GitHub

Qestit Systems
Certified-LabVIEW-Developer
Message 14 of 26
(1,038 Views)

Is this what you want?

"If you weren't supposed to push it, it wouldn't be a button."
Download All
0 Kudos
Message 15 of 26
(1,005 Views)

From my original thoughts, not really.

But as I said above (msg 13) what you're proposing is actually what I'm going for in the end. I just unticked the option "Load when loaded" in the option Window appearance tab. But thanks for taking the time.

 

I'm just still genuinely confused why a simple solution implementing a button "Close" in the subVI exists.

The "one Button Dialog Box" VI does this, problem is, it is blocking...

 

Anyway, I'll just make some changes here and there.

 

Still open for suggestions involving a button in the subVI to close the window without blocking the main and without creating a parrallel loop just for it 🙂

 

Vinny.

0 Kudos
Message 16 of 26
(973 Views)

@VinnyAstro wrote:

<snip>

Still open for suggestions involving a button in the subVI to close the window without blocking the main and without creating a parrallel loop just for it 🙂

 

Vinny.


You're going against the basic principles of dataflow.  Either it needs to block, or it needs to be in a parallel loop.  (Or it needs to not work.)

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
0 Kudos
Message 17 of 26
(959 Views)

@billko wrote:

You're going against the basic principles of dataflow.  Either it needs to block, or it needs to be in a parallel loop.  (Or it needs to not work.)


Hmm I haven't thought of that.

But what about the asynchronous calls then, isn't it the point of it ?

0 Kudos
Message 18 of 26
(949 Views)

Your only issue with the asynchronous call method was that the user could press the help button multiple times and multiple windows would come up, right? Or was there something besides that?

Redhawk
Test Engineer at Moog Inc.

Saying "Thanks that fixed it" or "Thanks that answers my question" and not giving a Kudo or Marked Solution, is like telling your waiter they did a great job and not leaving a tip. Please, tip your waiters.

0 Kudos
Message 19 of 26
(944 Views)

@FireFist-Redhawk wrote:

Your only issue with the asynchronous call method was that the user could press the help button multiple times and multiple windows would come up, right? Or was there something besides that?


Yep.

I thought of disabling the button when the window is open, but I kinda didn't want to do that. My idea behind it is that if the user have a lot of windows open at the same time and don't want to bother finding the info one, then he can just click again on "info" and the info window would: 1. If it is not open, open in front; 2. If already open but minimised/hidden somewhere, Pop-up in front (and not re-open again)

 

I might be nit picking here, but I feel that it would be a normal and most natural behaviour from an application showing a poping window : Opening/showing up on a click on a button and closing ether by using the cross or clicking on closing button.

 

Also, the thing is, for now I'm doing this for a relatively easy application, which is just opening a window displaying a static message, but later I will most probably have multiple windows displaying various dynamic informations. I just figured out that training first on a simple application would be better 🙂

 

0 Kudos
Message 20 of 26
(939 Views)