I'm little bit confused regarding how S7-1500 embeded OPC UA server communication works in case of a custom client installed on PC since all examples I've seen so far include a Simatic PC Station as OPC server!!!
On PLC side, I have S7-1511-1PN with OPC UA server activated. This PLC is connected over PROFINET to ET200SP+several AI modules.
On PC side (not Simatic PC Station), I have an application in which there is some kind of OPC UA client functionnality that reads inputs from AI modules, writes some tags on PLC and if necessary sends reconfiguration records of AI modules to PLC (reconfiguration via user program).
What I can't understand, is:
Why the Simatic PC station is always added as OPC server if the PLC already has this feature?
Does/How PLC OPC server communicates directly to my custom client? (Any programming needed on PLC)
For the certificates limitations as defined in "Function Manual, 10/2018, A5E03735815-AG (page 222)", what means "Max number of implementable server methods", "Max number of arguments", "Max number of server interfaces", "Max number of nodes in user-defined server interface", "Max size of loadable server interfaces"?
How can I estimated these numbers from my application?
(Yes/No) Do I need a second communication (TCP for example) between my PC application and PLC to send/receive reconfiguration data?
Why the Simatic PC station is always added as OPC server if the PLC already has this feature?
The SIMATIC PC station is not required. In the days before the S7-1500 PLC had a built in OPC UA server the only way to have an OPC UA server with data from the PLC was to use a SIMATIC PC station. A SIMATIC PC station is a computer running the SIMATIC NET software. The SIMATIC NET software can talk to the S7-1500 via an S7-Connection, the data it reads can be served to OPC UA/DA servers which are also part of the SIMATIC NET software.
Does/How PLC OPC server communicates directly to my custom client? (Any programming needed on PLC)
The OPC UA client must be on the same IP range as the PLC network interface. In the hardware configuration of the S7-1500 the OPC UA server is enabled. The OPC UA client is then pointed to the IP address of the S7-1500 PLC and using the OPC UA discovery will be able to read all the marker memory area, input and output memory area and data blocks. The OPC UA client will be able to subscribe to tags and write values if required.
EDIT: A router address can be set in PLC, so the client needs to be able to route to the PLC if on another subnet.
No programming is required in the S7-1500. In TIA Portal simply access the hardware configuration of the PLC and in the hardware settings there are options to enable the OPC UA server.
For the certificates limitations as defined in "Function Manual, 10/2018, A5E03735815-AG (page 222)", what means "Max number of implementable server methods", "Max number of arguments", "Max number of server interfaces", "Max number of nodes in user-defined server interface", "Max size of loadable server interfaces"?
In OPC UA it is possible to call methods. Methods can call function code from within the PLC logic. A method can be passed parameters and can return values. This is what the spec is refering to when it dicusses methods and maximum number of arguments. Each data point is considered to be a node in OPC UA, so this is explaining the maximum data points which can be read. As different PLC tags take up different amounts of memory the max size is the total size of all the nodes.
How can I estimated these numbers from my application?
This will be depending on the number of tags you wish to share from the OPC UA server. The update speed on the subscription and the amount of subscriptions allowed. There is no hard and fast method for calulcating this, it is very application dependant.
Do I need a second communication (TCP for example) between my PC application and PLC to send/receive reconfiguration data?
The OPC UA server can be configured to listen on any network interface of the S7-1500. There is no need for extra communication it is all part of the OPC UA protocol.
Siemens provide a nice application example with accompanying documentation which may help you get started. Download the documentation PDF from the link below.
https://support.industry.siemens.com/cs/us/en/view/109737901
Why the Simatic PC station is always added as OPC server if the PLC
already has this feature?
OPC UA has quite few advantages over other industrial communication protocol. The communication is/can be secure, the project is Open (Source available on GitHub, Specification are free), ...
Does/How PLC OPC server communicates directly to my custom client?
(Any programming needed on PLC)
The communication between your S7-1500 and your computer is an OPC UA End-to-End communication. I don't know the specification of the S7-1500 OPC UA Server neither your OPC UA Client but I guess they use OPC UA Binary over TCP
For the certificates limitations as defined in "Function Manual,
10/2018, A5E03735815-AG (page 222)", what means "Max number of
implementable server methods", "Max number of arguments", "Max number
of server interfaces", "Max number of nodes in user-defined server
interface", "Max size of loadable server interfaces"?
Your Configuration can contains OPC UA Methods. I guess there is some limit given by Siemens for the number of Methods. Same for the number of Arguments available in each Methods. There shall also be some limitation for the number of available Server interface in your controller.
How can I estimated these numbers from my application?
I am pretty sure you can find those limitation in your Siemens's PLC Manual ;)
Related
I have a SCADA system with an OPC DA client module installed on a windows PC.
Additionally I have a measuring instrument connected to the same PC through a COM port.
The instrument measures two numerical values which I can read in Python. I would like to feed the data into the SCADA system, but I don't know how. From what I can read the easiest way would be to apply an OPC DA server and have that communicating with the OPC DA client, but the vendor of the measuring instrument does not provide such a server.
All the information I can find provide details, using different programming languages e.g. Python, C, Visual Studio etc, on how to setup/create an OPC DA client assuming the server is already existing. I however, have the opposite situation where I have the client but not the server part.
Any ideas on how to setup my own OPC DA server so that I can get the measured values from my instrument into the SCADA system are most welcome...or any other ideas on how to fix the data transfer.
Best regards
What is the difference between the OPC-Router and Kepserverex? I have seen a solution where both of them were used - Kepserverex connecting to machines and sending data to the OPC-Router which then sends data to IT Applications. Couldn't one of them do both tasks together?
I did compare the features of both products, but couldn't figure out why you would use one or the other - or both together. Both products seem to support data exchange between different protocols and platforms.
The KepServerEX is an OPC Server. Connecting over 150 different kinds of machines and providing their data as OPC UA data for OPC Clients.
The OPC Router is an OPC Client and is a tool for system integration. With the OPC Router it is possible to transfer data between systems whenever the data is needed (triggered). So the OPC Router connects systems like SAP, databases, label printers and a lot more and moves data between them. This also includes workflow-like data transfers, like calling a Stored Procedure in a database with a defined set of input parameters and transferring the returned values back to another system (maybe to the PLC over OPC UA => over the KepServerEX). In general you enable systems to interact with each other by the OPC Router. And this is where Industry 4.0 starts.
Greetings from the inray-Team
In other words, is it possible for a server or a client to receive partial data before the transmission is finished?
I am sure this information is written somewhere in the extensive documentation of the OPC Foundation, but I think this is essential.
I am using the "atomic" phrase as used for database writes. When a programmer updates a table, the update is always atomic in the sense that it is either done or not done. We rely on the DB software for guaranteeing against the operation being only partially successful.
In the case of a PLC acting as an OPC UA server; when the client writes say 1 KByte data, are we sure that the program running on the PLC, on any instant read a part of this data while it is still being communicated and written? Since we are dealing with a very fast reading entity (the PLC) on the other side of the communication, is it possible that the PLC gets the first 100 bytes before the rest is received?
In the case of a PLC acting as an OPC UA server; when the client writes say 1 KByte data, are we sure that the program running on the PLC, on any instant read a part of this data while it is still being communicated and written?
You can be certain that any server will not be processing any read or write until the request has been fully transmitted by the client. There is no facility in OPC UA for dealing with streaming/partial requests from clients.
That said, how the server handles that 1KB of data it just received as a write is not covered by spec. There is no guarantee that it is written atomically to whatever the backing/underlying datasource may be (in memory, shared memory, a file, another device on the network, etc...).
I do believe that most OPC UA servers built in to PLCs are probably doing the right thing to ensure atomicity but there is nothing in the spec that guarantees it and no way to be sure other than contacting that vendor or consulting documentation.
Beckhoff OPC-UA Server communicates with the Beckhoff PLC through the ADS protocol.
The default Max Size of the consistent data sent with the help of the ads router is 16 kByte although it can be changed if needed.
This is important to understand, because the OPC-UA Server is not part of the PLC runtime environment.
When an OPC-UA client writes a node of an OPC-UA Server, the OPC-UA Server sends this data to the PLC.
In the Twincat development environment you have the option to declare a special attribute for structured types:
{attribute 'OPC.UA.DA.StructuredType' := '1'}
This tells the Beckhoff OPC-UA Server to send the data concerning that specific data structure in a consistent way to the PLC when it receives it from a client.
The Beckhoff OPC-UA documentation states:
"StructuredTypes allow you to read or write structures without interpreting each byte, because the UA Server
returns the information type of each element of the structure. Based on complex functions in modern
OPC UA SDKs, OPC UA Clients can search and interpret this structural information."
Therefor, regarding data consistency, it is also important that your OPC-UA SDK (client) is modern enough to be able to "search and interpret this structural information".
The answer is provided by Flippo & Kevin in the above comments. So this will be a recap for everyone to quickly spot:
OPC UA guarantees atomicity only for simple types (Integer, Double Integer etc)
Longer structures' atomicity depends on the specific manufacturer.
I am expected to design the solution for collecting/processing samples from a PLC device, and working with some control tags of the device. Please, suggest the approach. Sorry for the long question. I will split it to more questions after learning what are the smaller and more reasonable subjects/questions.
The solution for the company is built almost from scratch. There are some PLC devices, and there is a KEPServerEx (without the IoT Gateway). The PLC devices are already used through the third party proprietary software. But there is no "bigger framework" for future. From that point of view, I can introduce a modern design, but the budget is restricted.
From what I have learned so far, it seems that the KEPServerEx is a good choice for accessing PLC devices, but I have no hands-on experience with it. It seems to me that the OPC UA should be the choice over the older OPC (DA). I am also aware of the ladder way of working with PLC.
From what I have learned about "IoT Gateway" (which will not be used) for KEPServerEx, the KepServer can set the sampling frequency at the PLC tag level. And also the frequency of transferring the data can be set by IoT Gateway. The IoT Gateway then uses an internal (memory) buffer for storing the sampled values, and the tuples (tagID, value, quality, timestamp) can be read and passed to third party.
What is not clear to me is, how to do that without the IoT Gateway. I assume that it must be a basic operation. Is the (tagID, value, quality, timestamp) generic for working with PLC through any OPC server? Or is it generic only for KEPServerEx, or is it special for the IoT Gateway (optional) plugin?
I have learned that OPC Foundation added recently the Publih/Subscribe mechanism to the OPC UA. Does it require also newer version of KEPServerEx? Or can it be used with any earlier OPC server?
I am fairly experienced in programming and database things. I also have some technical background in industrial sensors, actuators,... However, I have never worked with digital automation in industry.
Thanks, and have a nice day.
Depending on the PLC you want to communicate with, and the communication network your devices will be transmitting data on, you need to purchase the appropriate driver package so that KEPServerEX can communicate with it.
For example:
If your PLC is an Omron NJ PLC, and it is on an Ethernet network with the server that KEPServerEX is residing on, you will need to use the "Omron NJ Ethernet" driver in the suite package Kepware offers called the "Omron Suite".
Regarding your question about the IoT Gateway:
From what I have learned about "IoT Gateway" (which will not be used) for KEPServerEx, the KepServer can set the sampling frequency at the PLC tag level. And also the frequency of transferring the data can be set by IoT Gateway. The IoT Gateway then uses an internal (memory) buffer for storing the sampled values, and the tuples (tagID, value, quality, timestamp) can be read and passed to third party.
This can be done without the IoT Gateway, by using the appropriate aforementioned driver, and then using another driver package to send the PLC data to wherever you would like (ODBC client, SQL Server database, etc.). It depends on what you want to do with the data you are acquiring.
When you talk to a specific device you need to know the protocol that the device uses and those protocols can vary really much.
Sometimes the manufacturer of a device provides an OPC server that shields you from this or as you mention a 3rd party Connectivity server like KepServerEx or Matrikon can be used presenting an OPC interface for your client to use.
I don't know anything about the KepServerEx or your particular requirements but normally an OPC server has a cache where values are stored from which the client can read from alternatively read directly from the hardware. Subscriptions can be configured similarly e.g. frequency, threshold etc.
The protocol from the OPC sever/3rd party to the device determines the frequency in which you can sample values. E.g. some protocols need the device to be polled for values, some are more elaborate.
If you create an OPC client then you are pretty much free what kind of OPC server you connect to whether it is a 3rd party or an OPC server from the manufacturer and having the client storing values whenever items in a subscription changes is pretty trivial.
If you are familiar with Visual Studio, then AdvancedHMI may be a possible solution. You did not mention any specific PLCs, but AdvancedHMI includes many PLC communication drivers as part of the free package. This gives you the ability to write VB or C# for transferring the values from the PLCs to a database. The drivers are not OPC drivers, but are designed to be much simpler to use and more efficient.
How can I interact with a PLC to send and receive data to/from a remote server(PC).
For example a robot that have a PLC and want to interact with a server that placed at near room with a wireless communication.
Data must move all over the time. PLC sending the data to the server and server must sending back the result of computation on the data to PLC.
review : My PLC brand is Delta but its model has not been selected yet .
A common scenario is that the manufacturer provides an OPC server for the PLC. You should check their website once you know the model. Then it is just a matter for you to create an OPC client.
A good way to start is to get a free OPC server simulator like the one from Matrikon. It doesn't need any hardware. OPC is a standard interface (although there are often some minor variations between manufacturers) - if you can get your client to work with the test server you can probably get it to work with the PLC.