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

Similar Messages

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!

VI Snippet Bug (IMAQ Image Vision Display with Property Node)

Colleagues,
Just found small bug in LabVIEW - Creating snippet from selection with Vision Display together with Property node is not working (means that nothing happened - no save dialog appear):
VI in attachment (VAS or VDM software required). Can someone reproduce this?
Andrey.
PS
LabVIEW 2009f3
Message Edited by Andrey Dmitriev on 01-21-2010 03:29 PM
Attachments:
Snippet BUG.vi ‏40 KB

Hi Andrey
Thank you for your post, I will clarify if this is fixed in the LabVIEW SP1.
If it is not, I am going to write a CAR for that.
Kind regards
Beat
AE NI Germany

Working with "property nodes" in pda module

Hi,
i already know that it is not possible to work with property node in pda module.
I have found something that allows to replace the visible property node
(LabVIEW_PDA_Module_Property_Additions), but i need other property
nodes.
I need the following property nodes:
disabled
caption.text
numrows (for a table control)
numcols (for a table control)
colhdrs[] (for a table control)
Can anyone give me a help with this?
Thanks,
Pedro

I think the only one you can do something about is the caption, which you can try to replace with a string indicator.
Try to take over the world!

Help with property node

I have a graph chart with 3 plots. I can make any of the plots visible or not using property node as shown in the attached file.
Is there a any way I can scale the block diagram and use less case structure . for instance is it possible to use just one case structure to set the plot visible property of the three plots.
Thank you.
Attachments:
PropertyNodeChartAssign.vi ‏29 KB

(You are using way too much code for these cases! Your true and false cases only differ by the boolean, which you already have from the control. In a first cleanup, you can delete the case structure and wire the button directly to the "visible" property. Same functionality! Right?)
Still, that's not the way to go!
Property nodes are expensive! You only need to write these properties if one of the selector changes, and not with every iteration of the loop! You should handle these thing in a seperate loop using an event structure. Attached is a simple example. See if it makes sense.
Notice that the bottom loop waits until needed and rarely spins.
Also: Instead of a column of similar controls, use an array of controls. Instead of using thee sets of "dices" use one in a FOR loop.
Message Edited by altenbach on 05-18-2007 08:32 PM
LabVIEW Champion . Do more with less code and in less time .
Attachments:
ChartVisible.png ‏16 KB
PropertyNodeChartAssignMOD.vi ‏28 KB

Save array control to .cfg with property nodes.

Hi there!
I have a front panel with many (and I mean many!) boolean arrays in tabs, and I want the option to save the values selected by the user to a .cfg file, which will be used to make the same selection again without the tedium of clicking on buttons. The only controls I want to save the value of are 1D boolean arrays of length 7 or 11, and these occur only on some of the tab pages; the others have been setup so that on their iteration a false criteria is met and no code executes.
I have managed to get references to each control in each tab, and using a 'more specific class' function to narrow it down to Array controls only. However, when this runs, an error from 'convert variant to data' pops up, and use of a probe tells me the reference being called by my property node at the time of the error is that of an array INDICATOR, rather than a control. I thought the 'controls on page' node and subsequently the array control class specifier would mean that references for other types of array wouldn't make it into the true case where the saving to config file happens.
The indicator in question is an array of a cluster of two strings and a string array, if that makes any sense/has any relevancy, and the error occurs on iteration 1 of the outer loop and iteration 21 of the inner loop, corresponding to the 22nd control reference from the second tab.
I hope I've made the problem clear.

There is a property called Is Control? (or Is Indicator?) that will help you sort them out. I do not recall the exact name of the property but that should get you close enough to find it.
Lynn

Broblem with property node and DAQ-card

Hi!
I am using NI DAQ-card to control mini relays and I have a following broblem. I use a "binary" button to control the DAQ-assistant and so on the relays. I have made property node of the "binary" button and set it to value mode(write). When I change the value of property node, the "binary" button in user interface works properly, but the the relay doesn't change the state.

The boolean array constant that you are writing to the property node is empty. That is it has been defined as a boolean array, but it has no elements.
The array constant on the left is an empty boolean array. Notice that all teh boolean constants are grayed out. This indicates that none of the constants are 'active'. The array on the right contains 8 active elements. Note that the 8 elemants are more solid in color adn the the 9th element is grayed out.
What you need to do is define your boolean array with the proper constants to turn on or off the proper digital lines.
EdMessage Edited by Ed Dickens on 05-25-2005 09:15 AM
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.
Attachments:
emptyarrays.png ‏2 KB

Error with property nodes and svx_DAQmx Popup for DSA.vi

Some example vi of the sound and vibration toolset 3.1 use property nodes with an undefined class (e.g. svx_DAQmx Popup for DSA.vi). I use Labview 7.1 and NI-DAQmx. Could it be that the vi uses classes from traditional NI-DAQ?

The error occurs in:
C:\Programme\National Instruments\LabVIEW 7.1\examples\Sound and Vibration\Utility\Daq\DAQmx\svx_Get DAQmx Info.vi
C:\Programme\National Instruments\LabVIEW 7.1\examples\Sound and Vibration\Utility\Daq\DAQmx\svx_DAQmx Popup for DSA.vi
see also attached screen shot.
It is a new installation on a PXI-system, WinXP, LabView 7.1, SVT 3.1, NI-DAQ 7.4 (only DAQmx driver installed). The examples had not been tested before.
Attachments:
screenshot.jpg ‏144 KB

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

Performance penalty with property nodes?

In a specific application I have a front panel with three combo boxes and another three string indicators. Based on the selections made in the combo boxes, various messages will have to be displayed in the string displays. This naturally calls for multiple instances in the same VI where the combo boxes will have to be read and string display updates.
One choice would have been local variables ( of combo boxes & string indicators ) for passing the values around. But since this is going to make several copies and hit performance, I decided to use property nodes. And it works fine.
The question is, whether excessive use of property nodes has any adverse effect on performance ?
Thanks
Raghunathan
Raghunathan
LV2012 to Automate Hydraulic Test rigs.

Thanks! I would suggest to just do the experiment.
The attached little demo (LabVIEW 7.1) does the same thing (increment a I32 variable in a loop) in three different ways:
-- shift register
-- local variable
-- value properties
On my slow laptop, 10000 iterations take the following total time in ms.
shift registers: 3ms
Local variables: 5ms
Value Properties: 1891ms (!!)
Notice that the shift register solution would be much faster (more than 10x (or 1000000 in 20ms)) if the indicator is placed outside the loop, the only thing slowing it down is the update of the indicator.
In conclusion value properties are much more expensive than local variables or shift registers. If you just write once e.g. at the beginning of the program, it does not really matter, but once you do things repetitively in a loop, the costs add up. I always prefer wires because they also make the diagram easy to follow. Local variables break the dataflow and can cause race conditions. They have their limited use, especially in user interface related code. They have no business in pure computations.
LabVIEW Champion . Do more with less code and in less time .
Attachments:
timers.vi ‏47 KB

Align graphs using property nodes

Hi,
I am displaying data from 8 channels each on a seperate chart. I am using plot area and position property nodes to fix the size of each of these charts.
I need auto-scaling but because of this, the charts are not aligned properly.
Is there a way to fix the plot area and boundaries such that all the charts are aligned properly ?
Shiv

In LV6.1: Try to disable the chart property "Auto Adjust Scales" (located
in front panel menu).
In LV6.0.x: There is no possibility turn it off. :-(
Robert
"ponnaboy" schrieb im Newsbeitrag
news:[email protected]..
> Hi,
> I am displaying data from 8 channels each on a seperate chart. I am
> using plot area and position property nodes to fix the size of each of
> these charts.
> I need auto-scaling but because of this, the charts are not aligned
> properly.
> Is there a way to fix the plot area and boundaries such that all the
> charts are aligned properly ?
>
> Shiv
>

How can I change the description of a control Icon with property nodes?

hi
I want to change the description of a control Icon and use for this the property nodes, but I don't know how. Who can help me?
labprog

If you're referring to the control's name on the screen, you can't change the label while the VI is running because it's part of the control's definition. Instead, make the label invisible and the caption visible and use the property Caption.
If this doesn't help, elaborate more on what it is you need.
Try to take over the world!

Libsslport library conflict when using components built with studio 11 & 12

I have a library built with Studio 11 that links with libstlport.so in studio 11. I then build an application with studio 12 which links with studio 12 stilport.so. When I do an ldd on the application it reports that it depends on stlport.so from both studio 11 and 12. This happens even if I set LD_LIBRARY_PATH to explicitly point to the Studio 12 lib directory.
On running the application it consistently crashes at exit with the following stack trace:
std::locale::~locale()
_exit()
exit()
The problem is resolved if we build everything with Studio 11.
It should be possible to link with components build with older version of the compiler. Can someone tell us what is the right way to do this.
Thanks.
Shirish.

Setting LD_LIBRARY_PATH is useful for testing and for one-off programs used only by yourself, but it is not a sustainable or scalable solution. For more on this topic:
http://blogs.sun.com/rie/entry/tt_ld_library_path_tt
When you build applications using shared libraries, you usually need to set the runpath (-R option).
By default, the CC command sets the runpath to point into the compiler installation area. If parts of the application are build with different compilers, you can by deafult wind up with runpaths pointing into each compiler area, which can lead to linking two versions of a library, a recipe for disaster.
The best way to solve this problem depends on how you will use and deploy the application. I'll suggest a general solution, which works even if you deploy the application to remote systems used by others.
Create a runtime environment for the application, perhaps a directory tree like this:
myapp/
    bin/
    lib/
    doc/Main programs go in the bin directory. Shared libraries go in the lib directory.
Build shared libraries and executable programs with a relative runpath pointing into the lib directory:
CC ... -R \$ORIGIN/../libIf you build an application entirely with Studio 11, copy the studio 11 version of libstlport.so into the lib directory.
If multiple compilers are used, copy libstlport.so from the most recent compiler into the lib directory.

Labview 2011 FDS (64bit) crashes when saving a vi with MATLAB node

After running a vi which includes a MATLAB node, the vi cannot be saved, because Labview crashes every time with error: "DAbort 0x1A7102DF in fpsane.cpp".
Why does a MATLAB node with simple array I/O corrupt LABVIEW's sanity ???
I have attached a minimum configuration, which gives a reliable crash. First run, then push save.
Configuration: Windows 7 (new installation), Labview FDS (64bit), MATLAB (64bit)

Amd1480 wrote:
did anybody could solve or got a work arround this problem?
I am getting the same error code when I use the Call Library Function to call external DLLs in my application.
I am using the following system configuration:
- Windows 7 32bit with SP1
- LabVIEW PDS 2011 32bit
Additionally to this error I am getting the following message (Ausnahme: Access violation (0xC0000005) bei EIP=0x00C0503F) (see attachments)
Note: calling the same DLLs using previous LabVIEW versions (8.2) works fine.
When such errors happen in an application that uses the Call Library Node, you can be almost certain that it is a problem in how the Call Library Node was configured (wrong!) or a bug in the DLL. That you happen to see this error, only means that the external code happend to overwrite memory that it was not supposed to do, and that memory happened to be some data structure that LabVIEW uses to represent some front panel element. That it didn't happen in 8.2 doesn't mean that it didn't have that error there too, only that it overwrote some different memory location, that had unluckily for you no visible consequences.
For all other cases with no Call Library Node included, it means that the VIs front panel resource got somehow damaged (and yes this could also happen from running the VI in an application with misbehaving Call Library Node, and then saving the VI). The most easy solution is to rewrite the VI, another option is to try to force a recompile with the Ctrl button pressed and then activating the run button in the VI toolbar. Other than that there is little we normal users can do. The only people who can do more here are the LabVIEW developers who can look inside the VI and identify the damaged data structure and repair it, but that is a lot of work and time, and NI doesn't commit to doing this normally.

Why do I get an error 1000 when using vi server with invoke nodes?

I use the invoke nodes with set control value and run vi. I want to use the called vi on the same machine and in parallel and I do not want to wait until it is done. If I set wait until done to true it works, if I set it to false I get the error message. Why is that and how can I solve that problem??

Hi,
Using LabVIEW 7 I was able to do what you want. I modified an existing example. The main vi will load the a second VI, and then the main VI will do "set control value" on a numberic labeled "Numeric" and you'll be able to see that it is changing the control value.
I've attached the modified VI.
Attachments:
parallel.zip ‏148 KB

Class conflict when programmatically editing graphs with property node

Similar Messages

Maybe you are looking for