RT Property Nodes for Typedefs

[TurboPhil]

I am adding a new feature to an RT application for which I would like to maintain scalability and flexibility by using a cluster type definition. The cluster will represent the channels to use for a particular modular subvi. I will reference this cluster in multiple locations, and there is a chance that I may need to add new elements in the future, which is why I want to use a type definition (to apply the update globally from one file location).

I also need to be able to return the list of elements in the cluster. Normally, I would do so by accessing the Controls[] property, then stepping through each control to get the Label.Text to get the individual item names. Unfortunately, I can't access such properties on an RT target. [Well, I can if I run it in the Development environment, but not when compiled into an executable] I understand that some property nodes are unavailable on RT targets, but it's not clear to me which ones are and are not. For instance,  I often connect via Remote front panels, and I know that I can use the Visible? and Disabled mode property nodes on front panel controls (both read and write) without problems, even though NI's stance is that the Front Panel does not exist on RT targets. Why can I use those properties, but not simple ones like Controls[] and Label.Text?

Also, has anyone else run into a similar situation and found a way around it? That is, a way to get the benefits of type definitions (i.e. globally updating) for groups of channels on an RT target?

[Justin_P]

Hi Phil,

The reason that this works in the dev environment and when using remote front panels is that a "front panel connection" is established.  Explained here.

If you needed to make your code scalable for the number of channels that you are going to use, you could have an array (or an array of clusters depending on what you are trying to pass around) and then auto index through the array and perform the operation that you need to on each channel.

 

[TurboPhil]

Thanks for the explanation, Justin. That makes sense how instantiating a front panel connection (via the development environment) will affect the RT target's ability to read certain property nodes. Or, at least I can see the logic behind it. I still think it would be nice if certain properties could be available to the RT target at run-time without a front panel connection, provided that reading from those properties will not affect the system's determinism....

As to your array suggestion, yes I completely agree with the concept. Except that--at least to my knowledge--there isn't a good way to prepopulate the array across all instances. That is, I want to have a predefined channel list defined as a type definition so that I can call it from multiple VIs and if I need to add to/remove from the list at any time, I only need to modify that one type definition. Using, say, an array of strings, the best I could do is use a control and modify the default value. But that would not propagate across all instances of the control throughout the project.

Typically, I use a typedef enum to define channel lists, and I have a little subvi to step through each element in the enum (since I can't access the Item Names[] property) to return the list of string elements. In this case, however, I wanted to have a little more flexibility: I want a typedef cluster whose elements are channel types and the entries in those elements specify the channel names. Specifically, I am working on a scalable CAN interface subvi that needs to be able to communicate with multiple different manufacturers' devices; for each device, I have a list of general channel types that I will use for communication (setpoint, feedback, temperature--to be represented by the cluster elemnt names), but each manufacturer has a different channel name (i.e. "SRA_Desired_Pos", "SRA_Actual_Pos", "SRA_Internal_Temp", etc.--to be reflected in the value of the cluster string element) for each type.

Just wondering if anyone out there has run into this kind of situation and come up with a clever way around it.

[Ben · Accepted solution]

---

TurboPhil wrote:

Thanks for the explanation, Justin. That makes sense how instantiating a front panel connection (via the development environment) will affect the RT target's ability to read certain property nodes. Or, at least I can see the logic behind it. I still think it would be nice if certain properties could be available to the RT target at run-time without a front panel connection, provided that reading from those properties will not affect the system's determinism....

As to your array suggestion, yes I completely agree with the concept. Except that--at least to my knowledge--there isn't a good way to prepopulate the array across all instances. That is, I want to have a predefined channel list defined as a type definition so that I can call it from multiple VIs and if I need to add to/remove from the list at any time, I only need to modify that one type definition. Using, say, an array of strings, the best I could do is use a control and modify the default value. But that would not propagate across all instances of the control throughout the project.

Typically, I use a typedef enum to define channel lists, and I have a little subvi to step through each element in the enum (since I can't access the Item Names[] property) to return the list of string elements. In this case, however, I wanted to have a little more flexibility: I want a typedef cluster whose elements are channel types and the entries in those elements specify the channel names. Specifically, I am working on a scalable CAN interface subvi that needs to be able to communicate with multiple different manufacturers' devices; for each device, I have a list of general channel types that I will use for communication (setpoint, feedback, temperature--to be represented by the cluster elemnt names), but each manufacturer has a different channel name (i.e. "SRA_Desired_Pos", "SRA_Actual_Pos", "SRA_Internal_Temp", etc.--to be reflected in the value of the cluster string element) for each type.

Just wondering if anyone out there has run into this kind of situation and come up with a clever way around it.

---

"Well that is a horse of a different color!"

Just parse the type descriptor of the enum.

Ben

[Wayne.C]

TurboPhil,

I have handled similar situations with cFP by using an Functional Global/Action Engine to be the keeper of the list.  Rest of program keeps checking in to make sure it has the latest copy of the list or to make any changes to the list.  In my case the list is an array of clusters.