Configure VI front panel for subsequent calls

When you call a VI with an unwired input, the default value for the control is used. Most of the time, this makes good sense. But then how can you configure a VI to operate in a particular way, and subsequently call it to repeatedly perform some function given the prior configuration?
For example, suppose I have a VI that works something like a virtual o-scope. I want to configure the instrument once (set up all the controls: time base, volt ranges, etc) and then periodically take readings. Is there any way to do this without having to wire the setup every time I take a reading?

Use Action Engines or Functional Globals.  They make use of un-initialized shift registers.  Upon first call, the initilization must take place inside the vi.  The init values get wired to the shift registers on the right side.  Upon next call, the shift registers will retain the values that were set on the first call.
See the Action Engine Nugget created by Ben.  Very useful and very practical.
- tbob
Inventor of the WORM Global

Similar Messages

  • Configuring Remote Front Panels on a Real-Time Target,smart camera,but there is no image in the web page.

    I do see the web page, but the image  itself is not loading.i know a problem is with the installation of the LabVIEW ActiveX plug-in or the IMAQ ActiveX plug-in.  The LabVIEW ActiveX plug-in is required for ALL remote front panel viewing, and the IMAQ ActiveX plug-in is needed for VIs that use the Image Display. how can i do ?where can i get the the IMAQ ActiveX plug-in. help me！

    Got it working, after much experimentation.  Seems to require installing exactly the right combination of items on the RT target, as some items (web services? web configuration? the "application web server"?) apparently run a separate web server - or instance of the web server - on port 80, which prevents remote front panels from being served on that port.

  • How can I create multiple front panels for a single block diagram?

    Hello,
       I have developed a VI with multiple controls and indicators that needs to run on computers with screen resolutions ranging from 800x600 to 1680x1050. The problem I'm having is that the front panel does not properly scale for this range of resolutions by checking the options in the "VI properties" option. Is there a way to create multiple front panels of various sizes for my block diagram and programmatically select the appropriate front panel based on the screen resolution?
    Solved!
    Go to Solution.

    See the attached Zip file.
    I have two different front panels.  Open either one and run it.  They both call MainCode.vi which takes the references passed to it and register for events.  From there, it does all the work of the code you would have put in your front panel .vi.
    This way each front panel can be laid out however you want for each screen resolution.
    Attachments:
    MainCode.zip ‏22 KB

  • Where can I buy a white front panel for my ipad4?

    My front panel of mi Ipad 4 wifi has broke, where  can I buy the original front panel????

    The standard 1-year Apple Care warranty only covers defects in materials and workmanship, not damage due to accidents.
    Apple's Limited Warranty http://www.apple.com/legal/warranty/ for iPad excludes coverage for damage resulting from accident, disassembly, unauthorized service and unauthorized modifications.
    Out-of-Warranty Service
         If you own an iPad that is ineligible for warranty service but is eligible for Out-of-Warranty (OOW) Service, Apple will replace (Apple doesn't repair) your iPad with an iPad that is new or equivalent to new in both performance and reliability for the Out-of-Warranty Service fee listed below. (The replacement will most likely be a refurbished iPad in a brown box, however, it has a new screen, back and battery.)   
    iPad model
    Out-of-Warranty Service Fee
    iPad mini
    $219
    iPad 3rd, 4th generation
    $299
    iPad 2, iPad
    $249
    A $6.95 shipping fee will be added if service is arranged through Apple and requires shipping. All fees are in US dollars and are subject to local tax.
    Certain damage is ineligible for out-of-warranty service, including catastrophic damage, such as the device separating into multiple pieces, and inoperability caused by unauthorized modifications. However, an iPad that has failed due to contact with liquid may be eligible for out-of-warranty service. See http://support.apple.com/kb/index?page=servicefaq&geo=United_States&product=ipad
    Make a Genius Bar Reservation
    http://www.apple.com/retail/geniusbar/
    You may can get the iPad repaired at 3rd party repair sources for less $, however, any remaining Apple warranty will be voided.
    iPad Repair & Screen Replacement Services
    http://www.ifixyouri.com/16-ipad-repairs
    RepairZoom iPad Repair
    http://www.repairzoom.com/ipad-repair.html
    Mission Repair
    http://www.missionrepair.com/Apple_iPad_Repair_Services_s/431.htm
    iGadgetResQ
    http://www.igadgetresq.com/ipad-repair/
     Cheers, Tom

  • How to lock block diagram alone from editing leaving front panel for editing?

    i want to lock block diagram from editing but front panel can be edited for creating controls, moving controls editing properties...

    executables will be delivered to customer and they can create new vi and edit frontpanel and link tag through databinding. but i dont want them to open block diagram...
    Natasftw is right - you seem confused about the difference.
    If the customer can "create a new VI and edit frontpanel" then they have to have LabVIEW Development System.
    If you give them an EXE, and they don't have the DevSys, then they can use your VIs, but not edit them or look at the code.
    If they have the DevSys, then they can edit your VI and look at the code, UNLESS you protect it.
    If you save a VI with protection (VI PROPERTIES - PROTECTION ) then you can LOCK it (user has to explicitly unlock it with an extra step), or you can PASSWORD PROTECT it (user has to explicitly unlock it by giving a password).  Either way requires the DevSys.
    There is no situtation where one can edit the front panel without being able to edit the block diagram.
    Steve Bird
    Culverson Software - Elegant software that is a pleasure to use.
    Culverson.com
    Blog for (mostly LabVIEW) programmers: Tips And Tricks

  • [PAP2] Configuring Multiple Service Providers for Outgoing Calls

    I'm trying to configure my PAP2 with Gizmo project (for incoming calls) and VOIPCheap (for outgoing calls).
    I tried to use the dialplan:
    (xx.<:@voipcheap.host.xxx:5060; usr=myvoipcheapuserid; pwd=myvoipcheappassword; >)
    But this doesn't seem to work. But when I configure the line for the VOIPCheap provider, then I am able to make calls through that account.
    Can someone help me configure my PAP2 adapter please?
    Thank you very much in advance.
    Sekhar.

    I shall have found this post a bit earlier... sik! 
    I have 2 PAP2T 'listenning' to 3 different providers (1 is common); that works... but to be optimal, both ATAs should allow using a 4th provider for outgoing calls.
    The ATA administration guide shows an example of a dial plan such as <8,:1408>xxxxxxx<:@pstn.Linksys.com:5061;usr=joe;pwd=joe_pwd;nat>
    Unfortunately, it applies for AG310 and SPA3102...
    VoIP_Addict, I guess that if you did find some time to 'play' with this, you can only confirm what has been said in this post, right?

  • What are the advantages of utilizing a dynamic VI compared to utilizing the VI Call Configuration Dialog Box Reload for each call option?

    Is it more efficient to use a dynamic VI or utilize the VI Call Configuration Dialog Box which apparently can perform the same function? I realize that there are restrictions on using the VI Call Configuration Dialog Box, however, if my scenario doesn't concern the restrictions, why would I want to go thru the trouble of creating a dynamic VI when I could simply click on the VI of interest and configure from a menu? Are there performance advantages? Thanks in advance!

    Generally, I wouldn't recommend playing with the call setup dialog at all (for those who don't know it, you can get to it by right clicking a subVI in the BD). By default, VIs are configured to load with callers and that's the correct options for almost all static VIs. The Open VI Reference primitive has multiple advantages:
    It allows you to select different VIs dynamically.
    It allows you to spawn multiple copies of reentrant VIs.
    It allows you to perform asynch runs (although I think that this is something that should actually be available through the call setup dialog).
    It allows you to open references to VIs in other application instances.
    In the rare cases where you do want the same functionality that the call setup dialog gives you, it doesn't hide it.
    Try to take over the world!

  • Show LabVIEW VI Front Panel When Sequence Step Called

    Hello,
    By clicking on the “Show VI Front Panel When Called” checkbox in the Step Settings pane displays the LabVIEW VI Front Panel for approximately 100 milliseconds. Is there a configuration way to display the VI front panel for a longer period of time, during that step execution, and allow the user to control the duration of the front panel exposure by clicking to resume execution of the sequence file at their will?
    Thank you.
    Solved!
    Go to Solution.

    Hi,
    You will need to have some sort of structure in your VI for handling front panel response, otherwise you front panel is only going to be visible for as long as it takes to execute an return back to teststand.
    But remember, once you hold your step within that VI which is waiting on the operator to eventual close it, your Sequence will be held as well and if you are expecting steps to continue running after your VI then you will have to consider running it in parallel to your main test sequence.
    You may also need to consider what happens if you want to terminate your Test Sequence, how do you close your VI.
    Check out 'Strategies for Terminating or Breaking Sequences' in the following.
    hope this is of help
    Regards
    Ray Farmer

  • Front panel of SubVI locks on 2nd call

    HI!
    I'm calling a SubVI and pass a Boolean Reference to this SubVI. In the SubVI I'm executing a While loop. The stop condition is the value of the boolean control in the VI that calls the SubVI. (Boolean Refnum + Property Node: VALUE connected to while stop condition)
    Mechanical Action of the Boolean in the calling VI is: Switch when pressed.
    For the first time this will be executed it works fine. But the 2nd time the SubVI is called. The Front Panel of the calling VI where the stop button is located will be locked.
    Does anybody have an idea why this happens and how I can solve that problem?
    ANDY

    I tried what you described, using LV 7.1, and I have no problems running the vi over and over again. See the attached examples. Ref1.vi calls Ref2.vi and passes the Boolean reference to it.
    - tbob
    Inventor of the WORM Global
    Attachments:
    Ref.zip ‏21 KB

  • How to show the front panel when launching VI with Call by reference node??

    Hello!
    I just wonder how I make the front panel visible during execution when I launch the VI with CALL BY REFERENCE NODE.
    Se example.
    Could u also show me how to change different properties (window size ..) of the front panel??? (launched with CALL BY REFERENCE NODE)
    Thank you!
    Attachments:
    test.vi ‏18 KB

    In VI Properties>>Window Apperance>>Customize you can check "Show front panel when called". This will open the front panel on each call. It doesn't matter how the call was initiated.
    You can set a lot of Front panel properties during runtime. Place a Property Node in the block diagram. Change the class from App to VI. Under properties select Front Panel window>>Panel bounds to set the position and size of the front panel.
    Waldemar
    Using 7.1.1, 8.5.1, 8.6.1, 2009 on XP and RT
    Don't forget to give Kudos to good answers and/or questions

  • Crio to host multiple remote front panels

    Hello all,
    I've a question abt remote front panel hosted by a cRIO system (cRIO9068 to be more specific, running RTOS).
    I have a top level VI (main) as the start up vi in my cRIO system, and it would call a subvi during run. I'd like to enable remote front panel for both the main vi and the sub vi so that I can see both front panels using a web browser. I'm not sure if such a configuration is possible at all and would like to listen to comments by users who have similar experiences.
    Thank you very much!
    Best,
    Jidong

    Hello hhaamm,
    To the best of my knowledge, I don't believe it is possible to host multiple remote front panels from the same executable, and, if it is, would be very difficult. The NI Web Server configuration file only specifies one port on which an executable can run web services, like remote front panels. In, short, I am not sure how you would be able to accomplish this.
    Another thing to keep in mind is that what you want to accomplish can be done in many different ways that would be much easier than creating multiple remote front panels.
    One of these is to move all of your controls and indicators to the top level VI. i.e. make the data you want to see from the sub-VI an output of the sub-VI and create a new indicator for this on your top-level front panel. This way you can still use a remote front panel and can use different decorations and labels to separate the top-level and sub-VI outputs.
    Another way to do this is to use the tab control to create multiple tabs, one for your top-level indicators, and one for your sub-VI indicators. This would still enable you to use remote front panels and would allow for the separation of your different indicators. Here is a note on how to do that:
    http://zone.ni.com/reference/en-XX/help/371361H-01/lvhowto/creating_tab_controls/
    And here is a more in-depth forum post on how to create them:
    https://forums.ni.com/t5/LabVIEW/how-do-you-create-tabs-on-the-front-panel/td-p/201495
    The final way I can think how you would accomplish this is to use a web service instead of remote front panels and host the output of the sub-VI as a separate website. 
    Hope this helps!
    Collin D.
    Applications Engineer
    National Instruments

  • Why do I get "error code 3: Could not load front panel" when I run my executable​.

    I have a LV 8.5 VI that controls only an agilent spectum analyzer. The agilent VIs call DLLs rather than SCPI commands. I created an application and an installer to load on a non LV machine and ran setup which was successful. When I run the EXE I get "error code 3: Could not load front panel" for each of my agilent spectrum analyzer VIs. I have to click "OK" about ten times, once for each VI. (My executable runs fine on all machines that have labview 8.5) The front panel does load with a broken arrow. The errors listed when the arrow is clicked for all of the Agilent VIs state: Missing subVI AGE444xInitialize.VI (or close.VI or read.VI etc.)
    There is an AGE444x32.DLL in the data folder with the EXE file so I included as support both the DLL and all of the agilent drivers in the application build. Still no luck. I have built the application and installer about 6 times in various forms. I NEED AIR SUPPORT.
    Unfortunately I do not have access to the internet at my jobsite so bear with me.
    Rob

    Hi V-rob,
    I'm glad to hear the executable is working now that NI-VISA is installed.  Thanks for posting the solution!
    Jennifer R.
    National Instruments
    Applications Engineer

  • Can't remove Front Panels in Application Builder

    I have had a few issues using Application Builder (v7.1) in regards to it removing or not removing front panels for my subvi's when I was trying to compile. Here are the conclusions I came to if anyone else runs into the problems I had.
    Problem 1) Some of the front panels were being removed for dynamically loaded VI's, which were not set as dynamic VI's in the Application Builder, but which were static-linked VI's in the program (so they were loaded in memory as linked subvi's but called dynamically). When the Application Builder decided to remove the front panel for those VI's, there was an error when loading them dynamically.
    Problem 2) Some of the front panels were NOT being removed for subvi's that I didn't want to have their front panel built into the compiled program. Loading front panels that are not needed uses extra memory, but there was no way to change the option to not load the front panel for certain particular subvi's in Application Builder--the option was grayed out.
    For problem 1, I decided not to worry about linking the files dynamically in the Application Builder, but to just make sure the Application Builder would include their front panels. For problem 2, I had to figure out what was making Application Builder force the front panels to be included when I deemed it unnecessary, so that I could fix them not to be included. Basically then, going through my VI's that were forcibly included, I came up with a list of stuff I began checking for each time I would run into one where I didn't want to include the front panel. I have attached my list to this post.
    My solution for problem 1 was then to use a customized appearance for my static-linked / dynamically loaded VI's, and disable the menu bar (forces the front panel to be included by Application Builder without changing appearance, since I never actually see the FP). My solution for problem 2 was often to remove property nodes referencing text on the front panel controls. Sometimes I was able to perform a numeric->text or enum->text conversion instead of referencing the text of the control itself, and sometimes I realized I didn't want anything to change and that it was ok to include the front panel so I could (for example) get a list of strings for my enum control.
    I have attached the reference list I came up with of things to check for to make sure your VI properties are set correctly if you are trying to get Application Builder NOT to include the front panel of your subvi. The list might not be complete, but it's helped me to narrow down things very quickly and find the problems I was having.
    Attachments:
    ThingsToCheck.doc ‏61 KB

    m3nth wrote:
    Problem 1) Some of the front panels were being removed for dynamically loaded VI's, which were not set as dynamic VI's in the Application Builder, but which were static-linked VI's in the program (so they were loaded in memory as linked subvi's but called dynamically). When the Application Builder decided to remove the front panel for those VI's, there was an error when loading them dynamically.
    This is expected behaviour. The application has no way of knowing that these VIs will at some time be called dynamically. That would require analysing and understanding the entire program and in cases where you calculate the dynamic VI to be called at runtime it still wouldn't be feasable to do so.
    m3nth wrote:
    Problem 2) Some of the front panels were NOT being removed for subvi's that I didn't want to have their front panel built into the compiled program. Loading front panels that are not needed uses extra memory, but there was no way to change the option to not load the front panel for certain particular subvi's in Application Builder--the option was grayed out.
    There are several reasons why a front panel is needed. One of them is when the VI is called dynamically, even if the FP is never displayed and AppBuilder will account for that for VIs which have been added as dynamic VI to the project.
    The other is when a VI uses some Property Nodes or Attribute Nodes as they are called now.
    So to solve your problem 1) you could also just drop some property node in the diagram of such VIs and be done with it.
    Rolf Kalbermatter
    Rolf Kalbermatter
    CIT Engineering Netherlands
    a division of Test & Measurement Solutions

  • Front Panel bounds on secondary monitor

    Hello!
    I would like to display some elements of the front panel on the primary and others on a secondary monitor. So I decided to make a subvi from the elements I wanted to show on the secondary display.
    It nearly works, but I would like to have fullscreen on both of the monitors. Unfortunately if I change front panel bounds to be written in the attached subvi, it shows up on the primary monitor. If I leave front panel bounds to be read it works with the secondary monitor.
    Could you give me some advices how to solve the problem?
    Thanks!
    Attachments:
    subvi.vi ‏15 KB

    Dear VampireEmpire,
    One way you can do it is to create 2 SubVIs (each with the specific indicators etc, then set the Window Appearence of those VIs Custom, and check "Show Front panel when called"
    If you are in a VI, press Ctrl+I, or right click on the icon of the VI on the front panels upper right corner, get VI Properties and navigate to Window Appearence.
    In each of these VIs use the Invoke Node : 
    VI Server Reference (This VI), --> Invoke Node --> Front Panel --> Run-Time Position --> Maximized, and wire monitor number 1 to the primary and 2 for the secondary. Use for example a while loop, and if you want to terminate only one of the VIs at Run-Time, remember to Close the Front Panel (Invoke Node), and the reference.
    Then create a 3rd, VI, call it a wrapper, and insert the two VIs to be called. When you run this wrapper, you programatically call the other two VIs front panels.
    I have created a little example how to do it. Please find the attachment and tell me your experiences. 
    A more sophisticated way to do it would be to programatically open the references from the main.vi, and Open --> Run Time.maximize in a while loop --> Close the front panel in the caller.
    https://decibel.ni.com/content/docs/DOC-29472
    Best regards,
    Peter L.
    National Instruments Hungary
    Applications Engineer
    Attachments:
    MONITOR.zip ‏18 KB

  • How to display remote front panels of subvis that are already open

    I inherited an RT project that uses remote front panels for nearly all the user interfaces. The host application opens a remote front panel the the top level RT vi, and there are several subvis on the RT system that are opened from that top level vi and thus displayed on the host (i.e. their "Show Front Panel When Called" properties are set TRUE).
    If the Host loses its connection to the RT system when any subvi front panels are opened, and the host application is restarted, it can re-open the top level vi remote front panel, but all the RT subvis that are already open will not display their front panels. I am looking for a way to open the front panels to these subvis from the host application.
    The kicker is, I need to know which subvis are actually running before I attempt to open remote front panels. Is there any way to determine what subvis are actively running (and not just in memory, such as subvis that won't get executed until the top level vi reaches a certain state)? I am thinking that I could create a list of the subvis that I need access to, check to see if any are actively running on the RT system, and then invoke a remote front panel connection with those that are running.
    Does anyone have any ideas as to how I might be able to do so? Or any other suggestions? [and yes, I know that RFP communication is probably not the best way to go, but we're too entrenched in this software to start over with a new system!]

    TurboPhil wrote:
    If the Host loses its connection to the RT system when any subvi front panels are opened, and the host application is restarted, it can re-open the top level vi remote front panel, but all the RT subvis that are already open will not display their front panels. I am looking for a way to open the front panels to these subvis from the host application.
    It might be possible to work around this behavior by placing VI invoke nodes in your top level VI that reference each of your subvis and setting the Wait Until Done invoke method to false.  This should cause the subvi to close when the top level VI closes even in the case of an unexpected restart.
    You can access this invode node in the functions pallet by selecting Application Control » Invoke Node and also selecting Application Control » Static VI reference.    Wire the Static VI Reference to the vi reference input node and double click the Static VI Reference and select the appropriate subvi in the dialog window.  Left click on the Method section of the invoke node and select Run VI. Finally right click on the Wait Until Done invoke method and select Create Constant and ensure this constant is set to false. 
    TurboPhil wrote:
    The kicker is, I need to know which subvis are actually running before I attempt to open remote front panels. Is there any way to determine what subvis are actively running (and not just in memory, such as subvis that won't get executed until the top level vi reaches a certain state)? I am thinking that I could create a list of the subvis that I need access to, check to see if any are actively running on the RT system, and then invoke a remote front panel connection with those that are running.
    You can access this information by using the Real-Time System Manager (Tools » Real-Time Module » System Manager).  This can be used to show what VIs and subvis are loaded into memory and which are running.
    For more information on using this tool please referere to this Knowledge Base article. 
    Message Edited by BLAQmx on 02-18-2008 11:40 AM
    Mark
    LabVIEW R&D

Maybe you are looking for