Getting the -18001 error when using TestStandLVRTS

[HCL]

I have developed my TestStand (v2.0) test sequences based on the LabVIEW adaptor. Everything runs well with the labVIEW development system. However, when I switch the labVIEW adaptor to the LabVIEW runtime server such as the TestStandLVRTS, I got the -18001 Error from the TSAPI with the message of "Unable to launch 'TestStandLVRTS.Application' ActiveX automation server".
I have tried all the suggested fixes described in the article "-18001 Errors When Using TestStand and LabVIEW". The error still persists.
Could you help me to solve this problem? Without this problem being solved, we will not be able to deploy our test sequences.

[Elaine_R.]

Hello HCL -

Do you notice any change in behavior if you manually go into /Components/NI/Runtime Servers/LabVIEW and launch the TestStandLVRTS.exe manually before running your TestStand sequence?

What version of LabVIEW are you working with? I have discussed your error message with a few of our LabVIEW developers and they say if you have an older version, an upgrade or a re-install of your LabVIEW Run-Time Engine may help resolve this issue.

You may also want to write to support@ni.com directly so that we can start a more indepth discussion as to yourr current system and development history.

-Regards

Elaine R.
National Instruments
http://www.ni.com/ask

[HCL]

Hi, Elaine:
I am running LabVIEW 6.1. I think the root of the problem is that the Application Builder deos not generate the type library file (.tlb). I used the Microsoft's OLE/COM viewer to exame the TestStandLVRTS runtime server. The server was registered but no type library file is associated to it. The tlb file from the TestStand NI directory (testStandLVRTS.tlb) had a differnt UUID than the runtime server built with my LabVIEW 6.1. Hence, by registering the tlb file does not solve this problem.
One way to prove that the Application Builder did not generate the tlb file (note that the ActiveX server has to be enabled) is to enable the installer. At the end of the building the application, the MSI will complain about missing tlb file.
Is this bug app
earing again? Has it been fixed since LabVIEW 5.0?

Thanks,
HCL.

[Elaine_R.]

Hello HCL -

Below I have attached my version of the 6.1 built TestStandLVRTS folder. If you are using the build file provided in this folder when re-compiling your run time server, you should be seeing the .tlb file being auto-generated. Verify that you are using the build file that ships with TestStand and that under application settings that you have the 'Enable ActiveX server' checkbox enabled.

There are no known bugs with LabVIEW 6.1 related to problems launching the TestStandLVRTS.exe, and given the good behavior I have seen between the two products here on the test machines, I am interested in seeing first if the problem lies with the executable and then we will try and troubleshoot your particular system.

--Regards


Elaine R.
National Instruments
http://www.ni.com/ask

[HCL]

Hi, Elaine:
I used your files and the Application Builder to build the runtime server. During the building process, it informed me that the TestStandLVRT.tlb file will be overwritten (the zip package has one). But after the buikding process, the tlb file does not show up in the directory (not in the data subdirectory, either). This is my point! The Application Builder some how decided to delete the tlb file or never generate it (I have no way of knowing which one). Is that the Application Builder I have is defective?

By the way, I build the runtime server again. This time the Application Builder did not list the tlb file as the "to be overwritten" list. This clearly proved that the tlb file is not in the folder after the first build. Any
idea?

Thanks,
Hung-chi.

[HCL]

Hi, Elaine:
By testing the Application Builder on a different user's machine, the tlb file was generated properly. Hence, I engaged the LabVIEW repair from the Installer on my machine. The repair fixed this problem. Now the tlb file is generated properly and the runtime server is usable from the TestStand. However, it is still a puzzle to me what went wrong in the Application Builder. For sure that the Application Builder did not check the existence of the tlb file for error conditions.

Thanks,
HCL.