Invalid LV Queue Ref in TestStand

[Oli_Wachno]

Hi,

having trouble storing LabVIEW queue refs in TestStand: I'm trying to have an asynchronous LabVIEW process running in parallel to the regular test sequence. Communication with the async process takes places using a LV queue.

So what I do:

1.) Call a VI that sets up the queues and returns the Q refs

2.) Store the Q refs in Numeric variable within TestStand

so far, it seems to work. When stepping into the VI and probing the references, the numeric values correspond to those TestStand shows in the local variables shown during the execution

3.) Call another VI that checks the queues for sanity first of all (and fails: Get Queue Status primitive returns Error 1)

when probing this VI, the numeric representation of the queue refs seems to be ok.

So... TestStand is only used for storing the refs which should be ok according to the manual.

Any ideas?

Cheers

Oli

[Oli_Wachno]

Clicked the Post button to fast

I started the Trace Toolkit. As you can see in the screenshot attached, it identifies the open queue refs as memory leaks.

Is it possible that due the different context between TestStand and LabVIEW the queue refs are diposed?

BTW Using TS 2013 & LV2012SP1

[Suse]

Hi Oli,

which versions of LabVIEW and TestStand do you use?

When I understand right, you have a queue reference from a LabVIEW VI and you want to transmit the reference to other steps in TestStand. right? Can you post a little sequence?

Best regards

suse

[crossrulz]

I would very highly recommend not storing the ref nums in TestStand.  Instead, use an Action Engine to store your queue and send the data.  I do this all the time and it works beautifully.

[Norbert_B]

While i also recommend to store LV internal data in an Action Engine, it should be possible to pass the references to TS and pick them up in the next module.

Can you please post an example, Oli?

I suspect an issue with "Application Instances". Is it possible, that one of the modules is running in the context of a LV project while the other one isn't?

Please check the step settings for usage of "lvproj"-file...

Norbert

[Suse]

I think it might be a LabVIEW issue. Which versions do you use??? Maybe there is a patch for this reference issue.

[Norbert_B]

OK, i tested it out and encountered the same issue..... with a certain inconsistency!

I used three separate VIs essentially encapsulating the three functions:

- Obtain Queue

- Enqueue

- Get Queue Status

I created an I32 queue using obtain, passed that refnum out. As TS doesn't have a type for "LV Queue" (as it depends on the datatype in the queue!), it is simply stored as numeric.

Just like you, Oli, i've seen the address of the queue correctly passed to TS. Noteably, the probe in "QueueRef Out" is of type variant telling me that i used an unnamed queue.

Passing the RefNum to the Get Queue Status VI works fine. A probe on "QueueRef In" tells me the correct address, it even states "Unnamed". I haven't checked for named queues.......

So let's enqueue things....

Here comes the inconsistency:

When using the same QueueRef In element as at Get Queue Status, the probe in the Enqueue VI tells me: Not a RefNum!

I don't know where this derives from, but i have found a solution: Pass the QueueRef to the Enqueue VI as numeric value. In the module, use the Typecast function to cast it to a queue RefNum (beware to use the identical datatype as for creation!).

This works well on my machine, should work for you as well....

Norbert

[Oli_Wachno]

Hi Norbert,

thanks for your help. Already feared, I nedd such a workaround.

Considering of using a named queue instead a numeric and a typecast and then just use the queues' name. If I have to change the interface anyway...

Best Regards from Geneva

Oli

[Oli_Wachno]

Me again,

the I32 and the typecast did not fix the problem... the behaviour is very similar. After passing the (typecasted reference) to the VI, the first Queue primitive (tried Get Status and Dequeue) throws Error 1

WIll try the String version....

[Norbert_B]

Oli,

have you used the type cast as shown in the following example)?

Norbert

PS: Due to a disturbing bug in Lithium only the screenshot 😞