OpenPLC V4 插件系统实战：用 Python / C++ 写自定义 FB 与协议驱动

V4 的”模块化架构”不是口号——硬件 I/O 和工业协议都是插件，而且你可以用 Python 或 C/C++ 写自己的。本篇讲清楚插件模型的初态、启用方式，以及怎么动手扩。

图：OpenPLC V4 插件系统与两种语言分工

图：协议/硬件 I/O 皆插件、默认全禁用；Python 做桥接、native C++ 做硬实时。

一、初态：装好即”沉默”

V4 的五个协议/IO 插件（modbus_slave、modbus_master、opcua、s7comm、ethercat）默认全部禁用。刚装好的运行时不吐任何现场总线，直到你改 plugins.conf 显式开启。这点和 V3”装好就有 Web + Modbus”很不一样，第一次用容易以为”坏了”。

启用步骤：

复制运行容器/安装里的 plugins_default.conf 为 plugins.conf；
把目标插件的 Enabled 改为 true；
重启运行时（systemctl restart openplc-runtime 或重启容器）；
核对日志确认插件加载、端口/证书符合预期。

二、两种插件语言怎么选

语言	适合	特点
Python	协议桥接、快速原型、对接 REST/数据库	开发快，依赖 `venvs/runtime` 的 Python 环境
C/C++（native）	高性能 I/O、确定性强、贴近硬件	编译进核心，实时性更好，如 `ethercat`、`s7comm`

经验：做”把某设备数据搬进 OpenPLC 标签”的桥接，Python 插件最省力；做”确定性闭环控制用的 I/O 驱动”，用 native C++。

三、自定义功能块（FB）的开发思路

结合前文 STruC++ 管线，自定义 FB 有两条路：

IEC 层 FB：在 Editor 里用 LD/ST/FBD 直接画 FB，纯 IEC 生态，最通用；
C++ 插件 FB：把重计算/硬件打交道的部分用 C++ 写，编译进运行时，IEC 程序里直接实例化调用。适合算法密集或需要直接摸寄存器的场景。

混合模型的优势在于：控制逻辑留在 IEC（工程师可读可维护），性能/硬件敏感部分下沉 C++（运行时快且稳）。

四、协议驱动示例（思路）

想把一支 V4 没内置的仪表接进来：

用 Python 插件周期轮询仪表（串口/HTTP/私有协议）；
把读到的过程值写进 OpenPLC 的标签（映射到 %IW / %MD）；
反向把 OpenPLC 的输出标签通过同一插件下发到仪表；
在 plugins.conf 启用后，IEC 程序完全无感——它只看到标准变量。

五、坑提醒

改完插件务必重启，光改配置不重启不生效；
native 插件改了 C++ 要重新编译（参考笔者 LuckFox 部署里的 native 构建流程）；
Python 插件的依赖装在运行时自带 venv，别用系统 pip 乱装，避免版本冲突；
生产环境对自写插件做异常处理，避免插件崩了拖垮扫描周期。

六、小结

V4 的插件系统把”OpenPLC 能不能接我的东西”从”等官方支持”变成”自己写就行”。Python 做桥接、C++ 做硬实时，是这个模型最顺手的分工。

→ 下一篇也是本系列的差异化王牌：AI 增强 PLC，把本地 LLM 接到这套插件/标签体系上做预测性维护。

配套代码与参考仓库

OpenPLC Runtime v4（Autonomy-Logic，MIT）：https://github.com/Autonomy-Logic/openplc-runtime
OpenPLC Editor v4（Autonomy-Logic，GPL-3.0）：https://github.com/Autonomy-Logic/openplc-editor
本系列配套示例（Docker Compose / 启保停 ST / GPIO 接线 / AI agent）：https://gitcode.com/linjian19901122/openplc-v4-samples
Python / C++ 自定义 FB 与协议驱动骨架，见示例库 plugins/

系列导航 · 双向链接（OpenPLC V4 系列 · 共 12 篇）

本系列当前均为草稿（draft: true）。建议发布序：① → ③ → ② → ④ → ⑧ 打头，⑩⑪⑫ 作深度延展按读者反馈穿插。