LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Is it possible to programmatically cause a stopped executable to be rerun?

Solved!
Go to solution

I have an executable (the "Worker") which when run does some work and then stops. I can click again on the run arrow and it will use the existing memory context to run again doing slightly different work and then stop. This all works as desired.  Now, instead of clicking the run arrow to start/restart the executable, I need to start/restart it programmatically from another executable (the "Launcher") whose only job is to start the "Worker", wait for it to set a network-shared variable and then exit. 

 

What I have found when I've tried this is the Launcher (using the System_Exec VI) can cause the Worker to start and run if the worker is closed (not in memory; has not been previously opened/run). But if the Worker is in memory because it has already been run and is now in a stopped state, the Launcher can no longer cause it to start running again (the equivalent of me pushing the RUN arrow again).

 

Is there a way to make this work programmatically?

0 Kudos
Message 1 of 9
(2,603 Views)

Hi WNM,

 

your executable should never stop - or it should close its frontpanel and go out of memory when stopping!

Did you ever needed to "restart" Word or Excel by some "run arrows"?

 

Instead have your exe run until the user really closes its front panel: use a button on the frontpanel to make it re-iterate…

Best regards,
GerdW


using LV2016/2019/2021 on Win10/11+cRIO, TestStand2016/2019
0 Kudos
Message 2 of 9
(2,599 Views)

It is much easier to run it as a VI.  If you want to protect your code, you can password protect it or place it in a library or packed library.

0 Kudos
Message 3 of 9
(2,586 Views)

@GerdW wrote:

Hi WNM,

 

your executable should never stop - or it should close its frontpanel and go out of memory when stopping!

Did you ever needed to "restart" Word or Excel by some "run arrows"?

 

Instead have your exe run until the user really closes its front panel: use a button on the frontpanel to make it re-iterate…


Normally I would agree with you but as it is, I have perfectly valid reasons for needing to do it this way driven by 3rd-party software and hardware that drive the requirement. It is not my intention to go into all the gory details of the full system. If you cannot accept the problem as stated, then you need not bother to waste any more time on it.

0 Kudos
Message 4 of 9
(2,585 Views)

Hi WNM,

 

I have perfectly valid reasons for needing to do it this way

You didn't provide all those "gory details", so I answered the most reasonable solution IMHO…

 

I have an executable (the "Worker") which when run does some work and then stops. I can click again on the run arrow and it will use the existing memory context to run again doing slightly different work and then stop.

Have that worker store it's "memory context" to a file. Load that file on next start.

Now you can start that worker again using SystemExec!

 

What I have found when I've tried this is the Launcher (using the System_Exec VI) can cause the Worker to start and run if the worker is closed (not in memory; has not been previously opened/run). But if the Worker is in memory because it has already been run and is now in a stopped state, the Launcher can no longer cause it to start running again (the equivalent of me pushing the RUN arrow again).

Problem solved, when that Worker stores it's "memory context" to a file and loads it on next start!

Best regards,
GerdW


using LV2016/2019/2021 on Win10/11+cRIO, TestStand2016/2019
0 Kudos
Message 5 of 9
(2,572 Views)

Worker stores it's "memory context" to a file and loads it on next start!

Been there, done that. Looking for an alternative.

0 Kudos
Message 6 of 9
(2,567 Views)

Hi WNM,

 

Been there, done that. Looking for an alternative.

The next bit of information you don't care to provide with your original message?

How long will it take until you provide the full picture?

 

What's wrong with storing the "memory context" so you are looking for an alternative?

 

When you insist on "rerunning a stopped, but not closed executable" you could try to call 3rd party tools like AutoIt: have it simulate the "run arrow" button click… (Still a stopped, but not closed executable is a NO-GO IMHO.)

(Or use a VI-server functions to restart a VI - as suggested before.)

Best regards,
GerdW


using LV2016/2019/2021 on Win10/11+cRIO, TestStand2016/2019
0 Kudos
Message 7 of 9
(2,559 Views)
Solution
Accepted by topic author WNM

Yes, it is possible.  You can set it up so the Launcher can get a reference to the main VI in the Worker, then execute the Run VI method.

"If you weren't supposed to push it, it wouldn't be a button."
Message 8 of 9
(2,533 Views)
Solution
Accepted by topic author WNM

@paul_cardinale wrote:

Yes, it is possible.  You can set it up so the Launcher can get a reference to the main VI in the Worker, then execute the Run VI method.


Thank you, Paul, for the concise answer to what I had hoped to have been a concise question. Your answer both let me know that it was possible, and pointed me in the direction that I needed to go, and from that, I was able to develop a solution that met my requirements. Thank you also for not questioning those requirements, especially in place of providing a useful answer. I have attached a zipped folder that contains my proof-of-concept project (LV v14) in case anyone else might find it useful.

 

Now that they will no longer be a distraction to the question that I had posted (and that has now been answered) I'll add a bit more detail about why I wanted to do this, primarily so that someone else who finds that they are stuck with this set of particularly unaccommodating hardware might find this code useful too.   The unfriendly hardware is the VersaSTAT 4. It is a potentiostat/galvanostat made by Princeton Applied Research (AMETEK). It runs a software package called VersaStudio and the VersaStat manual says "the VersaSTAT 4 does not have an open command set to allow user programming outside of the VersaStudio software."  The VersaStudio software is a script-based language that has a rather narrow focus on only what the instrument can do and little extra support for how a user might want to use the instrument as part of a bigger system.  When we, here, were faced with adding a 256-channel multiplexer to the input of the instrument and automating the use of the bigger system to scan repeatedly over those 256 channels, the closed nature of this instrument was not much help; but it was what we were given and told to make it work, so we did.  The VersaStudio does have one script command that make this possible and that is "Run External Application" with an optional "Wait for application to close." With it, we can call a LabVIEW executable to cause the mux to go to the next channel and then, when the LabVIEW executable closes, the VersaStudio knows that the change has occurred and it can go on to make the next measurement. As I had alluded to previously, we have been doing this up until now with a single executable that used a disk file for state memory as the executable was loaded, run and unloaded from physical memory. Having tried that, we wanted to explore alternatives* that would possibly leave a front-panel panel open so that the progress of the indexing of channels can be more easily monitored.  We may eventually go back to the old disk-based state memory, but we at least wanted to try this other before accepting that the old way is better; it may not be better for us.

 

*As is our prerogative, and which should not require justification, no matter how much it offends some people's sense of the natural order of the universe.

Message 9 of 9
(2,487 Views)