[BUG] TestStand 2013 receives corrupted data from LabVIEW adapter if cluster contains Waveform array

[JKSH]

Hi all,

I'm having some trouble with data corruption. My minimal test case is below.

I have a VI that returns an array of clusters. My TestStand sequence simply calls this VI and logs its output:

When I run the .seq file (with my VI open), I can see the LabVIEW Front Panel update with the expected values:

However, TestStand doesn't receive all of these values. The Waveform arrays have the correct values, but everything else is empty/zero:

If I remove the Waveform array from my typedef, then all the cluster elements are logged correctly by TestStand.

I've attached a sample test case (TestStand 2013, LabVIEW 2013).

Any ideas on how to make it work?

[HeroOfHyrule]

JKSH,

I ran the program in TestStand just fine and could not get the zero'd out values you refrenced in your pictures. Is there something I'm missing here? What values were you using for the Test UUT's? I believe I was using the correct ones, but this is the only step in reproducing your error that was not explicitly given and I just wanted to check. Thanks.

[JKSH]

Thanks for looking into this, Rob.

Did you mean the UUT Serial Number? I tried a variety:

• (Leaving it blank)
• 123
• 1
• 2
• 3

All gave me the same results.

You don't need to enter any numbers -- simply run the .seq file. The VI is already hard-wired to return non-zero values for "Array", "Number 1" and "Number 2".

Here are some more details of my PC, if it helps:

• Windows 8.1 64-bit
• LabVIEW 2013 SP1 32-bit
•  used non-SP1 when I wrote my original report, but updating to SP1 didn't help.
• TestStand 2013
• Fresh install, all settings at default values
• Using the default "administrator" TestStand account

[Daniel-E · Accepted solution]

Hey JKSH,

Thanks for the detailed report on this. I looked into it a bit last week.

I believe this is closely related to CAR 206892, which describes an issue where waveform data will not appear on the report unless a property or variable is specified for the waveform output parameter. However, this does not completely cover your case, because you're seeing incorrect numeric data as a result of having the waveform in your cluster. I've filed CAR 462209 for that issue, and we will be investigating it more thoroughly.

The issue only affects data that appears "below" the waveform in the cluster. In this sample case, if you put the waveform as the last element in the cluster, I believe it would work properly. I realize your actual data might be more complex than this example, but would this workaround help in the meantime? You could also consider separating out the waveform from the rest of the data, which would also likely work.

As I said, thanks for letting us know, and it's filed in our system now for a developer to investigate the issue. Please let me know if the workarounds aren't suitable for your application--we would be happy to find out a bit more about your overall use case to help come up with a workaround for the issue.

[JKSH]

Thanks Daniel, your first workaround did the trick!

My typedef is used in many places throughout my application, so separating out the waveform would have been painful. However, there's only one waveform array, so making it the last element in my cluster was a simple workaround. The other numbers come through correctly now.

I'm looking forward to seeing the issue fixed at its root though. Thank you for filing the CAR!

[JKSH]

Issue fixed in TestStand 2013 f1! 🙂 Many thanks to everyone involved.

http://digital.ni.com/public.nsf/allkb/D924B98E4C63171786257CAC0073C7F2?OpenDocument&metc=upsrv_ts20...