Limitation of the number of connectors by LabView VIs used in TestStand

[pericles]

Hi!

I use a LabView (8.2) Vi in TestStand and have following problem:

my VI has a very large cluster as in - and -output (as output it is even a cluster array). The cluster is connected to in/output connectors on the connector ane of the VI. TestStand seems not to have any problems with this cluster, any element of it is well accessible. But if I add a new connector to a connector pane - a queue reference, Teststand becomes unable to load this VI any more. The same happens if I connect to output pane a cluster and an array of these clusters. I get an error message in the red warning icon "LabView: Property name: Connector pane: Checksum old".

Does anybody know why I get this error ? The number of connectors by LabView is limited to 28, otherwise one should use cluster. I use a cluster with much more elements than 28, but it is connected only to one connector. Does LabView/TestStand counts not only connectors but the number of elements?

The queue ref which I would like to connect to the output connector will NOT be used by TestStand, but I need this connector for other usage of this VI.

It would be very helpful for me if somebody could explain me this effect.

With best regards

[RayFarmer]

Hi,

Can you post an example highlighting the problem. What TestStand version are you using?

regards

Ray Farmer

[pericles]

Yes, I add a VI with a corresponding control. The VI does nothing - it simply shows , that if it is put as a step into TestStand, it can be loaded, if only cluster is connected to the output pane. If Queue ref is also attached, the Test Stand can't load VI any more. I add also screen prints to show it. You see also TestStand version (it is 4).

[pericles]

I could attach only 3 files, now come VI, control and another picture:

[RayFarmer]

Hi,

I have a feeling that TestStand doesn't know anything about labview queued references.

You would be better off leaving them in labview and not pass them back into TestStand because while the VI remains loaded any other VI that uses the queue will still be able to use it.

Anyway I'll have a look at your example.

Regards

Ray Farmer

[pericles]

Oh, he doesn't need to! I would use this connector for other needs, e.g. when this VI acts as subvi in other LabView applications. I have read in the manual, that Test Stand doesdn't use que ref, but is able to save it as a number. for me it is even not necesary to save it - it sould be only present. Thanks a lot, if you find an explanatin for me!

[RayFarmer]

Hi,

I tried your VI without and with queue onthe connector pane. I was using TestStand 3.5 and LabVIEW 8.6.

Without queue, it was fine.

With queue, I received a Memory Full error when I tried the Reload Prototype. (see attached picture).

I created another VI, but this time I just used Item_Collection_HK_Events cluster instead of the very large cluster you had in your example.

With the queue reference on the connector pane the VI loaded ok into TestStand.

Therefore, your VI's queue data must be too large to handle.

I know you said this was used as a subVI in other applications, so why not use it as subVI to a VI you call in TestStand and instead od calling it direct and pass the queue reference as a Variant. (see attached picture). This works fine when loaded into TestStand.

Regards

Ray Farmer

[pericles]

Hi!

Thank you very much for searching of a solution for my problem. What I have learned is

- the cluster is too large to be handled and that may cause problems by LabView and TestStand

- the variant is a good alternative to pass agruments which cannot be passed in another way.

But - is there any known limitation  of the member of cluster elements? Or is it always an experience?

If I put my cluster in a queque and try to load it in TestStand, it doesn't work because the que data are too large. But if I do actually the same and convert que reference to the variat it works. Why? Does it mean that in this case TestStand doesn't check what happens in VI? But it may cause other problems by running this VI unter TestStand, right?

Best regards and many thanks for your help!

[Manooch_H]

Hi Pericles,

The problem you have experienced is due to an upper limit in the size of data connected to the connector pane rather than an upper limit in the number of elements. The current workaround is to create a wrapper VI. There are multiple implementation approaches that you can take, one being Ray's suggestion, and you'll have to find the one that works best for you.

This was reported to R&D (# 175068) for further investigation. In the meantime please continue to use the suggested workaround(s). Thanks for bringing this to our attention!

[pericles]

Hi, Manooch_H,

thank you for your comment because it is very useful to know the reason of the problem. I'll use a wrapper VI, which doesn't need to have queque ref as in or output. I attach a pic of a wrapped VI which is loaded inspite of a several clusters connected to output connectors. Obviously TestStand doesn't like que ref but manages clusters.

Is it possible to find the R&D (# 175068) in the knowledge base?

Regards