VI calling itself (run top level)

Just out of curiosity, is it possible for a top level VI to call itself?
For example, I have an ini configuration file w/ different settings for a simple power supply sweep. I would like to run different configurations one after another. The power supply vi is called 'supply sweep'.
While the program 'supply sweep' is running, if I use an invoke node to call 'supply sweep', the execution state is "run top level". The program outputs an error b/c the top level vi cannot call itself. I've tried making the vi re-entrant, but no luck yet.
Is there a way to get this to work? What is a better solution than creating multiple programs of the same program (i.e. 'supply sweep' calls 'supply sweep 2' which calls 'supply sweep 3', etc, etc.)
Thanks!

I am attaching a generic vi to hopefully better illustrate what I am trying to accomplish. If you run program 1, it will call program 2 which will attempt to call itself again.
The solution I am looking to get is one in which program 2 can successfully call itself again w/o error. As a first pass, I've made program 2 re-entrant, but this doesn't seem to solve the issue. So far, the temp solution I have is to make a new program called program 3 which is identical to program 2. This seems rather redudant, and depending on the configuration file... program 2 may call itself 2,3,4,5, etc. times. It would be optimal to only have 1 instance of program 2.
Attachments:
program1.vi ‏11 KB
program2.vi ‏12 KB

Similar Messages

  • Does lv know if the started programm is an application or a running top level vi?

    hello,
    is it possible to query the running programm if it is an applicarion or an running top level vi.
    if this is possible i could decide if lv should close (application) or only stop the running vi's.
    markus

    Just drop a property node on the diagram, and select "properties > Application > Name". The node will return "Labview.exe" or "application name.exe" when your vi is running in the dev environment mode, or as an executable, respectively.
    CC
    Chilly Charly    (aka CC)
             E-List Master - Kudos glutton - Press the yellow button on the left...        

  • Detecting whether vi has been called or run

        Ok, I must have missed something because I can't figure out how to
    detect whether a VI has been RUN (i.e. is a top-level VI) or has been
    called from another VI. I can get at the "Callers" VI server property
    to see if the array is empty or not, but if any VI that calls the VI in
    question is in memory at all, it gives a false positive. The "First Call?" VI is useless too since it gives a "true" whether the VI is top-level or has been called from some other top-level VI.
    Am I missing something obvious?

    "lanmat" <[email protected]> wrote in message news:[email protected]..
    &nbsp;&nbsp;&nbsp; Ok, I must have missed something because I can't figure out how to
    detect whether a VI has been RUN (i.e. is a top-level VI) or has been
    called from another VI. I can get at the "Callers" VI server property
    to see if the array is empty or not, but if any VI that calls the VI in
    question is in memory at all, it gives a false positive. The "First Call?" VI is useless too since it gives a "true" whether the VI is top-level or has been called from some other top-level VI. Am I missing something obvious?
    Hi,
    The Callers property returns all vi's in memory that call the vi. So that won't work.
    Try the Call Chain function. If there is only one element, the vi (the current run of it) is top level.
    You can also use the property "Execution>State", which returns "Running" or "Running Top Level". But the call chain is easier.
    Remember, if you put the call chain code in a sub vi (you should) you have to check if there are two elements!
    Regards,
    Wiebe.

  • [svn:fx-trunk] 13127: SystemManager was supposed to call ChildManager to finish initializing the top level window .

    Revision: 13127
    Revision: 13127
    Author:   [email protected]
    Date:     2009-12-21 13:42:09 -0800 (Mon, 21 Dec 2009)
    Log Message:
    SystemManager was supposed to call ChildManager to finish initializing the top level window.  LoaderConfig was not getting initialized otherwise.
    QE Notes: None
    Doc Notes: None
    Bugs: SDK-24625
    Reviewer: Peter F
    API Change: No
    Is noteworthy for integration: No
    tests: checkintests mustella/components/DataGrid
    Ticket Links:
        http://bugs.adobe.com/jira/browse/SDK-24625
    Modified Paths:
        flex/sdk/trunk/frameworks/projects/framework/src/mx/managers/SystemManager.as
        flex/sdk/trunk/frameworks/projects/framework/src/mx/managers/systemClasses/ChildManager.a s

    This girl here found the fix:
    How to Manually Fix Updates on Adobe Photoshop CS6 (from 13.0.3 to 13.0.6) on Mac with Retina Display |
    Basically, all you have to do is update the Application Manager (if your installation was like mine, I was still on v.6... it's up to v.9 now.  Go here for the update: Adobe - Adobe Application Manager : For Macintosh : Adobe Application Manager and run it... when done, launch Photoshop and check for updates.
    This is amazingly idiotic, I must add -- how does App Manager NOT update itself through the update process???

  • Passing data from a subvi to the top level with continuously running loops

    Hi All,
    This is a very simple question, for some reason the data available at a subvi indicator is not making it to the top level vi. I think it might be something to do with the while loop I am using but I cant figure it out, any help will be appreciated. I don't think I fully understand how the data gets out of a continuously running loop.
    GPSdisplay runs a driver called GPS.vi (im not worried about my event structure just yet which might be wrong, but I am yet to test that bit yet) Probe 1 should have the values from GPSCluster
    Loop within GPS.vi. GPSCluster (Probe 2) is being updated correctly
    I cant work out why the data is not being passed to GPSCluster in the top vi
    Solved!
    Go to Solution.

    Hi bennymacca,
    I think you are on the right track with an FGV. You can do this fairly easily with the GPS vi that you have.
    Before I go any further, your GPS while loop will only return the last reading, and because the "Read" boolean output state is FALSE, it will not stop. Do you see it exit at all? From the logic I read, once entering this while loop it won't stop until told to.
    There are a 3 options you can try.
    1) Use an FGV, as you are looking into. To do this you will need to change the state boolean to TRUE and put shift registers in for the GPSCluster - to parse the information around, holding it each time the vi is called and exited. Outside the while loop you will wire up the Cluster to the indicator that you wish to collect (OR, you could have it inside the case statement where it is read - be careful here, though). 
    2) in the main code, above the sequence frame you can place the GPS vi while loop (the "Read" one), having the state boolean wired to a Stop button local variable. This while loop will start depending on how LV feels, so wire an error line to both the While loop and Frame start (indicating that both are to run in a parallel fashion), OR you can put it in a case statement and say 'go' when you want to start reading. With this while loop, you can then output the Read data directly into your Cluster variable as it is generated.
    But, with (2) you are moving yourself away from the purpose of the GPS vi, which would be to bring all functionality of the GPS functionality into one sub vi - which is a good idea.
    3) put a condition on the "Read" case statement boolean state - only make it TRUE when you wish to stop reading data (do you have a time or condition you can refer to here?). Even doing so, you would/may still need shift registers on your while loop to retain data for each iteration.
    I hope all of that helps. Cheers. David.

  • Running multiple instances of a top level vi

    The following question is copied from a 1999 post which I am also interested in an answer to. It wasn't answered in '99, but maybe there are more people around today who could comment;
    "I am interested in running multiple copies of a top-level vi in Labview
    operating under Windows95/98/NT much like you could run several copies of
    notepad.exe simultaneously. Whenever I attempt to start a second copy of a
    vi (or .exe), in either the development or runtime environment, Labview just
    brings the first copy to the foreground. Is it possible to alter this
    behavior?"

    I think it is not a bug but an "open feature". What to do if there is 2 or more calls to the same VIT on the diagram? Should a new instance be created for each node or the same instance reused? It depends of the programmer's intents... The problem has been swept under the carpet allowing only one subVIT instanciation per diagram.
    Back to the topic, one would have to be very careful to code an application where the same hierarchy of VIs has to run in multiple copies in parallel. User interface VIs has to be instanciated dynamically user VITs. What to do with subVIs with unitialized shift registers that shouldn't share their data amongst different hierachies? It is doable but requires a careful design. However for simple user display and
    input, a VIT does the job.
    The easiest way is to duplicate and run an executable file copy. That is because when a second instance of a LabVIEW executable is run, it detects the already running instance, passes the control to it and quit. With a different file copy of the executable, the application can be relaunched with its own application space where you can run the same hierarchy of VIs without conflicts.
    LabVIEW, C'est LabVIEW

  • Portal run time error when clicking on top level-navigation

    Hi,
    When I select a link from the top level-navigation I get the message <b>Portal Run Time Error</b>.
    I found the log file with this entry :
    <i>#1.5#001438EE39C6006F0000130F000031E800041ABD6F12C098#1155300821516#com.sap.portal.portal#sap.com/irj#com.sap.portal.portal#Guest#0####6a3f43c0293811dba664001438ee39c6#SAPEngine_Application_Thread[impl:3]_37##0#0#Error#1#/System/Server#Java###Exception ID:02:53_11/08/06_0601_18813850
    [EXCEPTION]
    #1#com.sapportals.portal.prt.component.PortalComponentException: Error in service call of Portal Component
    User : Guest
         at com.sapportals.portal.prt.core.PortalRequestManager.handlePortalComponentException(PortalRequestManager.java:969)
         at com.sapportals.portal.prt.core.PortalRequestManager.callPortalComponent(PortalRequestManager.java:343)
         at com.sapportals.portal.prt.core.PortalRequestManager.dispatchRequest(PortalRequestManager.java:136)
         at com.sapportals.portal.prt.core.PortalRequestManager.dispatchRequest(PortalRequestManager.java:189)
         at com.sapportals.portal.prt.core.PortalRequestManager.runRequestCycle(PortalRequestManager.java:753)
         at com.sapportals.portal.prt.connection.ServletConnection.handleRequest(ServletConnection.java:240)
         at com.sapportals.portal.prt.dispatcher.Dispatcher$doService.run(Dispatcher.java:522)
         at java.security.AccessController.doPrivileged(Native Method)
         at com.sapportals.portal.prt.dispatcher.Dispatcher.service(Dispatcher.java:405)
         at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
         at com.sap.engine.services.servlets_jsp.server.servlet.InvokerServlet.service(InvokerServlet.java:156)
         at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
         at com.sap.engine.services.servlets_jsp.server.HttpHandlerImpl.runServlet(HttpHandlerImpl.java:390)
         at com.sap.engine.services.servlets_jsp.server.HttpHandlerImpl.handleRequest(HttpHandlerImpl.java:264)
         at com.sap.engine.services.httpserver.server.RequestAnalizer.startServlet(RequestAnalizer.java:347)
         at com.sap.engine.services.httpserver.server.RequestAnalizer.startServlet(RequestAnalizer.java:325)
         at com.sap.engine.services.httpserver.server.RequestAnalizer.invokeWebContainer(RequestAnalizer.java:887)
         at com.sap.engine.services.httpserver.server.RequestAnalizer.handle(RequestAnalizer.java:241)
         at com.sap.engine.services.httpserver.server.Client.handle(Client.java:92)
         at com.sap.engine.services.httpserver.server.Processor.request(Processor.java:148)
         at com.sap.engine.core.service630.context.cluster.session.ApplicationSessionMessageListener.process(ApplicationSessionMessageListener.java:33)
         at com.sap.engine.core.cluster.impl6.session.MessageRunner.run(MessageRunner.java:41)
         at com.sap.engine.core.thread.impl3.ActionObject.run(ActionObject.java:37)
         at java.security.AccessController.doPrivileged(Native Method)
         at com.sap.engine.core.thread.impl3.SingleThread.execute(SingleThread.java:100)
         at com.sap.engine.core.thread.impl3.SingleThread.run(SingleThread.java:170)
    Caused by: com.sapportals.portal.prt.core.PortalRequestManagerException: PortalRuntimeException
         at com.sapportals.portal.prt.core.PortalRequestManager.dispatchRequest(PortalRequestManager.java:143)
         at com.sapportals.portal.prt.core.PortalRequestManager.dispatchRequest(PortalRequestManager.java:189)
         at com.sapportals.portal.prt.component.PortalComponentResponse.include(PortalComponentResponse.java:215)
         at com.sapportals.portal.prt.pom.PortalNode.service(PortalNode.java:646)
         at com.sapportals.portal.prt.core.PortalRequestManager.callPortalComponent(PortalRequestManager.java:328)
         ... 24 more
    Caused by: java.lang.NullPointerException
         at com.sapportals.portal.navigation.NavigationService.getNavURLPrefix(NavigationService.java:531)
         at com.sapportals.portal.navigation.NavigationService.redirect(NavigationService.java:495)
         at com.sapportals.portal.navigation.NavigationEventsHelperService.redirectURL(NavigationEventsHelperService.java:1735)
         at com.sapportals.portal.navigation.NavigationEventsHelperService.normalizeNavigationTarget(NavigationEventsHelperService.java:1715)
         at com.sapportals.portal.navigation.NavigationEventsHelperService.getNavSessionParameter(NavigationEventsHelperService.java:784)
         at com.sapportals.portal.navigation.NavigationEventsHelperService.getCurrentNavNode(NavigationEventsHelperService.java:351)
         at com.sapportals.portal.navigation.NavigationEventsHelperService.getCurrentLaunchNavNode(NavigationEventsHelperService.java:421)
         at com.sapportals.portal.navigation.fpm.NavigationFpmListener.addToHistory(NavigationFpmListener.java:268)
         at com.sapportals.portal.navigation.fpm.NavigationFpmListener.doNavigatePhase(NavigationFpmListener.java:98)
         at com.sapportals.portal.navigation.fpm.NavigationFpmListener.doPhase(NavigationFpmListener.java:70)
         at com.sapportals.portal.pb.fpm.FPMContainer.distributeEvent(FPMContainer.java:63)
         at com.sapportals.portal.pb.fpm.FPM.doDocumentHook(FPM.java:143)
         at com.sapportals.portal.prt.service.document.DocumentHookMulticaster.doDocumentHook(DocumentHookMulticaster.java:100)
         at com.sapportals.portal.prt.service.document.DocumentHookService.doDocumentHook(DocumentHookService.java:119)
         at com.sapportals.portal.prt.service.document.DocumentHookServiceNew.doDocumentHook(DocumentHookServiceNew.java:183)
         at com.sapportals.portal.prt.connection.PortalHook.doDocumentHook(PortalHook.java:824)
         at com.sapportals.portal.prt.core.PortalRequestManager.callPortalComponent(PortalRequestManager.java:261)
         at com.sapportals.portal.prt.core.PortalRequestManager.dispatchRequest(PortalRequestManager.java:136)
         ... 28 more
    #</i>

    Hi Christophe,
    Since you set this question as "Answered", did you find a solution to the problem? We are experiencing a similar problem when clicking top level navigation, but only in some rare cases.
    Best regards,
    Erik Eriksson

  • How to prevent Sub VI's from popping up, when top level VI is Called?

    I wrote a VI simular to the "New Event Handler" VI found in th examples of 6.1, but when I first open the Top Level VI, all my Sub VI front panels pop up. I think there is a way to accomplish this feet, but I can't find what I'm missing. For when the "canned" example runs, the Sub VI's don't show up. I would be very thankful if someone could enlighten me.

    File > VI properties > Window Appearance > Custom
    > Customize. (Of subVI)
    Uncheck "Show Front Panel When Called" and
    "Show Front Panel When Loaded".

  • Running multiple vi's in top level app at same time.

    hello, i am wondering on how to run multiple vi's under the same top level application.  if i have a top level application that has multiple buttons that call other vi's, is there a way to minimize one of the sub vi's and open another.  i keep having problems because i think that the top level application needs the first sub vi to close befor you can call another sub vi.  i attach an example i found in the ni examples as an example.  thank you.
    Attachments:
    Dynamic Load Example.vi ‏52 KB

    Thank you for the response.  I tried to use this feature but i think i am doing it wrong.  Do you put the method in the sub vi's or in the top level application.  also what should you wire to the Auto Dispose Ref input for the Run VI method.  Thank you

  • Having placed more than one top-level VI in builder, is there a way to programmat​ically call the second applicatio​n?

    Builder allows for more than one Top-Level VI. The resulting Executable launches both applications at once. If I terminate one application, is there anyway to launch it again programmatically?

    You could monitor the names of all the VI's in memory. If the one you want running is not in the list, you can launch it dynamically.
    Ben
    Ben Rayner
    I am currently active on.. MainStream Preppers
    Rayner's Ridge is under construction

  • In application builder the top level vi is always set to "run when opened"; how do I turn this off so I don't have to change it each and every time I build a .exe??

    I build a lot of executables using Application Builder under LabVIEW and in every one I build, I don't want the top level vi to take off and run when I open the executable. Currently, I edit each .exe I build within Application Builder and change the option of "run when opened" from Yes to No for the top level vi. All the other subvi's are already set to No. It would seem as though there should be some way to "turn this off" if you will so the top level vi is not always set to "run when opened" by default within Application Builder. Is there such a solution that anyone knows of?? Any help would be apprec
    iated... thanks...

    Indeed the Application builder forces "run when opened" to true for top levels VIs. If you don't want your VI to make any real work when the application starts, you should simply put a do-nothing loop in the beginning of the VI that will loop until the user presses a boolean. It will be more intuitive for users to press a Run button on the FP than clicking on the white Run arrow in the bar.
    LabVIEW, C'est LabVIEW

  • Setting and calling top level varialbes

    Is there away to call and set a top level variable from a
    child component that way i can access the variable no matter where
    i am from inside the application. For example i have a login
    component that gets the userid. I would then like to set that
    userid to a scope that can be accessed from any other component as
    i use the userid to validate other cfc calls and so on.

    Application.application should get you there.
    i.e. Application.application.myVariable

  • I am trying to create an executable vi that will call out another vi and show its front panel in the executable​. When I try this I recieve this error message "top level vi (my main vi) was stopped at unknown on the block diagram of (my sub vi)

    I am trying to create an executable vi that will call out another vi and show its front panel in the executable.  When I try this I recieve this error message "top level vi (my main vi) was stopped at unknown on the block diagram of (my sub vi)

    Well the most common way is to enclude the vi's in the build spec either directly in the dependancies that the App builder automatically generates OR by declaring them in the build spec as "additional enclusions" (like you must do for dynamic vi calls in your app.
    I have heard rummors about My.app Stuff.vi in a nugget Intaris posted- and I've wanted to dig deaper into Intaris' claims- but have not tried it myself.
    If you go down the stuff.vi route Keep us curious guys posted
    Jeff

  • How can I close all open subVI front panels, without closing my top level VI front panel when all VIs are built into executables?

    I'm using the code shown in the sample VI discussed here: http://digital.ni.com/public.nsf/allkb/353A696A3F393D9B86256E8B007A2912
    to close all open VIs except my top level VI.  My top level VI is actually a separate executable and the sub-VIs are their own executables.  All reside under the same project.  It works very well if I'm running in LabView but will not work when I build them.  I added all the sub-VIs to the Always Include box in my top level VIs properties which did nothing.  I also tried adding them to the Startup VIs box.  This allowed me to close them all programmatically from the top level VI but it also open all the VIs at once (which was expected and not desired).  I think the problem is the executables are not able to see outside their own memory space so the top-level VI never finds any other open front panels to close.  Is this correct?  Is there another way to go about doing this? 
    Thanks!

    Where do I begin…..
    I’m using a “server” to control 4 “client” PCs.  My server opens references to 4 VIs on each client then executes them sequentially.  So on a normal day, the server will run everything itself and I will have no contact with the clients.  But on a several occasions, I’ve needed the ability to walk up to one of the clients and run just one of the 4 VIs. 
    We are updating from LabView 6.1 to 8.5 and we want to run executables rather than VIs for various reasons.  I have a new VI running on the client PCs who’s only function is to initialize the shared variables and open/close the VIs.  I initially thought of making the remaining 4 VIs sub-VIs but I will loose the ability to run them individually.  I think I would also have to rewrite the VI running on the server since the 4 references it originally opened do not exist.  I don’t think you can open a reference to a sub-VI on another PC.  Can you???
     As you can see, this is a huge mess.  I’m still pretty new with LabView so any help you can provide would be great. 

  • How to release top-level VI (only) source code?

    Hello,
    I am developing an addon to an application I already have. The application is large (over 1,500 VI's) and the VIs are set up to compile with mostly default settings (there's a top-level VI, a few with Front Panel visible, most of them are not visible).
    The customer wants the source code to the work I'm going to do, and it's going to use many existing sub-VI's. The addon itself will be a sub-VI (I have a Main.vi that basically opens 'screens', and this is a new screen). The existing sub-VI's basically do the data collection and processing, and the new code will do some additional processing and have a nice GUI to the existing code. The customer wants the source so they can make modifications as needed.
    Is there any easy way to provide just the source for the top-level VI? Basically, I want to give them M.vi, where M.vi calls n.vi, o.vi... etc, but o-z.vi need to remain closed-source. Also, M.vi is called by Main.vi, which opens screens A-M.vi
    One option is do copy the entire application, then open every sub-VI and save it without Source Code. But with so many files, this seems like a bad idea. I also then have to maintain two applications.
    Any good ideas out there? It seems so easy in other languages (use object files) that it seems like there should be a solution here I'm not seeing.... Thanks!
    Message Edited by rnelsonee on 06-02-2010 08:28 AM
    Message Edited by rnelsonee on 06-02-2010 08:31 AM
    Solved!
    Go to Solution.

    Dont know if this is the best solution for you, but you can create a "virtual folder" in the LabVIEW project with all the sub-VIs that you want to keep closed-source. Then create Source Distribution build specifications in the project and remove the block diagrams assign passwords to all VIs in the virtual folder. See attached pics.
    Attachments:
    Project.JPG ‏23 KB
    SrcDist.JPG ‏62 KB

Maybe you are looking for