Recently, the price of Siemens PLCs has risen significantly, causing quite a stir in the industrial control community. Not only have prices increased, but there are also shortages, forcing many to change their plans. It is said that the chip replacement has been completed recently, and supply should be restored soon, with prices expected to be adjusted.
From this incident, it can be inferred that Siemens holds a significant market share in the industrial control field. So for upper-level machine developers, how should we communicate with Siemens PLCs as lower-level machines?
Siemens PLCs support many communication protocols, mainly divided into two types: serial communication and Ethernet communication, and data communication can also be achieved through OPC.
Serial Communication
Siemens PLCs support serial communication, with built-in serial ports in the S7-200 and S7-200 Smart series. However, from the S7-1200 to S7-1500, these have gradually been removed, and if needed, can be added through expansion modules. This phenomenon is actually an inevitable result of industrial development. The advantage of serial communication is its simplicity and low cost, but the disadvantages are also very obvious, particularly its low transmission efficiency. The early serial communication of Siemens mainly used Profibus DP communication, but the upper-level machine cannot directly communicate with Siemens PLCs using Profibus DP. Therefore, the commonly used serial communication schemes for Siemens PLCs are as follows:
PPI Communication: PPI communication is only applicable to the S7-200 and S7-200 Smart series PLCs; other models do not support it.
ModbusRTU Master: Siemens PLC has good support for the Modbus protocol, where the PLC acts as a Slave (i.e., subordinate), and the upper-level machine acts as a Master (i.e., primary).
ModbusRTU Slave: Here, the PLC acts as a Master (i.e., primary), and the upper-level machine acts as a Slave (i.e., subordinate).
Ethernet Communication
Siemens PLC communication mainly relies on Ethernet communication. The Siemens communication protocols we commonly refer to are the S7 protocol and Profinet protocol; however, Profinet is a bus protocol, and currently, C# cannot directly communicate with Siemens PLCs using Profinet. Therefore, the commonly used Ethernet communication schemes for Siemens PLCs are as follows:
S7 Communication: This is generally achievable from S7-200 to S7-1500. There are many open-source or commercial libraries available, including http://s7.net, pronodave, libnodave, sharp7, or you can encapsulate your own communication library.
ModbusTCP Server: Here, the PLC acts as a Server (i.e., server), and the upper-level machine acts as a Client (i.e., client).
ModbusTCP Client: Here, the PLC acts as a Client (i.e., client), and the upper-level machine acts as a Server (i.e., server).
OpenProtocol Server: Here, it refers to open TCP communication, with the PLC acting as a TCP Server (i.e., server) and the upper-level machine as a TCP Client (i.e., client).
OpenProtocol Client: Here, the PLC acts as a TCP Client (i.e., client), and the upper-level machine acts as a TCP Server (i.e., server).
OPC Communication
OPC communication is a commonly used communication method in industrial control, mainly depending on the choice of OPC software and the selection of OPCDA and OPCUA. Therefore, the commonly used OPC communication schemes for Siemens PLCs are as follows:
PC Access Series: Siemens developed PC-Access software for the S7-200 and provided PC-Access Smart software for the S7-200 Smart, which can directly achieve OPCDA communication through these software.
Simatic Net Series OPCDA: Simatic Net is Siemens’ main OPC software, supporting the entire Siemens series, mainly focusing on OPCDA communication.
Simatic Net Series OPCUA: The new version of Simatic Net also begins to support OPCUA, mainly focusing on OPCUA communication.
KepServer Series OPCDA: KepServer, as a commercial OPC software, is widely used in China and also supports the entire Siemens series, mainly focusing on OPCDA communication.
Simatic Net Series OPCUA: The new version of KepServer also begins to support OPCUA, mainly focusing on OPCUA communication.
S7 Communication Protocol
Among the many communication methods and protocols mentioned above, currently, using S7 communication is the most convenient and should be the most widely used. So what advantages does the S7 protocol have over other protocols?
The biggest advantage of using the S7 communication protocol is that it does not require writing PLC programs, and the S7 protocol has strong encapsulation at the lower level, providing significant advantages in upper-level machine communication applications compared to other communication protocols.
Although there is no need to write PLC programs, some simple configurations are still required:
Enable Put/Get
On the PLC side, it needs to be set to allow Put/Get communication access from remote objects. For Siemens 1200/1500 series, Put/Get access must be enabled, while for 200Smart/300/400, it is not required.
Remove Optimization Access for DB Blocks
For projects based on Boto developing S7-1200/1500, if you want to communicate with DB block data, you need to remove the optimized block access for DB. For 200Smart/300/400, it is not required. If you want to communicate through tags, you can use OPCUA.
Ensure that the communication address is valid
Because most PLCs are based on storage areas, each address must belong to a certain storage area. As we know, Siemens PLCs come with built-in storage areas I, Q, M, T, C, but there is no built-in DB storage area; you need to create it yourself. This means that if you want to read a DB address, you must create the DB storage area in advance. Additionally, after creating the DB storage area, it starts with no bytes by default; you need to add variables one by one to form a valid storage area. Therefore, the range of a DB storage area is limited and visible (can be seen through offsets).
S7 Protocol Boolean Operations
Many protocols have Boolean operations, but here the Boolean operation refers to register Boolean, such as DB100.DBX0.0. Many times, we first read the value of DB100.DBB0, then perform bitwise operations to write the result back to DB100.DBB0 to achieve the operation of DB100.DBX0.0. However, this method has its drawbacks.
First: Each operation of a Boolean value requires two data interactions with the PLC.
Second: Safety and stability cannot be guaranteed; you do not know whether the value of this byte has changed between your read and write operations.
This problem also exists in the register bit operations of Modbus protocols, such as 40001.05, and in Mitsubishi and Omron’s register bit operations, such as D100.06, W12.04, causing many headaches for upper-level machine developers.
However, the S7 protocol supports direct bit operations, with dedicated message instructions to achieve this functionality.
S7 Protocol PDU Reading
Most people know that the S7 protocol has limitations on the amount of data that can be read at once, but how much is it? How is it calculated?
The length of data that can be read at once in the S7 protocol is calculated based on the PDU, which is derived from the PLC itself. Different CPU models have different PDU values, as shown in the two images below:
The PDU size of Siemens PLCs is closely related to the CPU, generally having three levels: 240, 480, and 960. Knowing the PDU, the maximum number of bytes that can be read at once is the PDU minus 18, where 18 refers to the header and footer of the packet. Thus, we find that a typical PLC can read 222 bytes at once (240-18=222), while for a PLC like the S7-1516, it can read 942 bytes at once (960-18=942). The longer the byte length that can be read at once, the greater the efficiency of communication for the upper-level machine.
The method mentioned earlier was tested using KepServer. In actual development, how do we obtain the CPU’s PDU? In fact, during the second handshake of establishing the connection, the returned message contains the PDU value.
The length of the message returned during the second handshake is 27 bytes, with the last two bytes being the PDU value. The image above shows the message returned by the S7-1200 PLC, where the combination of 0 and 240 represents 240.
For the S7-1500, I also conducted a test, and the results are as follows, where the returned result is 3 and 192, and the combination of 3 and 192 happens to be 960 (960=3*256+192).
Although the PDU is limited by hardware, we can achieve large data reads through software by making some encapsulations at the lower level. I conducted a test comparing the time taken to read 8000 bytes from the M area for both S7-1200 and S7-1500. The S7-1200 took over 800 ms, while the S7-1500 took only 200 ms, demonstrating the importance of hardware in communication.
S7 Protocol Multi-Group Reading
For many other communication protocols, when we encounter scattered data variables and need to read multiple storage areas or different parts of a single storage area, we can only make a data request for each storage area or block. However, the Siemens S7 protocol can solve this problem.
One powerful feature of the Siemens S7 protocol is that it can read many different storage areas simultaneously, supporting a maximum of 19 types, although the total reading length is still limited by the PDU.
Here, we take an experimental test as an example to experience the wonderful benefits of multi-group reading.
Assuming our communication groups are configured as follows:
Communication Group 01: Read 1 byte starting from 0 in the I area
Communication Group 02: Read 1 byte starting from 0 in the Q area
Communication Group 03: Read 200 bytes starting from 0 in the M area
Communication Group 04: Read 50 bytes starting from 500 in the M area
Communication Group 05: Read 60 bytes starting from 1000 in the M area
Communication Group 06: Read 20 bytes starting from 0 in DB100
Communication Group 07: Read 20 bytes starting from 20 in DB100
Communication Group 08: Read 20 bytes starting from 40 in DB100
Communication Group 09: Read 20 bytes starting from 60 in DB100
We use the commonly used S7-1200 PLC to configure the above 9 communication groups through configuration software and start communication testing. First, we select the single-group reading method, reading each group sequentially, and the result is as follows, taking about 200 ms, which should be considered relatively normal.
Next, we changed the reading method to multi-group reading, and the results were as follows:
Through the results, it can be seen that multi-group reading plays a very important role in projects with scattered storage areas, significantly improving communication efficiency.
Summary
Through the series of sharing above, I believe everyone has gained a deeper understanding of Siemens PLC communication. I hope everyone can practice more.
Each communication method has its own advantages and disadvantages. Only by understanding the various communication methods and protocols can you choose the appropriate communication method for different situations, providing the most reasonable solution.
————————————————
Copyright Statement: This article is an original piece by CSDN blogger ‘mayilove_2’ and follows the CC 4.0 BY-SA copyright agreement. Please include the original source link and this statement when reprinting.
Get Electrical Software for Free
Scan the QR code below↓↓↓to get it “for free“!
