需求/故障现场
- PLC 上有 100 个 word 需要读取，偏移量顺序排列，比如：从 0 - 200；
- 需要 1 秒读取 1 次数据；
- 转换后，数据转发到第三方系统：MQTT，SQL等；
- 逐个读取每个 word，两个字节，需要在一个 TCP 会话中执行 100 次请求；
- 每次请求，三个 TCP 数据传输，每次需要
15ms（423行-421行：3.614448-3.598902=0.015546s）；
- 这样的话，100次请求需要1.5546s，算上网络延迟和处理性能问题，整个过程需要2秒以上；
- 结果就是：完全达不到
1秒1次采集的需求。
分析过程
winCC 数据采集抓包
分析过程1：采集20个 real 数据字段
- winCC 将数据包分解成 3个 item
分析过程2：采集10个 word 数据字段
- 同样原理，winCC 将数据包按照每个 item 32 个字节
自有软件数据采集抓包
每次只是读取了1个 word 数据字段
解决方案构思
- 每次按照要求，获取所有需要的数据偏移量；
- 取回来后，按照测点要求，自己根据数据类型分解出来；
- 循环读取下一次数据；
验证
读取1000个字节
- 可以看到分了5次数据，222+222+222+222+112=1000
下一步是继续验证分多个 item 进行数据采集
winCC 数据格式
- 效率高，每次只需要 <2ms，分析原因：每次读取都是连续的地址空间，不需要PLC进行分段读取；
自己代码
- 效率低，每次需要20-50ms，分析原因：每个 item 里面只有一个测点（word类型），需要分段读取；
开发过程
大概过程描述
- 由于每次请求的数据量（按测点）叠加在一起，通过 S7DataItem 来组合，最多20个 item，打包一起发送到 PLC；
- 收到每次的返回数据，再解析成对象插入二维表，等待处理；
- 全部处理完成，统一根据请求数量，返回相应的结果集；
总结
- PLC 针对于每个测点的处理时间在 1-3秒，数量越多，时间越长，是累加的；
- 100个测点，算上 TCP 包头和包尾，大概来回数据时间是 220ms左右，200个测点是 400ms左右；
- 通过这种方式，一个 PLC 建议采集点不超过 500个，虽然对 PLC 性能影响不大，但是处理时间较长，不适用1秒一次采集需求；
- 每个型号 PLC 的处理性能不一样，支持的 TCP 连接数也不一定一样，所以，要根据具体需求来决定。
效果展示
- 存入 SQL 数据库，完全控制在1秒一次采集
- 4 个 TCP 连接非常稳定
- 网关性能稳定
- 与 PLC 交互的网卡网络流量很少
改进？
- 类似 winCC 的模式，一次性读取一段偏移量，节省 TCP 开销，也节省 PLC 处理每个测点；
- 针对一次读取来的一段偏移量内容进行解析，需要对字节码流处理非常熟悉；
- 对于新建项目，比较适合用改进的方法，毕竟 PLC 可以根据需求改动测点偏移量；