由于项目需要连接PLC和PC，所以传送几种状态和控制信息。 为了实现最快的响应速度，采用了I/O直接连接。 但是，这需要添加I/O卡，与PLC的I/O功能有些重复。 那么，网络通信可能吗？ 本文进行一些实验。
西门子S7-1200
概述
使用的PLC是目前主流的西门子S7-1200。 支持PROFINET、PROFIBUS等网络标准/协议，也可以间接连接到Modbus设备。 任何标准都有很多服务/协议。 详情请参照Communication with SIMATIC 但是，这些标准中有些用于西门子的设备相互连接，不一定适用于PC。下图为TIA门户v 14的通信相关命令，也可作为线索。
PLC通信指令
与PC的通信可以使用OPC服务器，但它是基于OLE/COM的，只能在Windows上使用。 一些软件(如LabView )支持与西门子PLC的通信。 是跨平台开源方案，一个是Snap7。 先试试这个吧。 另外，请尝试最原始的TCP协议。
Snap7
Snap7是针对西门子S7协议的。 PLC不需要S7的服务器这一配置，但只需要利用Snap7 lib，就可以将PC作为S7客户端读取/写入服务器端的数据块。
数据块映射
块分为输入区域(DI、AI )、输出区域) DQ、AQ )、程序块) DB )等。 在下图中，DB3是测试程序的数据块。
数据块和监视值
可以使用Snap7包附带的(编译的)测试程序查看/更改值。
Snap7测试程序
访问设置
读写前需要进行配置和权限设置。 禁用块优化，并授予完全权限。 有关详细信息，请参阅Snap7文档。另外，有些设置未在文档中列出，即允许从远程对象进行PUT/GET通信访问。 否则就会出现“函数不可用”，
错误，如“基于函数的处理器”。
Snap7通信的访问设定
Python版的Snap7
使用脚本语言有时会很方便。 Python-snap7是Snap7 lib的python软件包。 因为只是接口层的封装，所以对速度的影响很小。安装时，需要安装Snap7库，然后使用pip安装python-snap7。 有些平台没有现成的Snap7库，需要自己编译。 总之是草莓派，我自己编译的。 实测Python2和Python3都工作。
核心代码如下： I/O只有2字节，所以直接读取/写入2字节。
导入快照7
从快照7 .快照7类型导入S7区域数据库，S7区域PA，S7区域应用
第7类客户端：类
def _ init _ (自，ip，槽=1，轨迹=0) :
self.client=snap7. client.client (
self.client.connect(IP，机架，插槽)。
延迟(自) :
区域=S7区域应用
db=0
开始=0
amount=2
ba=self.client.read _ area (区域、数据库、开始、停止) )。
d=巴西
d=8
d|=坝0
返回d
efwritedq (自，数据) :
区域=S7区域帕
db=0
开始=0
amount=2
ba=字节数组(amount )
BA0=数据0x FF
BA [1]=数据8
sel
f.client.write_area(area, db, start, ba)速度测试
循环读/写DQ，看看总耗时。示意代码如下：
def testWriteLoop(self, count): d = 0 self.log.info("Write DQ from: %04x", d) t1 = time.time() while d < count: self.plc.writeDQ(d) d += 1 t2 = time.time() self.log.info("Write DQ till: %04x. Average: %.2fms", (d - 1), (t2 - t1) * 1000 / d)可以看到单次读/写的平均时间略高于9ms.
读写测试结果
下图是最低位的波形。10个周期对应于20次写，耗时约182ms。高低电平不对称的问题后面再说。
递增写DQ时DQ0.0的波形
反向通信
如果PC做Snap7的服务器，则PLC需要使用GET/PUT指令读/写PC端的数据。既然都是S7协议，我们假设它的速度和正向是相当的，暂且跳过，先试试另一类型的通信。
原始的TCP通信
S7-1200支持开放式用户通信，即基于TCP，但不属于任何标准应用层协议的，完全由用户自己定义的协议。
实验设计
PC端作为服务器：实际测试使用树莓派充当PC的角色。PLC端发送数据：由一个DI来触发数据发送。树莓派开启数据发送：通过控制一个GPIO来开关继电器，进而改变PLC端的DI（信号1）；树莓派在收到数据后，改变另一个GPIO的状态（信号2）作为标志；比较信号2和信号1的时间差。
实验器材及连线
PC端
PC端作为服务器，监听某一端口。在Linux上，可以用命令行工具netcat进行调试。
开两个窗口：
netcat -l 2000: 监听端口2000netcat localhost 2000: 与本机2000端口连接一个窗口输入字符，另一个窗口就会显示出来。
然后，用Python socket写一个类似的服务器端程序，核心代码如下：
import socket self.sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM) self.sock.bind(('', self.args.port)) self.sock.listen(1) self.conn, addr = self.sock.accept() data = self.conn.recv(32) self.log.info("Received: %02X %02X", data[0], data[1])可以用 netcat 测试这个服务器程序。
PC端的TCP server
PLC端
PLC端使用TSEND_C发送数据。
由trigger触发数据发送，trigger对应于数字输入，比如DI0.1.trigger同时触发一个计数器。TSEND发送这个计数器的值，这样PC每次收到的数据是递增的。CONT设为TRUE，保持连接，这样速度最快。
PLC端程序
在网络连接设置中指定PC端的IP地址和端口号，端口号要和服务器监听的端口号一致。由PLC主动发起连接。
PLC端网络连接设置
初步的结果
下图中，黄色为PLC端的输入（信号1），绿色为树莓派上收到数据后的输出（信号2）。
都以上升沿作为标志。两者的时间差不到9ms。
通信耗时的波形图
可以更快吗？
通信负载
由通信引起的循环负荷：默认是20%，取值可以从15%到50%。改变这个值，发现对通信时间并没有影响。
输入滤波器
这个值默认是6.4ms，它是用来过滤按键抖动的。但对于电路触发（非人工/机械按键）的情况，这个抖动可以设得很小。
PLC输入滤波器
将它调小至0.1ms，整个耗时降低了约6ms. 通信耗时不到3ms了。
通信耗时（0.1ms输入滤波）
循环时间
PLC的运行方式是不断循环去读取输入，执行程序块，更新输出的模式。循环周期过长，是否会影响网络通信呢？
通过在线诊断，可以看到循环时间最长为4ms，通常都在1~2ms。
PLC循环时间
这说明循环时间并不是瓶颈。而且反过来，循环时间比通信时间还短（即使输入滤波器为6.4ms，通信时间9ms时，循环时间依然是1~2ms），这说明通信和循环似乎是分头执行的。
其它
本来还想试一下中断执行方式的，但把通信程序块放到中断响应里执行并没有成功。考虑到对于PLC的百兆网口，3ms已经够快了，就没再折腾了。
还试验了一下，在PLC上单纯地增加一个计数器或反复翻转输出电平，每次操作耗时大约也是3ms。
顺便说一句，在PLC的数字输出上，却看不到电平的翻转（看到的总是高电平）。前面有一张“递增写DQ时DQ0.0的波形”图，18ms的周期，基本上已看不到电平下降到0了。感觉PLC的输出频率并不高，甚至可能有高频滤波。
结语
从PLC的众多网络通信方式中，本文试验了简单易行并且跨平台的两种方式，用来和PC通信。
使用基于S7协议的Snap7库，在读写PLC时大约耗时9ms.使用开放式的TCP协议，PLC向PC发送数据最快不到3ms.考虑到S7-1200只是百兆网络，这个速度应该是不错的，可以满足大部分需要。