Remote control of Labview using DCOM, class object not registered on local machine

[RRudek]

Hi, I'm being frustrated trying to use DCOM (ActiveX Automation ?), which produces the above error, "Class object not registered on local machine". I know exactly the reason why it does that, now. But am quite disgusted by the hackery that I'll probably need to do to fix it. I hope I'm wrong.

Here's basically what I'm trying to do.

The "server" has LabVIEW 7.1 installed, and is running a VI which I needed to retrieve info from, and control. The client machine does NOT have LabVIEW, nor the LabVIEW runtime installed - the runtime doesn't solve this problem, anyway.

Now, LabVIEW can operate like an ActiveX Automation Server (is that the right term, now?), and if I work from the server itself, it does work. However on the client, the LabVIEW COM objects (LabVIEW.Application, etc) obviously don't exist, and when you try to create them remotely (on the server), you get the above error, on the client.

Fine. It needs to know how to marshall, etc.

Now this is where we run into the problem. I've tried copying over LABVIEW.EXE and running the it on the client with the /RegServer switch, but no joy. Obviously, there are some DLL dependancies, but I'm not sure this is worth persueing, as I want it to run remotely.

I've found the Type Library for LabVIEW 7.1 in the resources folder, on the server's installation. But there is no other registry/class file(s) that I can find, which are needed on the client to create/register the LabVIEW COM objects. Does anyone know wether it exists ?

Better yet, is there an LabVIEW COM Object installer (package) that does all the required registrations, for a client machine such as this ?


Just to clarify, further. If you create an ActiveX EXE using VisualBasic 6.0, there is a project option to "Create Server files". When you make the EXE, this produces a TLB and a VBR file. I need the requivalent of this VBR file, for LabVIEW.

Yes, I can hack up a REG file to do this, but I'm hoping that this has already been done by National Instruments, and that the cold I'm suffering from is effecting my ability to find it in either the installation, or on the CDs. Also doens't seem to be documented, either... 😉

The TLB (Type Library) seems to be fine, as you can include it in the VB/Excel Project References and Browse it. The REGTLIB utility (part of Visual Studio) can also successfully register the TLB on the client. But that's not enough.

[Ankita A.]

Hi,

It looks like you would need to change some DCOM settings on both the server and client machine. Try the example code at the following link:

http://sine.ni.com/apps/we/niepd_web_display.display_epd4?p_guid=B123AE0CBA64111EE034080020E74861&p_node=DZ52051&p_source=External

Regards,
Ankita A.

[RRudek]

Thanks for taking the time. However, that example does not address the issue. It completely glosses over the issue. ie If LabVIEW is installed at both ends, there is no problem. But that's a harsh requirement, when the controller is not going to have any other LabVIEW programs running on it.

The issue is, or rather was, that there was no *easy* way to register the LabView COM/Automation objects on a PC that will be use soley for the purposes of controlling another PC running a LabView VI. Additionally, the LabVIEW runtime does not seem to register the COM/Automation object, either.

Since than, I decided to write my own Automation Server, and control it from the LabVIEW machine, instead. The opposite way round. In hindsight, this is a better solution. It meant I had to learn enough about LabVIEW to do it. But as I said, it is a better solution, in this case.

To register my Automation Server on the LabVIEW PC, I simply copy across my executable and the TLB, then run my executable with the /RegServer switch. So I guess my original attempts at registering the LabVIEW COM/Automation objects (using /RegServer) would have worked, had I resolved the DLL dependancies. When I'm done with this project, I try it.