Node-red开发软PLC程序？

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

首先，本文中的软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接口板）

结语

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