Reference a property node in a seperate VI

I have created a VI that calls on another VI, but before it does, I want to check the "connections to clients" property node in VI being called. Is there a way to get information from the second VI's property node into the first VI?
-Tek

Tek wrote:
I have created a VI that calls on another VI, but before it does, I want to check the "connections to clients" property node in VI being called. Is there a way to get information from the second VI's property node into the first VI?
-Tek
Hi Tek,
I didn't find the "connections to clients" property you mention, but here's an example of how to retrieve properties from a VI without actuallly calling it.
Hope it helps!
Cheers
When they give imbeciles handicap-parking, I won't have so far to walk!
Attachments:
Props.llb ‏36 KB

Similar Messages

Is there a way to reference the property node value of a control in another VI?

Let's say that I have a situation like the one shown in the attached image.
I have an interlock system which is basically a bunch of booleans
If for example the "RF Enable" button in the "interlock VI" is true, then I should be able to flick the ON switch in my other VI (in the back), but if the value is FALSE, then it shouldn't allow it.
In other words, how do I check the value of a control across 2 separate VIs (running simultaneously)?
Thanks!!
Attachments:
sample.jpg ‏295 KB

Is one VI launched by the other, or are they launched independently? If it's the former then you just need to pass the control reference to the subVI via terminal node. If it's the latter there are a variety of ways to handle this:
Use a global variable - somewhat "sloppy" as it requires a global variable, and can lead to race conditions. In the "Interlock" VI you just set the value of the global variable when you change the value of the Boolean. In the other you're just reading it.
Action Engine - Ben wrote a Community Nugget a while back. Similar concept to a global variable.
Queue - The "Interlock" VI simply pops an element onto the queue with the value. The other VI just monitors the queue for a new element. It just needs to have something like a shift register to keep track of the last state.
Use the VI Server to access the controls of the "Interlock" VI. You can do this by accessing the "Interlock" VI's pane and get the control references. With the control reference you just need to get the value with a property node.
... (I'll let others chime in)

What are the alternatives to updating indicators using property nodes?

Hello,
I'm building a VI which needs to update several controls/indicators at multiple points throughout its execution. It also needs to be able to accept new values from the controls at any given time.
The problem with this is that all of these controls and indicators are on the front panel of another VI which is calling my VI. The current version of my program updates all of these controls and indicators using references and property nodes (each indicator/control that needs to be used has its own reference control on my VI, and these references are then sent into property nodes), which naturally makes it slow.
At the moment I'm considering rebuilding my VI in such a way that the main one is able to retrieve the data without using references, but this will be not only very time-consuming but also difficult and possibly even impossible without my code turning into a massive disorganized pile (especially since the lab computer is slow enough, and the main VI large enough, that pressing the 'clean/reorganize block diagram' button causes a crash).
Any alternatives to this? Queues?
Solved!
Go to Solution.

This (my Event nugget) is the best general solution I came up so far.
Felix
www.aescusoft.de
My latest community nugget on producer/consumer design
My current blog: A journey through uml

VI Reference Property Node inside sub-vi

Hey Folks,
I was always curious about why this is:
If I open a vi-reference in one vi, and pass the reference to a sub-vi, I can put a property node in the sub-vi and get all properties just fine - as long as I am in debug mode. When I compile to an executable this problem has its own error message and everything. So why does debug mode not throw an error too? I'm just trying to deduce what the heck is the difference.
Check my painstakingly time-consuming example.
-Devin
I got 99 problems but 8.6 ain't one.
Attachments:
OpenMyReference.zip ‏42 KB

When I discovered this issue I was coding an "About" modal screen that a user could select from a run-time menu. This was supposed to work just like Labview's "Help->About Labview" screen, giving program description and version information. So I tried to simply link in the revision from my vi's proerties because that would automatically keep a revision count and I didn't care what the format was as long as I could get a number. I just wanted an easy way to check the revision, and its easy to give someone simple instructions to check the "about" screen. Is there an easy way for a user to check the revision if all I do is put it in the application builder? User-friendliness is key, because for me to support the application I will need to have them tell me the revision they are using over the phone or in an email.
Will it be possible to create this screen in 8? If I just do it in the application builder, is there any way to link to it and build an "About" screen? I don't really care what format. It could be revision 728 as long as a user can get to it in a simple way. Otherwise I will have to just build a screen with plain text on it and edit the text by hand every time I build an application. Isn't there a more elegant way to do it?
Message Edited by billings11 on 10-20-2005 11:28 AM
-Devin
I got 99 problems but 8.6 ain't one.

On cRIO-9033, property node: Owning VI Reference is Invalid

I am starring for the first time to work with a UI on cRIO-9033. The code I am trying to adapt to work on the RT is working on Windows just fine. But when I put it on the RT it throws errors. I looked through the code and I kept getting error 1026 Reference is No Longer Valid. I made a very simple code to try and run (as linked below), and it throws the same error.
When I probe the error coming out of the VI Property Node: Panel, it gives me an Invalid Reference Error. Nothing closed the reference and the VI is obviously still running and in memory since this is the VI. I'm not sure what is wrong. Could it be that I am running it from development environment? Or is this a quirk with programming in Linux?
Attachments:
Simpler UI.vi ‏16 KB

I found another bug. You just to follow my instructions if you don't mind
Open the attached code
Run it. It should work fine
Move anything on the front panel and save it
Run it. You should get errors.
I'm not sure what is wrong but I can reproduce the problem over here.
BEFORE IMAGE
AFTER IMAGE
notice the I moved error out 2
Actually on my more complicated example the property node giving the panel references passes invalid references all the time. Not just when I resave it.
Attachments:
Simpler UI.vi ‏19 KB

I get error 1055 "Object Reference Is Invalid" when I try to write to a property node

Hi, I'm trying to get these results to be displayed in two tables now, where I originally had them being displayed in just one. Outside of the attached vi, I can just copy the value property from one table to the other after this vi has run, and the table values appear properly. The problem with that is, that any table property I assign (changing background colours to be exact), is not considered part of the value property, and thus isn't copied when I copy the value from one to the other.
The thing I can't understand is that the second set of property nodes (at the bottom), give me the "Object Reference Is Invalid" when I added them. I've tried everything I can think of, but can see no logical reason why I get that error for those two, while I don't get the error for the top two (not wired to constants).
Any help on this would be much appreciated. Thanks
Geoff
Attachments:
Table Display Testing.vi ‏396 KB

The logical reason that you're getting that error is that you are not passing in a reference to Table In Two. The control is not wired to the connector pane so you are not getting a reference from the calling VI.

Error 1055 occurred at Property Node : Object reference is invalid. This Error occurs only in built application

I am using a WaveformChart to display multiple traces of data, the number of traces is variable, I use property nodes to set the number of traces and whether the digital display is visible or not, as more data is available the number of traces is increased and the digital displays are made visible. Within the Labview design environment everything works well. However when running the built application if two or more traces are to be charted I see error 1055. I suspect it is related to making the digital display visible on two or more waveform traces. See VI attached.
Why is this error happening ?
Thanks.
Single trace
Two traces
Solved!
Go to Solution.
Attachments:
Setup Plot Style.vi ‏29 KB

WF Charts only create their plots at development time.
If you attempt to access a plot that was never there you get that error.
To work-around this detail, simply size the legend for more plots than you ever expect to use at development time so that the plots are created and availabe when you do the build.
Ben
Ben Rayner
I am currently active on.. MainStream Preppers
Rayner's Ridge is under construction

Class conflict when programmatically editing graphs with property node

I am trying to programmatically move the cursors on a graph. I want the cursor to look the same on 2 different graphs so I made a subVI. The code works correctly when I have seperate property nodes, but when I try to use the subVI, I get a class conflict -
"You have connected a refnum of one type to a refnum of another type and both types are members of some class hierarchy, but there is neither a simple up cast nor type cast between the two classes."
I am not sure how to fix this. The graph that works is of a waveform, and the graph that doesn't is the output of the FFT Power Spectrum VI. Is the problem that the inputs are different? Or is there some kind of resource conflict when using property nodes in subVIs?

A shot in the dark here. But maybe if you make the subVI's input reference of type GraphChart it would work.
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines

Error 1055 occurred at Property node

Generating the error:
"Error 1055 occurred at Property Node in ... Possible reason(s): LabVIEW object reference is invalid."
when I try to wire the IMAGE OUT output from the IMAQdx Snap vi to the value property of an externally referenced image display control.
To describe in more detail, I have a parent vi with an image display control and a child vi which has a control refnum linked to the parent vi display. In the child vi I create a value property for the refnum and try to write images to it, essentially to drive the parent display from the child vi.
The technique works elsewhere, though I can't think of what I could have done differently to generate this error?

Hi Mike - looks like I may not need to. I've been working away at this and have found the original cause and something else a bit weird...
I deleted the objects from the sub-VI that was giving me errors, then cut and pasted the objects (image display refnum and value property) from a VI that was working and this solved the problem. So you might think that the issue was just some obscure configuration item, or I'd used the wrong type in my reference or something.
I found the display reference in the parent VI was not even wired to the sub VI - duh! Error between keyboard and chair. So at least the original error message made sense, but I have no idea why it actually worked after pasting in the new objects. Are these references using some sort of auto-magic? Who knows. Safer to wire up my sub-VI's properly methinks.
Sorry for wasting forum time on this one.

How do I use the Index Values property node with a multidimensional array.

I am using a 2D array to store operator inputs on my front panel. I only want to display one element to the operator at a time. I am trying to use the Index Values property node to change the displayed element. However, I can only get the Rows index to work. How do I direct the Columns index as well? The help says to use one per dimension. I need clarification on what this is talking about. I've tried adding a second element to the property node, 2 seperate property nodes, and diferent wiring techniques. (series, parallel)

If you only wire up one of the inputs (col or row) what you get out is a 1D array of either the column or row. If you wire controls to both, then you will get one element out of the array. Getting a single element in a 2D array requires you to specify both a row and column.
Message Edited by Dennis Knutson on 02-08-2007 08:34 AM
Attachments:
Index 2D Array.PNG ‏2 KB

How can I change the precision of a numeric array indicator using property nodes ?

I want to change the precision of a numeric array indicator programatically using property nodes. I tried to see all the array properties but I couldn't find it. URGENT !!!

If you want to change the precision of an element in an array you must first get the reference to the array element. Then raise the reference to the more specific class of a digital numeric. Use a property node connected to that reference to set the precision. See the attached vi for an example.
Brian
Attachments:
ArrayElementPrec.vi ‏27 KB

How to create a specific property node w/ VI script

I am writing a VI script to work with some multi column listboxes. I need it to create a property node that gets a reference to the ItemNames field. I see that I can create a property node via the invoke node method Create.Property Node, but how to get the ItemNames field specifically I so far can't figure out. Can anyone help?
To be clear, I am writing code that looks like this:
...and when I run the script, I want it to produce this:
Right now it produces the MCL as expected, via the New VI Object node...but I don't know how to get the ItemNames created automatcially. I thought it might be in the PropItems array but so far no luck.
thank you
Solved!
Go to Solution.

The output of "PropItems[]" will be a one element array. Index that element and wire the reference to an invoke node. Select the method "SetProperty".

Property Node in VI throws Error 7 in LV 7.1 but runs OK in LV80 and LV86

Hi everybody
I build a custom IVI instrument driver and using the LV tool <Generate VI Interface from Instrumnet CVI Driver> I was able to get a LV wrapper for each driver method. From LV86 I saved first in LV80 and from LV80 I saved as LV71. I have all these LV versions on installed on my PC.
I have no trouble in using these LV wrappers in any of these LV versions as they work OK.
Now my IVI driver has also Properties that the Import Driver Tool does not convert as a wrapper and for that reason I had to create a Property Node Warpper myself and saved in the same LLB under LV/instr.lib folder.
Once I have all these method wrappers and the property node wrappers I made a small VI
1. Initialize IVI With Options on a TCPIP instrument
2. Set-Get an IVI Timeout property
3 Close IVI driver on TCPIP instrument.
Good part is that in LV 86 and in LV 80 the VI is running fine when I use these LV version wrappers from their coresponding instr.lib folder.
As soon as I am going to use the LV 71 wrappers in LV 71 I could create the same small VI to Set/Get Timeout and the VI look OK nothing is broken but when I run it the Initialization is OK but as soon as is reaching the Timeout Set Property Node gets out an Error Code 7.
To run this VI the user need to install the jdCMR IVI driver then add the LV71 jdCMR wrappers inside LV71/instr.lib and then he may build any VI using these LV warppers.
The only problem is that the Property Node get out an Error Code 7 and the same error code get out from Property Node if I am picking the Property Node from VISA Advanced Pallette, connect this node to jdCMR driver, set Timeout property inside the node and after connecting the input and output references plus the input and output error to Initialize and Close LV wrappers I still get this error at running time.
The same LV 71 VI if I open in LV80 or in LV 86 runs without any problem?
Does anybody knows why LV 71 is not working the same way as LV80 and LV86 with respect to Property Node?
Btw When I save my VI from LV 80 to LV 71 I get this warning...
IVI Error Message Builder.vi
    Cannot save VI from VI.LIB to previous version.
Merge Errors.vi
    Cannot save VI from VI.LIB to previous version.
Thanks
Sorin

Hi
For further testing of the IVI driver Property Node bug with LabVIEW 7.1 IVI drivers I download and installed two different IVI drivers from two very known instrument companies, Rodhe-Schwarz and Agilent Technologies.
I have to mention that both these companies releasead their IVI NI LabVIEW 7.1 drivers under NI Instrument Driver Network and ready to be installed and used by any customer of these two instruments.
The bug is present only in LabVIEW 7.1 version as if I take the same VI that breaks in LabVIEW 7.1 I could run it without any problem in LabVIEW 8.0 or LabVIEW 8.6 versions.
Anybody could test this bug for these two NI released IVI drivers in simulation in LabVIEW 7.1 by following these links below.
Agilent ag81150ni IVI Driver for LabVIEW 7.1 install from here. Run in simulation only by setting Simulate=1
http://sine.ni.com/apps/utf8/niid_web_display.download_page?p_id_guid=55798957B1A633BDE0440003BA7CCD...
   Rodhe Schwarz rsngpt IVI Driver for LabVIEW 7.1 install from here. Run in simulation only by setting Simulate=1
http://sine.ni.com/apps/utf8/niid_web_display.download_page?p_id_guid=E3B19B3E91D6659CE034080020E748...
After installation complete close LabVIEW 7.1 if was open, then restart LabVIEW 7.1 and now you may see under the LabVIEW Instrument Driver Palette two new IVI drivers ready to be used as LabVIEW 7.1 wrappers.
Open a new blank VI and from Instrument Driver Palette use two well known Vis that are Initialize With Options.vi and Close.vi add them on your blank VI block diagram and connect thm together. Accept all default parameters except Simulate that must be Simulate=1.
Both Vis run OK in simulation mode without errors. Now pick a Property Node from VISA Advanced Panel and squeeze this between the Initialize With Options VI and Close VI and make the instrument reference in-out and error in-out connections.
Now run these two simple Vis in simulation
I run Rodhe Schwarz IVI driver and Property Node passes OK until the end
I run Agilent IVI driver but Property Node is getting out Error Code 7 that is the same as my own driver error.
Both these IVI drivers are under NI Instrument Driver Networks and have been built and integrated as native NI IVI instrument drivers.
Question is why they behave so different with respect to Property Node from the VISA Advanced Panel?
I attached the screen shots as PNG files that show clearly the difference of VISA Property Node behaviour when used under the same circumstances.
Thanks  Sorin
Attachments:
ScreenTestShots.zip ‏152 KB

Property nodes to items in cluster are FRAGILE

This issue has bugged me for a long time . I just got bit again and I wonder if anyone else has a workaround.
I just checked and LV 2009 has it too.
Create a custom control of a cluster with three elements named A, B, C (numeric controls, booleans, whatever, it doesn't matter).
Make it a TYPE DEF (non-strict) and save it.
Put an instance of it on a new VI panel.
Create a PROPERTY NODE for item B and set it to DISABLED property.
Wire a constant to that property node.
Now, if you run the VI, it sets the DISABLED property of item B to the value of the constant. Fine.
Now go to the TYPEDEF, and add another item, called A2 to the cluster.
Re-arrange the cluster order so that it's A, A2, B, C, and save the type def.
Look at your diagram. The property node is no longer linked to B, it's now linked to A2.
Apparently, LV uses the cluster order internally to keep track of the links. So now I'm linked to A2, not B.
If A2 was a different type of object from B, then you MIGHT get lucky and the diagram breaks. At least then, you can see the fact that it changed.
But almost everything has a DISABLED and a VISIBLE property, if that's the one you're using, then you won't notice that it was changed behind your back.
I have taken to adding a free label with the name of the expected control (in parentheses) next to the property node, along with the true label. So if I see a discrepancy between the true label and the free label, I can recognize such a case.
But that's only if I remember that this crap happens.
Anybody got any better ideas? How can I prevent, or at least recognize, such an unwanted change?
Bonus question: the same thing happens with events, for the same reason (I suppose). If I tied an event to item B, that event switches to item A2 behind my back.
Steve Bird
Culverson Software - Elegant software that is a pleasure to use.
Culverson.com
Blog for (mostly LabVIEW) programmers: Tips And Tricks

CoastalMaineBird wrote:
This issue has bugged me for a long time . I just got bit again and I wonder if anyone else has a workaround.
I just checked and LV 2009 has it too.
Create a custom control of a cluster with three elements named A, B, C (numeric controls, booleans, whatever, it doesn't matter).
Make it a TYPE DEF (non-strict) and save it.
Put an instance of it on a new VI panel.
Create a PROPERTY NODE for item B and set it to DISABLED property.
Wire a constant to that property node.
Now, if you run the VI, it sets the DISABLED property of item B to the value of the constant. Fine.
Now go to the TYPEDEF, and add another item, called A2 to the cluster.
Re-arrange the cluster order so that it's A, A2, B, C, and save the type def.
Look at your diagram. The property node is no longer linked to B, it's now linked to A2.
Apparently, LV uses the cluster order internally to keep track of the links. So now I'm linked to A2, not B.
If A2 was a different type of object from B, then you MIGHT get lucky and the diagram breaks. At least then, you can see the fact that it changed.
But almost everything has a DISABLED and a VISIBLE property, if that's the one you're using, then you won't notice that it was changed behind your back.
I have taken to adding a free label with the name of the expected control (in parentheses) next to the property node, along with the true label. So if I see a discrepancy between the true label and the free label, I can recognize such a case.
But that's only if I remember that this crap happens.
Anybody got any better ideas? How can I prevent, or at least recognize, such an unwanted change?
Bonus question: the same thing happens with events, for the same reason (I suppose). If I tied an event to item B, that event switches to item A2 behind my back.
For the disabled property inside of cluster whos definition hcanges... we are screuued.
For the events your idea to include the text name, is the same technique that Jim Kring shared with us when he discovered the same thing can happen with dynamic event references. I belive that was CAR'd.
No solutions so no bonus points.
Ben
Ben Rayner
I am currently active on.. MainStream Preppers
Rayner's Ridge is under construction

Use of multiple property nodes for GUI manipulation

I have a LabVIEW 6.0.2 application where I'm using 14 different property nodes in the main loop. All of these have to do with GUI - hiding buttons when "X" isn't pressed, disabling and greying out controls if <0, popping one button on top of another depending on the mode of operation, etc, etc. While this works fine, the program is getting slow. I've noticed that using the old 2-D buttons works faster - things update faster and redraw quicker. However, more to the point, I once read that if you have to use a lot of Property Nodes like this, that you should bundle them into a sub-vi, thus replacing what would be Property Nodes with references. How does that make it faster?
Richard

Not sure if bundling them into a sub-vi by itself would make it faster. The nodes in the sub-vi would still have to access the user interface thread, and that's where the slow down comes from.
When I use any property node, I put it in a case structure and only write to it when needed. You just need to be able to detect when the value being written is changed from last loop iteration. It's useless to constantly rewrite the same value (doesn't have to be the "value" property) to the node.
Bundle them into a sub-vi and put the change detector, case structure and nodes in the sub-vi, this should help speed things up a bit. Assuming of course that the nodes are the slowdown. It may also help clean up the diagram a bit.
Ed
Ed Dickens - Certified LabVIEW Architect - DISTek Integration, Inc. - NI Certified Alliance Partner
Using the Abort button to stop your VI is like using a tree to stop your car. It works, but there may be consequences.

Reference a property node in a seperate VI

Similar Messages

Maybe you are looking for