Best way to get a reference to Actor Core.vi?

[AristosQueue (NI)]

Spent a lot of yesterday working on this. "ThisVI" definitely seems like way to go. I stand by original assertion, and accuse (possibly wrongfully) user error. I'm going to meet Staab on Monday to see if something else is going on.

[mike-o-tronic]

I've a similar problem. I want to remotely open and close the frontpanel of some actors. Which I found the using the "ThisVI"-ref solution for. So my ancestor class has the property VI-ref, which I set when I start the descendant's actor core.

But it's a kind of annoying to insert the "set VI ref" by hand. Does somebody know a way to programmatically find the ref for originally called actor core?

[David_Staab]

mike-o-tronic wrote:

But it's a kind of annoying to insert the "set VI ref" by hand. Does somebody know a way to programmatically find the ref for originally called actor core?

Actor Core.vi is launched by ACBRProxyCaller.vi and could have multiple instances open at the same time, which means there's no straightforward way to get its reference. You'd have to get a listing of all VIs open in that context ("app instance") and then figure out which clone is the AC.vi you want using some unique information that isn't native to the VI itself. Constructing a single data field in your class when AC.vi initializes isn't a bad solution to avoid all this mess.

[mike-o-tronic]

Yeah David! You set the hare running! He might not look like beauty at the finish line, but he got there!

And here he is:

I wrote this in my ancestor's actor core. It goes along the call chain until it finds the last "Actor Core.vi" and there is the ref I was looking for.

[David_Staab]

Haha, I don't think that's a closed solution, but if it works for you I'm glad to have inadvertently helped.

[mike-o-tronic]

I know, it's somehow creepy... But it's simple and it works perfect for we wanted.

Is there a closed solution for the general case that a subVI wants to get its caller's reference?

[AristosQueue (NI)]

Mike: I want to stress to you how dangerous your solution is. The guys in R&D who created clones did not know that the Open VI Reference by name mechanism works on clones until I showed them early last year. They were somewhat horrified. The clones are designed to assume there is one and only one open reference to the clones *ever*, and that is the reference that creates them in the first place. That's why using "This VI Ref" is the only safe mechanism. By opening a second reference, you violate the entire design of the clones. The guys demonstrated several crashes that can occur if you work too much with that additional reference.

So, glad you found a workaround. BUT, try to do two things:

1) Keep the operations that you do with that second reference to a bare minimum to minimize your chances of triggering some unplanned for behavior.

2) Make sure you close the second reference *before* your Actor Core.vi finishes running. Relying on LabVIEW to automatically clean up that second reference is a prime way to crash.

The plan was to change Open VI Ref to make this trick no longer work. I talked them out of that plan because it is such a useful trick and the only way to make certain magics work. Fixing the various crashes is problematic -- I haven't taken time to understand the code myself, but my impression is that constantly checking "what if there's a second reference?!" adds significant performance overhead, and operations that could otherwise be assumed to be "only one caller" suddenly have to guard themselves against multiple entry or, worse, simultaneous calls of parallel operations.

So, be careful. Know that you're playing with a situation never contemplated by the designers and, in fact, designed to not happen. But, as always, be pragmatic. LabVIEW is surprisingly robust against situations that we never planned for -- a result of some very good foundations work laid down long ago. So if it works, great. Good luck!

[David_Staab]

AristosQueue wrote:

The plan was to change Open VI Ref to make this trick no longer work. I talked them out of that plan because it is such a useful trick and the only way to make certain magics work. Fixing the various crashes is problematic...

So you made an architectural decision not to fix a bug that causes several critical, likely unfixable errors in your application logic because it might be useful now and then?

[AristosQueue (NI)]

David Staab wrote:

So you made an architectural decision not to fix a bug that causes several critical, likely unfixable errors in your application logic because it might be useful now and then?

Yes. Wouldn't be anywhere near the first time. This is the problem with bugs in the runtime engine. Unless the bug is always a crash or logic failure, customers frequently have working programs that depend upon those few times where the functionality does not crash or fail. Changing the code to be functionally correct breaks those programs. As such, we have to weigh the risk of that fix against the damage done to those users that are working successfully. In this case, I weigh the damage done (no workaround for the lost functionality) as substantial unless/until we are able to provide some alternative mechanism for getting those VI references. Other developers agreed with me.

-- Stephen

[mike-o-tronic]

Hey AQ,

Thanks for the hints. I indeed played a little around and was able to cause some crashes as you said. Basically I just want to have the refnum to be able to open and close the front panels of my actors (ergo of my most decendant actor cores). Since I don't open and close my front panels permanently your first point should be covered just by the purpose.

The solution for your second point was to close the ref before the actor steps out to the next descendant core:

Of course to make this safe the Actor Core, which is opening and closing the refnum, must be overwritten. This is already implemented in my lib, so that I later don't need to care about this.

So far I don't have any problems with this solution. But will let you know, if I get some