Load subVI front panel in subpanel

I want to load subvi front panel in subpanel. I have attached VI , however instead of path of VI I want to provide sub vi reference.Is it possible to this?
Attachments:
SetSubPaneOrigin_LV861.vi ‏10 KB

Use a Static VI Reference that can be found on the Application Control pallette.
After dropping it, right click and browse.
Ben
Discalimer: In an eralier version of LV, Static refs did not work correctly in an executable.
Ben Rayner
I am currently active on.. MainStream Preppers
Rayner's Ridge is under construction

Similar Messages

Main VI Menu event calling a subVI front panel

Hi all,
I have a subVI whose front panel is loaded upon calling by a main VI.
I call the subVI using a User-menu event.
the subvi-properties are set to allow close window and i am not handling a 'panel close' event.
The problem is....
when i run the main VI and click on the menu that loads the subVI front panel, subVI window opens, and if i click on the window-close, the main VI hangs.
i understand that the control remains with the subVI only and never returned to main VI after i close subVI panel.
but is it the only way to handle the 'panel close event' or any other way out to solve this?

Try running the VI with highlight execution turned on, and see if anything unexpected is happening, or you could post your vi and let us take a nosey
Message Edited by yenknip on 09-12-2008 04:30 PM
- Cheers, Ed

Reference to control on main front panel fails when subvi front panel is closed?

Hi All,
I'm experiencing an odd bug. In my code, I use a subvi to control a piece of hardware. This subvi has controls for all of the functions of my hardware.
I'm changing the value of one of these controls from my main front panel by running a reference to a knob on my main front panel into the subvi, grabbing the value of the knob with a property node, and then updating the value of the subvi control using a signaling property node.
This works fine when my subvi front panel is open but fails to work at all when the subvi front panel is closed.
I'm new to labview , so any help is appreciated.
Thanks,
Arpan
Solved!
Go to Solution.

What is your LabVIEW version?
Front panels that are not shown are typically not updated and might not even be loaded into memory.
The presence of certain code elements (e.g. property nodes) often forces the front panel to be in memory even if it is not shown, but I haven't studied it in a long time so there might be subtleties. Maybe somebody from NI can give more details.
If it does not work unles the FP is open, open the front panel minimized to avoid distraction.
Can you attach some code? Maybe there are better ways to do all this anyway.
LabVIEW Champion . Do more with less code and in less time .

VI Front Panel in SubPanel reacts slowly

In LabView 2010F2, I have a VI that has several buttons and other controls on the Front Panel. When I run that VI standalone, it runs very quickly, uses less than 20% CPU, and is very responsive. ALl of the controls react very quickly. But when I put that same VI FP in a subpanel in a small VI, all of the controls in the VI in the subpanel are now running very slowly. There buttons are slow to react. There is almost a 1/2 second delay on the buttons. The CPU is stall down around 25% usage. The hosting VI does not do much and should not be responsible for this delay.
If the CPU is not very busy, what is the cause for the delay in the reaction of a Front Panel of a VI that is placed in a subpanel?
What can be done to significantly improve the response of a FP that is placed in a subpanel?

dbaechtel wrote:
Ben wrote:
How is you memory doing?
Do you have "show Kernal time' selected?
Ben
CPU Usage and Kernel Time do not pudge much during Save All or Clean Up Diagram of large diagram. CPU usage stays about 25%, Kernel time stays about 50-75% of Total CPU Usage.
I don't see any reason why LV would show "not responding" under these conditions unless there are some long LV processes that are being executed that include significant I/O delays that do not relinquish the CPU to do other things while executing these long LV processes. If LV was not blocked by I/O (disk) delays then I should see near 100% CPU usage. If LV was being delayed by memory swapping, the I should see less than 50% memory free,
I'll leave the discusion of Internals and Data Structure for another thread.
Spoiler (Highlight to read)
Both of my copies of that book are much more worn.
Both of my copies of that book are much more worn.
It is going to take some work to narrow down the possiblitlites since you have presented this situation as an interaction problem.
Generally speaking there is one hot button that comes to mind and that is the UI (User Inteface) thread where all GUI updates are handled as well as those things that do not play well if left to run in their own threads (property nodes for example).
SO I would like to suggest you start by trimming it down to something that work good and then start adding stuff back until you can detect the performance hit. At tath point step back and look for contention issues.
If I remebe correctly you can't post code images so asking you to post images of teh code that does not play nice together is a no-go.
You could also run the performance monitor.
THe Trace Execution tool kit should aslo help you get a the root of this situation.
Trying to help, wondering if if I can,
Ben
PS Regarding the bug thread. I depend on that thread to stay on top of potential bugs. I asked and Laura moved the off-topic posts to the proper thread. Please excuse my "anal-retentive" side.
Ben Rayner
I am currently active on.. MainStream Preppers
Rayner's Ridge is under construction

Problem about asynchronous call: subVI front panel doesn't pop up when called.

Dear All,
I'm new to LabVIEW, and this is the first time I try to use the asynchronous call.
I'm using LabVIEW 2011.
I want to build a directory for several VIs, and it should allow users to open more than one of the VIs at the same time by pushing the buttons. Before building this directory, I simply tried to use asynchronous call to call a VI form another VI, but found a big problem.
I followed the steps in the help file, created a strictly typed reference, set the option to x80 because I don't need the return. When I run it for the first time, it worked fine: the subVI popped up and run. Then I closed the subVI. But for the sencond time and on, when I run the caller VI, the subVI didn't pop up, instead it seemed to run silently on background because when I manually opened it from the file I found it running. Besides, I didn't find any option like "show front panel when called" of the asynchronous call.
The caller VI and subVI are attached. The address of subVI in caller VI should be changed accordingly.
What should I do to make it work properly? Thanks very much for any idea!
Solved!
Go to Solution.
Attachments:
asynchronous_call.vi ‏8 KB
boolean.vi ‏7 KB

Jeff·Þ·Bohrer wrote:
A better approach is to set the vi properties programaticly like this:
Jeff, you will be happy to know that I used this tactic in full force on a project recently (lots of dialogs in this program). Not sure how many LabVIEW reboots it has saved me from. Reuse VIs made it even easier to do.
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines

Plotting to a number of asynchronously called subVI front panels

Hello everyone,
I'm working on a DAQ and monitoring program and I have a dream of doing some very flexible window management for my plot windows. Trying to make it easy to quickly open different kinds of plots and display different channels in each window. So as not to reinvent the wheel I'm trying to use Windows windows to do this by calling VIs asynchronously. The VI will be built as an EXE and used by people who don't know LabVIEW, hence trying to make it really flexible and intuitive.
I've set up my VI like this example and it has me real close: http://zone.ni.com/reference/en-XX/help/371361J-01/lvhowto/acbr_call_clones/
When I run the VI it opens whatever number of plotting windows (instances of my plotting window SubVI) I've specificed but the plots don't update. Anyone have any tips as to how to get this behavior?
Xander Cesari
Automotive/Internal Combustion Test Engineer
CLAD certified, mainly focused on data acquisition
Been LabVIEWing for a few years, still a lot to learn
Solved!
Go to Solution.

Bob,
Thanks for the reply. I'm using a QSM-PC architecture, here's the relevant loop. Looks pretty much identical to the linked example, I hit that point and I decided I needed a bit of help wrapping my head around it. Data's coming in on a queue (the snippet broke the reference). My idea was to pop open all the windows in this state then use another state to plot data to them.
In 'synchronous' mode I was able to get the desired behavior out of my subVI but it was also set right in a while loop and by playing with the Call Setup a bit I got it to do what I needed (open a new front panel and constantly plot).
The queue idea is very promising though! I should be able to generate queues right in the For Loop that calls my VIs synchronously then enqueue in a "RUN" state. I'll give that a try.
Xander Cesari
Automotive/Internal Combustion Test Engineer
CLAD certified, mainly focused on data acquisition
Been LabVIEWing for a few years, still a lot to learn

Question about subvi front panel

I want to call a subvi in the main program and do like
this:
1. When the main program calls the subvi, the subvi shows its front
panel and executes.
2. After the subvi finishes, it can close the front panel.
Now, I meet a problem: I can popup the subvi node setup dialog to enable
"show front panel when called", which implements the first one, but I
can not close the front panel until originally closed(main
program stops). How can I close the subvi's front panel(after it
finishes running) even when the main program is still running?
Thanks in advances.
Sent via Deja.com http://www.deja.com/
Before you buy.

In article <[email protected]>,
"Remco Breen" wrote:
>
> [email protected] wrote in message <[email protected]>...
> >In article <[email protected]>,
> >"Kevin B. Kent" wrote:
> >> [email protected] wrote:
> >>
> >> > Now, I meet a problem: I can popup the subvi node setup dialog to
> >enable
> >> > "show front panel when called", which implements the first one,
but
> >I
> >> > can not close the front panel until originally closed(main
> >> > program stops). How can I close the subvi's front panel(after it
> >> > finishes running) even when the main program is still running?
> >
> >
> >
> >
> >> Select the "close front panel if originally closed" option.
> >> in addition to the "Show front panel when called"
> >>
> >> Kevin Kent
> >
> >
> >I have tried this, in this way, the subvi's front panel is closed
only
> >after the main program stops. In fact, what I want is to close the
> >subvi's front panel even the main program is still running.
> >
> >
> >zhljh
> >
> >
> >Sent via Deja.com http://www.deja.com/
> >Before you buy.
>
> Another option would be to open a VI reference (found under
"application
> control") and tie that to a property node and select the property
"front
> panel.open". Change it to a control and attach a boolean false to it
when
> you like to close.
>
> RB.
>
I think a more elegant way of closing the SUB VI is to start off the way
that Remco states regarding opening a VI reference. Only in the Sub VI,
you should program a Terminate control (such as an Abort button to exit
from a While loop... or something similar) and via the VI reference,
select the 'Set Control Value' method to gracefully stop the Sub VI
execution. Of course the Sub VI will have to set the close if originally
closed attrib set.
There is a great source of example LabVIEW apps at:
http://digital.ni.com/explprog.nsf/web%2Fswgrp?OpenView&Start=1&Count=50
0&Expand=3.7#3.7
In particular, see "Stopping a Running SubVI from the Main VI Using VI
Server" example. It demostrates this techniques better than I can
explain it. Hope this help.
Rick
Sent via Deja.com http://www.deja.com/
Before you buy.

Retain VI front panel in Subpanel after VI containing subpanel is stopped

Is there a way to retain the front panel image of a VI in a subpanel after the VI containing the subpanel is stopped? The default action causes the subpanel to clear when the VI containing the subpanel is stopped but not closed.
Thanks in advance...
Steve
Solved!
Go to Solution.

If you want the image of the FP, you can place a picture control under the SP, use the Get Panel Image method and push the result into the picture control. When the VI will stop the SP will become transparent and you will see the picture control.
I assume, though, what you actually want is for the FP itself to stay in the SP and I believe the answer is no. My experience has been that the caller removes the SP VI when it stops, whether you removed it or not, and a quick test indicates you can't insert a VI into an SP which isn't running. Personally, I never needed the SP to have a VI when the caller stopped.
One workaround you might be able to use is to place the SP in an XControl. Xcontrols run at edit time as well, so I'm guessing this will work, but I haven't tried it.
Try to take over the world!

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.

Exporting front panel of subVI to calling VI

Is there a way to "export" the front panel of a subVI so that it becomes part of the (or a pane of) the calling VI? If so, what is it called? I don't know the right language to search for examples of this concept.
My problem is as follows:--
I built a nice, classy interface to a test program that allows the user a great deal of flexibility in controlling the parameters of the device under test and in seeing the impact of those parameters on other parameters. This has about 8-12 control objects, some of which are also wired to act as indicators so that changing one can display on another and vice versa. This interface and its supporting program is big enough that it belongs in its own subVI rather than in the main program. In addition, I built another interface that charts signals from the device under test; this is also big enough that it belongs in its own subVI.
I would like to have the front panels of both of these VIs be part of the front panel of the main program. That is, the front panel of the main program should "inherit" the front panel of each subVI wholesale. If I need to tweak the interface of one of the subVIs -- for example, to add, delete, or replace controls, indicators, displays, charts, etc. -- I would like to be able to do this without having to wrestle with the main VI and the connector pane between it and the subVI.
It seems that LabView should be capable of this, but I cannot find any help, guidance, pointers, etc., in the documentation, textbooks, or examples.
Could someone give me a clue?
Thanks,
Hugh Lauer

So I tried to configure a subpanel, and found it very confusing. It seems that when you put a subpanel control on the front panel, you have to then set up a way to invoke the subVI. Since my subVI has some inputs and outputs on its connector pane, I created a VI reference for it and wired that to the type specifier node of the Open VI Reference node. I then inserted a Call VI by Reference node, so that I could wire up the inputs and outputs of my subVI. Finally, I wired this to the subpanel Invoke Method (Insert VI).
This is different from the examples I found. In those cases, the subVIs had no inputs or outputs on their connector panes, but rather took all of their information from their front panels.
I got different behavior on different attempts to run it. The most common (and most recent) behavior is that the subVI front panel opens up a few seconds after the main VI starts, but it is not quite "in" the subpanel. Instead, it is offset about an inch from both the top and left, as if it were a floating window that I cannot move. Also, it has annoying scroll bars on the bottom and right, which I don't want.
Incidentally, I have two of these subVIs, and I have not yet tried to put the second one into a subpanel.
What I would really like to do is
have both subVIs populate their respective subpanels as soon as the main VI starts, but before any work gets done.
after both subpanels are loaded, run the two subVIs in parallel, one to control the device under test and the other to capture its signals.
have no scrollbars in the subpanel windows.
In fact, what would be the best from a GUI point of view is for the two subpanels to be permanently part of the front panel of the main VI.
Any guidance or insight would be most helpful.
REgards,
Hugh

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

Open and Close Front Panel of SubVI

Hi all,
Running LabVIEW 2011 on Windows 7 x64. I am trying to get a subVI front panel to open from my main FP with the press of a button and then close with a button press in the subVI. Here is the piece from my main FP that calls the VI and opens the FP
Plots is defined in another loop and all of the loops are in a flat sequence. I did it this way because I want it to start with the first press and not stop my main loop from running. I have moved the item in the left loop around a lot so I'm not sure if I can run that in the same loop as the event or not. Either way opening the VI seems to work fine.
The problem shows up when trying to close the subVI for the SECOND time. The code is here:
As I said, the first time I open and close the VI everything works as I expect it should. I am then able to open it again but now the "blank button" doesn't function and I can't close the window or even open the block diagram to probe anything. I have been trying to figure this out for awhile, any insite would be greatly appreciated!
Thanks
Solved!
Go to Solution.

Its good that you found the bug.
This code may serve as a way for you to compare notes.
Ben
Ben Rayner
I am currently active on.. MainStream Preppers
Rayner's Ridge is under construction

Opening multiple sub VIs (front panels) in an application

Hi,
I am working on a small process control application. The main VI represents a layout of various equipment (pumps, valves, heat exchangers). Each TYPE of equipment
can be turned on/off through a particular subVI. The subVI is displayed when the operator clicks on the component. At the moment only one subVI front panel can be loaded. I would like to have multiple panels open at the same time; this to include multiple instances of a same VI and different subVIs.
I have tried to set properties in the WindowsApperance dialog box but cannot acheive the desired operation.
Any suggestions?
Thanks

Trust my personal experience: You do NOT want multiple dialog windows open. The users will hate you and curse your name if you do. You really want to use subpanels and limit what the user can do. Subpanels are a way of inserting a VI's front panel into another VI's front panel. So you want to have a section of your main front panel that the user can load whatever control subVI they need.
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines

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

Q:How to trim a VI's front panel at runtime?

The occupied front panel space can be obtained by calling
"GetPanelImage" via an invoke node. The resulting cluster "bounds"
describes the union of all front panel objects. The front panel can then
be resized to fit these bounds. The content of the front panel can be
repositioned by manipulating "FrontPanelWindow.Origin". This "...Origin"
points with an _unknown_ _offset_ (which varies with the FP´s layout) to
the upper left corner of the front panel content.
How to exactly calculate the origin from other front panel values?
Thanks,
TC

You can use a VI Server to position the front panel of your subVI. Look at the Ghost in the Machine.vi example that ships with LabView.
To see where to position the subVI, you need to know the position of the calling VI or of something on it. You could use a property node of the Get Details button.
1. On the front panel on Panel.vi, right-click on Get Details and select Create >> Property Node
2. Right-click on the Property Node and select Properties >> Position >> Left.
3. Point to the bottom edge of the property node and pull it down to add another element. That element should default to Top.
That will give you the coordinates of the Get Details button. Now use a VI server (based on Ghost in the Machine.vi) to place the subVI front panel the desired distance
from the Get Details button.

Load subVI front panel in subpanel

Similar Messages

Maybe you are looking for