Using Teststand 4.0.1 with LabVIEW 8.6 issue

[Blueprint]

Hi all,

I have an issue with TestStand 4.0.1 and LabVIEW 8.6 that I hope someone can help me with. To make the issue easy to reproduce, I made a sequence file with 1 action step with a LV 8.6 as module in the main sequence. TS use quite some time to load this module but that is not the problem. Having the action-step selected, I click something else to unselect it (<End Group> for instance). When I now press the action step to select it, TS spend 100% of one of my processors for 15 sec to 2 min loading. The same thing happens every time I select and often when I deselect a step containing LV code.

Is there a compability problem with using TS4.0.1 and LV 8.6? Is there any remedy? I appreciate response on this issue, because it is kind of annoying:)

[Anand_Jain]

Blueprint, 

I am not able to reproduce this issue with a simple case.Can you please post a simple example - (sequence file and VI) to help reproduce this issue.

Thank you 

Anand Jain

National Instruments

[Blueprint]

Ok, the error wasnt that easy to reproduce. I couldnt either reproduce it with a simple VI. However, with one of the VIs I have to use in my test the error provokes. This Vi is however too complex to post here (lots of subVIs). I have investigated further on the matter, and so far I have found out that it is related to one or more of my low level VIs doing communication on the serial line. By systematically making "Action" steps with the low level VIs, I found that one of my VIs had the following error (and additional similar errors):

Failed parsing the XML string:

Reason = 4

Code = 0x6

Line = %3

Position = %4

Text = %5An invalid character was found in text content

So, will my main VI having several calls through this VI be slow to load with this error?

Try the VI to reproduce the error.

Thanks,

OR

Message Edited by Blueprint on 08-25-2008 03:18 AM

[Blueprint]

Hi again,

It seems I was able to find out the second issue myself The previous error I described was fixed by removing the default in-paramter, which was a hex number (01 02 03 04). Apparently, TS didnt like to have a hex number as a default text string string (why btw?).

However, the original issue still remains, and here is an example sequence file with one of our VIs inserted as an action. (I know this VI is not perfect)

Please try to open it (you dont have to run it) and select/unselect the action step a couple of times and see if you get the same delay as I do: selecting it gives a delay of about 3 seconds. summing up multiples of this and other VIs in an action, the load time starts to get so high that it is not possible to work with.

In other words, I would really appreciate if anyone could try and at least give tips of what could be wrong.

Thanks

[Josh_W]

Blueprint,

The problem loading hex numbers has been reported to R&D (# 124073) for further investigation.

I also downloaded the example you created, and with TestStand 4.1 and LabVIEW 8.6, I see the same behavior you do.  I will look into this to see why this behavior is happening.

[Vladimir_Drzik]

Could it be that it's the same problem as this?

http://forums.ni.com/ni/board/message?board.id=330&thread.id=20842

Vladimir

[Josh_W]

Vladimir,

This was reported to R&D (# 124319) for further investigation.  We found the underlying cause of the behavior, and it is the same as the problem with the IMAQ control.  The delay in loading of a VI will happen if a VI has any IO control connected to the connector pane, and that VI has a sub-VI from \vi.lib.  We are investigating this problem for possible solutions.

Right now, there are a few workarounds that you could use.

The best workaround will probably be to remove the control from the LabVIEW connector pane, and use the TestStand API to directly set or get values from the sequence context to LabVIEW.

Another workaround would be to package your VIs using the TestStand deployment utility or a LabVIEW source distribution.  If you choose the option to include all sub-VIs from \vi.lib, then the paths of the sub-VIs will be changed, and this problem will dissapear.  This will really only be appropriate if you have completely finished development of your VIs and are only doing sequence development.

I acknowledge that neither of these possibilities are very good workarounds, and we are actively working on determining the root cause of this behavior.

[Blueprint]

Hi,

How is this issue going?

Btw, how can I follow a bug report to see the development of the case?

Best regards,

Blueprint

[Josh_W]

Blueprint,

We have identified the cause of this behavior, and are working towards a resolution. 

As far as I am aware, there is no automatic way to track a case online.  What you can do is contact our support through www.ni.com/ask and ask an Applications Engineer on the status of the case #.

[Blueprint]

Ok, thanks.