I am connecting from linux box to windows box and am having a problem. I am also running development on my windows box but still using OpenOPC mode, not dcom mode.
I have just tried to connect to Wonderware FSGateway version 3.0 and it does not show up in the list of OPC servers when I query it in Python. I can connect to the Matrikon servers on the windows machine no problem as they show up in the list.
I get a list of 4 servers, but there is the fifth one running that does not show up.
When I use the Matrikon OPC Explorer from my windows development box I can see all 5 servers including the FSGateway.
Any idea as to why the FSGateway server would not show up for the OPC Gateway Service?
Its name is 'ArchestrA.FSGateway.3' which I notice is the first server I have seen that does not end with '.1' this wouldn't have anything to do with it would it?
Thanks for any help you can offer.
I don't think the '3' vs '1' subscript means anything… actually most of my stuff doesn't even show up with a subscript at all. As far as why this one isn't showing up for you, perhaps it does not use a supported / mainstream automation dll file. If so, you can install the Greybox ('generic - fix all') dll that comes with OpenOPC and then see if the Wonderware OPC Server shows up in the server list.
actually, now that I think of it - the automation dll may only come into play when you go to connect to a given server. identifying what servers are on the box itself may not even require a compatible dll, which would make my thought moot.
I tried adding the graybox dll and registered it and that didnt make any difference I could see. But your comment led me down a path to a solution…
I see a couple of environment variables for OPC_Class and OPC_Server and this is how they were set for me:
Hci.TPNServer;HwHsc.OPCServer;opc.deltav.1;AIM.OPC.1;Yokogawa.ExaopcDAEXQ.1;OSI.DA.1;OPC.PHDServerDA.1;Aspen.Infoplus21_DA.1;National Instruments.OPCLabVIEW;RSLinx OPC Server;KEPware.KEPServerEx.V4;Matrikon.OPC.Simulation;Prosys.OPC.Simulation;ArchestrA.FSGateway
They actually did not have the ArchestrA.FSGateway on there, but I tried adding it to no avail. Then I thought to try one other thing, which was to wipe out the list of servers and leave only the graybox one. I tried this since the opc -i command was showing me that it only was using the first one in the list, the matrikon one.
I had to close the command prompt to get the new set of environment variables as well as restart the OpenOPC Gateway Service. Once I did this the opc -i now showed graybox as the class and voila, it knew how to notice the FSGateway was on there. Problem solved.
I also took the ArchestrA.FSGateway out of the OPC_SERVER list and it still worked, so it was setting the OPC_CLASS to the one I wanted to use that did the trick.
If anyone could add anything about what those two environment variables are supposed to do exactly and how to properly set them for the desired behaviour I would greatly appreciate any comments anyone that knows might want to add.
Thanks for the help!
One more comment, I find it strange that the Matrikon.OPC.Automation class when used by OpenOPC service gives different results than the Matrikon OPC Explorer, which presumably would use their own stuff?
Anyway to be clear, as on further reading I see it isn't here is my followup question:
When do I set OPC_CLASS AND OPC_SERVER and environment variables? And, how do they behave? Since they seem to behave in a way that might be expected as described above, even when in the list they don't neccesarily work until they are the only one in the list.
this makes sense now, and i'm glad you figured it out.
OpenOPC pulls in the Environment Variable (as declared by MS Windows). It then 'tries out' each one in the list, until it finds the first one that works. After finding one that exists on your computer, it utilizes it to query for existing / active OPC Server installations.
Personally, I hard-code the OPC_CLASS and OPC_SERVER variables into my applications. That is to say that I alter / override OpenOPC so as to explicitly declare (as an option in a text file) what Automation DLL that I want to use. I despise Microsoft Windows's implementation of Environment Variables and how it affects an otherwise transparent system.
So… the Matrikon DLL was showing you a bunch of servers, but not the Wonderware server - apparently the Matrikon DLL is optimized in such a manner that it is not compatiable with the Wonderware server.
The Automation DLL should (ideally) be identical from Manufacturer to Manufacturer - but it is not. Each MFG optimizes it for their own desires / needs. The Greybox one is very "vanilla" / generic, and will "see" just about any OPC server.
If you are using multiple OPC Servers on the same machine, and they are made by different Manufacturers, then it may very well be Best Practice to list the Greybox DLL first.
PS… in post #3 (above), I am clearly -WRONG- in hypothesizing that the Automation DLL does not play a role in discovering / listing active OPC Servers on the machine. Your trial and error (and both of our subsequent explanations) prove this.
PS again… I do not advise removing the OPC_CLASS and OPC_SERVER environment variables, or deleting their contents and only putting in the Greybox entry, etc.
I do not know what else in the 'wild' uses these environment variables, and it may very well be that your individual OPC Servers and other such software needs these variables (and will implement them differently). This is why I choose to over-ride rather than over-write / delete.
anyone can help me ?
I've the code written for python for me to send data from excel spread sheet to MatrikonOPC. But now I have no idea how to connect them together like how to test it out in matrikonopc to see if my data is actually send into it. Can anyone advice me on this issue?
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.