plc吧 关注：170,559贴子：841,096
不感兴趣
开通SVIP免广告
串口通信:
西门子PLC支持串口通信，在S7-200和S7-200Smart中，都直接集成了串口，但是从S7-1200到S7-1500，慢慢都取消掉了，如果需要，可以通过扩展模块的方式来增加，出现这种现象的原因，其实也是工业发展的必然结果。串口通信的优势在于简单、成本低，但是劣势也非常明显，就是传输效率低。西门子早期的串口通信主要是Profibus DP通信，但是上位机是无法直接与西门子PLC走Profibus DP通信的，因此，西门子PLC常用的串口通信方案如下所示：
PPI通信：PPI通信只针对S7-200和S7-200 Smart系列PLC，其他型号不支持。
ModbusRTU主站：西门子PLC对Modbus协议支持还是比较不错的，这里是指PLC做Slave（即从站），上位机做Master（即主站）。
ModbusRTU从站：这里是指PLC做Master（即主站），上位机做Slave（即从站）。
西门子PLC支持串口通信，在S7-200和S7-200Smart中，都直接集成了串口，但是从S7-1200到S7-1500，慢慢都取消掉了，如果需要，可以通过扩展模块的方式来增加，出现这种现象的原因，其实也是工业发展的必然结果。串口通信的优势在于简单、成本低，但是劣势也非常明显，就是传输效率低。西门子早期的串口通信主要是Profibus DP通信，但是上位机是无法直接与西门子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均可以实现，这里有很多可以选择的开源或商业库，包括http://s7.net、pronodave、libnodave、sharp7，也可以自己封装通信库。
ModbusTCP Server：这里是指PLC做Server（即服务器），上位机做Client（即客户端）。
ModbusTCP Client：这里是指PLC做Client（即客户端），上位机做Server（即服务器）。
OpenProtocol Server：这里是指开放式TCP通信，PLC做TCPServer（即服务器），上位机做TCPClient（即客户端）。
OpenProtocol Client：这里是指PLC做TCPClient（即客户端），上位机做TCPServer（即服务器）。
西门子PLC通信还是以太网通信为主，我们常说的西门子通信协议分别是S7协议和Profinet协议，但是Profinet是一种总线协议，目前，C#是无法直接与西门子PLC走Profinet通信的。因此，西门子PLC常用的以太网通信方案如下所示：
S7通信：基本上从S7-200到S7-1500均可以实现，这里有很多可以选择的开源或商业库，包括http://s7.net、pronodave、libnodave、sharp7，也可以自己封装通信库。
ModbusTCP Server：这里是指PLC做Server（即服务器），上位机做Client（即客户端）。
ModbusTCP Client：这里是指PLC做Client（即客户端），上位机做Server（即服务器）。
OpenProtocol Server：这里是指开放式TCP通信，PLC做TCPServer（即服务器），上位机做TCPClient（即客户端）。
OpenProtocol Client：这里是指PLC做TCPClient（即客户端），上位机做TCPServer（即服务器）。
OPC通信:
OPC通信是工业控制中常用的一种通信方式，主要在于OPC软件的选择以及OPCDA、OPCUA的选择，因此，西门子PLC常用的OPC通信方案如下所示：
PC Access系列：西门子针对S7-200开发PC-Access软件，针对S7-200 Smart又提供了PC-Access Smart软件，可以直接通过这些软件实现OPCDA通信。
Simatic Net 系列OPCDA：Simatic Net是西门子主推的OPC软件，支持西门子全系列，这里主要是OPCDA通信方式。
Simatic Net 系列OPCUA：新版的Simatic Net也开始支持OPCUA，这里主要是OPCUA通信方式。
KepServer 系列OPCDA：KepServer同样作为一款商业OPC软件，在国内使用率非常高，同样也支持西门子全系列，这里主要是OPCDA通信方式。
Simatic Net 系列OPCUA：新版的KepServer也开始支持OPCUA，这里主要是OPCUA通信方式。
OPC通信是工业控制中常用的一种通信方式，主要在于OPC软件的选择以及OPCDA、OPCUA的选择，因此，西门子PLC常用的OPC通信方案如下所示：
PC Access系列：西门子针对S7-200开发PC-Access软件，针对S7-200 Smart又提供了PC-Access Smart软件，可以直接通过这些软件实现OPCDA通信。
Simatic Net 系列OPCDA：Simatic Net是西门子主推的OPC软件，支持西门子全系列，这里主要是OPCDA通信方式。
Simatic Net 系列OPCUA：新版的Simatic Net也开始支持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通信是最方便，也是应该最广泛的，那么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协议支持直接位操作，有专门的报文指令实现这样的功能。
对于布尔操作，很多协议都有，但是这里的布尔操作是指寄存器布尔，比如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），这个一次性能读取的字节越长，越能提高上位机的通信效率。
大部分人都知道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），这个一次性能读取的字节越长，越能提高上位机的通信效率。
不感兴趣
开通SVIP免广告
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，这个时间应该相对来说还是比较正常的。
对于很多其他的通信协议，当我们遇到数据变量比较零散，同时读取多个存储区或者一个存储区多个不同部分的时候，我们只能针对每个存储区或者每块区域做一个数据请求，但是西门子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，这个时间应该相对来说还是比较正常的。
不感兴趣
开通SVIP免广告
