LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

CompactRIO, control properties, and objects

After a lot of debugging I found some odd behavior in interacting with control refs.

 

If I:

1) write to

2) a class control's property node

3) on my CompactRIO 9030

 

I get error code 1, "Property Node In rioctrlsimple.vi"

 

If any of these three conditions are different, there's no problem. I can read fine; I can write other, even complicated types fine; and it works fine on my PC.

 

I've simplifed the problem all the way down, and the snippet below demonstrates it. The top class control line will fail but the bottom cluster line will succeed.

 

Has anyone seen this before? Is it a bug? Any workaround?

 

ctrldebugging.png

0 Kudos
Message 1 of 4
(2,825 Views)

Interesting note: if I use a base LabVIEW Object, the common ancestor data type for all LabVIEW classes, then this works fine.

 

I haven't been able to find a way to exploit that into a workaround, though.

 

So now it's four conditions: 1) write 2) a non-LabVIEW Object object 3) to the property node 4) on the cRIO

 

I really think this is a bug in the cRIO's class casting into the control.

0 Kudos
Message 2 of 4
(2,707 Views)

Take a look at this KB article: http://digital.ni.com/public.nsf/allkb/752A325630EC09B886257B6B0065F4B9

 

The TLDR: It's not a good idea to use Value Property Nodes in a RT application.  There's workarounds suggested to avoid using these property nodes as well.

0 Kudos
Message 3 of 4
(2,678 Views)

Hi, Jeff

 

I find that often KnowledgeBase articles about RT don't actually apply to the cRIO, and this seems to be one of those cases. The cRIO I'm running DOES host a frontpanel, and that might make the difference.

 

For example, contrary to the Knowledgebase entry, and paraphrasing it, I find property nodes that reference front panel controls don't output the default value for the datatype, and when I try to write the Value property of a Front Panel Object, a value is written in all other cases.

 

Yes, I'd love to avoid using value properties, but our application requires us to access all of the elements of a cluster of objects to initialize them (without constructors this is the only way to ensure they're all initialized, grumblegrumble).

 

Tricks like cluster to array+array to cluster don't work because of both casting issues and because we won't know the number of cluster elements ahead of time (as array to cluster requires).

0 Kudos
Message 4 of 4
(2,663 Views)