VI locks up when front panel is displayed

[knight2]

Hi

Firstly, I apologise if I’ve sent this to the wrong forum – I’m not sure if this is a TestStand or Labview related issue or possibly both.

I have a test procedure developed using Labview 7.1 and TestStand 3.1. It’s run from TestStand’s Operator Interface VI (full version), and executes about a dozen TestStand sequences in turn which call lower level VIs that perform the actual tests.

The code was written on a Dell GX240 Pentium 4 PC, with Windows 2000 + SP4 installed and runs without a hitch. However, I also have a second PC, same model & spec, but running Windows XP + SP3 instead of Win2K. I’ve also installed the same versions of Labview & TestStand on it, and copied across all my TestStand sequences & VIs into the same working directory. However, when I run the program on this machine, again using the same Operator Interface, it executes until about half way through and then hangs up.

In several tests, I call up a graphical user interface VI which displays a picture and prompts the operator to click on either a ‘Pass’ or ‘Fail’ button – the actual text being passed as a parameter. When the lock up occurs, the front panel is displayed, but there’s no picture and the buttons are blank. Up to that point, previous calls to the VI have executed ok.

If I modify the step that causes the problem, to call another VI - for example, a sub VI that doesn’t display a front panel - the new VI executes and the program continues to run. If I then change this VI’s configuration so that it’s front panel is displayed at run time, the problem re-occurs - the front panel outline appears but everything then freezes.

Attempting to close the front panel window, results in either error code –18001 and the message ‘an error occurred accessing the Labview ActiveX automation server’ being displayed or the Windows prompt to close Labview as it’s not responding. Usually, clicking ‘End Program’ causes the PC to crash out & re-boot.

Skipping TestStand sequences, whether they execute the GUI VI or not, just moves the point where the lock up occurs further down the list of tests, to the next step where the GUI VI is called. It’s almost as if something isn’t being closed properly when the program runs, and eventually reaches some limit, but why this doesn’t appear to effect the Windows 2000 PC, I’m at a loss. 

Very much appreciate anyone’s thoughts.

Thanks

Bruce

[Lewis_G]

Hi Bruce,

I found a KnowledgeBase article relating to the error you are seeing.

It describes error 18001 "Error occurred accessing LV activeX automation server". 

Let me know if this helps you out.

This problem may also be due to how you have configured the Distributed COM (DCOM) settings on your machine. You will need to ensure that your DCOM settings allows the LabVIEW ActiveX Server to be launched and accessed through ActiveX automation. Even Administrator accounts can be denied launch and access permissions. To modify these permissions follow the steps below for Windows XP:

• Login to Windows using a UserID that has administrator privileges.
• Select Start»Run and enter dcomcnfg.exe. This displays the Component Services dialog window.
• Navigate to Component Services»Computers»My Computer and select DCOM Config. Ignore the warnings that may appear.
• Right-click on LabVIEW Application, TestStandLVRTS or the name of your LabVIEW ActiveX Server and select Properties to open the LabVIEW Application Properties dialog window. Select the Security tab. 
• You must give permission to the appropriate users so that they can access the LabVIEW server. You should give everyone access permissions and appropriate users launch permission. Only users who have launch permission will be able to access the server. Add permissions by selecting Customize and Edit for each of the three permission settings and manually adding permissions for each user.

I doubled checked that LabVIEW 7.1 and 3.1 are compatible with windows XP and they are.  Just to make sure, it is 32bit or 64bit you are using?

Let me know how you get on.

Kind Regards