PLC | 西门子 Siemens S7 ISO-on-TCP 通讯协议探究——提高数据采集效率故障分析(使用边缘计算网关)
众所周知,我们软件读取 PLC 数据时按照 Bool/Byte/Word/Real 等类型进行通讯,有时候,需要频繁读取 PLC 多个数据字段偏移量时,就会造成传输效率低下的问题。

需求/故障现场

  • PLC 上有 100 个 word 需要读取,偏移量顺序排列,比如:从 0 - 200;
  • 需要 1 秒读取 1 次数据;
  • 转换后,数据转发到第三方系统:MQTT,SQL等;
  • 逐个读取每个 word,两个字节,需要在一个 TCP 会话中执行 100 次请求;
  • 每次请求,三个 TCP 数据传输,每次需要 15ms(423行-421行:3.614448-3.598902=0.015546s);
    2023-03-30T07:43:07.png
  • 这样的话,100次请求需要1.5546s,算上网络延迟和处理性能问题,整个过程需要2秒以上;
  • 结果就是:完全达不到 1秒1次 采集的需求。

分析过程

winCC 数据采集抓包

分析过程1:采集20个 real 数据字段

  • winCC 将数据包分解成 3个 item
    2023-03-30T07:52:38.png

分析过程2:采集10个 word 数据字段

  • 同样原理,winCC 将数据包按照每个 item 32 个字节
    2023-03-30T07:54:16.png

自有软件数据采集抓包

每次只是读取了1个 word 数据字段

2023-03-30T07:55:07.png

解决方案构思

  • 每次按照要求,获取所有需要的数据偏移量;
  • 取回来后,按照测点要求,自己根据数据类型分解出来;
  • 循环读取下一次数据;

验证

读取1000个字节

  • 可以看到分了5次数据,222+222+222+222+112=1000
    2023-03-30T08:20:45.png

下一步是继续验证分多个 item 进行数据采集

winCC 数据格式

  • 效率高,每次只需要 <2ms,分析原因:每次读取都是连续的地址空间,不需要PLC进行分段读取;
    2023-03-30T09:05:48.png

自己代码

  • 效率低,每次需要20-50ms,分析原因:每个 item 里面只有一个测点(word类型),需要分段读取;
    2023-03-30T09:08:15.png

开发过程

大概过程描述

  • 由于每次请求的数据量(按测点)叠加在一起,通过 S7DataItem 来组合,最多20个 item,打包一起发送到 PLC;
  • 收到每次的返回数据,再解析成对象插入二维表,等待处理;
  • 全部处理完成,统一根据请求数量,返回相应的结果集;

总结

  • PLC 针对于每个测点的处理时间在 1-3秒,数量越多,时间越长,是累加的;
  • 100个测点,算上 TCP 包头和包尾,大概来回数据时间是 220ms左右,200个测点是 400ms左右;
  • 通过这种方式,一个 PLC 建议采集点不超过 500个,虽然对 PLC 性能影响不大,但是处理时间较长,不适用1秒一次采集需求;
  • 每个型号 PLC 的处理性能不一样,支持的 TCP 连接数也不一定一样,所以,要根据具体需求来决定。

效果展示

  • 存入 SQL 数据库,完全控制在1秒一次采集
    2023-03-31T08:01:49.png
  • 4 个 TCP 连接非常稳定
    2023-03-31T08:02:56.png
  • 网关性能稳定
    2023-03-31T08:03:38.png
  • 与 PLC 交互的网卡网络流量很少
    2023-03-31T08:04:52.png

改进?

  • 类似 winCC 的模式,一次性读取一段偏移量,节省 TCP 开销,也节省 PLC 处理每个测点;
  • 针对一次读取来的一段偏移量内容进行解析,需要对字节码流处理非常熟悉;
  • 对于新建项目,比较适合用改进的方法,毕竟 PLC 可以根据需求改动测点偏移量;
分享|如何高效地获取工业 PLC 数据测点/码点,为 MES 系统提供有力的数据支撑?
高效、高速、稳定的数据采集