LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

only opening one program at a time?

I was wondering if there is a way to restrict a program so that only one instance can be opened at a time.  I have two pieces of motion control software that control the same piece of equiptment (one is for maintenance and one is for normal operation).  I would like to make sure that only one of the programs can be opened at a time.  I thought of putting them into a single program with a tab structure, but that suggests that you can switch between the tab, and I don't want to allow that.  I also thought of having a pop-up when the program first launches that askes which program you want to run, that way you can only choose one or the other.   But you could still open two instances of that application, one of each. 

The only thing I can think to do would be to use a global variable as a flag and only allow the program to launch if the flag is off.  However if the program crashed and didn't exit properly the global flag would be left on and the program wouldn't start. 

Does anyone know if there is a good way to do this in LabView?

Thanks,
Kasey
0 Kudos
Message 1 of 5
(2,694 Views)
A simple one-instance solution involving a tab control is to put the controls for normal operation onto one page, the controls for maintenance on another, and disable the other page entirely whenever one of the programs is actually running. That way you enforce your desire about having only one of your motion-control modes active at any time, and you don't have to worry about setting system-level flags that could become corrupted for reasons beyond your application's control.
 
The controls on each page could call the motion-control subVI as the controls on the other page, passing in a "mode" flag, if you think there's enough commonality between normal operation and maintenance to warrant a single motion-control subVI rather than two.
 
An alternative is to use two subVIs, one for normal operation and one for maintenance, and load the appropriate subVI into a subpanel when the user flips a switch.
 
::Marty
0 Kudos
Message 2 of 5
(2,686 Views)

In my previous message, typo in second paragraph: should have been

"The controls on each page could call the same motion-control subVI as the controls on the other page..."

::Marty

0 Kudos
Message 3 of 5
(2,684 Views)
Thanks for your response.  I see what you mean about using the tab structure, although tabs are usually designed for switching, so it might be confusing to the user if the tabs are exclusive.  I just did a test where I made the program into an application and it seems like I can only open one copy of the program.  That actually solves my problem. 

Thanks again.
Kasey

0 Kudos
Message 4 of 5
(2,680 Views)

You're welcome. I first used tabs in LV 6.1, before subpanels were available. I didn't want to run subVIs as popups, as a rule. The filetab was a good solution. The selected page obscures front-panel objects on the other pages, so each page is like a separate screen. I labeled the pages according to function, and the user could switch pages accordingly. Switching tab pages is easier than clicking a button on the main VI's front panel to pop up a VI enabling one function; then clicking "End" to disable; selecting another button on main VI's FP for another popup VI; etc.

But there were certain things I wanted to do without interruption (hardware interactions), so I disabled all pages but the active page as long as the critical task was ongoing. Also, I would disable certain controls even on the active page ("Start" button was disabled until the test was over, etc.). I don't think that strategy violates the spirit of the filetab.

The only trouble was that most of the pages had complicated functionality, so many of them had clusters full of option buttons. User would click one, I'd have to hide the option menu, show a bunch of other controls, etc. Straightforward but tedious. Subpanels make that kind of thing easier, because the VI running in the subpanel is responsible for its own front-panel display. And different people can develop different subpanel VIs at the same time, without too many problems merging.

Anyway, I'm glad your problem is solved. I just tried to run two instances of an LV 7 application under Windows 2000 and I couldn't. So that's good to know.

::Marty

0 Kudos
Message 5 of 5
(2,674 Views)