References being lost when passed to Actors

[maynej1]

I have having an issue with passing a couple of references to an actor using the actor framework 3.0.7 (LabVIEW 2011 & TestStand 2010 SP1).

Some background:

My application has three main components:

• Main VI -- is not part of any class and Launches UI Actor.
• UI Actor -- Launches the teststand actor
• TestStand Actor -- Initializes and starts teststand.

The two references showing similar behavior (invalid reference) are the TestStand App Manager control and the "Current VI's Menubar" reference.  The App Mgr control is on the front panel of the UI Actor's Actor Core.vi.  The menubar reference is retrieved in the block diagram of the UI Actor's Actor Core.vi

Now,

When I run the Main VI I get an error in the TestStand Actor's Actor Core.vi (Remember Main VI launches UI Actor launches TestStand Actor) because the App Mgr and menubar references are invalid (.  I have checked and verified that in this scenario the references are valid in the UI Actor before it launches the teststand actor.

If I run the UI Actor's Actor Core.vi stand alone (i.e. run it top level) the App Mgr and menubar references are passed to the teststand actor, no error occurs, and the code functions as expected.

Why would these references be invalid by simply starting a different top level VI?  Could it have something to do with when the references are passed vs. when the front panel is loaded into memory?

I tried putting the App Mgr control on the front panel of the Main VI and passing it to the UI Actor and then to the TestStand Actor.  This works....

Anyone have any experience or knowledge to why this is occurring?

[AristosQueue (NI)]

Well, to begin with, I'd advise against sharing any references between actors. A big part of the point of the Actor Framework is to standardize all interaction between the actors to only be through the communication queues. Does that sound too restrictive? It isn't. You'll have to trust me on that point, but if you focus all your communications through those queues, your app has much more predictable behavior and various applications that have used the AF show that it scales just fine. Other shared references just introduce problems of who has lifetime control of the reference (which you're running into), who has rights to access the reference at any given time, who is responsible for reporting errors from the reference, etc.

BUT... since you have shared references... the cardinal rule of LabVIEW: A reference goes invalid when the top-level VI that opened it goes idle. So in your case, it sounds like one VI is obtaining the references, passing them to another VI, and then the first VI is exiting and taking the references with it.

[maynej1]

Ok, and thanks for the advisement.  I don't think any vi's are shutting down because I can see them running and also verified it with the desktop execution trace toolkit.  I initially went with keeping the TS app mgr control on the front panel of the teststand actor core vi, but I kept getting crashes, and then finally a error 3 (cannot load vi, yikes! revert source control).  So I went with the passing method because it didn't crash LV, and did function in the one scenario listed above.

I just moved it back to see if I can get it to crash again.  No crashes, but still no worky.

So right now I have the TS app mgr control on the front panel of the teststand actor core.vi.  Now get this....  If I have a main vi (not belonging to any class) launch the teststand actor directly everything works and teststand starts up and shuts down fine.  If I have the SAME main vi launch a different actor that then launches the teststand actor then error (TS app mgr control is not valid).

I am going to see if the culprit is the way the private reentrant Actor.vi is opened and ran using the ACBR node (...and having this call occur multiple times).  I have used the teststand app mgr control many times and have never had it give me this much inconsistency with LabVIEW.  I am probably missing a fundamental requirement with using the Teststand app mgr control, but I can't find anything in any of the documentation (other than it needs to exist).

Thanks for the help and advisement.  I'll keep digging...

[AristosQueue (NI)]

I've not done enough work with TestStand to comment further on this.... I'll flag some of the TestStand team to see if they can think of anything.

[LVB]

Any chance you could share your code with the community?  If so, I would be willing to take a brief look for any issues.

[maynej1]

I am actually able to get it to start TS now....kinda....  It looks like when another sub-actor was launched immmediately after my teststand actor then the teststand app mgr ref would go bad.  If I put a breakpoint after teststand actor is launched, wait until the teststand login prompt is displayed, and then continue the teststand app mgr reference is all good!  Teststand starts up fine and my additional sub actor is displayed A-OK.  So with seeing this I just had the teststand actor launch last (see below)

With this and the previous implementation my STOP message is not executing when both actors are launched( launch one or the other and the stop message works fine).  I have a Stop Core.vi override for the main actor you see here.  It is not executing when the event case shown below is ran.  BUT it is still queued.  When I go to File >> Close All and then select stop all running vi's I then see my Stop Core.vi override execute (weird).  See anything wrong with this?  I'm sure I am missing some fundamental detail.  I will be posting my code shortly.

[maynej1]

Here is a source distribution with the actor framework included.

Open OICommunityDebug.lvlib

• Main.vi -- dumb vi to launch initial actor, MainUI.lvclass.
• MainUI.lvclass -- main actor which launches a display and teststand actor
  • Actor Core.vi and Stop Core.vi are overridden
• TestStandController.lvclass -- teststand actor
  • Actor Core.vi, Stop Core.vi, and Handle Error.vi are overridden
• BatchDisplay.lvclass -- display actor
  • Actor Core.vi and Handle Error are overridden.

[LVB]

I just took a look at the project.  TestStand operator interfaces are quite complex due to the interaction the TestStand ActiveX server, ActiveX controls, and callbacks.  The execution system of your VIs must be considered:

From the "Using LabVIEW with TestStand" document on page 6-7:

When a case performs ActiveX operations that can process messages or performs TestStand operations that can call back into LabVIEW, the application must perform these operations in a LabVIEW execution system other than user interface, such as standard or other 2.

I would suggest a few things:

1. Review the execution systems used in the "Simple OI" under the <TS Public>\UserInterfaces\Simple\LabVIEW
2. Modify your code to use the "User Interface" execution system by default.
3. Determine the exceptions, based upon the Simple OI example and the rule above.  For instance, the IApplicationMgr.GetEngine should run in "Other 2" (as seen in the Simple OI).
4. Debug in small incremental steps.  It looks like you are already doing this.

I believe your challenge may be completing item #2.  Since this code is running in the Actor framework, I am not sure how the "Same As Caller" setting for execution systems is honored.  Is the top-level VI's (who launches the actor) execution system propagated through to the Actor Core?  Maybe AristosQueue could comment on how this works in the Actor Framework?

[maynej1]

Yikes!  It looks like in all my original debugging (before this post/learning the framework) I disabled the reentrant property of my main Actor Core.vi. This is the reason for the queues not executing.  The parent call to the actor cores wouldn't run until the first one stopped.  I reinstalled the framework. 

I knew the queues not executing was something basic. 

I am still having issue with the app mgr control becoming invalid if teststand is launched first then the display is launched.  For now I have the teststand actor being launched last, and all seems to be functioning.

[maynej1]

Thanks for the input LVB.  I will do my homework on the execution systems.