Coercion dots, Typedef. and Property Nodes

Hi,
following problem:
1. I place a simple Control (Button 1) and connect it to an Indicator (Indicator 1) -> OK
2. I place a Button as Typedef. (Button 2) and connect it to an Indicator (Indicator 2) -> Coercion dot on Indicator 2 (I don't see the point of a boolean coercion, but OK)
3. I create a property node for Indicator 1 (Value) and try to connect a constant (right-click>Create>Constant -> the constant is grayed out and the error message is 'type definition not found or contains error'
Details: The master copy for this type definition could not be found or the master copy has errors. You must find and fix the master copy, or right-click this type definition and select Disconnect.
4. I remove Button 2 and repeat step 3 -> the same thing happens
If I connect an existing boolean constant to the property node there is a coercion dot. As a matter of fact for using one Typedef. Control in a VI all other control property nodes suddenly have coercion dots even if I remove the Typedef. control. Does it mean either all controls and indicators better are typedef. or none at all?
Thanks in advance.
P.S.: the problem occurred originally in a VI with much more than two buttons...

benMyer wrote:
Something else: did you realize that the spell-checker for this forum does not know the word 'LabView'?
Because you are spelling it wrong. try LabVIEW instead.
LabVIEW Champion . Do more with less code and in less time .

Similar Messages

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

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.

Customize a control and property nodes

I don't know if and how it is possible. Is it possible to customize a control, but having access to property nodes too?
I explain better: if I create a control and I customize it, the customized control is a file.ctl, which has only front panel, but not block diagram. So that I cannot customize it using property nodes. Is there a way to bypass it?

You don't need to create a .ctl file to customize a control. It is just there so you can save a control you have customized to a file.
Yes you can customize a control using property nodes. You just use property nodes that are implicitly linked to a specific control, or you explicitly link to a control by passing a reference to the control to the property node.
If you want to programmatically save a customized control to a .ctl, or open a .ctl file and customize it further, I think you'll have to look into LabVIEW scripting. But I wouldn't do anything like that if I were you until you get thoroughly comfortable with using regular property nodes, which I don't think you are otherwise you wouldn't have asked this question.

Graph and property node

Hello all;
I want to make my .vi more powerful, so what I wanted to do is next:
1. my input must be: "boolean system check box" in 1D array(this is must have, I need this as input into call library function node)
2. all those checkbox(12) are connected to graph(in this example I choose 12 graphs and one input signal which is same, in real I have different signals, scales...)
What I wanted to do is when I check first check box, first graph will be appears(and on graph will be shown his name, which is same as at check box). And then for example if I choose 3,5,8 check box will be appears 3,5,8 graph which will follow one after the other and so one;
I started to make 1D array check box, but after I group all together and try to rename for example check box 1 to channel 1, it's changing all names not just those which I renamed. I know that I can use "property node" and choose "visible" and "value", but I don't know how to implement together and also moving graphs one after other if I choose for example 1,5,8 channel.
I attach testing file and picture;
thanks
Rookie; LV 2011 on WIN 7
Solved!
Go to Solution.
Attachments:
tesst.png ‏106 KB
test_check_box.vi ‏121 KB

Ok, I figure out, how to implement cluster->array; also add "visible" property; but I still don't know how to create "auto position", if I'd like just show for example 1,3,5 graph(all 3 must be inside TAB, also there can't be any free space from graph 2,4 in this case...). Please look my files (v.8.5, i can save to any other version up to 2011);
thanks
Rookie; LV 2011 on WIN 7
Attachments:
button.vi ‏110 KB
1.PNG ‏46 KB
2.png ‏121 KB

Tab Control and Property node

Hi everyone,
i'm trying to create a vi that is able to run more than one test simultaneously but so far i only succeed in using the tab control to control case structure.
What should i do to change the vi to suit my objective?
thanks for any insight.
Currently using labview 8, winsXP.
Attachments:
template.JPG ‏47 KB

The tab control is just something that tells which page is visible. It has nothing to do with the execution of code. To have multiple things happening at the same time, you will need several while loops happening in parallel with each test in its own while loop. Right now your code (and maybe its on a section of screen you didn't copy to the .jpg) does not show any looping whatsoever.

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

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

How to read the configuration of a FXP number via property nodes or other methods.

Hello all,
I am attempting to store in plain-text the value and configuration specifics of the LV FXP datatype. (please do not suggest I cast it to integer).
The ini config format does not support FXP. So we'd like to; using property nodes, interrogate the specifics of a FXP numeric control on the FP.
It appears this is not exposed by control ref's and property nodes.
Oddly enough, you cannot even interrogate the detailed type of an INT if it is a U8, I8 or I16 etc?! via property nodes, the deepest you can go is 'digital'.
Specifically, you need to know the following to 'reconstruct' a FXP:
1. Value
2. Signed\unsigned
3. Word length
4. Integer word length
Without this, there is a risk of corrupting the value during conversion.i.e we want to load initial FXP from disk at application startup. This is a critical application and we cannot tolerate rounding\conversion errors accumilating with numerous reads\writes of FXP settings.
It is odd that you cannot interrogate via property nodes the details of a numeric type. ie. you cannot 'discover' via the property node of an INT if it is a U8, I8 or any other type.
Regards
Jack Hamilton
PS: Don't suggest XML either....

Aristos Queue wrote:
Alias name here wrote:
..second post telling me the 'propertys' of a control have nothing to do with the value is bizzare - via 'properties' for a LV control is the ONLY way to configure the specific type of a numeric...so via the numeric 'property nodes' should\would be able to query it's configuration.
I do not see any way to set these things through the properties...
I think he means by right clicking the control on the front panel and configuring with the properties dialog. The properties are exposed there, but not within the property nodes.
Edit: You beat me.
CLA, LabVIEW Versions 2010-2013

Mysterious coercion dot

Found in this piece of diagram:
The constant 2 is of type I32, so why is there a coercion dot at the "Inverted" connector of the Compound Arithmetic function?
The interesting thing is that if I uncheck the "Invert", the coercion dot disappears, and if I check it off again:
Gone!
Full Disclosure: I inserted the I32 conversion function before I noticed the remnent coercion dot... And if I undo all these steps, I am unable to reproduce the coercion dot.
Mysteries of LV...

Hi,
I was able to reproduce it by playing a bit with LabView...
Step1 : I use a double and a U 32 as inputsa -> as expected, there is a coercion dot at the inverted input.
Step2 : I "insert" a conversion on the double line (when I deleted it first, I could not reproduce the behaviour... it only worked when I inserted it). The types should now be ok, without coercion dots.
Step3 : I save my VI... The coercion dot disappeared. (Same effect when I clicked on "run")
It seems that when we "insert" the conversion, LabView does not update the coercion dots... however, it is not forgotten, as they are updated as soon as we save or run the VI ...
Aurelie
Attachments:
Step1.PNG ‏3 KB
step2.PNG ‏3 KB
Step3.PNG ‏3 KB

The same type and red coercion dot

Hi!
A small project is attached to show how red coercion dot appears if you remove"lib type definition.ctl" from library to a virtual folder. It is interesting that this affects only class property nodes. It does not affect class accessors ("setters") and indicators. The same happens if you move "type definition.ctl" from virtual folder to the library.
Picture shows changes in "vi in library.vi" block diagram.
The application works but a peaceful bad feeling remains ...
There are discussions on this NI forum about typdef controls. It seems that using type definitions can cause serious problems if used together with property nodes. What would be suggested in these cases?
Regards,
Ljubo.
Attachments:
type definition and library.zip ‏69 KB

I can't unfortunately look at your code right now, but there are a couple points to be made:
I'm not sure the problem you show is a bug. Moving the control file out of the library and into a virtual folder in the project changes the type definition because it has a different name.
LV does at times show spurious coersion dots, but I have never seen it cause a functional problem - let alone a serious one.
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

Why is the Value Property Node of a Typedef control not typedef itself?

This is not preventing me from progressing, but I am puzzled by what I am seeing on one of my diagrams (LV 2011).
I have a typedef control which I am reading around my diagram and passing to some subVI. For this purpose I create a read "Value" Property Node and pass the value to the subVI.
The subVI uses the same typedef control as that in my calling VI but nonetheless there is a coersion dot on my calling VI's diagram when I connect the "Value" to the subVI connector. Why?
The closest to this discussion I found was this old one, but it did not end up with a final answer.... It turns out that the typedef control I am talking about is an enum, but that does not matter.
As a matter of fact, if you connect the Value output of a Property Node to a sequence and create a subVI from that sequence, the corresponding control has lost any link with the typedef. In other words, the Value property node of a typedef control is not a typedef. Why?

[...] Why?
Because you haven't posted an idea here.
Well.. maybe you or somebody else has and I missed it, after all there's more than 14k ideas so for just for LabVIEW.. What? Who said that means there's a lot of room for improvement in LabVIEW??
Jokes appart, if there is an idea, please give the link.
When my feet touch the ground each morning the devil thinks "bloody hell... He's up again!"

Why can't I create property nodes for item in STRICT typedef cluster?

I've tried this in LV7.0/WIN2k and LV 7.1/OSX - both versions work the same.
I have a TYPEDEF consisting of a cluster of items A, B, and C.
I have a front-panel instance of this typedef.
Under certain conditions, I want to disable and gray Item C, because it's not applicable.
So I need a property node connected to item C.
If the typedef is STRICT, then I cannot create such a property node - the menu item to create anything is just not there.
If I change to NON-STRICT, then I can create the property node.
I can change it back to STRICT, and the property node works just fine.
The question is, if the nodes WORK normally, why can I not CREATE one?
If there's some sense behind this, someone please point it out to me...
Steve Bird
Culverson Software - Elegant software that is a pleasure to use.
Culverson.com
Blog for (mostly LabVIEW) programmers: Tips And Tricks

I agree with you, It would be nice to be able to keep the non strict typedef auto-update and extend it to properities which effect the look of a control. I am not sure why you can change the properities on a strict typedef. A strict typedef should have private properities (can only be changed from within the definition and no public other vi scope for writing these values. I have in the past used a custom control for presentation purposes and contained the structure of the data to be displayed within the typedef cluster. This is not all that automatic since we need vi's to convert between the definition and control. Seperating data structure from presentation is much like XML where the file only contains data structure and a reference to a style for presentation. It would be a very nice option to allow nonstrict typedefs to have an additional auto-update properities which could be toggled on and off. I would be curious to here others opinions on how to keep data structure and presentation consistant across an application without being tied down to a strict typedef (allowing the optional change of teh presentation at runtime).
Paul
Paul Falkenstein
Coleman Technologies Inc.
CLA, CPI, AIA-Vision
Labview 4.0- 2013, RT, Vision, FPGA

FPGA: are typedef coercion dots bad for efficiency?

Howdy--
Using LV 2011 FPGA, I always get coercion dots when reading or writing to/from FIFO or Memory items typed with a typedef.ctl. Do these indicate some extra use of resources in the compiled code, or are they harmless?
Thanks a bunch all, and have a great day.
--Brad
Solved!
Go to Solution.

bcro wrote:
Awesome. For a minute there I was afraid I'd have to abandon typedefs..a scary prospect when you're as scatter-brained as I am.
Thanks a bunch Taper for the quick reply. Be Well.
Too answer this question yoursefl you could use
Tools >>> Profile "Show Buffer Allocations...
To bring up a toll that will show where the buffers are being created.
Ben
Ben Rayner
I am currently active on.. MainStream Preppers
Rayner's Ridge is under construction

Why this coercion dot on array indicator from strict typedef?

Why is there a coercion dot on the second control?
I created a trivial 3 element array of doubles, and created an indicator by right clicking on it in the block diagram. That's the "CreateIndicator" control.
Then I did the same thing to create a second indicator on the same output wire, and from the front panel selected it and customized it to a strict typedef, saved, and applied changes. That's the "CreateIndicatorThenCustomize" control. It has a coercion dot on it, though. Why?
Thanks to anybody who can shed some light on this for me!
Solved!
Go to Solution.
Attachments:
CoercionMystery.vi ‏9 KB
CustomizedStrictTypedef.ctl ‏6 KB

cebailey wrote:
Thanks, Ben!
Seems weird that this would be considered a coercion. Why do they do it this way?
Q1)
What is the falicy? Is it that you should avoid coercion dots because they force copies, and yet in this case there is no copying involved so the avoidance advice is incorrect?
Q2)
Also, different question, why is Customize Control grayed out in the front panel Edit menu, as long as another control customization panel remains open from the previous use?
Q3)
Finally, how did I miss this after all this time? Well, you probably don't know how I missed it. Actually, if you do know, it might be better to leave it unsaid anyway....
Q1 Correct!
Q2 Not being NI R&D I can only speculate that is was an expediant move to shut-down that functionality. It used to be possible to customize part of a control while customizing a control back in about LV 6. They shut it down making it more painful to do the edits within edits (you can save a control in one edit and then use "replace" to select it while editing the first)
Q3 I will leave taht question as an exercise for the reader.
take care,
Ben
Ben Rayner
I am currently active on.. MainStream Preppers
Rayner's Ridge is under construction

Coercion dots, Typedef. and Property Nodes

Similar Messages

Maybe you are looking for