Module Pre-Load runs slow after reboot

[GSinMN]

Rebooted testing controller (first time in quite awhile) and now the Module Pre-Load runs significantly slower than it used to.  Now takes several minutes when it only took a few seconds before.  Affects all sequences run on this station, not just tied to one sequence.  Does not appear to be any other applications running that would hog memory.  Tried rebooting again with no change.  Have not made any changes to Station Options (that we are aware of).  Any ideas?  Running Test Stand 2013 and Labview 2013.

Thanks.

GSinMN 

[Norbert_B]

There could be several reasons. I understand that the affected code modules are written in LabVIEW.

Options:

a) The modules are or contain VIs which are not in the correct version (LV 2013) and have to be recompiled. In order for this option, the LV module adapter in TestStand has to be configured to run VIs in "Development Environment". In "Runtime Engine", the VIs wouldn't work at all.

b) Your harddrive is close to full and is heavily fragmented. If you have a HDD (so no SSD!), you should use the MS Defrag tool to defragment the harddrive.

c) You have changed settings in Anti-Virus-Software or maybe Firewall. This changes don't need to be done by yourself manually... there have been incidences where settings were modified by e.g. hotfixes of software. This could lead to some kind of access restriction which resolves after hitting a timeout.

There are possibly more reasons, but these three are the most prominent i can think off.

Norbert

[GSinMN]

Hello Norbert,

  Thanks for the quick response.  Your first suggestion about file version may have an impact, because we have development done on several PCs, and the actual test rack is shared by several people.  There is a possibility that a file from Labview 2014 got loaded, but we haven't found it.  I think that the version of Labview installed on the controller would have had to change for it to not recognize any of the Labview modules.  If one file was a different version, it would only have trouble compiling that one file.  I did double check some of the modules to make sure they do not need to be resaved. 

  As far as the other two suggestions, we have discounted them.  All files are local (no network access) and the hard drive is less than 30% full, and scheduled defrag is active (once a week). 

Please share some of your other suggestions that you mentioned.  Thanks.

GSinMN     

[GSinMN]

I have an update to share:

  Base on Norbet's suggestions, we attempted to set the module adapter to Run-Rime rather than Development, in hopes it would identify the offending code module.  It of course caused an error, but it was on the first VI (so we expect that it would happen for all VIs). After changing the adapter back to "Development Mode" the problem appears to have corrected itself.  We are attemting to re-create the problem, but it would still be nice to know what caused it.  Any further suggestions would be appreciated.  Thanks.

GSinMN

[GSinMN]

Sorry, that should say "Run-Time"