Preparing to preload modules...

[Daniel-E]

Hey devonf,

Would it be possible for you to create a simple example that reproduces this problem so we can look into it further? Alternately, you can generate a memory dump file for the process when it is hanging, and we could take a look at that to determine what is happening when it appears to be hanging. If you wish to go with this second route, please send me a private message on the forums so I can send you instructions for generating the crash dump and sending it to us for review. 

Thanks!

[bienieck]

Sorry for thread necromancy but I have similar issue with preloading modules dialog. It is hanging from time to time in my custom OI and I have no idea where to look for solution. The problem is that this hanging is random - some times it is ok, and some times it freeze... I have not found any correlation.

Anyway, have you found a solution for this initial issue?

[JonP]

I am yet another user who gets this problem (using LabVIEW & TestStand 2013). One thing I have found is that the "Preloading Modules..." dialog you get when it hangs often specifies the step before the one that is actually giving the problem. I deduced this because:

1. The VI specified has already been loaded successfully by an earlier step.
2. Skipping the following step in TestStand stops the problem occurring.

I can work around the problem by setting the bad step to "load dynamically" and "unload after step executes", although this is far from ideal as it is a large VI that takes a couple of seconds to load.

This might be related to the fact that the problem VI is called through a LabVIEW project file and internally it calls a SubVI that is also called by an earlier step in TestStand.

[dmysliwiec13]

Since the original forum post is several years old, I recommend creating a new thread so that your questions gets more views. 

Best of luck on your projects!

Danielle

Applications Engineer 

[inniwhoni]

Hi JonP,

I'd like to get some more information from you regarding this issue to try and diagnose the root cause. 

1. Have you seen this issue reproduce in a later version of TestStand than 2013, like 2016 or 2016 SP1?

2. In earlier posts my colleagues suggesting setting Preload Progress Dialog Box Delay to -1 in Station Options > Preferences. Can you try this and see if it has any effect on the issue?

3. Do you see this in the Sequence Editor, an Operator Interface in the LabVIEW Run-Time, or an Operator Interface in the LabVIEW IDE?

4. Would it be possible for you to post a simple sequence file and piece of LabVIEW code  that reproduces the issue for us to test on our end?

We'd like to make sure that we get this issue properly solved for you. You can continue posting on this thread since it has a history of previous instances of the issue.

Thanks,

Kevin F.

Product Support Engineer | Automated Test Software R&D

National Instruments

[JonP]

I was not really asking for assistance, I realise this thread is old but it came up pretty near the top when I searched for the error so thought I should add my findings to the same thread. But to answer your questions:

1. Have you seen this issue reproduce in a later version of TestStand than 2013, like 2016 or 2016 SP1?

The same problem occurs in TestStand 2014, sorry it would take me too long to download and try 2016.

2. In earlier posts my colleagues suggesting setting Preload Progress Dialog Box Delay to -1 in Station Options > Preferences. Can you try this and see if it has any effect on the issue?

The same problem occurs (the GUI hangs) but without displaying a dialog.

3. Do you see this in the Sequence Editor, an Operator Interface in the LabVIEW Run-Time, or an Operator Interface in the LabVIEW IDE?

It does not happen when using the sequence editor, regardless of whether you configure the LabVIEW adapter to use the development system or the RTE.

It does happen with our GUI regardless of whether you run the built exe (which forces the runtime adapter to be used) or from the IDE.

It does not happen when using the LabVIEW Simple UI supplied with TestStand 2014.

4. Would it be possible for you to post a simple sequence file and piece of LabVIEW code  that reproduces the issue for us to test on our end?

Tricky ... our GUI is very large and dependant on lots of things, it would be hard to cut it down and then it might work since the TestStand simple UIs are OK.

[inniwhoni]

Hi Jon,

If you'd like to troubleshoot the issue, I'm happy to assist. There are a few troubleshooting questions / steps that we can try:

1. Does this issue occur with the LabVIEW Adapter Set to Run-Time Engine, Development System, or both?

2. Can you get a crash dump when this dialog is displayed? If the error occurs with the Development System, then we should get two dumps for the problem on two runs, to make sure the issue is consistent between runs.

3. We'll want to try and narrow down the issue to the component of the project and the OI that is causing the issue. For the OI I'd try removing differences between your OI and our shipping OI to isolate the component. Check if you have changed the Execution System that subVIs of your OI are set to use, particularly if they have been changed to run in the UI thread.

For the bad step VI, I'd take a similar approach, looking for any subVIs with changed Execution System properties, and isolating out different parts of the VI to try and narrow down the problematic component.

Regards,

Kevin

[JonP]

1. Does this issue occur with the LabVIEW Adapter Set to Run-Time Engine, Development System, or both?

Both

2. Can you get a crash dump when this dialog is displayed? If the error occurs with the Development System, then we should get two dumps for the problem on two runs, to make sure the issue is consistent between runs.

I have tried three times to upload a couple of dumps but Internet Explorer hangs when I click the "POST" button. Do you have an alternative way I can get the data to you?

3. Check if you have changed the Execution System that subVIs of your OI are set to use, particularly if they have been changed to run in the UI thread.

The OI is not running the problem VI, it is run from TestStand when TestStand is invoked from the OI. In one place the VI (whose execution system is "same as caller") is called directly in a TestStand step, in the other place, which is where the loading hangs, a higher level VI (also "same as caller") dynamically runs the same VI using the "Run VI" API call.

[inniwhoni]

Hi Jon,

We have an ftp site that you can post the crash dump files at ftp://ftp.ni.com/incoming. The reason that I asked about execution systems is that while the LabVIEW OI is invoking the TestStand engine the VIs can still be called in the same Application Instance of LabVIEW. Since the interaction between the two can be complex we have a White Paper that details this behavior: http://www.ni.com/product-documentation/14335/en/. 

-Kevin

[JonP]

OK I have uploaded PreloadHang1.zip and PreloadHang2.zip to the ftp site. These are taken from an execution using LabVIEW 15.0.1 (32-bit) and TestStand 2014 14.0.1.110 (32-bit), Windows 7. BTW when it hangs the process is spinning using 50% of one core.

Yes I understand the wonderfulness of the execution system and how it can trip you up, but I don't quite see why it could cause this problem. The VI called directly in the TestStand step is MyDouble_2015.vi . It is not called though an lvproj (it still hangs when it is). Then there is the subsequent step that runs a VI through an lvproj, which VI then runs MyDouble_2015.vi again using the Run VI API. One thing I tried was to change this later step not to use the lvproj, it still hangs but another clue is that it gives me an error during execution of that VI when running from TestStand:

Method Name: Run VI

VI Path: C:\blah\blah\MyDouble_2015.vi
LabVIEW: The VI is not in a state compatible with this operation.

Which suggests that the execution system believes it is running a different VI with the same name even though the path is identical in both places?