NI TestStand

cancel
Showing results for 
Search instead for 
Did you mean: 

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

Solved!
Go to solution

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?





Copyright © 2004-2020 Christopher G. Relf. Some Rights Reserved. This posting is licensed under a Creative Commons Attribution 2.5 License.
0 Kudos
Message 1 of 7
(4,136 Views)

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.

Message 2 of 7
(4,132 Views)

@AristosQueue 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.





Copyright © 2004-2020 Christopher G. Relf. Some Rights Reserved. This posting is licensed under a Creative Commons Attribution 2.5 License.
0 Kudos
Message 3 of 7
(4,124 Views)
Solution
Accepted by crelf

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"

0 Kudos
Message 4 of 7
(4,115 Views)

@AristosQueue 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?





Copyright © 2004-2020 Christopher G. Relf. Some Rights Reserved. This posting is licensed under a Creative Commons Attribution 2.5 License.
0 Kudos
Message 5 of 7
(4,112 Views)

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.

0 Kudos
Message 6 of 7
(4,109 Views)
0 Kudos
Message 7 of 7
(4,063 Views)