
Introduction

Recently, Siemens PLC prices have surged significantly, causing quite a stir in the industrial control sector. Not only have prices increased, but there are also shortages, forcing many to change their plans. It is said that chip replacements have been completed recently, and supply is expected to resume soon, along with price adjustments.
This incident indirectly shows that Siemens has a large market share in the industrial control field. So for upper computer developers, how should we communicate with Siemens PLCs as lower computers?
Siemens PLC supports many communication protocols, mainly divided into two types: serial communication and Ethernet communication. Data communication can also be achieved through OPC.

Serial Communication

Siemens PLC supports serial communication. The S7-200 and S7-200 Smart series directly integrate serial ports, but from S7-1200 onwards, they have gradually been phased out. If needed, additional modules can be used to increase this capability. This phenomenon is actually an inevitable result of industrial development. The advantage of serial communication lies in its simplicity and low cost, but the disadvantage is very obvious: low transmission efficiency. Early serial communication of Siemens was mainly Profibus DP communication, but the upper computer cannot directly communicate with Siemens PLC via Profibus DP. Therefore, common serial communication solutions for Siemens PLC are as follows:
PPI Communication: PPI communication is only applicable to S7-200 and S7-200 Smart series PLCs; other models do not support it.
Modbus RTU Master: Siemens PLC has good support for the Modbus protocol, where the PLC acts as a Slave and the upper computer as a Master.
Modbus RTU Slave: Here, the PLC acts as a Master and the upper computer as a Slave.

Ethernet Communication

Siemens PLC communication is primarily based on Ethernet communication. The commonly referred Siemens communication protocols are the S7 protocol and Profinet protocol. However, Profinet is a bus protocol, and currently, C# cannot directly communicate with Siemens PLC via Profinet. Therefore, the common Ethernet communication solutions for Siemens PLC are as follows:
S7 Communication: This is generally achievable from S7-200 to S7-1500, with many open-source or commercial libraries available, including
http://s7.net, pronodave, libnodave, sharp7, or you can create your own communication library.
Modbus TCP Server: Here, the PLC acts as a Server and the upper computer as a Client.
Modbus TCP Client: Here, the PLC acts as a Client and the upper computer as a Server.
Open Protocol Server: This refers to open TCP communication, with the PLC acting as a TCP Server and the upper computer as a TCP Client.
Open Protocol Client: This refers to the PLC acting as a TCP Client and the upper computer as a TCP Server.

OPC Communication

OPC communication is a commonly used communication method in industrial control, mainly depending on the selection of OPC software and the choice between OPC DA and OPC UA. Therefore, the common OPC communication solutions for Siemens PLC are as follows:
PC Access Series: Siemens has developed PC-Access software for S7-200 and provided PC-Access Smart software for S7-200 Smart, allowing direct OPC DA communication through these software.
Simatic Net Series OPC DA: Simatic Net is Siemens’ main OPC software, supporting the entire Siemens series, focusing on OPC DA communication.
Simatic Net Series OPC UA: The new version of Simatic Net also supports OPC UA, primarily focusing on OPC UA communication.
KepServer Series OPC DA: KepServer is also a commercial OPC software widely used domestically, supporting the entire Siemens series, primarily focusing on OPC DA communication.
Simatic Net Series OPC UA: The new version of KepServer also supports OPC UA, mainly focusing on OPC UA communication.

S7 Communication Protocol
Among the various communication methods and protocols, using S7 communication is currently the most convenient and widely applicable. So what advantages does the S7 protocol have compared to other protocols?
The greatest 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 computer communication applications compared to other communication protocols.
Although writing PLC programs is not necessary, some simple configurations are still required:
Enable Put/Get
On the PLC side, it is necessary to check the option to allow Put/Get communication access from remote objects. For Siemens 1200/1500 series, Put/Get access must be enabled; for 200 Smart/300/400, it is not required.
Remove Optimization Access for DB Blocks
For projects developed based on the S7-1200/1500 using B&R, if you want to communicate with DB block data, you need to remove the optimized block access for DBs; for 200 Smart/300/400, this is not required. If you wish to communicate via tags, OPC UA can be used.
Ensure Communication Address is Valid
Since most PLCs are based on storage areas, each address must belong to a specific storage area. As everyone knows, Siemens PLCs come with built-in storage areas such as I, Q, M, T, and C areas. However, commonly used DB storage areas are not included, requiring manual creation. This means that if you want to read a DB address, you must create the DB storage area in advance. Additionally, once created, the DB storage area does not have bytes by default; you need to add variables one by one to create a valid storage area. Therefore, the range of a DB storage area is limited and visible (which can be seen through offsets).

S7 Protocol Boolean Operations

For Boolean operations, many protocols exist, but here the Boolean operation refers to register Boolean, such as DB100.DBX0.0. Often, we first read the value of DB100.DBB0, then perform bitwise operations and write the result back to DB100.DBB0 to achieve operations on DB100.DBX0.0. However, this method has drawbacks:
First: Each operation on a Boolean value requires two data exchanges with the PLC.
Second: Safety and stability cannot be guaranteed; you do not know if the value of this byte has changed between your read and write operations.
This issue also exists in Modbus protocol register bit operations, such as 40001.05, and in Mitsubishi and Omron register bit operations, such as D100.06 and W12.04, causing much distress for upper computer 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 what are the specifics? How is it calculated?
The length of data that can be read at once using the S7 protocol is calculated based on the PDU value, which comes from the PLC itself. Different CPU models have different PDU values. You can refer to the following two images:


The PDU size of Siemens PLC is closely related to the CPU, typically at levels of 240, 480, and 960. Knowing the PDU, the length of data that can be read at once is the PDU value minus 18, which accounts for the header and footer. Thus, we find that a typical PLC can read 222 bytes at once (240-18=222), while for PLCs like S7-1516, it can read 942 bytes at once (960-18=942). The longer the length of data that can be read at once, the higher the communication efficiency of the upper computer.
The previous method 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 representing 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 were as follows: the returned result is 3 and 192, where the combination of 3 and 192 is precisely 960 (960=3*256+192).

Although the PDU is limited by hardware, we can achieve large data reads through software by performing some encapsulation at the lower level. I conducted a test comparing the time taken to read 8000 bytes from the M area for S7-1200 and S7-1500: S7-1200 took over 800 ms, while S7-1500 took only 200 ms, highlighting 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.
The Siemens S7 protocol has a very powerful feature: it can simultaneously read many different storage areas, supporting up to 19 types, with the total reading length still limited by PDU.
Here, we will use experimental testing to experience the wonderful benefits of multi-group reading.

Assuming our communication group is configured as follows

Communication Group 01: Read 1 byte starting from I area 0
Communication Group 02: Read 1 byte starting from Q area 0
Communication Group 03: Read 200 bytes starting from M area 0
Communication Group 04: Read 50 bytes starting from M area 500
Communication Group 05: Read 60 bytes starting from M area 1000
Communication Group 06: Read 20 bytes starting from DB100
Communication Group 07: Read 20 bytes starting from DB100, starting at 20
Communication Group 08: Read 20 bytes starting from DB100, starting at 40
Communication Group 09: Read 20 bytes starting from DB100, starting at 60
We use the commonly used S7-1200 PLC, configure the above 9 communication groups through configuration software, and start communication testing. First, we choose the single group reading method, reading each group sequentially, with results as follows: it takes about 200 ms, which is relatively normal.

Next, we changed the reading method to multi-group reading and found the results as follows:

The results show that multi-group reading plays a very important role for projects with scattered storage areas, greatly improving communication efficiency.

Conclusion

Through this series of sharing, I believe everyone has gained a deeper understanding of Siemens PLC communication. I hope everyone can practice more.
Every communication method has its own advantages and disadvantages. Understanding various communication methods and protocols will enable you to choose the appropriate communication method in different situations and provide the most reasonable solution.
Source: This article is reproduced from the internet, and the copyright belongs to the original author. If there are any copyright issues, please contact us for deletion. Thank you!

Scan to Follow
WeChat ID|13615417996
Follow the left QR code to get free
[Siemens Data Collection]