OPCclient Object Alarm

[Josh Highland]

I'm running LookOut Direct (V4.5.1 Build 19) on several Windows XP Pro (SP 2, firewall turned off) boxes.  I'm trying to connect an OPCclient object to a remote server (running KEPDirect).  This set up works great on three boxes I've tried it on but I get the alarm "OPC/OLE error (1): OPC Server interface not supported (66): Interface not registered (80040155)" on three other boxes.  I've completely reformatted one and reinstalled LookOut only to get the same alarm.  Can anyone tell me which drivers specifically need to be registered on the boxes for the client object to work?  Perhaps any other ideas?  I greatly appreciate any help.

[Ryan.S]

Try to reinstall the OPC Server first. If it doesn't work, download and install this one. http://www.opcfoundation.org/DownloadFile.aspx?CM=3&RI=385&CN=KEY&CI=286&CU=14

[Josh Highland]

Thanks for the response Ryan.  I did get it to work late last night by installing the OPC server software on the client boxes that are running LookOut.  At this point, I don't know why it worked.  After getting it to work with the server software I installed, I un-installed it and the LookOut OPCclient object continued/continues to work.  All I can really glean from this is that the OPC server software registered a driver or made a registry edit that LookOut needed (and wasn't doing during it's install) in order for the OPCclient object to work.  Another note is that the KEPDirect uninstaller isn't as complete as one would hope (but then most aren't).  I do appreciate you responding and not blowing me off because it's LookOut Direct.  Thanks.

[LabBEAN]

Hi Josh,

You mentioned that the KEPDirect uninstaller isn't as complete as one would hope... I installed KEP, then uninstalled KEP, then installed NI OPC Servers (flavor of KEP), then installed KEP again.  Both OPC servers work through their quick clients, but I get error -2147221163 (the fix proposed in another forum for this does not work -- opcenum appears to be registered correctly) when trying to add an OPC client to LabVIEW project.  I'm wondering if something is left over from when I uninstalled KEP.  (I've been through my DCOM and firewall settings and tried to make them match my laptop where everything works.)

Did you do anything in particular to "complete" your uninstall of KEPDirect?

Thanks!

[LabBEAN]

My issue was solved by replacing:

C:\Program Files\National Instruments\LabVIEW 8.6\vi.lib\variable\tagger\opcClient\ni_monads_opcClient_gui.dll

The problem was related to some mysterious DCOM setting and the way LabVIEW was interfacing to opcenum.exe.  This will NOT be experienced by most users.  NI R&D tweaked the DLL (above) to work with the latest version of a component of opcenum.exe.  If you have a similar issue, call NI and reference the DLL.  I'm hesitant to provide it here (unless authorized by NI), as the DLL will not be officially released for some time.

[RayFoulk]

I'm having this problem with a LabVIEW 8.6.1 application, which is built and distributed as an install package & running on top of LabVIEW RTE 8.6.1.  When trying to print a graph control using the NI_Standard Report.lvclass, I get error code -2147221163 (0x80040155) with message: Interface not registered in NI_Standard Report.lvclass:new report subVI.vi.  This same code has worked with no problems on other stations for a number of years.  Something is wrong with the configuration on one specific station.

Per another post: http://forums.ni.com/t5/LabVIEW/OPC-Interface-Not-registered-error/m-p/107666  I've tried reinstalling the OPC_Support\opcsupp.msi\opcsupp.msi and reinstalling the LVRTE (8.6.1) but these steps haven't worked.  Any help would be very much appreciated.  Thanks for your time.

- RFoulk

[Kevin_H.]

Could you give more details regarding the specifics of how the error might be recreated? Without being able to recreate the problem (or finding a reference to someone who has recreated the problem) all I can really do is tell you various things to reinstall. If you can minimize your code so that I can recreate the issue I will try to track down the configuration issue you're having further. (I have not had any luck determining the reason for you error beyond improper installations of the various components involved)

[RayFoulk]

Thanks, Kevin.  I've reduced the code down to the problem area (attached) and was able to generate the error under more controlled conditions.  It happens under our production environment (meaning no LabVIEW or LabWindows installed) but not under the development environment.  I believe the problem can be reproduced with the following steps:

1.) Start with a clean Windows XP SP3 and install the full NI Developer Suite from Second Quarter 2009, including almost everything.

2.) Build the test application, including the installation package.  Verify that it works correctly.

3.) Uninstall the LabWindows and LabVIEW development environments, leaving all drivers, runtime engines, MAX, and everything else.

4.) Application produces the error.

I suspect the uninstallation of the development environments took something out along with them when it shouldn't have.  We are going to strip the station image down and reinstall to try to get operational again.  This is a brute force approach obviously, and we'd really rather know what specific DLL or package is causing the problem.  Your help is very much appreciated.

- RFoulk

[RayFoulk]

Just a brief update: We were able to sidestep the problem by finding an alternative print method using Invoke Nodes on Control & VI references.  See the updated NIReportError attachment for an implementation.  Also after some testing I'm now convinced the problem is caused by some component that was removed along with the development environment as described, but I don't know which one.  Please see the attached detailed package difference/comparison between the two station configurations.  Thanks again.  -RFoulk