02-18-2002 10:37 AM
02-18-2002 11:14 AM
02-18-2002 04:25 PM
02-18-2002 05:41 PM
LabVIEW, C'est LabVIEW
02-18-2002 11:06 PM
02-19-2002 05:01 PM
07-05-2024 04:08 PM
in the build specification go to Source file settings. choose the source file. Then choose customize settings. Then uncheck the run when opened button
07-05-2024 04:45 PM
I'm mostly doing development, and haven't built all that many executables, but am intrigued by the question posed here, and by having some who say "You can't prevent the built Executable from running when you start it" and those who say "Just tell the top level VI in the Build Spec to not Run when Opened". Sure enough, I did this, ran my Executable, it popped up not running and let me set the Controls as I liked them (it's processing some files, so I have to enter the paths to the files). Once I was RTR (Ready to Roll), I pushed the Run button, the code started up, I pushed the "Start Button" on my Front Panel (the "normal" way to run this is to start it, "fill in the blanks" with files, then push "Start", which checks to be sure you filled-in-the-blanks before continuing).
So at least in LabVIEW 2019, you can build an Executable that does not "auto-run". [Well, maybe that's too strong -- how about "I've built one Executable and tested it once, and it sat idle until I pushed the Run button to start it running ..."].
Bob Schor
07-07-2024 02:58 AM
@Bob_Schor wrote:
I'm mostly doing development, and haven't built all that many executables, but am intrigued by the question posed here, and by having some who say "You can't prevent the built Executable from running when you start it" and those who say "Just tell the top level VI in the Build Spec to not Run when Opened". Sure enough, I did this, ran my Executable, it popped up not running and let me set the Controls as I liked them (it's processing some files, so I have to enter the paths to the files). Once I was RTR (Ready to Roll), I pushed the Run button, the code started up, I pushed the "Start Button" on my Front Panel (the "normal" way to run this is to start it, "fill in the blanks" with files, then push "Start", which checks to be sure you filled-in-the-blanks before continuing).
So at least in LabVIEW 2019, you can build an Executable that does not "auto-run". [Well, maybe that's too strong -- how about "I've built one Executable and tested it once, and it sat idle until I pushed the Run button to start it running ..."].
Bob Schor
All this begs the question about why you would do this in the first place. It would be much more conventional just to build a VI with a state machine where the first state would be to wait for user input. Unless this was just a simple engineering tool, (e.g., enter two numbers, get a result) which seems like quite a bit of overhead just for running one VI.
07-07-2024 10:51 AM
@Sateesh wrote:
LabVIEW excutables run automatically when started the first time. I need to change my inputs when running the first time. So the first run is useless without changing the input. I tried using the "STOP" command if I do not give an input (or if the input is the default - invalid). This works in stopping the first automatic run. And it works in running after applying the proper input. But it stops further runs. I cannot duplicate the error in the non-executable version. And I need to be able to run the executable about 100 times a day (using it in a production test program).
WRONG QUESTION! The correct question is "How do I revise my code so that the User may change parameters and then executes a section of code exacly once whenever a User presses a 'Run Test' button many times until the User closes the exe?
The easiest way would be to simply place an Event Structure around the code. Place a While Loop Around the Event Structure. Create Two Boolean Buttons (Latch when released mechanical action.) Configure the Event case with your original code in it to respond to the "Run Test" Button Value Change Event. Add a case to respond to the other button "Stop" value change and this case should wire a TRUE value to the While Loop conditional terminal to Stop the program.
That's the simple method....the FP will be locked (by default) While a Test executes and, there is no way to Abort a Test Run (unless you use the Abort button, please don't)
But, if you then look through examples and online training material you'll see how you could improve the code with a Producer Consumer (Events) pattern 😉