Control Reference Terminal on the InPlace Element Structure

[TonyZammit]

The Current Situation:

In a LabView Real Time program Control References cannot be used because the front panel is removed (even if debug mode is enabled). In order to write to a control in a cluster, the only options are to use unbundle/bundle or variants. It is preferrable to be able to programmatically write to any control within the cluster when one is required to be able to change any value within a large multi-level cluster that has many controls. Using variants and drilling down into the cluster to access and change a value causes execution issues in a Real Time program.

The Idea:

Have a Control Reference Terminal on the Data Value Reference Read Node on the InPlace Element Structure. This is shown in the code below.

This would allow the value (and whatever other properties make sense to be accessible) to be programmatically modified inside the InPlace Element Structure. This would work in the Real Time environment too.

[crossrulz]

How would this work in Real-Time?  As you said, the front panel is removed.  So there are no actual control to reference.  And property nodes are slow to begin with.  I just don't see the need.

Besides, how would the IPES know what control the cluster came from?  If you want something like that, you need to put the reference in a cluster.

[CMal]

"In a LabView Real Time program Control References cannot be used because the front panel is removed"

That is not true.  Many VI Server properties and methods are available in LabVIEW RT, and they work just the same as they would on a desktop target.  You can check whether a property works on RT by looking at the Help document for that property.  There is a table listing the characteristics of the property, one of which is "Available in Real-Time Operating System".

[TonyZammit]

The "Controls" that it is referencing are the "Controls" in the data type of the wire that came into the Data Value Reference function (for example controls in a cluster in the wire). They are not controls on the front panel, because there is no front panel in a compiled Real Time program.

I only used the term "Control Reference" to refer to it allowing a subset of the properties that are available using a standard Control Reference property node. It would actually be using the reference created by the Data Value Reference function (i.e. a reference to the data in the wire). It is strange that NI provides a method to create and destroy this reference to the data in the wire (so that one can operate on the data using a pointer instead of by making a copy of the value), but not provide any functions that can use this reference other than the Data Value Reference Read Node on the InPlace Element Structure. Im just advocating that NI creates property nodes that can take the Data Value Reference as the RefNum, just like the current property nodes take a Control Reference as the RefNum.

It is my understanding that property nodes are only slow because they are running in the UI thread. In the case of the Real Time operating system I'm not sure if there is a UI thread, but if not then they would need to be run in another thread.

Another example of where this would be useful is extracting the strings for an enumerated in a Real Time program. As far as I know, there is no way of extracting the strings directly from an enumerated in a  Real Time program. One could only create a case structure and output a string in each case that matches the string in the enumerated. With this idea, one could simply extract the strings from the enumerated using the Strings[] property node.

[tst]

A typedef has two different uses - it is used to define a data type and it can also be used to define a UI element. In the common case of defining a data type, the actual UI element used to build the typedef becomes irrelevant - it's only there to define what the data type, the label and and default value should be. The fact that the UI element has other properties is not transmitted as part of the data type, which is what the DVR actually uses, and that's why your code can't work - there is no control for you to edit. The DVR holds a copy of the data, not a copy of the control inside the typedef. The two are separate and the data doesn't have the properties you want.

Even if DVRs gained the ability to access the properties of controls which were parts of typedefs they were using as their data type, that wouldn't solve your problem, because LV RT would suddenly be able to do something it hasn't done before - access to control properties would still have the same restrictions it has today.

If what you want is a shorthand way of accessing nested elements in clusters, there are already ideas in the IE which have such suggestions. If what you want is to get the strings of an enum with a property node, there are solutions on line for that too, such as looping over all the values of the enum and using Format Into String or flattening the enum to a string and using the type descriptor to extract the strings (since in an enum the strings are part of the data type).

[AristosQueue (NI)]

> It is strange that NI provides a method to create and destroy this

> reference to the data in the wire (so that one can operate on the

> data using a pointer instead of by making a copy of the value), but

> not provide any functions that can use this reference other than

> the Data Value Reference Read Node on the InPlace Element

It isn't strange... it is by design. No other functions can manipulate that data because we need a structure node to know how long you want to hold the lock for your operations and so that multiple references can be unlocked in a single structure boundary (thus allowing us to unlock in a cannonical order to avoid the dining philosophers' deadlock issue).

There is no control reference because there is no control. There's just the data. There's nothing else to point at. I don't know how else to say it -- this data exists in the DVR and no where else, and there is no control that has the rest of the image state (i.e. font size, bounds, color, etc) hiding somewhere. It's just data.

[MaryH]

Idea is based on a flawed concept of what a data value reference represents. We cannot expose the control reference because there is no control underlying a DVR.