I am creating NI Knowledgebase article 28989AAT that will contain the following information.
LabVIEW may hang when your client application runs VIs using the LabVIEW ActiveX automation server that is provided by the LabVIEW 6 development environment. This hang occurs without error and may be misinterpreted as a hang in your client application.
This problem is restricted to the LabVIEW development environment. It will not occur if your client application calls into a LabVIEW ActiveX automation server provided by a LabVIEW executable that you created with the LabVIEW Application Builder.
Typical Scenario:
This problem was first detected when running multiple TestStand sequences in parallel that in turn ran LabVIEW VIs. In this case, TestStand, the client application, was running a large number of VIs using LabVIEW ActiveX automation server. Eventually all sequences appeared to hang in mid-execution, at a step that called a LabVIEW VI. The problem occurred anywhere from 20 minutes to 8 hours after initiating execution of the sequences. See the suggestion TestStand solutions below.
1) Before your client application runs VIs using the LabVIEW ActiveX automation server that is provided by the LabVIEW 6 development environment, open the attached Thread EC Fix.vi. When this VI is loaded it in turn loads ThreadECs.dll into LabVIEW's memory space. ThreadECs.dll must be located in the same folder as Thread EC Fix.vi. This DLL must be loaded in the memory space of the LabVIEW application before and while you run VIs using the LabVIEW's ActiveX automation server that is provided by the LabVIEW 6 development environment.
Cause:
The LabVIEW 6 development environment is unaware that it should appropriately release certain resources required to run a VI using the LabVIEW ActiveX automation server. Since the resources are finite, LabVIEW eventually hangs when the resources are used and not released. ThreadECs.dll detects and notifies LabVIEW when these resources should be released.
2) If you are distributing your application, you may not have the LabVIEW development environment installed on the target machine. In this case, you might use a LabVIEW ActiveX automation server that is provided by a LabVIEW executable you created with the LabVIEW Application Builder. The LabVIEW executable uses the LabVIEW run-time engine, which does not have the problem described in this knowledgebase article.
3) You can use LabVIEW 5.1.1 or earlier, under which this problem does not occur.
4) If you encounter this problem when using TestStand, as described in the Typical Scenario above, we recommend that you call Thread EC Fix For TestStand.vi from the first step in your process model entry point. Copy the contents of the attached zip file to \Components\User\Models. Select the LabVIEW ActiveX Automation Adapter from the adapter ring control of the TestStand Sequence Editor. Add an Action step to the Setup step group of both the Test UUTs sequence and Single Pass sequence within your process model. Configure each of these steps to call Thread EC Fix For TestStand.vi. This will ensure that Thread EC Fix For TestStand.vi and ThreadECs.dll are loaded into LabVIEW's memory space before any sequence is executed using the process model entry points, Test UUTs and Single Pass. If you are going to execute sequences without the process model entry points then you will need to add a similar step at the beginning of each sequence that executes LabVIEW VIs, to ensure that ThreadECs.dll is loaded in LabVIEW's memory space before your sequence executes. Typically after distributing your TestStand application, your sequences use a LabVIEW ActiveX automation server other than that provided by the LabVIEW development environment. In this case your distributed application will not encounter the problem explained in this knowledgebase article.
