TestStand and LabVIEW treat polymorphics with instances with private access scopes in classes differently.

[crelf]

Say I have a LabVIEW Class, and that class contains a method that's a polymorphic VI, and that polymorphic has instances. If I set the instances' access scope to private, and the polymorphic to public, then I can force developers that use the class to use the polymorphic VI (and not call the instances directly). That's awesome. I like that.

but...

Say I'm building a TestStand API that uses a polymorphic and its instances as described above. I create a LabVIEW action step, with a Class Member Call call type, and I target my class. TestStand doesn't support polymorphic VIs, which means neither the polymorphic nor its instances show up in the Member Name list.

This means that, to support my LabVIEW users and my TestStand users, I need to create two separate APIs, which is not a happy place to be. Anyone come up against this and found a workaround? Or am I looking at this the wrong way?

[AristosQueue (NI)]

No, you're looking at it the right way. There is no way to support both, nor can I suggest a mechanism whereby NI could modify either TS or LV to support both. The polyVIs are inherently tied to LabVIEW's abilities as a compiler to determine type propagation. TS is just a static declaration of specfic function calls. We could start making TS try to call into LabVIEW to determine which instance to call, but now you have to have a connection to LV just to edit your TS sequences. We could modify LabVIEW so that if a VI is a member of a polyVI then it breaks if you try to invoke it directly instead of using the access scope, but that comes with some interesting baggage.

If you want TS to be able to call your VIs, you're going to have to make them public.

[crelf]

---

@AristosQueue (NI) wrote:

The polyVIs are inherently tied to LabVIEW's abilities as a compiler to determine type propagation. TS is just a static declaration of specfic function calls.

---

I expected as much - thanks for letting me know Stephen.

[AristosQueue (NI) · Accepted solution]

It occurred to me later that we could actually modify TS to be a static link to a particular instance VI via the polyVI. After all, you can manually select a specific polyVI instance. This would just be a way to declare in TS "link to this particular instance of the polyVI." That would allow TS to say "I'm going in through a public interface to get to a private function."

So instead of linking to "A.vi" you might link to "PolyVI.vi : A.vi"

[crelf]

---

@AristosQueue (NI) wrote:

It occurred to me later that we could actually modify TS to be a static link to a particular instance VI via the polyVI. After all, you can manually select a specific polyVI instance. This would just be a way to declare in TS "link to this particular instance of the polyVI." That would allow TS to say "I'm going in through a public interface to get to a private function."

So instead of linking to "A.vi" you might link to "PolyVI.vi : A.vi"

---

Right - and that's what I'd assumed LabVIEW was doing, right?

[AristosQueue (NI)]

Not exactly... I always forget that you can explicitly choose an instance and think in terms of LV auto adapting to the wired type. If you changed the poly VI, a caller of the polyVI isn't broken for lack of an expected subVI if it can just adapt to one of the other instances.

[crelf]

Idea posted: http://forums.ni.com/t5/NI-TestStand-Idea-Exchange/Modify-TestStand-to-be-a-static-link-to-a-particu...

[Parker123456789]

Is this still the case for more recent versions of labview (2019 / 2021) & TestStand 2021? I'm running into the same issue and wondering if this has changed since then

[AristosQueue (NI)]

I can ask. TestStand hasn't told me that they've changed this situation.

[AristosQueue (NI)]

As a workaround, you could create a wrapper VI around the poly VI and then have TS invoke the wrapper VI instead of the poly instance directly. The wrapper VI would use LabVIEW's access scope rules.