first a big thank you for this work, I currently use OpenOPC only for some tests but we plan to use it for a pilot implementation of a research project.
The OPC-Server that we have to use is a tool provided by a SCADA system producer OPCManager
For here I will only use the opc.exe command-line tool although we use our own python development. For the reported question this has no influence I suppose :-?
If I connect to the server via dcom
opc -C Graybox.OPC.DAWrapper -h localhost -s OPCManager.DA.XML-DA.Server.DA -i
the result is fine:
Client Name OpenOPC
Current Time 12/02/11 16:50:56
Vendor OPCManager by sc
Now if I use the gateway service
opc -m open -C Graybox.OPC.DAWrapper -s OPCManager.DA.XML-DA.Server.DA -i
the result is:
Connect to OPC server 'OPCManager.DA.XML-DA.Server.DA' on 'localhost' failed - Connect: Server execution failed (Server execution failed)
But if I connect the same way to the default Graybox.Simulator.1
opc -m open -C Graybox.OPC.DAWrapper -s Graybox.Simulator.1 -i
Gateway Host lti-gsc-12740:7766
Gateway Version 1.1.6
Client Name OpenOPC
OPC Host lti-gsc-12740
OPC Server Graybox.Simulator.1
Version 1.5 (Build 1210)
Start Time 12/02/11 16:55:03
Current Time 12/02/11 16:55:03
Vendor Graybox Software
Every thing seems to be OK
I had a look about the functioning of the OpenOPC gateway (OpenOPCService.py) and it seems to be somehow a pyro wrapping around the basic OpenOPC module and classes.
Thus I do not know way the dcom access is working and the "open" access fails but only for this OPCManager server.
For Information: I tried specifying all OPC parameters in the environment variables but there is no difference.
At this state of our development I can simply use the dcom connection and this works fine for all developments. But we plan to locate the final control application on a separate target system in order not to impact to much on the project partners hardware and software infrastructure.
Thanks for your help
I may be way off, but I recall something about the OpenOPC Gateway Service having to be run as an administrator. So if you go into Adminsitrative Tools / Services, and click to edit OpenOPCGateway be sure it is set to run as Administrator and not as a lower-priviliged user.
Also - be sure the OPC Server itself is running as Administrator.
Finally, I would suggest logging into the machine as an Adminstrator and running the "opc.exe" command that you wish as the Adminstrator.
I try to avoid all this permission junk (on any system) by simply making one user (an Administrator) and doing everything as that user. I mean, it's a server (or at least that's what you're emulating if in testing), not a public workstation.
Hi and thanks for your quick reply.
I am administrator on that machine. Do you know if it is enough to be in the administrator group or should I really log using the administrator account.
This (testing) is the machine of the lab I am working and there is a IT service responsible for all the machines. I do not know if I can have the login for the administrator account as this will probably be the same for all machines of the lab.
I will analyse the user used for the service and for the server. But as the behaviour for the other servers (I also installed) is not an issue I suppose it is more a problem of the specific server configured by this OPCManager.
I will report on the evolution here.
Being in the Administrator Group is sufficient, you don't have to be the actual 'Adminstrator' account.
Have you tried any other OPC Servers? (such as Kepware / InGear / etc… ?) I would think that would be the next logical step, to try it with a known working server, and then if it works with that but not the OPCManager that you've got, then there may be an issue with that.
I was on holiday for some days and thus could not reply.
Concerning the connection to another OPC-Server, yes As I wrote in my first email, I can connect to Graybox.Simulator.1 which is a demo server and I also tried the MatrikonOPC server (simulator) with no problems.
I can of cause test other OPC servers but I think it is a problem with this specific OPCManager.
What is the best way to debug this kind of problems related to OpenOPC gateway. I would like to get some more details about the real issue before contacting the provider of OPCManager.
The best way to debug is directly in python. There could be some weird issue with the precompiled opc binary file (opc -m… etc etc…).
Let's say the test server you have already setup is at 192.168.0.200 (and is currently running the OPCManager software, OpenOPC Gateway service, and the GreyBox automation wrapper).
If you have a second computer - let's say at address 192.168.0.100 - install the following…
- openopc (just copy and paste it to c:\openopc )
- python 2.5 / 2.6 / or 2.7
- pryro 3.7 or better
I will assume you're working in Windows, and that firewalls have been turned OFF on both the test server and test client machines, so I'll list the following commands accordingly, but the same would apply to a Unix/Linux client setup (just different syntax)…
Open up a command line window (dos prompt)…
C:\> cd c:\openopc\src
Python will now start a shell, with the base directory as c:\openopc\src… the python prompt is ">>>"… continue commands within the shell as follows…
>>> import OpenOPC
>>> opc = OpenOPC.open_client('192.168.0.200')
Now, you should be "in"…
… that should list all of your servers, in your case you might see one of the following two:
… or something similar - I honestly don't know, as I have not tried to connect to anything through the Graybox wrapper before, so it may show up as it's "real" name (OPCManager) or as its "wrapped" name (Graybox).
Regardless, whatever shows up - WORD FOR WORD - is what you must then try to connect to…
For example, on my "day job's" server, we get… - we're looking for what is between the single-quotes… so I "read" that as simply 'RSLinx OPC Server' (for the first one).
Let's say that "OPCManager.DA.XML-DA.Server.DA" showed up… then you would type…
If you've gotten this far without a problem, then you can continue to try to read items one at a time using the guide for the OpenOPC API … http://openopc.sourceforge.net/api.html
Specifically, check out "opc.list()" and "opc.read()" for debugging purposes.
Don't be alarmed if you get disconnected or kicked off randomly or for no reason. After connecting, it's wise to wait a couple seconds before issuing commands. But, in the same token, if you wait too long, the connection may go stale. This is nothing to worry about - in a real world application, the connection would be kept quite busy, and you should build in error handling to handle gracefully disconnecting and reconnecting if a problem arises.
Thanks for your long reply, but this is what I already did. To keep short in my first post, I used the shell command to illustrate the propblem.
The problem comes form the fact that I can not connect to 'OPCManager.DA.XML-DA.Server.DA'
gateway = 'localhost'
opc = OpenOPC.open_client(gateway)
This takes several minutes and ends with the error message:
here the traceback in IPython
OPCError Traceback (most recent call last)
D:\Project-work\MoGREPo\Wormeldange\OPC-Linking\PythonTest\<ipython-input-13-55bc4797fdd7> in <module>()
---> 1 opc.connect('OPCManager.DA.XML-DA.Server.DA')
c:\Python26\lib\site-packages\pyro-3.9.1-py2.6.egg\Pyro\core.pyc in __call__(self, *args, **kwargs)
382 self.__name = name
383 def __call__(self, *args, **kwargs):
-> 384 return self.__send(self.__name, args, kwargs)
386 class DynamicProxy:
c:\Python26\lib\site-packages\pyro-3.9.1-py2.6.egg\Pyro\core.pyc in _invokePYRO(self, name, vargs, kargs)
457 # rebind here, don't do it from inside the remoteInvocation because deadlock will occur
-> 459 return self.adapter.remoteInvocation(name, Pyro.constants.RIF_VarargsAndKeywords, vargs, kargs)
461 # Pickling support, otherwise pickle uses __getattr__:
c:\Python26\lib\site-packages\pyro-3.9.1-py2.6.egg\Pyro\protocol.pyc in remoteInvocation(self, method, flags, *args)
438 self.lock.acquire() # only 1 thread at a time may use this connection to call a remote method
-> 439 return self._remoteInvocation(method, flags, *args)
c:\Python26\lib\site-packages\pyro-3.9.1-py2.6.egg\Pyro\protocol.pyc in _remoteInvocation(self, method, flags, *args)
499 # we have an encapsulated exception, raise it again.
-> 500 answer.raiseEx()
501 return answer
c:\Python26\lib\site-packages\pyro-3.9.1-py2.6.egg\Pyro\errors.pyc in raiseEx(self)
70 def raiseEx(self):
--> 72 raise self.excObj
73 def __str__(self):
OPCError: Connect: Server execution failed (Server execution failed)
What is special is that this works fine for the to other servers I have on this box.
Now what I would like to do is to debug the gateway side as the error seems to come from there via Pyro.
But I can not reproduce the problem if I directly connect to the OPC server via dcom (using …
opc = OpenOPC.client()
This works fine and I can read from and write to variables.
What I have problems to understand is the difference between both as the gateway seems to use standard dcom for connection (see the OpenOPCService.py opc.create_client() ) The connect method is only passed trough pyro.
So I would know like to debug the gateway side to find out where the problem comes from. But I do not know how to do this.
Both "OpenOPCService.py" and "opc.py" ultimately use (call) "OpenOPC.py".
OpenOPC.client() speaks directly via DCOM when called from "OpenOPC.py"
OpenOPC.open_client() when called from "OpenOPC.py" funnels through a running instance of "OpenOPCService.py", and right back onto another copy of itself.
… client machine uses OpenOPC.py on client to run function 'OpenOPC.open_client()'
… … this is pushed through running instance of gateway ("OpenOPCService.py") on server
… … … gateway service calls "OpenOPC.py" on server to run 'OpenOPC.client()' server side.
… on client "OpenOPC.py" line 123 opens an communication channel to "OpenOPCService.py" on server
… … "OpenOPCService.py" on server executes line 67 to create a client instance, and on line 70 you can see that it actually does call OpenOPC.client() and returns the result via the communication channel to the client.
… … … once this is done, "OpenOPCService.py" on server is commanded by "OpenOPC.py" on the client to execute functions from within the server-side copy of "OpenOPC.py", and the results of those functions are returned through the communication channel.
The only difference between executing OpenOPC.py directly on the server using OpenOPC.client - versus using OpenOPC.py as a client (whether on the server or via an actual remote client machine) is that you're funneling the commands through Pyro. So there is added latency, not much, but it is by definition a few additional steps, and however small of an amount of time it takes, it still does exist.
I agree that this would lead you to suspect Pyro, the Gateway, or some combination of the two as the issue.
However, I would suspect more Pyro than the Gateway itself.
I have not had reason to upgrade, so I'm still on Pyro 3.7 - just for the sake of argument, you may want to try downgrading from Pyro 3.9 to Pyro 3.7, and see if that "magically" resolves the issue.
Beyond that, I am not versed in the inner workings of Pyro, so I will not be of any use in debugging it or the manner in which the Gateway uses it.
your explanation is exactly what I supposed the system client - gateway - server is working.
Do you think that from the OPC-Server point of view, there could be any difference (except the possible latency) between the gateway service connecting or a client connected.
I ask this because the use of the gateway with the OPC-Servers Graybox.Simulator.1 and Matrikon.OPC.Simulation.1 work without any problem. It is only the OPCManager.DA.XML-DA.Server.DA OPC-Server that has problems if connected through the gateway service. The python script and environment (Pyro,…) are for all this tests exactly the same.
I use pyro-3.9.1 on python 2.6
That's why I suspect more an issue at the interface between gateway and OPC-Server.
As I have no access to the OPCManager code, I thought about debugging on Gateway level to see what is written to the server. This could eventually also be done on DCOM level bot I have no experience at all on how to log the DCOM messages.
In my current installation I use the provided gateway service (exe file - I did not run this directly from python).
Is this possible by stooping the service lunching the python OpenOPCService.py in a separate console?
OK I will try the downgrading to Pyro 3.7 to see if this makes any difference.
What's worrying me is that the other two tests (graybox simulator and matrikon simulator) are only simulators, not actual opc servers.
You may be able to get a trial version (free) of Kepware from here - not sure though --
I'm just concerned that something else may be going on at a lower system level that is not just preventing OPCManager server, but that would prevent -any- real server.
From the OPC Server's point of view, there isn't any difference between a client connecting via OpenOPC directly or OpenOPC via Gateway - ultimately "OpenOPC.py" on the server is doing all the communication with the OPC Server - other than latency as you mention, there should be no difference.
If you don't have any luck with downgrading Pyro, or with trying a trial version of a known working 'real' server (such as Kepware ESX or Rockwell RSLinx), then the next step I would say is to contact Barry and see what he thinks…. firstname.lastname@example.org
If you do get a resolution, post it here so that if anyone else runs into the same thing they'll know how to fix it.
happy new year to you :-)
I found some time to install and test the Kepware Communications Server 5.7 (V126.96.36.199).
As I have no real hardware (PLC…) here I tested it with the embedded simulator (for several data formats) in reading from and writing to the server.
I tested both ways: local dcom connection and gateway connection using opc command-line, own python scrips and ipython interactive use.
-> Every thing worked out without any problem. Connection to server OK, reading OK writing OK, closing connection OK
This was all done without downgrading Pyro.
Do you think that the fact that I used the Kepware Server embedded Variable simulations still may be different to a real OPC server behaviour?
Happy new year to you too.
I'm very glad to see that the Kepware embedded simulator worked for you. I have used that simulator before, and I do not believe there would be any different (to the client) whether it was talking to an actual device / plc, or to the simulator. The simulator you are using is actually much like the Rockwell SoftLogix simulator - the OPC Server is a real server, doing real work, it's just talking to a simulated DEVICE. The actual SERVER is 'real'. So that's a good thing.
I'm also glad to see that was successful without downgrading Pyro (being 'foward'-compataible with new versions is a good thing, because you never know when the latest version of an operator system will stop supporting an older version.
Now that we know that your installation -DOES- work, we're back to trying to figure out why OPCManager server is having a problem.
This may seem like a stupid idea, because it does work via direct connection, but we've covered all the 'normal' reasons, so we're left with just the 'weird' ones…
- OpenOPC is only compatible with OPC DA (up through the latest 3 series) specification servers. It does not communicate properly with HA or other style servers. Typically, an OPC Server software will always have 'basic' DA interface, and then may additionally also have HA and other interfaces… but they usually always at least have DA. It is possible that OPCManager does not have standard DA access, or implements DA in a way that is not standards-compliant. Is there a website for OPCManager or somewhere in the literature for it where it states what OPC Foundation standards that it uses?
briefly, I am facing the same problem just using a different Matrikon.OPC server. I can connect in dcom mode, but I cannot connect in open mode. Still, I can connect in open mode to the Matrikon.OPC.Simulation server.
Have you guys found any solutions to this problem?
Thanks for any help,
I have to apologize but I stopped investigating the problem due to time reasons.
I still use the DCOM approach with the specified OPCManager, we found an agreement to run the python application on the same hardware the OPCManager is running. So DCOM is fine for now.
But I principally are still interested if someone finds a solution to the problem.
Your comment seems to underline the problem not to be restricted to the OPCManager server.
I had the same problem. I managed to connect via dcom but not through the gateway. Now I'm running an OPC server on a Windows machine and interacting with it thorugh a linux machine via the gateway.
I guess the problem is related to the installer. I uninstalled OpenOPC and started the gateway service like this (as administrator):
And now everything works. I don't have a deep knowledge on how services work, so this is as far as I can explain!
I think that OpenOPC installer sometimes messes up the system.
I have extracted all the files from it (it's a self extracting ZIP file) and executed "OpenOPCService install" in the "bin" folder.
In the "services" control panel applet you can set OpenOPC service to start automatically.
I have had the same problem with Citect & GE Cimplicity.
The debug trace is the same as posted by Georges.
I tried what Andres suggested, but it didn't have any effect. I don't really have the option of using dcom since I want to transfer data to a Linux machine.
Has anybody found a solution to the problem?
Log in to post a comment.
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.