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

Similar Messages

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

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

Calling the front panel of a sub.vi

Is there a way to call the front panel of a sub.vi so that as soon as the sub.vi begins to execute, its front panel is displayed?
Solved!
Go to Solution.

LarsUlrich wrote:
That link you posted... is that a function I can find from the block diagram somewhere? I'm looking for it but can't seem to find it (also I am running a pretty old labVIEW 8.5) and I have no clue what the "VI methods" class is.
It's a method for a VI reference. You create a reference to a VI (for example, by using the Open VI Reference function), and then connect it to an invoke node. Select the method from the popup list.
The settings in VI properties will probably be fine, but I can't find it either, (there are 12 menu tabs, after all) and it probably isn't labeled as obviously as "open front panel when run." My guess is under "execution," maybe the run when opened selection?
VI Properties -> Window Appearance -> Customize.
EDIT: The method you used applies only to that instance of the subVI. If you have the subVI in several places on your block diagram, then the other instances are not affected. This would be applicable if your subVI is an information dialog or something.

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 .

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

Calling vi front panel object update in a running sub-vi loop?

Hello All. I have a calling sub-vi with a "Start Test" button on the front panel. I passed a control reference for that Start button into a sub-vi that runs in a while loop. The while loop is monitoring that Start button and other things.
Problem: Once the sub-vi runs, it no longer takes updates from that Start button. My program never leaves that while loop in response to my Start button.
Is there some way I can make the sub-vi take an updated value from the calling vi?
Attached is the sub-vi (top level, LabVIEW 2011). Please note that I have already tried putting the Start Test terminal inside the loop, but that did not help. I put comments in the block diagram and the front panel to help identify the problem code.
I am going to get around this problem by running this whole vi through a loop in the calling vi, where I can easily respond to button changes. This is mainly an academic or curiosity problem now.
Thank you, Richard V
Solved!
Go to Solution.
Attachments:
Channel Setup.llb ‏286 KB

Lets just whip up a little example then shall we?
The subvi you see contains:
Go ahead and run the top vi. Press OK and watch the value of Value change (up to 20 times per second but that is faster than your eyeball).
Why the difference between this simple example and what you are seeing?
If I had to guess (And, I do since the caller wasn't encluded) I would suspect that you misswired the reference. With that over-burdened connector pane and no required terminals it would be fairly easy to do.
And thats where you might want to ricght-click the vi and deselect view as icon.
You'll find out that its a lot easier to wire the right terminals that way. Also, changing the terminals to "Required" for anything that is as important as an exit condition is a good idea. Perhaps even exit if the reference is null although that should cause an error on the property node. Did you shut off automatic error handling?.... Nope you didn't so there is a valid reference going into the sub-vi. But a reference to what? maybe not the button you think.
Jeff

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.

Call a front panel

Hi,
did anyone try to make a VI organized in one main panel (main menu) from
where to call others sub-panels with "return to main manu'" function in ?
Thank you for your help.
Roberto

Look at the "Popup Panel Demo" in LabView example (section Advanced,
Customizing Controls and VIs). The architecture is like you said: a vi call
other vi's, and they can be close when you click on "close"!
Philippe Nobert
Université Laval
Dep. Chimie
Québec, Québec
roberto o a écrit :
> Hi,
> did anyone try to make a VI organized in one main panel (main menu) from
> where to call others sub-panels with "return to main manu'" function in ?
> Thank you for your help.
> Roberto

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

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

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

How can we tell if a VI is already running before calling Start Asynchronous Call?

The new Start Asynchronous Call node is awesome for spawning multiple instances of reentrant VIs. However, I've stumbled a bit in using it for non-reentrant VIs. The old practice of using the "Run VI" method would allow us to check the Execution.State of the VI before invoking the method to run it. That way if the State was Running or Run Top Level, we could skip the invoke node and just use a property node to open its front panel. WIth the Start Asynchronous Call node, it looks like we have to use a strictly typed static VI reference, and when we open the VI reference, the VI gets reserved and its Execution.State = Running. So, how can I tell if it is not just reserved by the thread but actually executing before making a redundant Start call?
By the way, the redundant Start has interesting behavior. It will actually cause the targeted VI to be executed again after it stops. Even if you hit the Abort button on the target VI, it will immediately execute again and again equal to the number of times the Start Asynchronous Call node was run. There's nothing wrong with that, and I suppose the simple answer is to just go back to using the old "Run VI" method. It's just that the ability to wire up those inputs directly to the connector pane is so nice. Perhaps I am missing something obvious. Oh, I am referring to the Call and Forget mode (0x80).
Thanks,
Dan
Solved!
Go to Solution.

Just throwing it out there, I know I'm a year.5 late on this but if it's a psuedo-modal dialog or some other window that you only want a single instance visible at one time, you can check the FP.State property on the strictly typed vi reference. If it's loaded and visible to the user it will be "Standard", if it was closed or not opened prior then the state will be "Closed".
I think the standard behavior of serializing execution on another thread would be great for doing a pre-set number of iterations with a sub vi in a non-blocking sort of way but for sub vi's meant for UI interaction checking FP.State works.
Philip
CLD

Unexpected loop behaviour with asynchronous call

I am having trouble with loop behaviour when using an asynchronous call.
I am building an application to record simultaneously temperature (NI USB-TC01 thermocouple), displacement (DC voltage, read from an Agilent 34401a) and resistivity (using a Keithley 2400 sourcemeter).
I am using a voltage sweep function on the Keithley 2400 to alternate current direction in a sample and measure the voltage drop - this is a common technique for eliminating thermal emf from resistance measurements. But what you need to know is that I set the number of current cycles I want and then wait for the instrument to measure and return the meausurements - up to 50 samples, which takes nearly 30 seconds. With the other two measurements, I have to programmatically call a measurement vi for each sample I want.
I have set up my application to asynchronously program the resistivity measurement and then wait for the response, and I want to in parallel measure temperature and position until the resistivity is done. I then want to record the mean and standard deviation for each signal. I used an event structure to interrupt the temperature and position measurements when done.
The problem I am running into is that after the first resistivity measurement is completed and I go to do the second one, the loop that measures temperature and displacement only runs twice, so I only get two samples, regardless of how many resistivity samples I want to collect. For example, if I want 50 resistivity samples at a time, the first iteration will measure rougly 40 samples of temperature and displacement, but any subsequent iterations will only measure twice.
I know this is probably overwhelming to understand the operation, but can anyone help? I have attached my code ('Delatometer') as well as a test vi I built that uses the same structure but has no interactions with instruments ('asynchronousCall').
The
Attachments:
Delatometer.zip ‏221 KB
asynchronousCall.zip ‏29 KB

I forgot to mention...the test vi that I uploaded executes as expected, so I am thinking that maybe its an issue with the instrument calls? I also found that if I run the Delatometer program in 'highligh execution mode' it runs properly, and it is my understanding that in 'highlight execution mode' there is no multi-threading.

Plotting to a number of asynchronously called subVI front panels

Similar Messages

Maybe you are looking for