executing subvi in parallel whithout interrupt the main VI

[Pierre_F]

hello

inside my state machine application, I need to execute a popup menu that doesn't have to pause the execution of the principal VI.

this popup is using devices that must not be used by the two VI at the same time, so the popup VI must communicate peripheral allowances to the main VI.

I tried the available tools "open reference VI" and "call by reference". it executes correctly but still stop the principal VI despite the way it is called.

my last solution would be to "destroy" my state machine by adding a second parallel while loop. 😞

do you have any idea of what solution I can apply?

I would ideally like to keep state machine, but I'm open to any other suggestion.

thanks

[GerdW]

Hi,

use the second parallel loop!

Why should that destroy your state machine?

[natasftw]

Take a look at http://zone.ni.com/reference/en-XX/help/371361H-01/lvhowto/acbr_call_and_collect/

You'll want to create a mechanism to talk between the two and I'm not entirely sure you care about the collect portion of this.  But, it's the general idea.

[mikeporter]

What you need is a nonblocking dialog box -- one that opens while letting the rest of the application go on and then signals when the application when it closes.

http://www.notatamelion.com/2014/12/02/adding-a-non-blocking-dialog-box/

Mike...

[johnsold]

If the state machine VI and the pop-up VI both need exclusive access to some device and yet the pop-up should not blcok the state machine, you need to do at least two things.

First, you need a non-blocking dialog as Mike suggested above.

Second, you need the state machine to be able to detect the fact that the pop-up has control of the device, AND it is designed to continue with other operations while awaiting access. You can probably use the Semaphore functions to implement this.

Your description raises a red flag (or at least a yellow cautionary flag) for me. Exclusive access to a resource (the devices) and continued operation without that access seems contradictory.  Perhaps you should take a closer look at the requirements for the performance of the system and at your implementation to see if an alternate approach might resovle the conflict.  You have not given us enough information to even begin to make an educated guess.

Lynn