I'm trying to access an OPC Server on a Windows Machine using a Modbus Master on Linux and was wondering if that's possible
Not typically. You should use an OPC client.
No. OPC and Modbus are completely different.
Tipically you see an OPC server accessing a Modbus slave. You can model an OPC server as a two-layered component. The "upper" layer talks OPC with OPC clients. The "bottom" layer talks whatever protocol you want (in this example Modbus). The server's main task is to move data through these layers.
Related
I am trying to connect robot controler CODESYS program with OPC Expert through OPC UA server and that's listening 4840 port and on OPC Expert I'm getting like opc.tcp://hp-nb:4840/uadiscovery. I also installed freeopcua in my machine and that's listening 4840 port as well and on OPC Expert it's like opc.tcp//0.0.0.0:4840. On OPC Expert I need to connect with CODESYS application. I can connect with CODESYS OPC server but I'm not able to connect my application from CODESYS controler. Is it happening because of two servers are listening on same port? if not then how can I resolve my issue? Attached an image of my issue enter image description here
Two programs or processes running on the same computer cannot listen on the same port.
It would be possible only if that computer had two network interface cards with two different IPs and you could choose through which interface each process connect, a thing that is not usually possible to do
UPDATE
CODESYS Soft PLC emulator, which is usually installed with CODESYS, also includes an OPC Server listening on port 4840, if you stop the Soft PLC right clicking the icon on the windows notification area probably it will close the listening port
In theory, two OPC UA servers could share the same port (on the same network interface) if they coordinate together. For opc.tcp, there is no standard way for them to do it. Therefore, two servers from the same vendor that are written in such special way could theoretically share the port. In reality, however, OPC UA servers using "opc.tcp" cannot share the same port, because they do not know how to coordinate the access and route the data.
For other protocols the situation is different. E.g. for OPC UA over HTTPS it is easier to have servers listening on the same port - mainly because the operating system already contains a piece that can listen on the port "for them", and route the requests based on the URL.
In your situation, however, it is not just that two server cannot share the same port. There is also a problem with the fact that one of the servers returns "0.0.0.0" as its IP address in the connection point description, which is invalid anyhow.
Is it possible to connect an OPC UA server to another OPC UA server, in order to redistribute its data?
In fact, I have a small device which runs a small OPC UA server that exposes some data. The device is running in a private network. Then I have the main OPC UA server accessible from the internet, where I would like to view some of the small device's data, together with some more generic data.
Yes, it's possible, you just need a server that has this feature. It's not a standard part of OPC UA that any server will be able to do.
One option would be to use KEPServerEx's client driver.
OPC UA is a server-client architecture. Therefore, you cannot make two servers talk to each other directly. There must always be an OPC UA client implementation between them. Yes, KepServerEX does support this feature as having an OPC UA Client Driver out-of-the-box. However, you can implement your own little OPC UA client between the servers as a gateway too, which may suit your solution better I believe.
As far as I understand this will be possible by using an OPC UA Aggregation Server as main server (which is accessible from the internet).
You could test it with the open source UA-NetStandard Aggregation Server.
Is there a OPC Historian server in between? where PLC or SCADA connects to OPC UA
Not unless you've put one there.
I think your question needs a lot more information or it's going to get flagged.
I am using OPC Foundation's OpcNetApi.dll to communicate with an OPC DA server.
I am curious if there is a programatic way to kill specific connections which are currently active on the server using this library or a similar library.
I'm not positive, but I don't think what you are asking for is always possible (without a debugger). OPC is based on Microsoft COM. There are two ways that COM can be implemented:in-proc and out-of-proc. The choice depends on the OPC server vendor.
With an in-proc implementation, if you are running the OPC client on the same machine as the OPC server then the OPC server is just a dll that is loaded directly into the memory space of the OPC client. This dll exposes the OPC interfaces like CreateGroup, ReadAllItems, etc. Now it is probably getting the actual data through some other mechanism (named pipe, TCP/IP, etc) but this depends again on the OPC server implementation. The only way to really force stop this OPC server is to end the OPC client or get the OPC client program. Of course the OPC client or OPC server may already have implemented a mechanism to end, but there is not guarantee.
If it is an out-of-proc OPC implementation then the OPC server will run in a separate executable so you can find the name of that executable and terminate it. (You can search in regedit for the name of the OPC server to find the corresponding executable name). If I remember correctly, the OPC server can be designed so all clients share one executable or each OPC client gets their own instance of the executable.
If you are running the OPC server remotely then it is probably going to be loaded inside of a stub program if its an in-proc implementation and then tied to RPC. If you block the ports that RPC communicates over I think most clients would decide to disconnect after a while, although there is no guarentee they won't try to reconnect later.
Here's some more information:
https://www.opcsupport.com/link/portal/4164/4590/Article/711/May-I-get-a-In-Proc-and-Out-Of-Proc-explanation
We can't get our PLC to reliably connect with KEPServerEX (OPC).
I was wondering if anyone else here at SOF has experience working with PLC and OPC. If so do they have any tips on making a reliable connection with our OPC Server. We currently use KEPServerEX for our OPC, but if anyone knows a better program to use we are open to suggestions.
I use Kepware OPC server for MODBUS TCP, Simatic S7 and Yokogawa for more then 5 years on 4 servers in industrial environment without any problems. It was easy to set up and showed no problems during exploatation. Actually, it was so nice that we decided to not use it only when it doesn't support the device we have (which is rare, and mostly happens when I have to develop custom OPC server). Kepware OPC server is even able to use reserved PG connection for connection to Siemens PLCs (unlike Simatic OPC Server, this is good if you have limited number of connections like in CP343 LEAN version communication module). It will also save you $$$$$ if you use data from it in some historian like OsiSoft PI which charges per OPC server connections, since all Kepware OPC servers will show as single OPC server to Osisoft PI. The only thing that made me angry was that after some trial time it stopped without warning all servers (including licenced ones) when I was evaluating one new OPC server I was supposed to try out. Have you tried Kepware technical support? Have you checked your cabling? Are you aware that trial version will stop after some time?
As an alternative you can try Matrikon OPC servers. They are also very good and run without problems.