Can't Get Control Reference in RT?

[R6]

I have experimented with getting references to VI->Front Panel->Controls[]->etc... in the LV Windows environment. (LV 7.1)
 
I tried carrying the experiment over to a VI on an RT target.  However, when I try to get the reference to the Front Panel I get an error message that the "Manager does not support it."  I assume this has something to do with RT's special dealing with front panels, but I don't fully understand it because I am still watching the front panel over VISA right?
 
Nonetheless, I would still like to get a reference to all of the controls on my RT app.  But the only way I know to get those references is to first get a reference to the front panel.  What gives?  Surely you can get references to RT controls?!  Can anyone tell me how?  I don't want to do graphical manipulations, just values.
 
I am also aware of the method of "Get All Control Values," but this is no good because it only gives labels, type descriptor and flat value - no reference.  I want to directly read and set the values (albeit using variants) via references without having to search through text labels.
 
Thanks for any pointers, or should I say references.

[Ben]

I discovered the same thing in LV-RT 6.1.
 
Even a simple property node to read the strings of an enum are not available.
 
So,
CONTROL references are NOT supported in RT to the best of my knowledge.
Hopefully someone else will tell us I am wrong!
 
Ben

[tst]

tst wrote:



I think if you open a control's reference by name it should work.


I'm sorry, I must have been a bit confused and thought that there was a VI that allows you to get a control reference by name.:smileyvery-happy:
What you may be able to do is place all the controls inside a tab and use the reference from the tab to get the Controls[] property.

[R6]

But is it possible to get a reference to a control in RT without going through the front panel or its objects?  Trying to get them through the front panel yields errors.
 
A reference is much more direct than using the "Get Control Value" method, etc.  Those methods search through all the controls looking for a label match.  I know it gets the job done, but it seems very inefficient when dealing with lots of controls.
 
I am concluding that the answer to the question is no.  I wish someone could show me otherwise.:smileysad:
 
Thanks for the replies!
Message Edited by R6 on 07-26-2005 04:03 AMMessage Edited by R6 on 07-26-2005 04:03 AM

[Ben]

Hi tst,
Yes, VI server is still available. I will use VI functional globals that are served.
From the Windows side I can do an invoke node call by reference as a simple way to control and monitor the RT application.
RT although very similar to non-RT is a very picky animal. Simple tricks you would get away with under Windows just simply are not allowed.
Examples:
Do you use strings in your application? Bad idea in RT. Because strings can change length the memory allocated for them can change when you can't predict. This leads to consumption of memory that is NEVER given back until you reboot the node.
This includes strings in the error cluster! I had to resort to replacing the source fields of error cluster with empty strings to prevent RT nodes from crashing under error conditions.
Concatenat string? Bad.
Build array? bad.
Control references and property nodes just do not work.
Do you use locals to update GUI's inside the DAQ loop? Bad idea in a TC loop. Touching the user interface blows away determinism.
I managed to work-around using control references and this should not be a "show-stopper". The only challenge I faced was how to determine the strings associated with an enum. I had to push this issue becasue I needed to ensure the multiple developers involved did not get out of sync.
Attached is a VI that NI Support provided that allowed me to get the strings of a enum without using a property node. This VI existed prior to me reporting the "no property node" issue because this was a known issue.
Here is the VI as a LV 7.1 llb.
 
Ben
I do not think this is a bug.Message Edited by Ben on 07-26-2005 07:16 AM


NOControlRefInRT.llb:
http://forums.ni.com/attachments/ni/170/133639/1/NOControlRefInRT.llb

[tst]

Ben wrote:

I do not think this is a bug.


Well, I'm not sure how I would look at it. I never had the need to dynamically contact a RT target to access controls, so I didn't really think about it, but at first glance I would say that opening a reference to the FP should work if the FP exists, even if destroys determinsm. That should be the user's problem. I can understand why it doesn't work, though.
The other stuff brings up some interesting considerations. Luckily, I didn't run into cases where using strings eats up the memory (I think), but it's good to know these things. This may help explain some "mystery errors" where the module seems to stop responding until rebooted. I assume Deallocate Memory doesn't help? Is this documented somewhere? I found a small section about this in chapter 6 of the manual (can also be seen <a href="http://zone.ni.com/devzone/conceptd.nsf/webmain/ADDE63E507AFE8AD86256ACB005DEF2F" target="_blank">here</a>), but I also found another <a href="http://zone.ni.com/devzone/conceptd.nsf/webmain/4DB571A3513C859C862568EB0075A635" target="_blank">reference</a>&nbsp;which makes no mention of this. I suppose it's logical, now that I think about it, but it really seems to me that this wasn't stressed out too well.
Like I said, I'm fairly sure I did see property nodes work on a RT target (I think they were supposed to help with the UI when connecting to the FP).
Also, can you save that LLB for 7.0?

[Ben]

Example as LV 7.0
&nbsp;
It's been about 4-5 yeras since I took the LV-RT course. Much of what I shared is based on experience.
&nbsp;
That is all I have to offer.
&nbsp;
The RT-OS does not play that allocate/deallocate game very well (if at all). This is GOOD!
&nbsp;
When my RT app needs to respond within sub-millisecond time frames, I do not want the memory manager to get involved.
&nbsp;
Ben


NOControlRefInRT.llb:
http://forums.ni.com/attachments/ni/170/133652/1/NOControlRefInRT.llb