Teststand reporting [Error Code: -18005, Failed to convert a TestStand type to a LabVIEW type or vice versa.] for flattened string input

[twilson1111]

Hi,

I am using TestStand 2010 and LabVIEW 2011 on Windows XP.  The programs are being deployed with run-time licensing on PCs for the purpose of automated test.

I am running into an intermittent issue where one of the VIs I use in my TS sequence is reporting [Error Code: -18005, Failed to convert a TestStand type to a LabVIEW type or vice versa.] for an input which is a binary string.  The content of the string is a flattened version of a fairly complex data structure.

I see that some people have run into this error code with regards to VISA refnums, but this is the first time I have seen a binary string be a problem.

Shouldn't TestStand be able to handle any binary string regardless of its contents?  The error is fairly rare, it only happens once every few hundred calls maybe, but that is enough to impact my automated test throughput.

I have recently updated to SP1 for TS and LV.

Tom

[dug9000]

Are your machines configured to use English as the default code page (i.e. default language for non-unicode programs)? Are you sure it's the binary string parameter that is leading to this issue (are there any other parameters to the VI, is the string passed directly or is it in a cluster)? Do you have the string configured as a binary string in teststand (i.e. is the binary string checkbox checked)?

-Doug

[twilson1111]

Hi, in response to the 3 questions.

1.On the deployment PC, the cmd command "chcp" returns 437.  On the development PC, the same command returns 850.  Is this a valid method of figuring out default code page?

2. The error string includes the text "Flatten In", which is the name of the binary string in question.

3. I double-checked the TestStand string type field and it is definitely "Binary".

Thanks for the help.

Another detail worth noting is that before being input into a VI, the binary string is passed into a sub-sequence "by reference".

[Al.B]

Hi twilson,

Would it be possible to post the problematic VI or another VI that reproduces the issue?  If you would rather not post it publicly, let me know and I will send a private message with my contact information.

Also, I have a couple additional questions:

1. Does this behavior only occur on deployed machines, or on development machines as well? If so, does it occur with both the runtime engine and development system adapters? I am assuming you are using the LabVIEW runtime engine adapter on your deployed machine

2. If you create a sequence with just this VI in a loop, does the behavior occur?  Any simplification will help us narrow down the cause.

[twilson1111]

Hello,

Here is the problematic VI:

[twilson1111]

The issue only happens on deployed machines.  In my TS sequence, the adapter is configured as "Development".  However, the deployment machine only uses runtime engines, so I assume this would mean that the adapter is actually the run-time version.

Is there a way to check on my development PC when I upgraded to SP1 for LV and TS?  This issue just started cropping up and it is suspiciously close to when I upgraded to SP1, although I'm not able to say for sure without having a way to find out when I upgraded.

Tom

[AmitKaria2k]

All,

See the solution that worked for me : http://forums.ni.com/t5/NI-TestStand/error-18005/m-p/2189652

- Amit Karia