因项目需要PLC与PC连接，传输一些状态和控制信息。为了最快的响应速度，保险的方式是采用I/O直接连接。但这需要额外增加I/O卡，而且和PLC的I/O功能有些重复。那么，网络通信是否可行呢？本文将进行一些实验。
概述
使用的PLC是目前主流的西门子S7-1200. 它支持的网络标准/协议很多，比如PROFINET, PROFIBUS等,还可以间接连接Modbus设备。每个标准下都有很多服务/协议，详情可以参考Communication with SIMATIC 。但这些标准有些是用于西门子的设备互联的，不一定适用于PC。
下图是 TIA Portal V14 中通信相关的指令，也可以作为线索。
和PC的通信，一种方式是使用OPC server，但它是基于OLE/COM的，只能用于Windows。有些软件比如LabView提供了和西门子PLC通信的支持。跨平台的开源的方案，有一个是Snap7。我们可以先试试这个。另外可以尝试最原始的TCP协议。
Snap7
Snap7是针对西门子S7协议的。PLC不需任何配置就是S7的server，而我们只需要利用Snap7 lib，就可以让PC作为S7 client，读/写服务器端的数据块。
数据块映射
数据块分为输入区(DI, AI)，输出区(DQ, AQ)，程序数据块(DB）等等。下图中，DB3是测试程序的数据块。
用Snap7包中自带的（编译好的）测试程序可以查看/修改它的值。
访问设置
在读写前需要进行配置和权限的设置：禁用块优化，给予完全访问权限，详见 Snap7的文档。
还有一个文档中没提到的设置：允许来自远程对象的PUT/GET通信访问。否则会出现 "Function not available", "function refused by CPU"之类的错误。
Python版的Snap7
有时使用脚本语言会更方便一些。python-snap7就是一个Snap7 lib的Python封装。因为只是接口层的封装，对速度的影响很小。
安装时需要先安装Snap7的库，再用pip安装python-snap7。有些平台没有现成的Snap7的库，需要自己编译。反正树莓派上我是自己编译的。 实测Python2和Python3都可以工作。
核心调用代码如下。因为I/O只有两字节，就直接读/写两字节了。
import snap7
from snap7.snap7types import S7AreaDB, S7AreaPA, S7AreaPE
class S7Client:
def __init__(self, ip, slot=1, rack=0):
self.client = snap7.client.Client()
self.client.connect(ip, rack, slot)
def readDI(self):
area = S7AreaPE
db = 0
start = 0
amount = 2
ba = self.client.read_area(area, db, start, amount)
d = ba[1]
d <<= 8
d |= ba[0]
return d
def writeDQ(self, data):
area = S7AreaPA
db = 0
start = 0
amount = 2
ba = bytearray(amount)
ba[0] = data & 0xff
ba[1] = data >> 8
self.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。高低电平不对称的问题后面再说。
反向通信
如果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: 监听端口2000
- netcat 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 测试这个服务器程序。
PLC端
PLC端使用TSEND_C发送数据。
- 由trigger触发数据发送，trigger对应于数字输入，比如DI0.1.
- trigger同时触发一个计数器。TSEND发送这个计数器的值，这样PC每次收到的数据是递增的。
- CONT设为TRUE，保持连接，这样速度最快。
在网络连接设置中指定PC端的IP地址和端口号，端口号要和服务器监听的端口号一致。由PLC主动发起连接。
初步的结果
下图中，黄色为PLC端的输入（信号1），绿色为树莓派上收到数据后的输出（信号2）。
都以上升沿作为标志。两者的时间差不到9ms。
可以更快吗？
通信负载
由通信引起的循环负荷：默认是20%，取值可以从15%到50%。改变这个值，发现对通信时间并没有影响。
输入滤波器
这个值默认是6.4ms，它是用来过滤按键抖动的。但对于电路触发（非人工/机械按键）的情况，这个抖动可以设得很小。
将它调小至0.1ms，整个耗时降低了约6ms. 通信耗时不到3ms了。
循环时间
PLC的运行方式是不断循环去读取输入，执行程序块，更新输出的模式。循环周期过长，是否会影响网络通信呢？
通过在线诊断，可以看到循环时间最长为4ms，通常都在1~2ms。
这说明循环时间并不是瓶颈。而且反过来，循环时间比通信时间还短（即使输入滤波器为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只是百兆网络，这个速度应该是不错的，可以满足大部分需要。
