Property node broken lvoop

This only started happening recently, no code changes had been implemented leading into this issue.
When I start my program it will show a broken arrow, after digging to the cause I find that the property node for a few of my objects (I'm utilizing the LabView object oriented features) are broken. Please see image below...
When I click on one of the broken property nodes it shows that all the properties are still available (see below)
If I then select a different property then what is currently programmed and then switch it back the property nodes (all of them in the VI) become fixed and the VI functions fine (see below). However, even if I save the VI and project which contains it, the next time that I open this VI from scratch (completely exit the project and open again) the problem comes back and I have to repeat the process. Also, it only appears that this behavior is occuring in one VI in my project even though I use property nodes throughout on the same and other objects.
Thanks for any help you can give in advance,
Randy
PS I'm running on Windows 7 with LV2010SP1.

Hi there,
I got the same problem as Redrabbit reported. I am also running Windows 7 (32 Bit) and LabVIEW 2010 SP1.
To get my property nodes back to work, I only place a new object on the block diagram if the described situation occurs. This object could be anything...a simple add function or something else. Immediately after that, the property nodes get back in a normal state and I delete my add.
Not the best way to do it, but better than nothing.
The problem is not reproducable on my site...it occurs randomly.
Because of further problems with the property nodes on classes (heavy crashes without message) I replaced them in most cases with the accessor VIs. This seem to work more stable but is not that cool for the coding style. I'd like to use the property nodes, but I have no time for searching the crashing error.
I read a thread on Lava.org about problems with the oop property nodes, but that was already 2010. Does anyone know if the issue is fixed in 2011?
Here's the link to the lava-thread: Lava-Forum
Thanks
gibbi

Similar Messages

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

Why the VI starts breaking when I enter property nodes?

Hi,
I'm a student in engeneering and need to do a work in labview. It's a Signal generator with in-built osciloscope.
The VI was working fine ultil I add the property nodes to change wavegraph scales and the VI start breaking with them.
Can anyone see my VI and tell me why does it happen?
I send the VI below.
Best regards
Ricardo Ferreira
Solved!
Go to Solution.
Attachments:
PROJECTO_FINAL.vi ‏212 KB

The VI is not broken and can run.
However, your axes are set to auto scale so the property nodes for the axes and auto scale are constantly fighting each other.
LabVIEW Champion . Do more with less code and in less time .

Using LV Class Property Nodes in In-place Element structure causes the code to halt

I have some code written in LV RT 2010 that uses property nodes from a LVOOP class that I created. I am using access the property node from inside an in-place element structure. When the code reaches the property node, LabVIEW stops running. (as if the abort button was pressed). I verified this behaviour using highlight execution. When I remove the in-place structure code runs fine.
Is this is know bug in LabVIEW? Is there a CAR to resolve this created for a future release?

Bob,
I tried to reproduce the behavior you're seeing by recreating the Trigger and Trigger List classes, but I have not been able to reproduce it. Please take a look at my version of the project in the attached zip file. Take a look at Test.vi, and feel free to modify and repost it to show me how to make the problem occur. I would like to file a CAR to make sure we get the problem fixed, but I will need to be able to reliably reproduce it first.
On a similar note, you can get much better performance out of the Process Triggers VI by preallocating the list array, instead of using build array in a loop. Take a look at Process Triggers2.vi in my project. You can run Benchmark.vi to see the performance difference between the two different approaches.
Chris M
Attachments:
triggerlist test.zip ‏165 KB

IVI-COM Vi's or property nodes?

I'm fairly new to IVI-COM instrument drivers and have up until now been using the supplied IVI-COM Vi's for the instrument I'm doing a driver for. However I'm finding that more and more it's making sense to just use a property node to set things such as Start Frequency etc so I'm thinking I might just use them for everything from now on.
All I really want to know is are there any major issues with doing this - and is it something is recommended to be done - just really want reassurance that if I take the route of using property nodes I won't get bitten on the arse by something that I don't know about.
Any thoughts happily received,
David Clark
CLA | CTA
CLA Design Ltd
Hampshire, England

Hi David,
I'm guessing that you've got a bunch of LabVIEW vi's from the vendor - that are basically wrappered IVI-COM calls? (If you can tell me where to download the driver from I can look in more detail). The low level IVI-COM calls will just use ActiveX (so property nodes and invoke nodes) to access the COM object.
Whether you use the wrappered vi's or the lower level calls is up to you, it will depend on the level of flexibility that you require. For some configuration settings for the instrument there might not be a ready built vi - so you may have to use the lower level calls to acheive it. (A bit like the usual plug and play instrument drivers, versus low level calls directly using VISA - which may or may not give you an idea - depending on whether you've used them!).
Take a look at the following tutorial which might give you some more pointers:
http://zone.ni.com/devzone/cda/tut/p/id/4505
I guess one point to bear in mind is that the vendor can at any time change the ActiveX methods and properties with a new release of the driver (a bit like Microsoft have done in the past with things like media player and office) which may leave code you've generated with broken wires, if you are using their wrappered vi's then its possible that they'll keep the wrapper and change whats inside so that its seamless to the end user. - (Its also possible that they could update the automation servers version number which would result in a non working vi - but may not result in broken wires, working with the vendors LabVIEW API should solve these issues - since they will have re-linked them specifically to each version)
Another factor that should help you make up your mind is how well documented each of the options are - they may have put more time into the friendly end user vi's than they have to the API?
But if you're generating your own driver, then it will probably be more useful to you to strip away some of the abstraction to get more efficient results.
I hope this helps - perhaps other members of the NI community can give you their experiences
Hannah
NIUK & Ireland

Is there a performance loss or gain when enabling 'make available through property nodes' in class accessor?

As the topic states, I'm pondering if there is a performance hit (or gain?) by making class accessor available through property node?
Specifically, I wonder if the 'class accessor property node' is somehow different than 'normal' property nodes, which I tend to avoid as best I can due to how they often involve the GUI thread and are often detrimental to performance.
And since the follow up question to any answer would be to ask if including error handling terminals changes the answer?
-People who write LVOOP on a semi-regular basis or more, is there a concensus on when/if you use the property node option? Is it preferred as a default almost? Is it affected by whether the accessor is dynamic or static?
Thanks!
QFang
QFang
CLD LabVIEW 7.1 to 2013

As far as I know, there is no difference between a subVI call and a property call and they should behave identically behind the scenes. There shouldn't be a forced call in the UI thread, because these don't deal with UI elements. It's simply a different syntax, so it should be the same for DD. I have seen some complaints about performance issues and/or bugs in earlier versions, but I don't remember if there was anything concrete. You can search on LAVA.
Likewise, I don't think the error I/O itself causes delays, but both the serialization of the calls and having case structures acting on those errors can. AQ had some posts on that and he dislikes both. Personally, I tend to like the readability, particularly for serialized calls. Note that some people don't like accessors (at least public ones) as a concept, suggesting that having writers for individual fields leads to all kinds of troubles, and that it's generally better to have specific functions with the relevant inputs.
Try to take over the world!

What is difference between local variable and property node ?

What is difference between local variable and property node ?
" 一天到晚游泳的鱼"
[email protected]
我的个人网站：LabVIEW——北方客栈 http://www.labview365.com
欢迎加入《LabVIEW编程思想》组——http://decibel.ni.com/content/groups/thinking-in-labview

To make things clear, here are two small examples that show how nasty locals and value properties can be to the naive programmer.
- Open the diagram of the race condition.vi before running it and try to predict what will be the values of the two counters after the third run.
- Use the Compare Locals Properties and Wires.vi to find out how slow locals and value properties can be (times 1000+).
This being demonstrated, I must add that I use globals and value properties quite often, because they are often very convenient
Chilly Charly (aka CC)
E-List Master - Kudos glutton - Press the yellow button on the left...
Attachments:
Race condition.vi ‏9 KB
Compare Locals Properties and Wires.vi ‏18 KB

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)

Is it better to use Invoke nodes or property nodes to set/get control values?

I have a series of VI's that run in parallel, each to manage different functions- pumping, sensing, a fluid flow model, an experiment generator/runner.
These need to exchange data, which I am currently doing using invoke nodes (that are all in subVIs), using methods "Set control value" and "Get control value". I find that every now and then (perhaps 1% of the time) the data isn't exchanged correctly and therefore the system doesn't work. I can imagine how "set" could go wrong if they happen simultaneously, and can devise ways of preventing this. However, the "Get" method suffers from the same problem. This is a major problem, because I want to leave it running for several hours.
I could in
principle achieve the same thing using property nodes and find myself wondering if this might be more reliable. But I don't want to change over only to find it makes no difference!
Can anyone advise?

You can use some kind of syncronization such as queues, occurances, or notifiers but I think the easiest way would be to create and action engine. This was only one action can execute at a time avoiding a "race condition". Possibly a write action and a read action might help. You also can add queues or notifiers into this concept. hope this helps.
BJD1613
Lead Test Tools Development Engineer
Philips Respironics
Certified LV Architect / Instructor

Just checking on another odd feature: Typedef enum Property Node "Value" not reflecting changes in the Typedef?

Just encountered this odd behavior in LV 2011 which I reduced to the following example:
- create a new VI and drop an enum control on te FP.
- make this control a typedef and open the corresponding typedef
- create a "case 1" item and a "case 2" item
- save the typedef (I used the name Typedef Control 1) and CLOSE it (this is to allow updating of the original control).
- drop a case structure on the diagram and connect the enum to it:
So far so good. Now create a "Value" Property node for the enum and use it instead of the terminal:
If I now go back to the typedef and add a "case 3" item, save the typedef and close it, the control is updated, but the Property node is not.
How do I know that? For one, the Case Structure contextual menu does not offer to create a case for every value. Also, if I add a "case 3" case manually, it turns red.
Luckily, the magic Ctrl-R key stroke actually does solve this problem.
Tested in LV 2011.

By Ctrl-R trick do you simply mean running the VI? That is one way to force a recompile, but if you hold down Ctrl while pressing the run button you can recompile without running. This should not be "dangerous" in any situation.
As you have drawn your example, I see no reason not to use a local in that situation (ok, maybe for vanity). Still, I view the behavior you describe as a bug, and it should certainly be fixed for the benefit of local haters out there. You have to be a little careful where you draw the line between what gets handled in real time and what gets handled only at compile time.

NI 845x USB: Error -301713 occurred at Property Node (arg 2) in General I2C Read.vi

Hello,
I am currently working with digital accelerometer LIS35DE from ST Microelectronics. I want to start with tests of this device. For that purpose I used NI 845x USB to connect with accelerometer via I2C. Unfortunately, when I made electrical connections and set up parameters of communication and run the program (I found it in examples) the following error occured:
Error -301713 occurred at Property Node (arg 2) in General I2C Read.vi
Possible reason(s):
NI-845x: An input parameter, or combination of parameters, is invalid. An example of this error may be setting an invalid baud rate or enabling I2C ACK polling while using 10-bit addressing.
The code can be found in attachements. I couldn't find any extended description of this problem. What could be a problem: incorrect device address, register address, configuration parameters?
Any help is appreciated!
Best regards,
Michael
Attachments:
General I2C Read.vi ‏24 KB

Hi MicMac89!
First of all could you please post which version of LabView are you using?
Could you please tell me which version of 845X hw are you using? (8451 or 8452)
I opened the example you attached. As you wrote the error occurs at the second argument of the property node. (I guess this is the first property node where the error occurs.)
This argument of the property node enables the onboard pull-up resistors. But not all NI-845x hardware support pull-up resistors. (Because of this is important to know which hw version are you using.)
Did you try the example with disabling the pull-up resistors?
I suggest you to go through the Manual of this product, (if you did this not yet) This could make it clear where and when to use what kind of pull-up resistors.
For example: If you are using 8452, you must enable pull-up resistors, for Vref ≤ 1.8 V for the FPGA to properly detect a low-to-high transition
Manual: http://www.ni.com/pdf/manuals/371746d.pdf
HW specification: http://www.ni.com/pdf/manuals/290598a.pdf
Please post if my suggestions helped. Of course if you have any questions, don't hesitate to post them.
Best regards,
Balazs Nagy

Error 1073807202 occurred at Property Node (arg 1) in VISA Configure

I am working with the 30-day evaluation version of LabVIEW
(Version 9.0 32-bit). I am attempting to perform the serial loopback test
described in NI's Developer Zone Tutorial, executing Basic Serial Read and
Write.vi. When I click the Run arrow a dialog box appears with the
following legend:
"Error 1073807202 occurred at Property Node (arg 1) in VISA Configure
Serial Port (Instr).vi>Basic Serial Read and Write.vi. LabVIEW: VISA or
code library could not be located. ...required drive not installed..."
I can find the "smplserl.vi" driver in the /examples folder on my PC.
What's wrong?

Did you do a search for that error? Install NI-VISA.

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 to show/hide sliders on a slider control using property nodes?

If I have a slider with multiple sliders on it how do I change which sliders are visible using property nodes? The only property I have found is making the entire control to be visible or not. This is a possible solution to have two different controls, one slider with only one slider and another slider with two sliders overlapped, but not desirable.
I found on a thread in the forum that it is possible but the user did not provide any specifics about which property it was. (http://forums.ni.com/ni/board/message?board.id=170&message.id=181279&query.id=34404#M181279)
I would appreciate an example VI if possible (Preferred version is 8.5 but versios 8.2, 8.0, and 8.6 are available to me).
Thank you in advance for the help,
Aaron

Just make them transparent! Here's a quick draft.
LabVIEW Champion . Do more with less code and in less time .
Attachments:
HideSliders.vi ‏20 KB

How to use Property nodes?

Hi everyone,
I am a beginner of LabVIEW. So I want to know about Property Node in detail. Please Please someone help me know the function of each property node......
Thank You in Advance,
Solved!
Go to Solution.

Achuthaperumal wrote:
I am a beginner of LabVIEW. So I want to know about Property Node in detail.
Property node allows you to programmatically read/write that particular property of associated object. For example, say you have a String Control, and you want to modify its 'Display Style'... for that you need to create and use that particular property node (of the String control).
Check the attached example.
I am not allergic to Kudos, in fact I love Kudos.
Make your LabVIEW experience more CONVENIENT.
Attachments:
Example - Using Property Node [LV 2009].vi ‏11 KB

Property node broken lvoop

Similar Messages

Maybe you are looking for