Community access scope inside a packed library differ between LabVIEW and Test Stand

[codcoder]

Hi,

I'm having an issue regarding the "community" access scope inside a packed library. Let me exemplify:

I create a library with two sub-libraries. I set two of the vi's to public, one to private and one to community access scope. And I create a build specification for a packed library. Please see the following screen shot.

I also let library A be a friend of B (although not doing this doesn't seem to affect anything).

If I build this library and open it stand alone or add to a new LabVIEW project it behaves as I expect. Only the public vi's are accessible from the outside world but the private and community are not. *This is what I want to achieve*.

The packed libraryThe packed library inside a new project

However if I open the packed library inside TestStand the community vi is accessible for some reason!? But also the private is not.

TestStand

Is this an expected behaviour? Is there something about the community access scope I am not understanding? Is there some setting I should or should not activate? Or have I stumbled upon a bug?

I'm running TestStand 2020 and LabVIEW 20.0.1.

BR, CC

[l.hovs]

Hi codcoder, 

To my knowledge I can say, that yes, this is expected behavior in this case. Actually, it might be connected with difference of environment. Best way to achieve desired result is keeping option as a private.

I have attached links below, where access scope options are well described. 

Setting the Access Scope of Member VIs - NI

Configuring Access Options in Project Libraries - NI

Regards)

[bienieck]

---

@l.hovs wrote:

To my knowledge I can say, that yes, this is expected behavior in this case.

---

But normally Community B.vi could be called only by members of A.lvlib (and B.lvlib of course) right? And calling this vi in TS should not be allowed because how could you call it from complied A library? Directly calling it also should not be allowed, right? It's not in the public scope.

---

@l.hovs wrote:

Actually, it might be connected with difference of environment.

---

What do you mean?

[codcoder]

---

@l.hovs wrote:

Hi codcoder, 

To my knowledge I can say, that yes, this is expected behavior in this case.

---

Is it possible for you to elaborate how this is an expected behaviour?

I have also posted this question in the other discussion forum, as I did not recieve any answers here at first. If I understand this correclty there is a technical explanation why this occurs, and that LabVIEW hiding community scoped VI's is cosmetic only, but if not a bug I still consider it to be bad Ux at a minimum. So why is it implemented like this? 🤔

I have concluded that community scoped VI cannot be executed from TestStand, so there is no risk that a VI you do not want to be used by TestStand is used, but in a sense it conufuses me even more as it implies that TestStand is aware that the VI is not public and therefore cannot be used directly in a TestStand sequence.

I am aware that setting a VI's scope to private will solve the issue of not exposing the VI to the end user but perhaps I should be a little more concrete of what I am trying to achieve here:

In my actual implementation each library "A", "B" and so on are drivers and other utitilites for instruments in a rack assembly. I.e. one library for each instrument.

Encapsulating one instrument per library is pretty straight forward in my head but one of the instruments, that transmits a data stream to the DUT, has a VI for calculation of a checksum. I would like this VI to be accessible by another library, that handles the instrument that receives the data stream from the DUT, while still not exposing this VI to the outside world. Of course I can create a copy of the checksum calculation VI but it doesn't make sense to do so.

If anyone has another idea how this would be achieveble I'm all ears. 🙂

[bienieck]

IMHO, it is a bad UX and laziness. The API already gives you properties to filter out community VIs (see screenshot). Not adding such filtering will save very little time, sweat, and money. The decision not to add it will leave a stench instead.

It can be done using ActiveX as well, so I don't see any blocking points in TestStand.