LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Start Asynchrounous Call if not already running

One thing I should point out is that a running vi in LabVIEW that is waiting on something, like a Queue or Semaphore or whatever, isn't actually occupying a thread or using any CPU.  Memory is different, as LabVIEW tries to reuse memory, and you have to do more than stop a vi to release memory.

0 Kudos
Message 11 of 15
(437 Views)

If it's a non-reentrant VI, what's stopping you from writing to a global variable when the VI gets called and again when it stops. Call the Global "Running" and write to it appropriately. T when starting, F when stopping.

 

The global will then tell you pretty easily if the code is running or not.

 

I can't think of a more simply way to do it tbh.

0 Kudos
Message 12 of 15
(429 Views)

Frankly,  I would just let the subvi go idle and stick an Event loop on top of it.  Let it respond to dynamic Events like "Execute", "Quit" or "Abort(enqueued other end)"


"Should be" isn't "Is" -Jay
0 Kudos
Message 13 of 15
(402 Views)

I mean, what I don't get is:

If your calibration is already running, why would your program want to start another calibration? Your program seems to have some issues with communication. Why is the previous call valid and the new one is not?

If the new one is not valid, why call the calibration at all?

What's wrong with queuing up a second run?

So many questions.

0 Kudos
Message 14 of 15
(371 Views)

@Intaris wrote:

If it's a non-reentrant VI, what's stopping you from writing to a global variable when the VI gets called and again when it stops. Call the Global "Running" and write to it appropriately. T when starting, F when stopping.

 

The global will then tell you pretty easily if the code is running or not.

 

I can't think of a more simply way to do it tbh.


I've used this approach in the past, but you need a separate globale variable for each windows, which gets annoying quite quickly.


Instead I use the "FindWindowA" method from the user32.dll to find if the window is already open, if not launch it. If yes, bring to the front (or do whatever). It is my standard template for launching any asynchronous window that has only 1 instance.

 

Bring to Front Example.png

Example above is attached (LV2018)

 

I guess the only downside is that you cannot change the window title dynamically. In that case, use the global variable approach I guess.

0 Kudos
Message 15 of 15
(355 Views)