SubVI data

I open a VI in one of the subpanels in my main VI. I need to enter a filename, valid pulse widths and nof commands in the subpanel VI. Using the filename entered in the subpanel, I should open the binary file and find the nof valid commands and their pulse widths and dispaly that in another subpanel . I don't know how to get these values from the subpanel VI and do mt job. Hope someone can help me.

Hello srini,
two answers:
1) If you need your filename as indicators (for sending data through connector to an other vi) just make a indicator, connect that indicator with your text control and with connector terminal and finally hide that indicator (right-click on terminal in block diagram).
2) Do I understand you right: you want to send the status of the OK-button also to a second vi (with the case structure in it)? See answer 1!
Best regards,
GerdW
Best regards,
GerdW
CLAD, using 2009SP1 + LV2011SP1 + LV2014SP1 on WinXP+Win7+cRIO
Kudos are welcome
Attachments:
Hidden.png ‏9 KB

Similar Messages

1-to-1 Relationship Between UI and subVI Data Cluster

Discussion continued from here.
In summary:
JackDunaway wrote:
Yes,
I can see clear benefits in implementing this Idea - that is, if your
underlying datatype elements have a 1:1 relationship with the UI
elements.
I will
illustrate this point by showing some potential flaws in your example:
"Profile Running" and "Profile Complete" are mutually exclusive, no?
Wouldn't it be better to have a single enum named "Profile" with three
elements "Idle, Running, and Complete" for the underlying datatype?
Having two mutually exclusive pieces of data in an underlying datatype
is among my favorite of code smell indicators.
Also, the underlying datatype probably only needs "Forward Miles" and
"Reverse Miles" since "Total Miles" is derived. Exclude "Total Miles"
from the underlying cluster and just show the sum for display.
Another
argument against using a 1:1 relationship: the customer now wants to
multiply speed by -1 if Direction==Reverse and not show the Direction
enum on the UI. The data source (the VI that generates the data) would
need to be updated using your 1:1 relationship. Using underlying data
different from the display data, only the data client (the UI front
panel) needs to change. I would be much more inclined to service the UI
FP for a cosmetic upgrade rather than tracing the data source back
through the HMI framework, through TCP, back to the RT, back to FPGA...
Basically...
I question a perfectly overlapped Venn Diagram where the set of data
shown to the user equals the dataset used for underlying data
processing/messaging/storing. The underlying datatype should be as
stripped and streamlined as possible, while the display datatype can
inherit all the flair and post-processing that Upper Management wants to
see in a UI.
LabBEAN wrote:
<JackDunaway wrote
I will illustrate this point by showing some potential flaws in your example...
<LabBEAN response
The data you see maps directly to tags on the PLC.
<JackDunaway wrote
Yes, I can see clear benefits in implementing this Idea - that is, if your underlying datatype elements have a 1:1 relationship with the UI elements.
<LabBEAN response
JackDunaway wrote:
This is a good indicator that we're both aware at this point that I'm
missing something... in all seriousness, could you reply to the 1:1
argument? I really want to understand this Idea and learn how/if I need
to apply it to my own style (our last back-and-forth turned out to be an enlightening and introspective exercise for me).
***EDIT: By all means, please start a discussion on the LabVIEW board so we're not hindered by the Exchange's interface. ***
My long delayed response:
The indicators you see map to tags on the PLC. That is, we were connecting through OPC to an application on a PLC that was written ~15 years ago. I have a VI where I read a bunch of SVs (Shared Variables). Each SV is bound through OPC to a PLC tag. In the interest of disclosure, two 16-bit tags are required to represent each 32-bit mileage number. In the same subVI, I read each set of mileage tags, convert, and feed my subVI cluster indicator. The same is true for wheel size: three bits get converted to the enum. Regardless, though, I have one subVI that reads SVs and outputs the same "underlying data" cluster that is seen on the UI. The UI has a "Faults" cluster full of fault Booleans that follows the same logic. When the user configures a profile of steps, they do so via an array of "step" clusters (although the cluster look is hidden for aesthetics). It's the same thing as above except we write tags instead of reading them.
In my case, each set of 16-bit tags is worthless as two 16-bit numbers. They are only useful as a 32-bit mileage, so I don't pass around the raw 16-bit data. The same is true for the wheel size bits. My software can just as easily (in fact, more easily) operate on the enum. So, the underlying cluster from the subVI is programmatically useful and applicable to the UI. I would guess that the same is true for a lot of RT applications, where the read VI can have some intelligence to process the data into useful / applicable clusters.
There are going to be cases where "Upper Management" would like to see "flair and post-processing" as you say. Your speed illustration is a good example of this. There are also instances where the cluster works fine on the UI the way it is (like this one and many others that we've seen).
<JackDunaway wrote
"Profile Running" and "Profile Complete" are mutually exclusive, no?
Wouldn't it be better to have a single enum named "Profile" with three
elements "Idle, Running, and Complete" for the underlying datatype?
<LabBEAN response
Did you mean "not" mutually exclusive? We combined 3 "dependent" (not mutually exclusive) Booleans into an enum for Wheel Size, as I mentioned above. Not sure now why we went the other way with these two (this was 2 years ago). In any event, with regard to UI representation, I still pass a cluster out of my read-raw-data-and-process-into-cluster subVI up to the applicable queued state machines and to the UI.
<JackDunaway wrote
Having two mutually exclusive pieces of data in an underlying datatype
is among my favorite of code smell indicators.
<LabBEAN response
Working with applications written in ladder logic, it is not uncommon to see separate Booleans that indicate the same condition. This seems to be especially true when safety is a concern. That is, ladder Coil A ON and Coil B OFF == switch open. Coil A OFF and Coil B ON == switch closed. If you ever read OPC tags from Coil A and Coil B and the two are the same, you know the ladder is in transition (hasn't updated the tags). Throw that point out and read again.
I, too, appreciate our back-and-forths. Good discussion.
Certified LabVIEW Architect
Wait for Flag / Set Flag
Separate Views from Implementation for Strict Type Defs

Thanks for replying, Jason. Let me see if I can craft a coherent response after getting back up to speed...
(...later)
OK, let's go. I'm going to fully agree with you that LabVIEW imposes a strange constraint unique from most other languages where a Typedef defines two things: the underlying data structure, and also the view. A Strict Typedef should be more accurately deemed the Datatype-View-Definition, and a Typedef would be more accurately called the Datatype-Definition-and-View-Suggestion. And to be clear, there are two types of views: the programmer's view (a SubVI look and feel) and the UI view (what the user and Upper Management sees). (Finally, I admit I'm ignorant whether view or View is more a more appropriate term)
Linking the programmer's view to the datatype is perfectly fine with me, and based on your original Idea I think we both agree that's OK. I think we run into a disagreement where you have loosely tied the concept of "Strict TD" to "UI View".
Historically, I have used Strict Typedefs for the programmer's view (SubVIs), since I like to maintain a "functional UI" at the SubVI level. I don't use type definitions on User Interfaces - only Controls. That's the reason your Idea does not appeal to me, but perhaps if your Idea were implemented, it would appeal to me since View and Implementation would be divorced as separate entities within the Type Definition. (Does that classify as a Catch-22?) So, you're Idea is fundamentally suggesting that Type Definition .ctl files should be more accurately called "a container that holds both a Type Definition and any number of View Definitions as well".
Fundamentally, I think I finally understand the gist of your Idea: "let's ditch this weird constraint where View and Datatype are inextricably defined together in one file", and for that, I'll give Kudos to the original Idea. I got really tied up with the example you used to present the Idea, and plus I'm still learning a lot.
Additional thoughts:
This Idea reminds me of another: Tag XControl as Class View
We've still got some arguing to do on a 1:1 relationship between underlying datatype and UI presentation, so put your mean face back on:
Since our last conversation, interestingly, I have been on an anti-Typedef kick altogether. Why don't you drop some feedback on my attempt at a completely typedef-free UI framework?
a.lia-user-name-link[href="/t5/user/viewprofilepage/user-id/88938"] {color: black;} a.lia-user-name-link[href="/t5/user/viewprofilepage/user-id/88938"]:after {content: '';} .jrd-sig {height: 80px; overflow: visible;} .jrd-sig-deploy {float:left; opacity:0.2;} .jrd-sig-img {float:right; opacity:0.2;} .jrd-sig-img:hover {opacity:0.8;} .jrd-sig-deploy:hover {opacity:0.8;}

Run in the same time with watching the result?

I have a question
how can I get 2 or more VI's in the same program run simultaneously, each has several SubVI, and if I press a button then I get the result of a VI and without stopping at the same time on another button and I get the result from other VI?

Natsheh,
thank you for your interest in learning LabVIEW. There are two possible ways of approaching your task:
a) using global or shared variables which store the data and can be accessed from the subVIs as well as from the main VI, or
b) using VI Server methods to query the actual values of indicators from the subVIs in your main application window.
Using global variables is the easiest implementation, and a good starting point. When your LabVIEW skills advance, you will want to also look at VI Server technologies, as they provide a more flexible way to access subVI data.
To get you started, let me please recommend the following introduction to LabVIEW:
Getting Started with NI LabVIEW Student Training
http://zone.ni.com/devzone/cda/tut/p/id/7466
Module 6 of this online training deals with global variables, and should give you a first overview.
If you are already familiar with LabVIEW Projects, you may as well use Shared Variables. They are introduced here:
Using the LabVIEW Shared Variable
http://zone.ni.com/devzone/cda/tut/p/id/4679
Also, I would like to point you to our "real-world" training courses which are held thoughout the world. The LabVIEW courses Basics I & II together not only cover these aspects (SubVIs, Variables, VI Server calls, ...), but also give you a good start in "thinking LabVIEW" :-)
Best regards,
SFK

How can I display data gathered in a subVI in a graph of the main VI?

I have written a largish application (~50 VI's) which acquires, analyzes, display and saves data from an instrument with a built-in DAQPad. My problem is that my block diagram is rather messy by now. I'm using an event structure in my main VI which reacts to buttons being pressed on the front panel. During data acquisition (one frame of the event structure), I need to do a lot of data processing, and I'm displaying both raw data and analyzed data on the front panel. I'm using a lot of subVI's for this, but I always need to get data out of the subVI's again to display it on the front panel, cluttering my block diagram. It would be much nicer if the subVI could update the main VI's graphs and indicators. I just found two examples with control references which show how a subVI can modify e.g. a 3Dgraph of the main VI, but I'm unable to use this with normal graphs and charts - I can't find a way to update the actual data in the plots (I can scale the plot or color it blue etc - but I really want to change the data it's displaying, not color it blue). Is there anything I'm missing? Is there example code for this kind of problem?
best regards
Martin

im assuming that you want to update your graphs and indicators as you are performing your DAQ, otherwise, you can pass out your value/s when the DAQ completes.
I have attached a very simple example of using a reference to update your front panel graph.
Hope this helps.
Attachments:
Reference Example(LV7.1).zip ‏17 KB

Avoiding data memory duplication in subVI calls

Hi,
I am on a Quest to better understand some of the subtle ways of the LabVIEW memory manager. Overall, I want to (as much as practically possible) eliminate calls to the memory manager while the code is running.
(I mainly do RT code that is expected to run "forever", the more static and "quiet" the memory manager activity is, the faster and simpler it is to prove beyond reasonable doubt that your application does not have memory leaks, and that if will not run into memory fragmentation (out of memory) issues etc. What I like to see as much as possible, are near static "used memory" and "largest contiguous block available" stats over days and weeks of deployed RT code.)
In my first example (attached, "IPE vs non-IPE.png"), I compared IPE buffer allocation (black dots) for doing some of the operations in an IPE structure vs. "the old way". I see fewer dots the old way, and removed the IPE structure.
Next I went from initializing an array of size x to values y to using a constant array (0 values) with an "array add" to get an array with the same values as my first version of the code. ("constant array.png")
The length of the constant array is set to my "worst case" of 25 elements (in example). Since "replace sub-array" does not change the size of the input array even when the sub-array is "too long", this saves me from constantly creating small, variable sized arrays at run-time. (not sure what the run-time cpu/memory hit is if you tried to replace the last 4 elements with a sub-array that is 25 elements long...??)
Once I arrived at this point, I found myself wondering "how exactly the constant array is handled during run-time?". Is it allocated the first time that this sub-vi is called then remains in memory until the main/top VI terminates, or is it unloaded every time the SubVI finishes execution? (I -think- Mac's could unload, while windows and linux/unix it remains in memory until top level closes?) When thinking (and hopefully answering), consider that the the code is compiled to an RTEXE runningg on a cRIO-9014 (vxWorks OS).
In this case, I could make the constant array a control, and place the constant on the diagram of the caller, and pipe the constant all the way up to the top level VI, but this seems cumbersome and I'm not convinced that the compiler would properly reckognize that at the end of a long chain of sub-sub-sub VI's all those "controls" are actually always tied off to a single constant. Another way would perhaps be to initialize a FG with this constant array and always "read it" out from the FG. (using this cool trick on creating large arrays on a shift register with only one copy which avoids the dual copy (one for shift register, one from "initialize array" function)).
This is just one example of many cases where I'm trying to avoid creating memory manager activity by making LabVIEW assign memory space once, then only operate on that data "in-place" as much as possible. In another discussion on "in-place element" structures (here), I got the distinct sense that in-place very rarely adds any advantage as the compiler can pick up on and do "in-place" automatically in pretty much any situation. I find the NI documentation on IPE's lacking in that it doesn't really show good examples of when it works and when it doesn't. In particular, this already great article would vastly benefit from updates showing good/bad use of IPE's.
I've read the following NI links to try and self-help (all links should open in new window/tab):
cool trick on creating large arrays on a shift register with only one copy
somewhat dated but good article on memory optimization
IPE caveats and recommendations
How Can I Optimize the Memory Use in My LabVIEW VI?
Determining When and Where LabVIEW Allocates a New Buffer
I do have the memory profiler tool, but it shows min/max/average allocations, it doesn't really tell me (or I don't know how to read it properly) how many times blocks are allocated or re-allocated.
Thanks, and I hope to build on this thread with other examples and at the end of the thread, hopefully everyone have found one or two neat things that they can use to memory optimize their own applications. Next on my list are probably handling of large strings, lots of array math operations on various input arrays to create a result output array etc.
-Q
QFang
CLD LabVIEW 7.1 to 2013
Attachments:
IPE vs non-IPE.png ‏4 KB
constant array.png ‏3 KB

I sense a hint of frustration on your part, I'm not trying to be dense or difficult, but do realize that this is more towards the "philosophical" side than "practical" side. Code clarity and practicalities are not necessarily the objectives here.
Also, I have greatly appreciated all your time and input on this and the other thread!
The answer to your first question is actually "yes, sort of". I had a RT application that developed a small memory leak (through a bug with the "get volume info.vi' from NI), but to isolate it and prove it out took a very long time because the constant large allocation/deallocations would mask out the leak. (Trace's didn't work out either since it was a very very slow leak and the traces would bomb out before showing anythinng conclusive.) The leak is a few bytes, but in addition to short term memory oscilations and long term (days) cyclical "saw-tooth" ramps in memory usage, made this very hard to see. A more "static" memory landscape would possibly have made this simpler to narrow down and diagnose. or maybe not.
Also, you are missing my point entierely, this is not about "running out of memory" (and the size of 25 in my screen-shot may or may not be what that array (and others) end up being). This is about having things allocated in memory ONCE then not de-allocated or moved, and how/when this is possible to accomplish. Also this is a quest (meaning something I'm undertaking to improve and expand my knowledge, who said it has to be practical).
You may find this document really interesting, its the sort of thing you could end up being forced to code to, albeit, I don't see how 100% compliance with this document would ever be possible in LabVIEW, thats not to say its worthless: JPL Institutional Coding Standard for the C Programming Language (while it is directed at C, they have a lot of valid general points in there.)
Yes, you are right that the IPE would grow the output if the lenght of my replacement array is not the same, and since I can't share the full VI's its a bit of a stretch to expect people to infer from the small screen dummp that the I32 wires on the right guarantee the lengths will match up in the IPE example.
Once, on recomendation of NI support, I actually did use the Request deallocation primitive during the hunt for what was going on in that RT app I was debugging last year. At that particular time, the symptom was constant fragmentation of memory, until the largest contiguous block would be less than a couple of kB and the app would terminate with 60+MB of free memory space.. (AKA memory leak, though we could not yet prove that from diagnostic memory consumption statistics due to the constant dynamic behavior of the program) I later removed them. Also, they would run counter to my goal of "allocate once, re-use forever" that I'm chasing. and again, I'm chasing this more as a way to learn than because all my code MUST run this way.
I'm not sure I see what you mean by "copying data in and out of some temporary array". Previously (before the constant array) at every call to the containing sub-vi, I used to "initialize array" with x elements of value y (where x depends to a large degree on a configuration parameter, and y is determined by the input data array). Since I would call to "initialize" a new array each time the code was called, and the size of the array could change, I looked for a way that I could get rid of the dynamic size, and get rid of dynamically creating the array from scratch each time the sub-vi was called. What I came up with is perhaps not as clear as the old way I did it, but with some comments, I think its clear enough. In the new way, the array is created as a constant, so I would think that would cause less "movement" in memory as it at that point should be preventing the "source" array from (potentially) moving around in memory? Considering the alternative of always re-creating a new array, how is this adding an "extra" copy that creating new ones would not create?
How would you accomplish the task of creating an array of "n" elements, all of value "y" without creating "extra" copies? -auto-indexing using a for loop is certainly a good option, but again, is that sure to reuse the same memory location with each call? Would that not, in a nit-picking way, use more CPU cycles since you are building the array one element at the time instead of just using a primitive array add operation (which I have found to be wicked fast operations) and operate on a constant data structure?
I cannot provide full VI's without further isolation, maybe down the road (once my weekends clear up a bit). Again, I appreciate your attention and your time!
QFang
CLD LabVIEW 7.1 to 2013

How can I pass data generated in a SubVI inside a Case Structure out of the Case Structure?

Hello,
I am using a USB 2701 to control a heater. I have three SubVIs that are all working properly on their own. I'd like to use an Enum to select which of the SubVIs is running at a given time. The problem is that no data is passing out of the case structure. How can I pass the temperatures and heater outputs acquired by the SubVIs to the main VI? I've attached my some of my code below. I can't attach more than 3 files, but you can see how the main VI is configured. Like I said, the SubVIs are working individually, so you shouldn't really need to look at them.
Thank you,
CJones581
Attachments:
RampHeater6-21-07.vi ‏305 KB
69_Heater_Case.vi ‏23 KB
HeaterTCD6-21-07.vi ‏210 KB

CJones,
You might check a couple of things.
Your HeaterTCD... VI has a While loop with a stop button condition. HeaterTCD pass out values only when it finishes running. If it doesn't pop open the front panel (which usually doesn't happen when running a SubVI) you could run into a stuck loop because you don't have access to the Stop button. This could appear in the form of no data being passed out (because the SubVI never stops running). The primary VI opens the HeaterTCD VI, starts it, and waits for the VI to finish and pass final values .
Secondary note: Unless you want your SubVI panel (which probably isn't open when running the main VI) to update continuously, consider moving your Temperature Graph and Temperature oC indicators outside the while loop. Pass final values to them via a tunnel, since the main VI will only read their values after the loop finishes running, anyway.
It might help to add error management to HeaterTCD like you have for RampHeater. If you connect error lines with Error Outs to your main VI, that will help tell if there is an error somewhere that is preventing info output.
RampHeater SubVI has the same issue with the stop button. It is also probably getting stuck in the While loop waiting for a manual push of that SubVI's Stop button.
An easy way to test this would be to set up a logic circuit so that when the While loop iteration counter reaches a certain number, it registers True and sends it to the conditional. I know this isn't what you want to do long-term, but if that lets your SubVI return outputs it means that the SubVI was just never stopping.
Hope that helps.
David C, Applications Engineering
David C
Applications Engineering

Multiple instances of a subVi to display data

What
is the best method for creating and using a subVi that was created specifically
for displaying results?
I created a subVi for displaying stress (tension & compression). I started
with a Numeric Control/Vertical Pointer Slider which I changed to a Numeric
Indicator. I added 2 LEDs for out of bounds indicators (+ and -). I used the
Property Node for the Slider to permit setting the minimum and maximum values
for the scales. The subVi has only two inputs; the min/max scale value and the
data to be displayed. I added a Decoration in the form of a graduated color
scale to match that used in PTC's Pro/E.
When I use the subVi each instant in the Block Diagram uses the same Front
Panel. This makes the Slider or Needle flicker.
What I'd really like is for my subVi to work and act like the original Vertical
Pointer Slider and appear directly on the main Vi.
I know I can create multiple copies of the subVi's file in the folder on the
disk but that makes maintenance a pain because each change will require the duplication
once again. This will still create multiple Front Panels to display the data.
I need a solution that will work with the data for about 20 strain gauges
displayed on the screen at the same time.
Copying
and pasting the Block Diagram for my stress subVi into the main VI will work
but will also create a wiring nightmare
How
do create this type of display.

Dynamik,
Thanks for "Slider2.vi" it was quite
informative! It's taken me a while to get back to working on my VI.
I tried to create a modified version of "slider2.vi" so I
would understand what you had done (I still don't understand everything) as
well as creating the vi I needed for my testing. I succeeded except for being
able to display the information on the front panel. For some reason I create a
cluster with 20 clusters within it each of them containing a slider (with a
multi-colored scale) and hi/lo out of bounds indicators. I used "Cluster
to Array" so I could use "Bundle by Name" within a "For
Loop" to set the values. The problem comes when I attempt to take the
array information and apply "Array to Cluster." The resulting cluster
only has 9 elements. What happened to the other 11 elements? The
"Help" has not been very helpful. With the broken wire deleted, I've
inserted an indicator for the "For Loop" index and a "Wait"
to slow down the loop so I can follow the values. The index goes from 0 to 19
as expected.
I'm at a loss as to how to proceed. I've attached my
"Test-problem.vi" to this message. Is there something fundamental
I've missed? Where is the problem?
Thanks
To answer your question: I've been programming for 25+ years, Everything
from assembly language, to procedural languages (FORTRAN, PL/I, PASCAL,
C), to object oriented languages (Java), to scripting languages (C
Shell, Perl).
Message Edited by JoeSz on 10-05-2005 06:17 PM
Attachments:
Test-problem.vi ‏227 KB

How to save the data in a Subvi

Dear people,
I am currently making a program which is calling with a Call by Reference Node. after that, I read out data (in this case an array of clusters) and I am writing new data to the cluster of the subvi.
My problem is that the new data isn't stored in the subVI. If I close my Caller VI and i take a look in the SubVI all the 'new' data is erased and it seems to me that the program returned to its Default Values...
How can I make a program so that the new data is stored in the subVI after I called it. I tried already with a invoke Node and then as method: Make all current Values Default. Actually, the SubVI is in the wrong state to execute that node...So I don't know how to go...
Message Edited by btwesseling on 09-21-2006 07:37 AM

Yes, I can explain,
I am making a test program which is testing a device. There are around 400 different tests, and it is important that all the tests go in a sequential order.
Before I actually run a test I need to give up some parameters. The parameters are been given in a mainprogram.
so, if I load my main program, it is scanning which tests are available. From each test I would like to see the paramters in my main-program. I am doing this by putting it into a cluster, which is been read-out by my main program.
I also would like to change the paramters, and then save the paramters back into the SubVI. For Example, In my main prgram I can set if a test is enabled or disabled.
After setting the paramters the subvi closes. At the begin of testing, I scan all the tests outputs using a 'Call by Reference' node and I look if they are enabled or not. If yes, I make up an array of paths and after that all the tests which are in that array are been called and executed. the results aretransferred back to the main program, stored, and finally written in a TSV file (Tab Separated Value file.)
the reason for a dynamically load is that in the case of someone wants to add a new test, it is dificult to change the mainprogram. In other words, the program which I am writing is for people who don't know much about labview, so I want to make it as user-friendly as possible. I am planning to make a kind of an wizard that helps the engineers to add tests.
the second reason is that there are different devices which needs to be tested. If I load all my tests in one time, that means that for each different device I have to load all the tests. that means that I have to load over 5000 tests in one time, which is not so nice.
iI hope it is more clear now, but If you have more questions please let me know!

Is there and alternative to shift registers for saving data across iterations in a subVI operating inside a loop?

I am creating a subVI state machine (case structure) which will run inside a while loop which will be executing every 250ms. The reason I wanted to make the state machine case structure into a subVI is because I want to execute 64 of the machines within the same loop. The goal is to monitor certain types of voltage changes on 64 I/O channels on a FP2200 RT module and report periodic details about state changes to a database. My thinking was that by executing each independent machine in the same loop structure, I will only worry about one thread. It seems that the alternative of having one state machine thread per I/O channel is probably more than the RT module can handle. Please correct me if I am wrong on that.
The issue I'm now having is as I'm creating the state machine, I am finding that I need to keep track of some pieces of data from one loop iteration to the next. This is easy enough to do with shift registers but in order to use them, I have to create additional input nodes to my SubVI as well as output nodes. For example, I want to use a queue to buffer some I/O data but as of now, I have to create this queue outside the loop, pull it into the loop across a shift register, feed it to the subVI, and output it to the out Shift register. It would be better if I didn't have to output this queue because there's no reason for anything to have access to it outside the subVI. It just creates an extra set of wires to look at and makes me worry a bit about maintainability.
Is there a better way to approach this problem?

You could place a while loop inside your sub vi that has a true constant wired to the stop condition. Then add unitialized shift registers to that while loop to keep data between iterations.
or you could use a feedback node inside the sub vi

Main VI is not updating the data from subVI

Dear all,
I
have a Vi A using the data front a subVi B. When I run it, I see the
data is updating in the subVI, but not the main Vi and the Front Panel.
The subVi has three output channels and the main Vi tries to display
those three channel data on the Front Panel.
Could somebody tell me how I can solve the problem?
Thanks a lot.
Roy
Solved!
Go to Solution.

You could probably use Control Refnums but as Dennis mentioned, be sure to explain the use case to us.
How Can I Update the Changes Made to a Control/Indicator from a SubVI on the main VI?
Message Edited by Adnan Z on 06-02-2009 02:48 PM
Adnan Zafar
Certified LabVIEW Architect
Coleman Technologies

Is it possible to pass data from a subVI before that subVI has finished executing?

Basically this is my problem:
1. I have a subVI which contains a loop that reads data from a device for a specified amount of time.
2. I would like to graph this data in real time on the front panel of the main VI.
So is there a way to pass data from inside the loop of my subVI to the graph of my main VI before the subVI has finished executing, and if so how do I do this?
Thank you.

How about using a global variable or a Queue?

How do I get live data from a subvi while it is running ?

Hi.
I'm finishing up my little application, and one of the things I cant figure out to get to work is getting live data from a subvi and displaying it on my main vi's front panel.
In my subvi I am sending about 10 commands to the serial port, each time updating a local variable that writes value to a progress indicator. I would like to get that indicator displayed on my main vi so I can see the progress of my subvi.
Currently I have just linked the progress indicator on the sub to a terminal, and connected that to my main vi, but, that only updates when the sub finishes its mission. Is there a way to update the main while the sub is active ?
Any ideas appreciated !
/Brian

In your VI Prg_all_sub, you are actually only writing out the progress bar once to the contol reference. Once the code to the top has executed, it will never execute again although you continue to write values to the local variable PP throughout the program.
The quickest fix would be to put that code at the top in a loop with a small time delay function. That way it continues to execute every time a new value gets written to the local variable. You would have to use a local variable stop button to stop hat loop wonce your string of VISA reads and writes executes. Also make sure to reset that stop boolean to false once the loop ends so that the loop will execute properly the next time this sub VI is called.
Other recommendations for cleaning up the programming is to use arrays or bundle values into clusters that you pass into and out of subVI's. Prg_all_sub and MPS setup loader have numerous wires going into and out of the sub-VI's. Bundling these together would simplify the wiring quite a bit.
Note also that in a lot of places you send in a wire to an indicator and branch it off to a local variable of the same indicator. That is redundant. Sending the wire to the local variable does the same thing as sending the wire to the indicator. Try to use wires instead of local variables as much as possible. For instance, near the top you send the output of the VISA resource name control back into a local variable of itself, (not necessary) then use a local variable numerous times in the case structure below. Just wire the name into the case structure border, and maintain the value through all of the loops using a shift register. This will eliminate dozens of copies of the VISA resource name variable.
In several places you concatenate a carriage return character to a string constant. Just put a "\r" at the end of the string constant when it is shown in \ display. Then you can eliminate the concatenation.
I hope this helps you get your progress bar working and help simplify the code for you.
Message Edited by Ravens Fan on 08-13-2007 09:34 AM

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.

Stream data from a subvi to the main vi - path refnum

hello everyone
sorry my english
http://forums.ni.com/t5/LabVIEW/stream-data-from-a-subvi-to-the-main-vi/m-p/2205150/highlight/true#M...
- refnum boolean worked
- refnum graph worked
- refnum numeric worked
how to create a path refnum? stream data from a subvi to the main vi
where do I start?
thank
Solved!
Go to Solution.

Bom Dia Saille,
Eu acredito que o que você tenha hoje seja isso aqui (Desenho bem simplificado):
Hoje o que você tem é o Aplicativo do Medidor + USB Driver controlando o seu medidor. Basicamente, sua aplciação está dividida em três camadas:
Aplicação - Onde estão as funcionalidades principais do programa (interface com o usuário, apresentação de dados, geração de arquivos, etc.)
VISA - Uma arquitetura de Software para controle de instrumentos. Basicamente, ele se comunica com o Driver USB para poder enviar e receber pacotes de dados através do barramento USB.
Device Driver - Intruções de SW de baixo nível para controlar um periférico através de um barramento.
No desenho, eu aponto duas camadas onde você pode tentar atuar para automatizar suas medições:
Aplicação - Você pode usar o VI Server para controlar o Aplicativo do Medidor (Se este aplicativo tiver sido desenvolvido em LabVIEW, o que eu suponho ser verdade). No entanto é necessário saber se o desenvolvedor do produto permitiu isso (Veja Using VI Server to Pass Data Between a VI and a LabVIEW Executable). Outra alternativa é conversar com o fabricante para ver se ele desenvolveu alguma API (Application Programming Interface) para que você consiga controlar o instrumento diretamente.
VISA - O LabVIEW Fornece uma API chamada NI-VISA para poder enviar e receber informações através de diversos barramentos (Veja Serial Instrument Control Tutorial)
É possível acessar o Driver diretamente também, mas eu não recomendo. O resultado não compensa o esfroço!
Espero ter esclarecido suas dúvidas e espero que você tenha sucesso na sua aplicação!!
Atenciosamente.
Felipe Flores
Engenharia de Aplicações
National Instruments Brasil

Passing Data to SubVIs: W/O clusters?

Dear all,
I have 40ish measurement (real) values and 30ish boolean values continuosly coming from a measurement. I need to pass them to various subVIs for processing the data. I intend to bundle this data in order to not have 70 wires an SubVI-Terminals.
What am I recommended to do?
I like the bundle/unbundle function for clusters, but any change in cluster shape during development brings a huge effort to fix all folowing VIs. This is not practical.
I could pack all data of the same type in big arrays, but i would have to manually "unbundle" them via "index array" (no? is there another way?)
What is a practical solution to this?
Thank you!
Solved!
Go to Solution.

Hi OPCer,
use a cluster with two arrays. One array holds "real" (aka float or DBL) values and the other holds the boolean values…
I like the bundle/unbundle function for clusters, but any change in cluster shape during development brings a huge effort to fix all folowing VIs. This is not practical.
Well, when using clusters you should always think of type definitions! There's a reason we have those…
I could pack all data of the same type in big arrays, but i would have to manually "unbundle" them via "index array" (no? is there another way?)
There are key-value datatable implementations available. You may have a look at them…
And yes: there's no other way then using IndexArray to get elements from an array (apart from using autoindexing in loops).
Best regards,
GerdW
CLAD, using 2009SP1 + LV2011SP1 + LV2014SP1 on WinXP+Win7+cRIO
Kudos are welcome

SubVI data

Similar Messages

Maybe you are looking for