Passing control reference to subVI crashes labview

Hi,
using a image control (as indicator) provided by imaq Vision, I tried to pass the reference of the control to a subVI. On a computer it works and on a other (same labview version, same vision version, same os, same hardware and hardware drivers!), this crashes labview. I tried to close the control refnum at the end of the subVI, but that changed nothing to the issue. Now I use the reference as a global variable and it seems to work...nevertheless, I would like to understand what the issue and if I should remove any passing to subVI of control ref because this can potentially triggers an error. My correlated question is if this global passing is a "fake" workaround or have real chance of improving (this before going through the whole code for changing all passing of reference to subVI)
thanks a lot

Hi,
thank CoastalMaineBird for your answer
How do you know it's this issue which causes the crash?
When I remove this parameter from and the only property node in the subVi that write to it, I have no longer any problem. Moreover, to ensure that's really the "passing", and made a global variable containing the reference to this control and use my original SubVi that do access the control through its reference number
, and it works! In this last exemple, the only change is the way of transmitting the reference
What LabVIEW version?
8.0.1
up to date according Measurement & Automation update tool
Given that one computer works OK, and another crashes, I would say that
you are seeing the effect of something else, not the cause. If passing
a control ref via terminals was fatal, it would be fatal all the time.
You have some other sort of issue, perhaps timing of the different
machines triggers the bug, perhaps running out of memory, perhaps
LabVIEW is corrupted on one machine.... But I don't think changing all
your code to use globals would solve the real problem. Actually, saying that I wonder about problem of synchronisation. I know from Visual C++ that this kind of error happens if two process try to access the same control at the same time. This is typically an error changing from a computer to an other, and mutex or semaphore are the way to deal nicely with that. But does labview contains already such a securisation? If so, the global variable point on a single object and can "fell" the semaphore/mutex. But passing make a copy that will likely have two different semaphore/mutex but will point to a single control! Do someone know if I'm wrong in this idea or not?
Thanks

Similar Messages

Pass control references to subVI using Invoke Method

Hi guys,
Can I use <Control Value Set invoke method> to pass some control references to a sub VI, then use the <Run VI invoke method> to run the sub VI with the previously passed data? The control refnums are for some frontpanel controls in the Main VI.
I was able to pass other data but the refnum didn’t work.
Thanks

Hi there, There are a couple examples that use the same method. Check them here:
- Set Control Values and Trigger UI Events in Another VI
- Set Values and Properties of Controls in a SubVI
- Save and retrieve front panel control values
Alejandro | Academic Program Engineer | National Instruments

Control references as subVI input

I have a subVI which accepts control references as input. But these are optional inputs. I have code in the subVI whcih uses the refernecs. I want this code to execute only if the control refernce inputs are wired from the main VI. Is there any way I can check whether the control refernce inputs were wired in the main VI?

You can use Not a Number\Path\Refnum from the Comparison palette or you can type cast the reference to a numeric and check if it is not equal to 0. There are probably some other ways.
Try to take over the world!

Finding vi running in subpanel from a subpanel control reference?

I've poked around considerably and cannot find a way to take a control reference to a subpanel control and get the vi reference for the current vi running inside the subpanel.
I know I can save this locally inside the vi containing the subpanel (from the invoke node call to insertvi), but I'm wanting to do this externally from an app that just has references to all the controls.
Any help would be greatly appreciated.
Thanks

If I'm interpreting you correctly, you would like to find the VI reference of the subpanel VI based off one if it's control references that has been passed to some external application from the VI that contains the subpanel VI? See the attached VIs for an example if this is the case.
"VI with subpanel" passes a control reference to "SubVI" which can then get the reference to the "VI in subpanel".
I grabbed the original files from here:
http://digital.ni.com/public.nsf/allkb/0B11E4964685B49F862571430000091E?OpenDocument
Trey B
Applications Engineering
National Instruments
Message Edited by Trey B on 07-24-2007 11:30 PM
Attachments:
VI in subpanel.vi ‏27 KB
VI with subpanel.vi ‏29 KB
subVI.vi ‏8 KB

How can I duplicate a control in a subVI using the reference?

Here's what I want to do. I have a tree control in my main application. I add and delete items dynamically based on user input. If I pass my tree reference to a subVI, I can add, subtract and reorder the items in the tree and the changes are shown on the main tree. How can I duplicate the tree in the subVI? Would I simply pass the tree control in (which I'd rather not do) or is there some other way to accomplish this?
Thanks in advance for any help.
Gary

Here's my attempt. This VI uses a control reference of the old tree and generates a data structure that can be used by the "Edit Tree Items.Add Multiple Items to End" method to add contents to the new tree that should be identical to the contents of the original tree. Note that this VI only works with LabVIEW 8.0 and later, since the afore-mentioned method is not available in previous versions.
I hope this helps...also note that I saw some re-draw issues with LabVIEW 8.0, i.e. after the VI ran, I didn't see the tree displayed properly until I minimized/restored the window, or dragged another window over it. I did not see the redraw issues in LabVIEW 8.2.
-D
Darren Nattinger, CLA
LabVIEW Artisan and Nugget Penman
Attachments:
Duplicate Tree.vi ‏21 KB

Bind FPGA host reference to type definition in labVIEW 2012 crashes labVIEW

Hi,
I am using FPGA target device 5641R and labview FPGA 2012 with 5640R ver 1.7.
On the configure window of open FPGA VI reference function, choosing the dynmaic mode shows broken arrow when wired to the 5640R configuration VIs (i.e. Configure timebase, Configure ADC default, Configure ADC NCO functions). So i tried the other option which is binding the FPGA host reference to type definition and choose the control from path C:\Program Files\National Instruments\LabVIEW 2012\instr.lib\ni5640R\Configuration\NI-5640R VIs\ni5640R FPGA VI Reference.ctl. But after that when i try to save the VI on which open FPGA VI reference function is placed, labVIEW crashes. I am unable to figure out the reason. Earlier I was working with labVIEW 2011 and it was working fine there. Any suggestions would be highly appretiated.
Please see the attached images for more details.
Thanks
Attachments:
1.png ‏33 KB
2.png ‏71 KB
3.png ‏40 KB

Check out this thread. It looks like someone else ran into a similar issue and made changes that fixed their application.
http://forums.ni.com/t5/IF-RIO/correct-5640r-template-use-recommendation/td-p/1331918
Jeff B.
Applications Engineer
National Instruments

Passing a reference to a type definition to a SubVI

I have created a type definition that I would like to use across my application. This particular type definition is also the front panel control to my top level VI. I wanted to pass a reference to this control to my SubVi's so that they could dereference as needed and in very rare cases update the values on the front panel. However, as I built the application I noticed that I was breaking the control reference as I updated the type definition. This implies that they type of the reference changes as I change the type definition.
How do I go about building the reference I need or is there some other way to do this that works just as well. Even if I can't make a reference to the control that is tied to the type definition, I'm willing to pass in a variant who can house the reference as long as I can build the data type (the reference) inside my SubVis.
Solved!
Go to Solution.

Okay, so I tried all three approaches in a SubVI, here's what happened.
My approach was simply to create a Type Def control, right-click and create a Reference. Then create a control from that reference by right-clicking the output of the reference and selecting the Create Control option. I then pasted this 'cluster' reference into my SubVi, made it an input and then wired up the reference in the parent to the control in the SubVi.
Result: This breaks when you update the Type Definition.
Next, Ben's approach (or my best effort at doing what he suggested). I created a control from reference to the type def. I cut it from the parent VI and pasted it into a new type def. I then put the type def in the SubVI and set it as an input.
Result: This breaks when you update the Type Definition (but it actually takes a bit longer for the error to propogate).
Finally, Christian's solution (or my best effort). I took the type def reference and put it through a To More Generic Class guy, casting it to a Control Refnum. I put a Control Refnum on the front panel of my SubVI and wired it to a To More Specific Class guy. I created a control of the type def in the subvi, hid it, and created a reference. I wired the reference to the more specific guy and verified I was getting the right data.
Result: It works!
It's possible I just didn't understand how to make the reference type def you were referring to Ben. I would prefer a method with less verbage. I pass this refnum into a class which holds it. Since I can't replicate the type exactly prior to run time (i.e. create a control that is exactly a reference to the type definition of my front panel), I have to save the reference as a Control Refnum and cast it every time I need it (i.e. create a control from the typedef, create a reference frome the type def, etc). More verbage than optimal, but still good!
Thanks for the help.

Using "Set Control Value" to pass a reference

Hi,
every time I tried to passe a Control Reference using "Set Control Value" I have the Error 1 (invalid input parameter at invoke node). Why is it not possible to pass a control reference using the invoke node??
Thanks
Golzio

Hi,
This is possible. Trick is, the type of the control reference needs to be
the same as the input. E.g. a string control reference is a different type
as a numeric control reference (, or a control reference).
To avoid this conflic, make sure the input of the vi is a control reference
(and not a e.g. string control reference). Also make sure the to convert the
reference you pass to a control reference (using Application Control>To More
Generic Class).
Regards,
Wiebe.
"Golzio" wrote in message
news:506500000008000000C1F00000-1079395200000@exchange.ni.com...
> Hi,
> every time I tried to passe a Control Reference using "Set Control
> Value" I have the Error 1 (invalid input parameter at invoke node).
> Why is it not possible to pass a control re
ference using the invoke
> node??
>
> Thanks
> Golzio

Control references and XY graph

hi there,
I was wondering if somebody can help me with passing data to a " XY graph
" not waveform graph [ in a main VI ]
from a sub vI using the concept of a control reference..
p.s: I dont intend to flatten data .
It works fine with waveform graph but there is nothing to show ( even
examples ) me how to do it with XY
graph.
thanks.
ananth

In the example, why is the control reference outside the case statement, since the graph
is only updated when plot=true the ref belongs inside or did I miss something?.
ananth wrote:
> thanks
> and you said it right. that was the problem.
>
> "John Lum" wrote:
> >>>I was wondering if somebody can help me>>with passing data to a " XY
> graph" not>>waveform graph [ in a main VI ] >>from a sub vI using the concept
> of a>>control reference.. >>I don't see any problems here using LabVIEW 6.0,
> and I'm wondering if you're>having trouble with a Variant input or something.>>Here's
> an example of a subVI that spits data into a main VI's XY Graph by>way of
> a control reference>ftp://ftp.ni.com/incoming/xy.zip>>Regards,>John Lum>Na
tional
> Instruments

Control references vs. global variables

I guess my question centers on the appropriate application of control references.
I am writing a complex program that has a state machine at the top level, and, for one frame of the state machine, a while loop containing a couple subVIs, each of which contains many subVIs. The lower-level subVIs are affected by buttons on the top-level VI. Information from the lower-level VIs must be shown on the top-level front panel within the loop. My question is: what is the best way to do this?
(I have a previous version of the program that I wrote that keeps just about everything on the top level so that I can update the front panel, but this is not at all modular.
In addition, I considered breaking things up into more than on
e front panel, but this doesn't seem to be a good option for this section of this program.)
Last week I read about control references, and decided that this could be the way to deal with this issue. I have not worked with them before, so I want to know: Are control references an appropriate solution for this issue? Is it good programming practice to use them, especially to update data on charts and graphs? How do they compare programming-wise and efficiency-wise to global variables?
Global variables are another solution, I think, but I would have way too many variables to update. I think the advantage with global variables is that one could just insert a global variable in a subVI and not have to wire it up through the different subVI levels, which one would have to do (I think) with control references.
Can you offer any advice?
Thanks!

Paul,
The actual implementation of the solution is up to you. This is indeed a complex question.
I would offer the following advice:
On globals:
Try to avoid them. I try to restrict the use of globals to unidirectional. If you have ever dealt with a race condition, you will know why. Mistakes are often made with globals, and they are quite apt to become the biggest source of bugs in a program, especially in one as large and/or complex as your appears to be. If you must use globals, try using a shift register, or LabVIEW 2 style global instead. Basically, you use an unitialized shift register with two (or more) cases: Read and Write. This prevents race conditions, but only if the VI is non reentrant. However, implementation is still difficult.
Control References:
I also have read and heard about control references. I have had much use for them, for controlling the appearance of controls and indicators (and decoratiopns too, I guess...). However, I would caution you on using them to pass data around. This violates dataflow in a big way, as you are passing around pointers, instead of data. I believe this is difficult to implement, and even more difficult to keep straight. I personally recommend using them only for attributes of FP components, not for passing data.
So, what do I believe is the most elegant solution? I think a data server is your best bet. This is close to a LabVIEW 2 style global, but a little more active. Simply write all of your data into a subVI in any manner, a queue, a FIFO, LIFO, etc. Then, retrieve the data as desired. Buffering, queuing, etc are all handled by the data storage and retrieval subVI. It becomes sort of a small active database. The two sides (storage and retrieval) are independent of each other, and the code is all handled in the function. A basic version is a LIFO, Last In First Out, wherein the data is overwritten constantly. The data is then read by the reading VI, the front panel VI in your case, at any time, and the data is always the latest. You can add complexity as you need, such as making it a FIFO. This is done by simply writing the data to an array, then reading back the oldest value (by reversing the array and reading index 0.)
I believe this is an elegant solution to your problem. It does maintain dataflow, except that time is taken out of the equation, depending on how you look at it. It simplifies your program because you only need to do three things. Write the data handler, then drop in the function into the VI that writes, and the one that reads. It is also flexible in handling the data.
Good luck, and let us all know how you do.

Propert nodes using references in subVIs

Does passing a reference to a control in the master VI to a subVI for use of changing the control via property nodes cause the subVI front panel to load in memory? I would think that it would not since the property node does not refer to a control on the front panel of the subVI.

hi there
"..For example, this can occur if the subVI uses Property Nodes, because Property Nodes manipulate state information for front panel controls..."
i think that's true for the front panel that holds the control from which you call properties. the sub-VI calls a property of the control on the Top-Level, NOT of the reference control on the FP of the Sub-VI. rename the executable i posted in the zipfile to *.llb and open it in explorer. then open the Sub-VI and you'll see that the FP is not part of the executable anymore. so it can't be loaded at all.
if you call a property of the reference control you can't remove the frontpanel in the VI-settings any more (see attachment), because now you refer to a control of the Sub-VIs FP.
Best regards
chris
CL(A)Dly bending G-Force with LabVIEW
famous last words: "oh my god, it is full of stars!"
Attachments:
Properties.JPG ‏18 KB

Data acquisition with control references

I'm a new LabView user and I would like to acquire data in a subVI and display that data in the main VI. I think that I need to use control references and refnums, but I just haven't been able to figure it out. I would GREATLY appreciate any help I could get.
Thank you!

From your description I would guess that the "subVI" has a loop in it that repeatedly reads the FP hardware, and the indicator is inside the loop. Right?
The thing to do is move a lot of the logic in the subVI up to the Main VI--or add the Main's added logic to the subVI, whichever is easier. In the first case, the subVI would go away, in the second, the subVI would become the Main VI.
If you're confused, post your code in V6.0 format and I'll show you what I mean.
Mike...
Certified Professional Instructor
Certified LabVIEW Architect
LabVIEW Champion
"... after all, He's not a tame lion..."
Be thinking ahead and mark your dance card for NI Week 2015 now: TS 6139 - Object Oriented First Steps

Do I need to set something when using Dynamic VIs to pass control values to an executable VI

I am using VI server to pass control information from one VI to another.
In the development system this works fine.
How ever once I build the VI's into an executable the values from one of the VIs does not get passed.
I use the same method in three different applications, 2 of the applications work fine, but one does not.
The only thing I can think of is that there is something that needs to be set that I did (without realizing) in the first two but not in the third.
All the Applications run fine.
The problem that occurs is in the values passed. The same value gets passed everytime this turns out to be what ever the default was prior to running application builder.
I a
m currently using 6.02.

Kandrew wrote:
> I am using VI server to pass control information from one VI to
> another.
> In the development system this works fine.
> How ever once I build the VI's into an executable the values from one
> of the VIs does not get passed.
>
> I use the same method in three different applications, 2 of the
> applications work fine, but one does not.
Are you using Call by Reference or Set Control Value method? The second
absolutely requires the Front Panel to be present to work properly. The
LabVIEW application builder wants to remove the Front Panel by default
if the VI hasn't been configured to show its front panel when called or
doesn't have at least one Control Property Node in its diagram.
Rolf Kalbermatter
Rolf Kalbermatter
CIT Engineering Netherlands
a division of Test & Measurement Solutions

How do you pass vi references from one event to another

I have a vi which gets vi references (thereby loading the vi's into memory) for all the vi's in a given directory when a user clicks a button on the front panel. To do this I use an event structure. My question is whether it is possible to have another event (user button on the front panel) which unloads the vi's from memory. I have tried passing the vi references that are initially generated to the close reference function but whenever I do I get a 'vi reference invalid' error. Does this have to do with trying to pass the vi references between one event and another? If I use a local variable simply pass a reference to another indicator and then probe it, the originally-generated refnum and the local vari
able refnum match up. However once I try to wire that same indicator to the close reference function I get the 'vi reference invalid' error. Is there a different/better way to unload the vi's from memory based on a user button click? Any suggestions would be welcome.
Jason
Attachments:
Load_Directory_of_vi's.vi ‏57 KB

Several problems with your code:
1... Bad idea to use lights as buttons. Yes it can be done, but it's not "natural".
2... If you've gotta do that, set their mechanical action to "LATCH WHEN RELEASED"
3... Because of #2, you are getting TWO copies of every array when you click the LOAD VIs light (er... button).
4... No need for the conversion from path to string and back - use BUILD PATH to append each file name to he folder path.
5... Set the BROWSE OPTIONS on your PATH control to EXISTING DIRECTORY to allow browsing of directories, not files.
6... Your code doesn't care whether the file is a .VI file, or a .ZIP file, or a .TXT file, or what. Use the PATTERN input on the LIST function to discriminate.
7... Your code is only storing the latest refer
ence, not the array of references.
8... An ERROR DIALOG on the OPEN REFERENCE function will tell you that you're getting an error. Why? You are asking to prepare a non-reentrant VI for reentrant execution (why use options = 8?)
9... Because of #8, the latest VI reference is invalid.
Steve Bird
Culverson Software - Elegant software that is a pleasure to use.
Culverson.com
Blog for (mostly LabVIEW) programmers: Tips And Tricks

Help!: Control reference seamingly "lost" in run-time execution mode

Hi!
The Facts:
LabView 6.1 PC under NT.
I've been using "Vi loader" technique since a few month s to distribute a LabView application on severals PCs without having to re-compile it each time. My application uses more than 500 VIs so I can't build it directly. The directories/Vis of the application are simply copied on the target PC and run through the Vi loader technique instead of using the development environnement.
The problem:
Since the last release of the my application, differences between the application running in development mode or run-time mode have appeared:
One VI reading a .ini file does not act the same way if runned in the developpment environnment or
runned in the run-time environnment. This VI uses control-references from its front-panel and passes them to sub vis. In run-time execution those references seems to be perverted: the sub-vis get them but can't access their properties like Label Name, Values,...
All works perfectly fine if the VI is runned in the environnment developpment.
Moreover the same sub-vis called with other control references in other VIs work fine.
Question:
Has anyone seen any behavioral difference between run-time execution and development environnement execution?
Are there any differences in the linkage process between those 2 execution ways?
Is there any labview Feature that would automaticaly "de-allocate" references at run time and would do so "too early"?
Is there any know problem with poly-morphique VIS in run-time execution mode.
That's all, any idea, lead, wellcome!

Hi Andrew!
I've allready had a look at the "Problem with VI Loader technique". It only deals with top vis not working (ie broken) when called from loader in Run-Time mode because of ill declared vi.lib path.
It's "unfortunately" not my problem: My VI is not broken, it's kind'a working, but not as it does in development environment execution mode.
If NI people are reading this, I would like to send them the VI and it sub-VIs to understand if something has been perverted .
The problem is seen on all three target PCs.
Moreover, a new one has appeared: in run-time mode, the standard "file dialog" vi called to prompt the user for a file with a given extension pattern sends back the file name with the extension "double dotted" (exemple: anything..data
instead of anything.data).
About the first problem, does any know why a Ctrl Refnum would loose its parent information (name, value...) in run-time execution mode?
Bye!

Passing control reference to subVI crashes labview

Similar Messages

Maybe you are looking for