终于有人把西门子plc通信说明白了！

前言

近西门子plc价格大幅上调，在工控界引起了不小的风波，不仅涨价，甚至还缺货，导致很多人不得不更改方案。听说近已经完成了芯片替换，希望不久能够恢复供货，并把价格回调。

通过这件事，从侧面可以看出，西门子在工控领域的市场占有率很大，那么对于上位机开发人员来说，使用西门子plc作为下位机，我们应该如何与之进行通信呢？

西门子plc支持很多种通信协议，主要分为两种，一种是串口通信，一种是以太网通信，同时也可以通过opc实现数据通信。

串口通信

西门子plc支持串口通信，在s7-200和s7-200smart中，都直接集成了串口，但是从s7-1200到s7-1500，慢慢都取消掉了，如果需要，可以通过扩展模块的方式来增加，出现这种现象的原因，其实也是工业发展的必然结果。串口通信的优势在于简单、成本低，但是劣势也非常明显，就是传输效率低。西门子早期的串口通信主要是profibusdp通信，但是上位机是无法直接与西门子plc走profibus dp通信的，因此，西门子plc常用的串口通信方案如下所示：

ppi通信：ppi通信只针对s7-200和s7-200 smart系列plc，其他型号不支持。modbusrtu主站：西门子plc对modbus协议支持还是比较不错的，这里是指plc做slave（即从站），上位机做master（即主站）。modbusrtu从站：这里是指plc做master（即主站），上位机做slave（即从站）。

以太网通信

西门子plc通信还是以太网通信为主，我们常说的西门子通信协议分别是s7协议和profinet协议，但是profinet是一种总线协议，目前，c#是无法直接与西门子plc走profinet通信的。因此，西门子plc常用的以太网通信方案如下所示：

s7通信：基本上从s7-200到s7-1500均可以实现，这里有很多可以选择的开源或商业库，包括https://s7.net、pronodave、libnodave、sharp7，也可以自己封装通信库。modbustcpserver：这里是指plc做server（即服务器），上位机做client（即客户端）。modbustcpclient：这里是指plc做client（即客户端），上位机做server（即服务器）。openprotocolserver：这里是指开放式tcp通信，plc做tcpserver（即服务器），上位机做tcpclient（即客户端）。openprotocolclient：这里是指plc做tcpclient（即客户端），上位机做tcpserver（即服务器）。

opc通信

opc通信是工业控制中常用的一种通信方式，主要在于opc软件的选择以及opcda、opcua的选择，因此，西门子plc常用的opc通信方案如下所示：

pc access系列：西门子针对s7-200开发pc-access软件，针对s7-200smart又提供了pc-access smart软件，可以直接通过这些软件实现opcda通信。simatic net 系列opcda：simaticnet是西门子主推的opc软件，支持西门子全系列，这里主要是opcda通信方式。simatic net 系列opcua：新版的simaticnet也开始支持opcua，这里主要是opcua通信方式。kepserver系列opcda：kepserver同样作为一款商业opc软件，在国内使用率非常高，同样也支持西门子全系列，这里主要是opcda通信方式。simatic net系列opcua：新版的kepserver也开始支持opcua，这里主要是opcua通信方式。

s7通信协议

在以上众多的通信方式和通信协议中，就目前而言，使用s7通信是方便，也是应该广泛的，那么s7协议相对于其他协议来说，有哪些优势呢？

使用s7通信协议大的优势在于不需要编写plc程序，而且s7协议在底层做了很强的封装，在上位机通信应用中相比其他通信协议来说，也有很大的优势。

虽然不需要编写plc程序，但仍然需要做一些简单的配置：

开启put/get

plc侧需要设置勾选允许来自远程对象的put/get通信访问对于西门子1200/1500系列，必须要勾选允许put/get访问，对于200smart/300/400，则不需要。

db块去除优化访问

对于基于博图开发s7-1200/1500的项目，如果要与db块数据通信，需要要去除db的优化的块访问，对于200smart/300/400，则不需要。如果希望通过标签通信，可以采用opcua。

务必保证通信地址是有效地址

因为plc大多数是基于存储区的，每个地址肯定是隶属于某个存储区，大家都知道西门子plc自带的存储区有i区、q区、m区、t区、c区，但是对于常用的db存储区是没有的，需要自己去创建，也就意味着，如果你要读取db地址，必须要提前创建好db存储区，除此以外，db存储区创建之后，默认是没有字节的，需要自己一个个添加变量，才能形成有效存储区，因此一个db存储区的范围是有限并且可见的（可以通过偏移量看出来）。

s7协议之布尔操作

对于布尔操作，很多协议都有，但是这里的布尔操作是指寄存器布尔，比如db100.dbx0.0，很多时候，我们都是通过先读取db100.dbb0的值，再通过位运算结果，写入到db100.dbb0中，实现db100.dbx0.0的操作，但是这种方式有弊端

：每次操作一个布尔值都需要与plc进行两次数据交互。

第二：安全性和稳定性无法保障，你不知道在你读取和写入之间，这个字节的值是否已经发生了改变。

这样的问题也存在于modbus协议的寄存器位操作，如40001.05，三菱、欧姆龙的寄存器位操作，如d100.06、w12.04，给上位机开发者带来很多苦恼。

但是s7协议支持直接位操作，有专门的报文指令实现这样的功能。

s7协议之pdu读取

大部分人都知道s7协议一次性读取有限制，但是具体是多少？怎么计算出来的？

s7协议的一次性读取长度是根据pdu计算出来的，这个pdu的值是来自于plc本身，不同型号的cpu，它的pdu是不一样的，可以参考下面两张图：

西门子plc的pdu大小是和cpu息息相关的，一般会有240、480、960三个档次，知道pdu之后，那么一次性读取的字节长度，就是在pdu的基础上减去18，这个18是指包头包尾会有18个字节，这样我们就知道了一般的plc，一次性能读取222个字节（240-18=222），但是对于s7-1516这样的plc，我们一次性是可以读取942个字节的（960-18=942），这个一次性能读取的字节越长，越能提高上位机的通信效率。

刚刚的方式是通过kepserver测试的，实际开发过程中，该怎么获取cpu的pdu呢，实际上在建立连接的第二次握手时，返回的报文中就包含pdu的值。

第二次握手返回的报文长度是27个字节，后两个字节就是pdu的值，上图展示的是s7-1200plc返回的报文，0和240的组合即为240。

对于s7-1500，我这里也做了一下测试，结果如下，返回结果为3和192，3和192的组合恰好是960（960=3*256+192）。

虽然pdu是由硬件做了限制，但是我们可以通过软件的方式，实现大量数据的读取，只需要在底层做一些封装即可。做了一下测试，针对s7-1200和s7-1500同时读取m区的8000个字节的耗时比较，s7-1200耗时800多ms，s7-1500耗时仅需200ms，由此可见，硬件对通信的重要性。

s7协议之多组读取

对于很多其他的通信协议，当我们遇到数据变量比较零散，同时读取多个存储区或者一个存储区多个不同部分的时候，我们只能针对每个存储区或者每块区域做一个数据请求，但是西门子s7协议可以解决这样的问题。

西门子s7协议有一个非常强大的一个地方，可以同时读取很多个不同的存储区，大支持19种，总共读取长度仍然受pdu的限制。

这里我们仍然以实验测试为例，体验多组读取带来的美妙体验。

假设我们的通信组配置如下：

通信组01：读取i区从0开始的1个字节

通信组02：读取q区从0开始的1个字节

通信组03：读取m区从0开始的200个字节

通信组04：读取m区从500开始的50个字节

通信组05：读取m区从1000开始的60个字节

通信组06：读取db100从0开始的20个字节

通信组07：读取db100从20开始的20个字节

通信组08：读取db100从40开始的20个字节

通信组09：读取db100从60开始的20个字节

我们采用常用s7-1200plc，通过配置软件实现配置以上9个通信组，开始通信测试，首先我们选择的是单组读取的方式，就是针对每个组，依次进行读取，结果如下，耗时大约200ms，这个时间应该相对来说还是比较正常的。

接着，将读取方式改成了多组读取，再进行测试发现结果如下：

通过结果发现，多组读取对于存储区较为零散的项目来说，有着非常重要的作用，可以大大提高通信效率。

总结

通过上面一系列的分享，相信大家对西门子plc通信有了更加深入的了解，希望大家可以多多实践。

每种通信方式都有自己的优缺点，对各种通信方式和协议了解之后，你才能够在不同的场合选择适合的通信方式，给出合理的解决方案。