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.
Related
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 working on a legacy modbus program for an industrial SCADA system.
Currently, the c++ program acts as both a modbus TCP server and client.
Client behaviour:
It reads from a number of vendor PLCs (servers) on site, performs calculations and sends control commands back to the PLCs based on the data received across the site.
Server behaviour:
responds to a variety of TCP read and write requests from web interfaces and laptops on site.
Until now, this has worked fine, but we have recently installed a logging client on the network which polls our program very frequently (sub-second) and this has revealed timing issues: the program can potentially take a very long time in its client loop performing calculations and reading PLC values before acting as a server and responding to incoming requests.
Easy solution would be to split the programs into a modbus server and client instance, and keep them both running on the same embedded PC.
The issue I have is that the remote web interface (HMI) must be able to control the behaviour of vendor PLC 2 and Vendor PLC 2 will only allow one TCP connection from the embedded PC. In the past the program has handled writes requests from the HMI by forwarding them on to the PLC 2 via the open socket.
I'd be keen to gather thoughts on best practices here.
My thinking:
the modbus server program will need to respond to the HMI requests and somehow store the information required for vendor PLC 2, and it will also need to set a status register to inform the modbus client that there is data for vendor PLC 2.
The modbus client program will need to read the status register (and data) from the server and pass this on to vendor PLC 2.
Am I heading in the right direction?
Without having details on your implementation I can only guess the problem is that your program is single-threaded, and delays are caused by waiting responses from PLCs.
So, if my assumption is correct, you need to switch to 'select' function and redesign your software to be totally async. You have to put all sockets (both connected and accepted) in a FDs set and wait events on them.
win32:
https://learn.microsoft.com/en-us/windows/desktop/api/winsock2/nf-winsock2-select
linux:
https://www.opennet.ru/cgi-bin/opennet/man.cgi?topic=select&category=2
I've written the same app ages ago on win32 (but without calculations) and it easily processed about 200 PLCs, working on the same machine with SCADA.
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.
I am planning to make some microcontroller boards which would do miscellaneous tasks. For example measuring analog voltages or controlling other instruments. Each board needs to be controlled/downloaded it's data from one place. For that purpose I would use an ethernet interface and do the comnunication over that. So my question is: which would be the most suitable method of achieving that. My ideas are: run a webserver on each module and communicate with POST/GET, or run a telnet server on boards and communicate with a telnet client. The security and speed/latency is not an concern but the data integrity is.
I don't need a html based gui for modules because I will implement an application which will communicate wizh the modules periodically, gets the data from them and stores in a database. And the database is what I will use later, for examining the data for example.
An other example:
I have a board which measures measures temperature. There is a server on the board itself run by the mcu. It is connected to a router via the ENC chip. I have my pc also connected to that router. I have an application which connects to the server run by the Atmega328 and collects the data then stores to a database. It repeats this let's say in every hour. I would use an Atmega328 and an ENC28J60 ethernet interface chip. What do you recommend?