Are References Absolute?

[R6]

Are references to controls etc absolute memory pointers or are they relative to a VI reference?  I would like to pass references to controls and indicators accross the network to a host so that the host can refer back to them on the target later.  If those references were coming from various levels of sub VIs, does the host need to tell the Target which VI the reference is within, or will the single control reference suffice?  I was hoping to get a quick answer here without setting up the experiment.

Thanks!

[tst]

As far as I know, reference values are absolute Per-LV-app. This means that if you run 2 instances of LV at the same time, the value of the reference itself won't help you - you will have to open a reference to the LV app and get the value to the reference. The same will apply to a network - simply passing the numeric value of the reference isn't enough.

In addition, the numeric value exposed to you is apparently not the value used internally by LV. 

If you want to see an example where 2 different numbers can point to the same object, look at the reference you get from the Front Panel>Controls[] property as opposed to the reference of the control itself (a discussion here). I'm guessing that just passing the numbers won't help, but you can try it. It might surprise you. In any case, if you close and reopen the local instance, the numbers will probably not be valid, so I wouldn't advise it.

[Lycangeek]

Yeah, what he said.

All references (refnums) are valid only in the instance of the application that opened them.

[R6]

Is there any reason why a control reference could not be flattened, sent out over TCP/IP and then come back, unflattened, and be used to access the same original control?

[shoneill]

I don't quite grasp why you would be sending a reference across a network, but anyhow...

Theoretically this should be possible assuming that the origin of the reference is the one unflattening it and re-using it.  If the program has re-started in the meantime, then the reference is invalid.  Why you might ask.  Simple, The OS loads the programs into a different location in memory each time, so the references change each time the program is loaded.

Generally passing references around is a bit tricky.  Why not send the VI name and control name around, the programs involved can always generate the reference on-the-fly.  This way you'll get rid of much of the "invalid reference" problems.

Hope this helps

Shane.

[tst]

---

@R6 wrote:

Is there any reason why a control reference could not be flattened, sent out over TCP/IP and then come back, unflattened, and be used to access the same original control?

---

Once again, the number you are seeing is not the actual reference and it is specific per application. It would have absolutely no meaning in the other application. As far as I know, if you open a reference to the control from the other app, you would get a completely different number. Like Shane said, why not use the VI server to open a reference to the application and get the references like that?

I would also like to revise my earlier statement. I said it might surprise you because I thought there would be someway to open an app reference before using the number. Now that I think about it, I can't see a way, so I don't think you should even try it.

[R6]

I am building a host display/calibration application that will connect to a target over TCP/IP.  I will have many controls/indicators on the host identical in data type to those on the target.  I did the VI server thing over TCP/IP.  It coded nicely.  The only problem was that it was slow as molasses.  I then discovered that the problem was that many small messages going over TCP/IP is much much slower than many messages bundled into a few packets.  I reworked the app to have VI server apps on both the target and the host, getting values to its own controls, bundling up string packets of all the controls, and sending them over TCP/IP.  The other end unpacks them and finds the matching control name and sets the value.  This has proved to be much much faster than using VI Server explicitly over the network.

Sooo, now I am looking into reworking it so that the target will initially pass up to the host a list of all its controls/indicators, including target-references to those controls/indicators.  The host will determine what indicators are currently visible on the host display (tabbed panes, etc.), and put together a list of target-references that the host would like to be receiving values for.  Likewise, the host could also send control values, along with target-references, down to the target.

Passing references this way would allow the target to more quickly pack up indicator values and set control values directly via references, instead of searching through labels, or having VI Server search through labels.  If I am way off in the weeds, let me know, but I am trying to make this app able to very generically deal with hundreds of controls/indicators on a target, and most importantly very efficiently.

And to make this all very frustrating, I am discovering that my target apps running on RT are not able to get references to controls/indicators.  I asked about this in another thread yesterday.  What's up with that?  So it looks like I am back to dealing with labels.

Thanks for your replies.

R6.

[tst]

If I understand what you want, you're talking about using the reference in the original application, which I think should work as long as it remains open. The question is why not generate a reference array (in a LV2 global) at the beginning of the program and use that to keep the references to the controls? That way, you pass the index of the reference in your array instead of passing the reference itself. The array itself is identical on both sides, except for the reference values.

[Ben]

VI Server >>> call by referece

That technology automates all of the above tasks AND work in RT.

Ben

Message Edited by Ben on 07-26-2005 07:48 AM