LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

can a built application be setup so that it runs when it is called

When configuring a projects build specifications (for an .exe), the "Source File Settings"->"VI Properties" allows for execution when the built application is opened.  Is it possible to set up the built application so that it runs when it is called.  The effect I am after is to have the application front panel still be visible after it has completed (I have to currently force it to exit LV) and the next time it is called it just runs again.  I would like to have the results of a test run by the application, to be visible until the next time the executeable is called.  Currently the front panel shuts down immediately on completion of the test, which I have to do, otherwise I cannot get the application to run again.

 

Thanks

Herbert Niesler
0 Kudos
Message 1 of 9
(2,481 Views)

Your question doesn't make much sense, and I suspect it's due to your terminology.

 


When configuring a projects build specifications (for an .exe), the "Source File Settings"->"VI Properties" allows for execution when the built application is opened. 

This is the same as setting a VI's execution properties to "Run when opened". You can either set this property in the VI and not change it in the build spec, or you can override its value in the build spec.

 


Is it possible to set up the built application so that it runs when it is called. 

I do not understand what you mean by "when it is called". Called how? Treat the LabVIEW app the same way as any other app. How do you "call" another app? You don't. You launch it.

 


The effect I am after is to have the application front panel still be visible after it has completed (I have to currently force it to exit LV) and the next time it is called it just runs again.  I would like to have the results of a test run by the application, to be visible until the next time the executeable is called.  Currently the front panel shuts down immediately on completion of the test, which I have to do, otherwise I cannot get the application to run again.

It sounds to me like you want to save information state during subsequent runs of the application. For this you need to save the data to file so the application can read the files (if they exist), and pre-populate the controls/indicators with the values that were saved from the last run. If you are dealing with simple control values then I suggest looking at this: Community: Easy saving and loading of control values

0 Kudos
Message 2 of 9
(2,468 Views)

Hi Herbert,

 

What I think you are talking about is to have an .exe that when you open it, it can run the program and when the program ends, it remains open and you can be able to see the latest results and also start the program again. This can be achieved with the right architecture in your program; in this case I will recommend an event structure. The event structure will run your actual program (for example, when a “start” button is pressed), and a while loop will be over the event structure, this will make the program to remain open.

 

In the attached VI you will find an example of what I’m describing, this Is a simple VI, when you hit “start” the program will start counting and the led will set to on when the count gets to 9. The results will remain on the screen until you hit “start” again.

 

I hope this helps you in your task.

 

You can find more information about event structores here, and you can find example code here.

 

 

Regards,

steve.bm
AE | NI
0 Kudos
Message 3 of 9
(2,457 Views)

Hi Steve,

 

   yes you are pretty close to what I was trying to describe.  I did miss another detail (sorry), the application is sometimes being launched from a DOS batch file.  In this case it is launched from another built LV application.

 

 If I do not terminate the "called" application(.exe), at the end of its execution, with a "Quit LabVIEW" function, the window just sits there (which is fine by me, as this is what I would like).  However the crunch comes the next time the DOS batch file tries to run it (or it is run again from another LV application), all that happens is the window pops to the front, but the application does not run.  To get it to run, the window has to be completely shut down, before it is "called" to run again.

 

  I tried to open your VI but I have LV10, so that didn't work.  From your description, I think it is not the solution to what I am after.  Thanks for your contribution.

 

   Cheers

 

                   Herbert

Herbert Niesler
0 Kudos
Message 4 of 9
(2,451 Views)

Yes, I did miss on some info that would clarify the situation.  Please see my reply to the post below.  Thanks for the contribution.

Herbert Niesler
0 Kudos
Message 5 of 9
(2,450 Views)

Hi Herbert,

 

One way you can get the last data to show when the .exe is called is to save and read to a file. You can modify your vi to set it with a read routine, show the last results from the last time it was run, then when the program ends, you can save to this same file and overwrite the data. This way you can call and close the .exe and you will be able to read last data and save the new data for the next run.

 

Regards,

steve.bm
AE | NI
0 Kudos
Message 6 of 9
(2,432 Views)

Hi Steve,

 

yep that is clear and would work. Thanks.

 

This leaves me with the issue that I cannot get the already open executeable (open from its previous execution, but no longer running), to run again when it is called (via a "System Exec" function or DOS batch file or document hyperlink).

 

I had achieved this previously in an .exe by including the front panels of the vi's I was calling in the same built .exe.  That worked well as I could leave the sub VI panels open after they finished execution and the next time I called them (from within the same .exe) they would run.  However now I need to do this with the ability to call built .exe's, as my software system has got a lot larger and maintaining it is easier if I have my applications in independent .exe's.

 

   Cheers

 

             Herbert

 

 

Herbert Niesler
0 Kudos
Message 7 of 9
(2,427 Views)

Hi Herbert,

 

I’ve been thinking about this for a while. I believe that calling .exe is a difficult task and consumes resources from the system and might leave open references. Isn’t a better option for you instead of having multiple .exe, transform these to libraries that you can call?

 

Regards,

steve.bm
AE | NI
0 Kudos
Message 8 of 9
(2,397 Views)

 Hi Steve,

 

         ok, this might be an option.  I will have to experiment with libraries to see how they can be made to work in my situation.  I am not familiar enough with the workings of libraries and there are a fair number of constraints I have with the software system I have already built up.  This is one of those design issues that needs to be properly resolved at the start of a project, which I haven't done, due to (surprise, surprise) the pressures of getting something up and running.

 

  Thanks for the suggestion, was surprised you were still cogitating on this issue after all this time.  Appreciate your effort.

 

 

                     Cheers,

 

 

                                           Herbert

 

Herbert Niesler
0 Kudos
Message 9 of 9
(2,378 Views)