Unable to Launch 'LabView.Application' ActiveX automation server. [Error Code: -18001]

[Mack Truck Engines]

I am attempting to deploy a TestStand sequence using the User Interface\User\Simple\ CVI\TestExec.exe. I built the deployment, installed and ran the application fine, but when I try to run the sequence I get this error (see attached). I suspected I was missing something. The target machine (lab PC) has TestStand (4.0.1) and LabView (8.5) installed but only has an evaluation license. When I tried the evaluation license in the development environment and tried to run the deployed sequence I get the same error (and on another PC with an evaluation license). However, when I log in to the lab PC with my own login, I have a license on my PC, everything works fine. What am I missing in the runtime deployment that it requires a development license to run? How do I specify the runtime license in the deployment?

Thanks.

[Snowman 6008]

Mack,

Make sure that the LabVIEW Adapter is configured to use the LabVIEW run-time engine and make sure that you include your testexec.ini (located in <TestStand>\Cfg). Are you using the ActiveX automation Server? Also what operating system are you deploying to? There is a really good KnowledgeBase article on 18001 errors in TestStand: 18001 Errors using TestStand and LabVIEW I would strongly suggest that you take a look at it, if you haven't already. 

[Mack Truck Engines]

I am not sure how to do most of the things you reference.

- configured to use the LabVIEW run-time engine --------------------How do I check this?

- Are you using the ActiveX automation Server?  ---------------------How can I tell? I am not building the exe.  

The target is a Windows XP PC, so is the development computer.

I looked at the KB article and DECOM Config. It seemed the settings were not the problem. My guess is the license but why would that cause an ActiveX error? When I use my own login, the sequence runs on the same machine. The machine is supposed to have a Deployment Debug license.

[Snowman 6008]

Mack,

You can change your adapter settings using the information in this link: http://forums.ni.com/t5/forums/replypage/board-id/330/message-id/23964. You will not be able to change the adapter settings from the deployment machine since you are using the simple user interface. You can change the adapter in your development machine and then re-deploy making sure to copy the settings over. This is most definetly a licensing error. If you can open the user interface then your machine can find the correct TestStand engine license. There is no LabVIEW or CVI license needed to use each of their runtimes. What is that step doing that is getting the error? Also have you tried running a super simple sequence file that calls no code modules on the deployment machine? We need to figure out if this is an error with the code that TestStand is running, or an error coming from within TestStand. Based on current information, it seems like the problem comes from the code we are calling possibly needing depenencies/files/something that is not on your deployment machine, but is on your development machine. 

[Mack Truck Engines]

Unfortunately we lost our testbed hardware yesterday. A powersupply decided to quit working which complicates resolving this problem.

The TestExec GUI does work after requesting the evaluation license (should it not be doing this? re: "There is no LabVIEW or CVI license needed to use each of their runtimes."). I just found out that the PC connected to the testbed hardware is supposed to have a deployment license but that license was allocated to a different machine. That should be resolved shortly. The error appears after Open Sequence File and selecting Single Pass. I believe the step that causes the problem is the first step which is a VI that established a connection from the Lab PC to the server PC over a simple LAN in the testbed hardware. The next step is a VI that starts a hardware simulation in the testbed server PC. It is definitely one of these two steps.

Your link does not work. When I remove the period, I get a reply box to my original question. I think this is the information I am seeking so please provide the link you intended.

How do I "copy the settings over"?

I assumed it was a licensing error when I was able to run the sequence on the deployment PC with my own login but not with the lab login. For that reason, I don't think there is any missing code unless it has to do with network drives associated with my login.

[Snowman 6008]

Mack,

Sorry to hear that your power supply went bad.The User Interface seems be working fine, and while technically the GUI itself does not need to be licensed, the TestStand Engine needs to be licensed, and should work (and does work on your system) using an evaluation license. Here is the link again for using the LabVIEW Adapter Configuration Dialog Box (i double checked the link this time). The settings that you modify in your development environment are saved in the TestExec.ini file found in the Cfg directory C:\Documents and Settings\All Users\Application Data\National Instruments\TestStand 4.0\Cfg. You must manually include this file in your workspace file when you deploy or the settings will not get carried over.

When different users are logged on, different files are available under under documents and settings, that may be the source of the problem, or as you mentioned the network drives associated with your login.  Again the fact that we can launch the User Interface means this is not a licensing issue. Is there any way you can associate your the network drives that are connected with your login to the lab login account?

I am also a little confused about what works and what doesn't in terms of your computers. From my understanding you have a development machine, that has a full copy of TestStand and  LabVIEW. You also have a seperate computer that you are deploying code to, this computer has an evaluation version of  LabVIEW (which we don't need and aren't using at this point), and either a licensed or evaluation version of TestStand (either is fine, the fact we can open the UserInterface means this work great). Everything works on the development machine. On the machine that we deployed to, it works when you use your Login, but not when you use your "Lab" Login? Did you deploy using your account or the "Lab" login? We could verify that this is not a local file issue, by running the installer again under the "Lab" login. This will put any needed files where they should be, though as you mentioned it sounds more like a network drive issue. 

[b_hall]

I disagree with your suggestion to change the adapter setting to use the runtime engine.  If you purchase the Debug Deployment Environment License option, it is my understanding that this license should in fact activate the development version of LabVIEW Professional in order to be quickly step into code modules for debug purposes.  If someone chooses to run in production with a Debug Deployment Environment License, shouldn't that include the ability to continue running with the adapter set to "Development System (Active Version: X.X.X)"?

I have experienced a similar problem with installing TestStand and LabVIEW on a target system, deploying all of my TestStand configuration files (TestExec.ini and others) to the target system, and activating the Debug Deployment Environment License.  On most systems, this has worked fine - which includes leaving the adapter configured with the Development System as the desired option.  However, on a few systems, I get an error when running from our compiled FFUI and attempting to run a sequence that contains LabVIEW code modules.  The only 'workaround' I have found that occassionally worked was removing TestStand and LabVIEW, then reinstalling everything from scratch.

I now have a system where this 'workaround' has failed to work properly.  I have code that relies upon some DAQ drivers that we have been unable to get to execute in the runtime engine due to some strange dependencies.  Tried dozens of settings in the source distribution to get it to work, but haven't been successful.  This forces us to run with a development environment for the time being - which is why we selected the Debug Deployment Environment License as our option.

Is it possible to activate a Debug Deployment Environment License with the intention of running sequence steps with the development environment and not use the runtime engine?  I believe that is what is stated on the description of the license when it is purchased...

[jdubs]

I believe that you are correct that with the TestStand Debug Development Environment License, you should be able to leave the adapter set to "Development System."  Do I understand correctly that this has worked for you on some machines, but not all?  Please take a look at -18001 Errors in TestStand, especially the third point, second cause.  Also, as basic as it seems, please double check that the version of LabVIEW on the deployment machine matches what the adapter expects.

If you continue to experience problems, the next thing we need to do is try to narrow down what is causing the error.  What are the differences between the machines that work and the machines that don't?

Thanks,

Jen W.

Applications Engineer

National Instruments

ni.com/support