Expert lecture "Exploration of PLC Communication Principles" series of videos: https://www.ad.siemens.com.cn/service/elearning/series/288.html
Serial one: [Exploration of PLC communication principles] The preface of the egg behind the big lecture hall
Serialization Part 2: [Exploring the Secrets of PLC Communication Principles] A Preliminary Study of the Eggs Behind the Scenes in the Lecture Hall
Serial number three: [Exploration of PLC communication principles] The failure of the eggs behind the scenes in the lecture hall
Serial number four: [Exploration of PLC communication principles] The dawn of the eggs behind the big lecture hall
Serial number five: [Exploration of PLC communication principles] The darkness of the eggs behind the big lecture hall
Serial No. 6: [Exploration of PLC Communication Principle] The Breaking of Eggs Behind the Scenes in the Lecture Hall
Serialized Part Seven: [Exploring the Principles of PLC Communication] The Sail of the Eggs Behind the Scenes in the Lecture Hall
Serial number eight: [Exploration of PLC communication principles] The shadow of the eggs behind the big lecture hall
Serial number nine: [Exploration of PLC communication principles] The bright flower of the egg behind the big lecture hall
The application of Wireshark allows me to clearly see the structure of the data message and fully understand the role and meaning of the ISO / OSI reference model. I remember learning Profibus before, and using Amprolyzer software to capture packets on Profibus to see the message structure, but at that time, I did n’t understand it in any way, so I rarely used this software. Actually think about it now. This software is definitely not weaker than the use of an oscilloscope to detect Profibus failures, but now there are fewer and fewer opportunities to use Profibus, because Profibus has really entered the sunset stage. And now is the era of Ethernet!
In addition, when using Profibus to configure S7 communication, you can always see the term TSAP. Although it is represented by two numbers in Step7, it is also a mess when you are learning Profibus communication. Or how to explain this parameter. I remember not paying attention to it at the time, because both configuration and programming have nothing to do with this parameter, it seems to play a role of display.
When I understood Ethernet deeply and studied the ISO / OSI reference model, this parameter surfaced again, making me have to face it again. It turns out that the layers of the ISO / OSI reference model rely on SAP and Service Access Point to communicate, which means that the communication between layers depends on SAP. For example, TSAP is located between Transport Layer and Session Layer. The first letter T and SAP of the transport layer of layer 4 are used for naming. The SAP between other layers is implemented according to this naming method. Learning by searching information on the Internet, I found that the TSAP of the ISO / OSI reference model is the Port in the TCP / IP model. So all this is easy to understand, and then look at Profubus S7 communication, which uses the ISO / OSI reference model, so you can only see TSAP.
Going back to those S7 packets captured by Wireshark, I found that the size of the S7 PDU is 240B, and the size of the data must be less than 240B, because the S7 PDU also contains the S7 Header, this S7 packet header also takes up some bytes . This is easy to understand, but I read the manual, including the aforementioned data consistency size of PUT / GET communication of S7-300 is 240B, then I began to doubt that the size of the communication data consistency is 240B, and S7 PDU It is also 240B, so the real communication data must be less than 240B. If it is as described in the manual, 240B must be composed of S7 data in two frames. Since it is two frames, it is not the data sent at the same time, then the data How to ensure consistency? Through the Step7 online help, you can see that when using the S7-300 with integrated PN interface, the data consistency of PUT / GET is 212B, 222B, and then combined with Wireshark, the S7 data in the frame of PUT and GET is indeed consistent with the data of the online help At this time, I felt suddenly bright, as always! It also shows that the size description of 240B data consistency in the 300CPU manual is not accurate.
In fact, the earliest concept of exposure to data consistency came from PII / PIQ, because the manual said that the data of PII / PIQ remains unchanged for a CPU cycle. In fact, this is not a certain address, but the entire PII / PIQ address area. For example: The size of the process image area in S7-300 is 256B by default. Understanding the concept of data consistency was limited to this at the time, but I felt that this concept was very important when programming. Remember to do the rolling mill project in the past. The self-written coil diameter calculation formula requires some parameters. The communication data from the driver requires these. The data should be consistent, because only in this way can the formula be calculated correctly. This also shows that understanding this concept is definitely instructive for the programming of engineering projects.
So is the data consistency of BSEND / BRECV 240B as described in the manual? Always read the manual, S7-300PLC can carry out a maximum of 32k S7 communication, S7-400PLC can carry out a maximum of 64k S7 communication, S7-300PLC can guarantee 240B data consistency, if you want to maintain consistent data in the entire communication data area Sex, need to use Done / NDR signal.
After capturing packets through Wireshark, I see that the size of the S7 PDU is still 240B. So the data consistency of 240B in the manual requires two packets to synthesize a 240B S7 data? If so, is the PLC complicated? How can it be guaranteed internally? Or is the data consistency not 240B? Although Wireshark captures packets and can see the true size of S7 data, for example, the length of the first packet data of S7 communication is 204B, is this the true size of data consistency? How to prove it?
This is indeed a difficult problem. I feel that I have just set off, and I have run aground here, and I feel that solving it must be in front of the sea and sky!
