TestStand 2012 preload problem

[Jimmy_Reumuth]

Could you try turning off the preload progress dialog to see if that is the problem? You turn it off through Configure >> Station Options >> Preferences, then set Preload Progress Dialog Box Delay to -1.

[CoastalLabVIEWER]

It looks like you got it Jimmy.  Taking away the dialog and from the time I click the Test UUTs button until I get the serial number prompt is about 15-20 seconds.  With the dialog it is taking in the 5 minute range.

I don't know if this helps anyone at NI who might see this thread and try to debug this, when it seems to be "looping" forever it isn't displaying anything on the Module Path line.  And then in the last few seconds right before it stops running it will start displaying module paths.

[dug9000]

With the dialog is it finishing after 5 minutes or is that just as long as you waited?

-Doug

[CoastalLabVIEWER]

Hi dug,

Yes.  I let it run twice and at ~5 minutes both times it completed.  Essentially I have a particular.seq that has many sequences in them (~150).  The 5 minute run was with deleting down to 5 sequences.  I'm running it again with 20 and it got to 10 minutes when I finally just canceled it.  When we first really noticed this problem with the full .seq we let it run for 20+ minutes and it was still going.

So, a couple more things I've just tried:

Setting the dialog to -1 and it loads the full .seq file in ~2 minutes.  I did this twice (unloading all modules in between trials).  I set the dialog time to 180 seconds and at the 180 second mark it still hasn't preloaded and it begins displaying the dialog with the "looping" behavior.  I canceled it at the 6 minute mark still Preloading.

[dug9000]

Please elaborate on what you mean by "looping". Also, does the sequence file call sequences in other files or only within the same file? Is there anything unusual or unique about these sequences or the sequence calls or other steps they contain? What kinds of step modules are you using (e.g. LabVIEW vis, dlls, .net dlls, etc.)? If LabVIEW are you using the runtime engine or the labview development environment? Are you using LabVIEW projects?

We have not yet been able to reproduce this problem. Thanks for any info which might help us to do so.

-Doug

[CoastalLabVIEWER]

By "looping" I mean I see the same sequences and vi's continuing to display in the dialog box over and over and over again.  I'm calling it looping only because my first theory was as stated before, Sequence A was calling B and vice versa causing it to be stuck in some kind of odd loop.

Some details:

About 100-150 module calls

90% of these are LabVIEW with a few being ActiveX to the TestStand APIs.

The model launches 3 executions.  One of these executions launches 3 executions.  We do a bit of threading in some .seqs and a bit of call by expression.  Otherwise It's fairly vanilla stuff.

Using the development system 2012 (no patches). 

Not using projects.

I've tried to to narrow down one particular sequence that might be causing the problem but as it takes minutes per trial it's real slow work.  Can you tell me how the preload is doing it's thing?  Is it iterating every single step (starting with the model?  The client sequence?) following it down as far as it can and preloading any modules it hits?  Would I expect to see the same VIs pop up over and over again in the dialog box?  I know with 100% certainty that I see some of the same sequences/VIs display over and over again in the dialog that are called only one time when we enter our model entry point (so far only Test UUTs actually) during an entire test run, client sequences aren't calling these VIs.

[dug9000]

If you have the same vi used in more than one step, then it should show the same vis more than once, though it should be much faster to load them after the first time. It should not show the same exact step over and over again though. Since it does complete eventually, it does not seem to be in an infinite loop. Perhaps there is a performance problem with preloading the vis when using the dialog. Do you perhaps have recursive search directories that take a while to resolve? What could be happening is that with the dialog the resolution of the module paths might be getting done more times and if that is slow it could make a significant difference in performance. I think the resolution is cached though so that's probably not that likely. If you have custom search directories though it might be something worth looking at. Especially if some are to network paths.

-Doug

[Al.B]

Hi,

If you are experiencing this issue, please either post or private message me with the sequence file and code modules you are using.  This will help us to identify the issue, and fix it if there is indeed a bug in TestStand causing this behavior.  Thanks for your help!