Modifing Cluster component properties on sbRIO? No 'To More Specific Class' node???

[pneumann]

Hello,

I'm designed a fairly large RT application.  Our structure is to have our main RT vi with several large clusters that get passed down to subvis who modify the passed cluster's components through its reference. (Easy) In addition, we need to modify some of the cluster component's properties as well. From other examples, to modify a cluster component's properties from its reference, one does:

1) Get Controls[] property of the cluster

2) Index in the  Control[] for the component

3) Use 'To More Specific' class with the exact type of the component

4) Attach a property node to access the desirec property

This has worked fine except we are now deploying to a sbRIO system. All of the 'To More Specific Class' are now broken with the error message that this node "is not support on the current target".

I talked to one NI rep who told that 'To More Specific Class' is NOT supported on real-time hardware. If this is the case, how does one modify a cluster's component properties without using the 'To More Specific Class' node???

Attached is a simple example. It shows a simple cluster with two components that need to have to have their properties changed. This works fine on a non-real-time hardware (like a PC host). It breaks on our sbRIO.

Again how does one modify a cluster component's properties on a real-time system such as sbRIO????

We're using LabView 8.6.1 on a sbRIO 9642.

-Paul

 

[Stephen_S.]

Paul,

The list of Unsupported LabVIEW Real-Time Features (VxWorks) includes object oriented programming, which includes classes, objects, etc. Also, note the section on modifying front panel objects, which says that front panel property nodes are only available if there is a front panel connection.

You can also use the Unbundle by Name function to split the cluster, and at that point you can modify their values and rebundle the cluster together

Are you doing something other than changing the value, or front panel properties? If so what are you trying to do?

Regards,

Stephen S.

[pneumann]

Stephen,

My question was about altering a cluster's front panel properties from a subvi with a cluster's reference on a real-time hardware. (Changing a cluster component's value is not a problem.) My simple example that I posted illustrates this point. 

I can understand that a stand-alone appication won't have a front panel. (Although what happens with a stand-alone application with a remote Front Web panel? That certainly looks like a front panel of the selected VI is displayed back remotely.) We are currently deploying our Vis by hand. There is a front panel displayed back to our host machine from the sbRIO. So a front panel of all deployed Vis clearly exists at this time.

An example of what we are doing: We have a cluster which contains system components such as battery slider indicators. When the battery voltage drops, we want to change the battery slider color to indicate to the user that the system will need recharging. We have a subvi which performs other modifications to this cluster so we logically thought the battery color alternation should be done in this subvi but we can't. Again because 'To More Specific Class' node is not available.

The work around that we're currently using is call direct propery nodes of the cluster components on the*main* RT Vi - not sub-vi. It's ugly but it looks like there no alternative. See the picture below which continues my simple example posted earlier.

Again I don't understand this reasoning. If a front panel doesn't exist on real-time hardware, why can one create direct property nodes of a cluster component in the VI which contains the cluster but can't access them in a sub-vi? It would seem that all access to front panel properties on a real-time hardware would be banned.

-Paul

 

[Stephen_S.]

Hi pneumann,

A front panel property node will have no effect if the front panel is not being viewed through a remote front panel connection or through front panel communication.

I was able to run a VI on a Real-Time target with a front panel property node (modifying the label of your cluster, or making it blink) either in the main VI, or in a subVI. Maybe you could post the code that works with a property node in the main VI, but not in a subVI to see the behavior that you are talking about.

In general though, Real-Time VIs are not intended to have user interface as a major component of their operation.

Regards,

Stephen S.

[pneumann]

Stephen,

Again, my question is changing the individual elements of a cluster - not the cluster itself. The example that I posted had a knob whiose maximum values must be changed and a slider whose color must be altered. Also we have a front panel. Our program is NOT auto-deployed. Again there appears to be a double standard that one can modify inidividual components of a cluster at the same level of the cluster (with a standard propery node) but not in a sub-vi which requires a 'To More Specific Class' node. If there is no front panel, standard property nodes are ignored so why can't 'To More Specific Class' nodes be ignored as well? 

Yet another example, my boss designed another cluster on our main RT vi. The cluster contained a multicolumn listbox. He wanted any component of our program to be able to write a me into the listbox when an important event occurred. I told him that this is NOT possible. The only way to place a string into a listbox is through a property node and NI doesn't permit one to modify a cluster component's property in a sub-vi. Since the majority of our program are sub-vis, none of them would be able to write a message into the listbox. The only alternative is to have a *separate vi* with a *separate window* that any sub-vi could call. (If we could do our approach, we would just pass the cluster containing the listbox reference directly to any sub-vi and they could directly modify the listbox's Strings[] property. But this cannot be done.) The listbox cannot be integrated into our main RT vi front panel window as my boss had designed. He replied that forcing the listbox into a separate window was not acceptable. He wants the users to have *one* window. He doesn't want them switching or searching for multiple windows. I told him that this cannot be done and that NI recommends that we should not be using any front panels with real-time hardware. My boss replied that a 'no screen' approach is further down the development cycle. We need an intuitive front panel to demonstrate the project at this time.

I ended up designing a separate vi with the listbox in its own window - no cluster, not integrated in our main RT vi as my boss had wanted. My boss isn't thrilled about it, but it works.

Again I don't understand why standard cluster component properties can be modified on the same level of their clusters but not within a sub-vi. If a standard property node can be ignored when there is no front panel then why can't a 'To More Specific Class' be ignored rather than breaking vis and forcing users into less streamlined designs.

-Paul

[pneumann]

Oops, The property to enter a string into a multicolumn Listbox is ItemName - not Strings[]. My augment still stands. One cannot modify ItemNames from a passed cluster's reference in a sub-vi but can modify it with a standard property node only in the VI containing the cluster. Again on a real-time platform.

[pneumann · Accepted solution]

I installed LabView 2009 today and lo and behold - the 'To More Specific Class' node is now permitted on a real-time target. Nothing in the documentation indicates this but I'm not complaining. One can now modify a cluster component's property in a sub-vi on a real-time target. Thanks to whomever fixed this!