Actor system with TestStand - LabVIEW runtime adapter

[wrkcrw00]

I have an actor based application that I call from TestStand. When TestStand is configured to use the LabVIEW development adapter, the sequence works fine. When I configure TestStand to use the LabVIEW runtime adapter, the actors fail to open. 

I do NOT have the "show front panel" on the launch actor enabled. My main actor does pop up it's UI but I use an invoke node on the block diagram to do that. 

I created a simple test harness in LabVIEW that mimics the TestStand sequence, then built that into an executable and was able to run that just fine. I even did a remote debugging session on the executable to see if I had any hidden errors or other discrepancies when launching the actors. I found nothing.

This might be solely an issue with TestStand, but I have a feeling it's related to using actors. I'm not quite sure how to proceed debugging actors in TestStand using the runtime adapter. Any ideas?

[justACS · Accepted solution]

Most likely, your Actor Core.vi is broken.  The most likely cause of that problem, in this case, is that your VI cannot find Actor.lvclass:Actor Core.vi.

That happens because LabVIEW Run Time does not include a copy of vi.lib, and thus does not have access to actor.lvclass.  You will need to either:

1. create a source distribution of your actor(s) that explicitly includes actorframework.lvlib and its contents, or
2.  create a PPL of your actor framework, and link your actors to it.

You can exercise Option 2 as early as LabVIEW 2015, but you are better off if you use LabVIEW 2016.  If you do exercise this option, you will need to change your actors to point to the new PPL (which can be simple or tedious, depending on how you go about it), and then make sure to include your new PPL in the projects you use to write your actors (assuming 2016 or later).  Once the PPL is in the project, the provider tools will create new actors and messages that point to the PPL instead of the vi.lib copy.

See here for details:  PPL Support in Actor Framework Project Provider

[AristosQueue (NI)]

This sort of thing can happen when you call any VI that is part of vi.lib from outside of LabVIEW. The runtime engine doesn't know how to resolve the references unless you copy the vi.lib subVIs.

[wrkcrw00]

Just to make sure I understand, I'm going to explain what I think you said. Please correct if I'm wrong.

From TestStand, VI's can be called directly using the runtime adapter (since TestStand can run a VI with LabVIEW runtime), but any reference those VI's make to vi.lib can't be resolved b/c TS is outside of LV. The reason I can create an executable and it works is because when building an application, all referenced VI's (even in vi.lib) are included in the build. 

This seems like something of an oversight with TestStand. I can see many cases (in fact I had another case earlier this week) where VI's I want to run in TestStand reference code in vi.lib. I will look into the two options justACS suggested.

[AristosQueue (NI)]

It's not an oversight of TestStand, really. It is something that would be true of any third-party application that calls into LabVIEW to run VIs. Either they call into the IDE where all those VIs are available or those VIs have been packaged up (somehow) for use in the run time engine.

TestStand just isn't special.

[wrkcrw00]

Fair enough. I would have thought that  LabVIEW and TestStand would have special treatment of each other since both are made by NI. It is what it is.

So, is there a convenient way to change over a bunch of actors and messages to inherit from the new PPL other than individually changing the inheritance? My actor system isn't very big, yet, but it's still a few dozen manual operations (and I might miss something!)

[AristosQueue (NI)]

> ... is there a convenient way to change ...

Not really. But you don't have to worry about that if you build all of your VIs into one PPL. Or use a source distribution. But if you need separate PPLs, no, there's not a convenient path.

[wrkcrw00]

I created a PPL for my projects, included all my vi's and relevant dependencies and it works! Thanks for the help!

[justACS]

My understanding is that you can right-click on a .lvlib in a project and replace it with a .lvibp, and the project will handle the relinking.  (You have the opportunity to point to an existing PPL.)  My understanding is that the relinking is imperfect, so you may still have some work to do.  So, in theory, you *should* be able to drag actorframework.lvlib from dependencies into the project and do this.  AQ, do you know for sure if this does or does not work?

Disclaimer:  I have not tried this.  So back up your project first, and try a few test cases before you pull the big trigger.

If that doesn't work, you can probably do it with VI Scripting.  Most of what you need would be in the project provider code, most of which is not protected.

[justACS]

---

@AristosQueue (NI) wrote:

> ... is there a convenient way to change ...

Not really. But you don't have to worry about that if you build all of your VIs into one PPL. Or use a source distribution. But if you need separate PPLs, no, there's not a convenient path.

---

I'd recommend having a separate PPL for the AF library.  It's cleaner from a package management perspective.  I think you'll be happier in the long run.  I'd avoid putting all of your actors in a single PPL, too.  There may be practical limitations to the PPL technology that argue for the monolith, though.