通过脚本让AI连接并操作软PLC

AI 把程序写进 CODESYS 工程之后，怎样让它进入控制器并运行？作者给出的路线是：让 AI 规划操作，通过 CODESYS 内部的 Script Engine 执行，再由软 PLC 运行应用。目标是把下载、启停和变量读写接成一条在线操作链路。

这篇短文的价值是划清各层职责，也提醒读者：生成代码只是其中一环。不过，原文没有提供脚本、调用参数或运行记录，适合用来理解方案，距离照着复现还有一段距离。

从工程同步到在线控制，补上了哪一环

作者上一篇解决的是「工程 ⇄ 文本 ⇄ AI」：让工程内容与 AI 能处理的文本互通。但程序仍然停留在工程里，还没有进入控制器执行。

这次要补的是在线通道。这里的「在线」指连接控制器运行时，对应用执行下载、启动、停止，以及变量读取和写入，并不是把工程上传到某个云端服务。

工程里的程序与控制器中正在运行的程序，是两个需要分别处理的状态。

因此，作者特别强调：下载与运行是分开的步骤。不能把「下载完成」直接当成「应用已经启动」。这对理解 AI 的操作计划很关键，否则一句「部署并运行」就可能掩盖中间尚未完成的动作。

为什么让 Script Engine 执行，而让 AI 规划

原文给出的链路是：

AI → Script Engine → soft PLC。

AI 负责安排动作，Script Engine 负责对运行时执行操作，软 PLC 负责运行应用。其中，Script Engine 使用的是 CODESYS 内部的 IronPython。

这套分工容易理解：AI 决定要做什么，脚本层把决定落实为具体操作，运行时承接程序执行。对熟悉 AI 编程工具的读者来说，可以把脚本层理解为 AI 操作目标系统的工具接口。

但原文只交代了职责，没有展示工具接口怎样定义、AI 怎样提交动作，也没有给出连接、下载或读写变量的 API。不能据此断言，它已经具备稳定的自动执行能力。

环境与变量路径，是复现时绕不过去的条件

作者列出的环境是 CODESYS V3.5 SP17、SoftMotion Win 64，以及 Windows + PowerShell 5.1。这些是方案的环境边界，原文没有说明其他版本是否兼容，也没有解释 PowerShell 5.1 在链路中承担什么工作。

变量访问还有一个明确约束：路径遵循控制器的命名方式，包括 GVL 和程序作用域。也就是说，AI 不能只凭一个业务名称就准确读写变量，它需要知道变量在控制器中的实际归属。

作者还指出，仿真模式可以在没有物理硬件的情况下使用。这给验证流程提供了入口。不过，仿真模式与文中软 PLC 环境如何配置、如何切换，原文没有展开。

我的判断

我认同它把「工程同步」与「运行时操作」分开，也认同由脚本层承接执行的分工。这样至少能明确：代码在哪里、动作由谁执行、程序在哪里运行。

但作者称之为在线闭环，展示的内容还不足以验证闭环质量。原文没有执行结果、变量读写示例，也没有说明 AI 是否会读取反馈并判断操作成功。它更接近一份架构说明，不能当成完整实践教程。

与人工在 CODESYS 中操作、或直接编写固定自动化脚本相比，引入 AI 是否更省时、更可靠，作者没有给对照数据。这里应保留判断：链路有用，AI 带来的额外收益尚未被证明。

能拿来做什么

• 如果你正在做 CODESYS 自动化，可以先把连接、下载、启动、停止、读取、写入分别列成明确动作，避免用一个含糊指令包办全部步骤。
• 给 AI 提供变量上下文时，应带上 GVL 或程序作用域及实际路径，不要只提供变量的业务含义。
• 复现前先核对 CODESYS V3.5 SP17、SoftMotion Win 64、Windows + PowerShell 5.1 这些环境条件，并优先利用无物理硬件的仿真模式验证流程。
• 如果你的日常 AI 编程只涉及前端页面或 Node 服务，可以借鉴「规划与执行分层」的思路；这篇没有提供可直接迁移到这些场景的实现。