当前位置: 首页 > 工具软件 > OpenPLC > 使用案例 >

Node-red开发软PLC程序?

诸修伟
2023-12-01

这是个胡思乱想,但是萦绕不去,索性写下来。文中逻辑混乱之处表示思想不深入。

首先,本文中的软PLC指IEC-61131-3的编辑器和运行态,典型代表是德国CodeSys开发平台。

Node-red与软PLC相似之处

Node-red和软PLC其实很像的:
1)都是流式数据,数据流动方向在各自的编辑器里甚至都是从左到右
2)输入、输出节点都可以是硬件驱动
3)数据处理节点大都是简单的算术处理
4)Node-red有injector节点作为定时器,而IEC-61131-3中的程序有固定的运行周期

区别之处

二者的区别在于:
1)定时周期差了2个数量级,Node-red是秒级(虽然设成0.2秒好像也可以?),而软PLC程序一般是1-100毫秒级;
Node-red对硬件不挑,对操作系统更不挑;IEC-61131-3的程序在实时环境下才能发挥最大威力
2)Node-red的硬件驱动弱而通用,基本上只有串口和网口,且串口节点相当糟糕,连包头包尾都没法定义;IEC-61131-3就不用说了,硬件驱动强悍而专用
3)数据处理节点方面,Node-red连全局变量和静态变量都没有,想在不同的控制/通信周期里存点全局数据,必须借助几个context api(心好累);而IEC-61131-3的寄存器天然就是静态变量,基于差值做控制很方便,比如PID里的D

合理性

现阶段让我纠结的其实是这两个问题:将Node-red与软PLC编程融合的话,是否合理/有何好处;可以用何种技术路线

首先考虑合理性问题,就是是否值得做。

有一个眼前的好处是方便“MES工单-PLC命令”转换。

简单来说,生产执行过程本来是要完成如下工作:
1)将L3级的工单指令分解成PLC命令序列
2)依序将PLC命令下发给各PLC,并更新工单的完成进度(也许还有工单内部物料的实时跟踪信息)
3)当PLC命令序列全部正常完成时,将工单设为完成
4)当PLC命令执行出错时,走异常分支,并将L3工单设为异常

以上工作(让我们简称它为PPC,Programmable PLC Control)显然是个服务。

如果Node-red与软PLC融合的话,大概就可以在Node-red里编辑PPC、实时查看状态;每个PLC程序是PPC里的一个节点,双击后可以编辑、实时查看状态。

用Node-red编辑PPC的话,可以有效地利用Node-red的各类消息驱动节点,方便与L3各应用打交道。(局限则是Node-red相对比较傻,类似AGV动态寻径这种高随机、高交互性的工单分解还是不方便。)

技术路线

技术路线有很多条:
1)彻底改造Node-red
将Node-red直接改造为软PLC编辑器和实时引擎,这需要剪裁个实时Linux、将流激发周期缩短到几十毫秒级、新开发一批符合规范的节点(主要可能是寄存器相关的)。
2)共享编辑器
将Node-red改造为软PLC编辑器,但是单独开发软PLC引擎,这需要剪裁个实时Linux、开发软PLC引擎、开发几个封装软PLC TASK的Node-red节点并在节点属性页里实现TASK编辑器。
3)完全分开
二者的编辑器和运行引擎彻底分开。只开发几个封装了软PLC TASK的NR节点,在NR节点属性页里直接链接到软PLC编辑器。软PLC TASK的实时数据由其自行负责。但其输入参数、启停控制、状态输出、参数输出要在NR中实现。

第三个路线看起来挺靠谱。。。走这条路线的话,Node-red与软PLC既可以合并部署,也可以分CPU部署。而且可以完全借鉴开源的OpenPLC项目,软PLC的编辑器和引擎有现成的。

几个想到相关的技术难点(也许对其他人不难)先记在这里:
1)实时Linux
2)OpenPLC
3)在Node-red做节点的深度封装,例如节点的“状态输出”怎么实现。
4)软PLC的硬件平台选型,特别是高速IO接口选型(PCIE总线不好走,也许要用USB接口板)

结语

不写出来不知道。看起来这是个相当麻烦的工程,几个人月内没法完成。可能要长期摸索了。

 类似资料: