AI辅助PLC编程：用结构化文本ST和Agent闭环提升效率

干PLC这行的这些年我写过的梯形图估计能堆满一个文件柜但真正遇到配方管理、运动控制、数据处理这些复杂需求时还是会老老实实切到ST结构化文本。今年开始我试着用AI把需求直接变成完整ST程序又顺手搭了一套基于agent的生成、编译、反馈闭环跑了两个项目确实省了不少时间也踩了不少坑。这篇文章就把我摸索出来的这套玩法整理出来适合想用AI提高PLC编程效率的电气工程师、自动化运维也适合刚接触ST语言的新人。1. 为什么PLC编程需要AI这条新路子1.1 梯形图到结构化文本痛点究竟在哪梯形图确实是PLC编程的“母语”电气工程师看着继电器电路就能上手排查故障时一眼看到通断状态这个优势到现在都无法替代。但设备越来越复杂你总会在某个时间点遇到梯形图很难写清的逻辑上百条配方要按表切换、温度PID参数需要在线自整定、Modbus报文要拆字节还要做CRC校验或者一个状态机有十几个互锁条件。用梯形图写这些网络会铺得特别长改一个条件可能牵扯七八个网络。ST语言本质上是PLC世界里的高级语言语法和Pascal、C有点像能用IF、CASE、FOR这些结构把复杂逻辑写得像一份清晰说明书。缺点也明显没有梯形图那种可视化通断新人需要一段时间适应变量、作用域、函数块这些抽象概念。我接触过不少老师傅梯图画得很溜一看ST就头疼原因不是学不会而是没有足够的实践场景去练。AI恰好补上了这个缺口——它能在你描述需求之后立刻给出一份结构完整的ST代码相当于凭空多了一个随时待命的“编程搭子”。1.2 agent和普通AI问答的关键差别早期用AI写程序最多的操作就是复制粘贴在对话框里说“帮我写一个PID功能块”拿到代码往PLC软件里一贴编译报错再复制回来让它改再贴回去。来回三五次人都麻了。后来我意识到这里缺的不是AI写代码的能力而是把“写完—编译—报错—修改”这个循环自动化的能力这正是agent的思路。agent和普通AI问答的最大区别是它不是一个只会回答的单点工具而是一个能拆解目标、调用工具、观察结果并修正行为的执行系统。打个比方普通AI像打字很快的文员你让它写一段话它写完交差agent像一个会看反馈改稿的编辑它写完之后会拿着编译器的报错信息回来判断错在哪自己改掉再提交。你要做的只是把最终结果再审一遍。我建议的思路是用大模型做推理核心用脚本或工具把“提示词生成、ST代码落盘、调用编译器或语法检查、收集报错内容、回传给模型”串起来。这个闭环跑通之后整个流程就变成你下需求agent自动完成多轮迭代最后交给你一份已经通过语法检查的ST文件。项目忙的时候这种方法能把“写代码—改bug”的时间压缩到原来的三分之一左右。如果不想搭完整工具链手动按照这个闭环来操作也同样有效只是人肉多跑几趟而已。1.3 哪些场景用AI写ST收益最大我最推荐AI写ST的场景有这么几类第一算法密集型逻辑比如PID变体、模糊控制、数据滤波、坐标变换AI对标准算法的掌握比大多数人牢靠第二批量重复代码比如十几个结构相同的模拟量处理块让AI照着模板批量生成再用查找替换微调第三跨平台移植把一个老项目的梯形图逻辑描述成文字让AI改写成CODESYS或博途SCL工作量能省一大截第四配方和数组数据处理这种代码全是循环和索引手写容易漏边界条件。但有个反向场景我劝你别用AI——简单的启保停电路、点动控制、按钮互锁这类逻辑梯形图二十秒就能画完用AI反而要把需求反复描述清楚最后还要检查纯属浪费时间。AI适合的是“写起来费劲、查起来费时”的中大型代码不是所有PLC程序。确定场景之后第二步不是直接打开聊天窗口而是把ST语言基本功和AI的能力边界先摸清楚否则AI给的东西你连怎么审查都不知道。2. ST语言基本功与AI助手的边界2.1 想用好AI先把ST这些语法扎牢你要让AI帮你写ST自己至少得能看懂ST。不需要达到手写大师水平但核心语法必须过一遍。ST里最常见的就是赋值表达式、IF/CASE分支、FOR/WHILE循环还有功能块FB和函数FUNCTION的区别。比如一个电机启保停逻辑用ST一句话就能写清楚bRun : (bRun OR bStart) AND NOT bStop AND NOT bFault;这句代码的意思是只要没有停止信号、没有故障只要启动信号为真或者当前已经在运行输出就保持为真。梯形图要用三个网络表达的逻辑ST一行搞定。稍微复杂一点用一个FB函数块可以描述整个设备的状态我常强调新人必须理解一件事FB声明后要先实例化才能调用就像图纸设计完要在现场“安装一台”才能运转。AI常见的工作方式是生成一个带VAR_INPUT、VAR_OUTPUT、VAR内部变量的FUNCTION_BLOCK。如果你不理解这些声明的作用就不清楚为什么程序里能直接用bStart也不知道bSensorA这些变量的值从哪来。审查AI代码的第一步就是对照接口声明看有没有漏变量、有没有类型不匹配。时间字面量也值得注意T#5S在ST里表示5秒AI偶尔会写成TIME#5S或直接写5不同平台兼容性不一样。2.2 AI能写什么不能写什么我把AI在ST编程上的能力边界划得很清楚。能写的部分包括标准算法、数据处理与转换、状态机框架、批量模板生成、注释和文档、代码风格统一、现有代码的解释与重构。这些都是“信息完整、规则明确”的活模型从训练数据中学过大量相似代码生成质量通常不差。不能做的部分更关键AI不知道你现场传感器怎么接的不知道设备有没有机械互锁不知道某个品牌的PLC在处理浮点数时是不是需要特殊设置更不知道你的安全急停回路有没有硬接线。它给出的Modbus寄存器地址可能是别的型号的它写的数组边界可能跟你PLC的寻址方式不一致甚至会把供应商库函数的名字写错。这些都只能由有工程经验的人兜底。所以我对AI生成代码的态度就六个字可用但必须审。AI是快马不是导航。你要驾驭它就得自己先知道路往哪走。2.3 搭建一个称手的PLC agent工作台想真正把“PLC agent”落地需要一个最小的工作环境。硬件方面一个支持ST的PLC开发环境就行最常见的是CODESYS、西门子博途的SCL、汇川InProShop、信捷XD系列等没有实体PLC就装仿真器CODESYS自带软PLC仿真博途也有PLCSIM。模型方面不要迷信最贵的模型选一个能处理长文本、输出代码稳定的大模型即可再准备一个能保存ST文件的工作目录。搭agent闭环时我实测下来最省事的流程是先写一个需求模板每次把控制描述填进去生成提示词然后让模型输出完整ST代码到文本文件接着用PLC软件的库或者自己写的小脚本检查语法和变量声明把检查结果反馈给模型修改。这个过程里最重要的是“可重复”——同一个需求换参数生成逻辑骨架不变这样审查压力会小很多。这里还经常遇到一个入门问题PLC软件连不上控制器。以CODESYS为例默认网关端口一般是11740如果现场改过端口就得在Device设置里改成一致多台PLC在同一个网段时建议先通过MAC地址确认到底连的是哪一台别对着A设备下载了B设备的程序。博途连接不上时多数是PG/PC接口和网卡选错模拟屏不显示数据也先查驱动版本和PN/DP地址。这些环境和通信问题虽然和AI无关但往往是卡住整个流程的绊脚石。3. 实操从需求到ST程序的完整流程3.1 需求拆解先写一份“控制说明书”真正开始让AI写程序之前我会花十几分钟把需求写成一张表。这一步看起来繁琐但它决定了AI生成代码的上限。你给AI的接口越清楚它写的代码就越接近能用。一张标准的控制需求表包括四个部分控制对象和工艺流程、输入信号、输出信号、逻辑约束。以我最近调的一个三工位气缸顺序控制为例项目内容控制对象A、B、C三个气缸按A→B→C顺序动作输入信号启动按钮、复位按钮、急停、A/B/C三个到位传感器输出信号A/B/C三个电磁阀线圈、报警灯逻辑约束上一步到位后才能执行下一步任一步超时5秒报警停机急停时所有输出为FALSE操作模式手动点动、自动循环这张表一出来控制任务就被翻译成了计算机能理解的语言。写程序的人或AI不需要去现场看设备也清楚知道有哪些变量、有什么约束。这也正是AI最喜欢的输入方式——信息完整、边界明确、规则简洁。3.2 提示词模板把控制逻辑翻译给AI有了需求表接下来就是写提示词。很多初学者直接把“写个三工位气缸程序”丢给AI得到的代码多半没法直接用因为AI不知道用什么平台、什么变量名、什么逻辑约束。我的提示词模板一般长这样你是一名精通IEC 61131-3结构化文本的PLC工程师。 请用ST语言编写一个功能块用于三工位气缸顺序控制。 平台CODESYS 3.5程序组织单元FUNCTION_BLOCK。 接口定义 输入bManual、bAuto、bReset、bStart、bEmergencyStop 以及三个到位传感器bSensorA、bSensorB、bSensorC。 输出三个电磁阀bValveA、bValveB、bValveC报警bAlarm。 逻辑要求 1. 自动模式下按 A→B→C 顺序动作前一步到位后才能执行下一步。 2. 手动模式下每个输出可独立控制外部按钮点动。 3. 任一步动作超过5秒未到位置位bAlarm并停止后续动作。 4. 急停有效时所有输出为FALSE。 5. 使用CASE语句描述状态机代码注释完整。 请直接输出完整ST代码并在代码上方列出关键变量说明。这模板里有几个关键词角色设定PLC工程师、平台版本CODESYS 3.5、程序组织单元FUNCTION_BLOCK、接口定义、逻辑要求、输出格式。每一条都是在降低AI生成“废话”或“不确定代码”的概率。实测下来包含平台版本这一点特别重要因为ST在不同IDE里的语法有细微差异明确告诉它之后函数块调用、时间字面量这些地方出错的概率会小很多。3.3 代码生成与人工审查要点模型给出代码后我第一遍不会看实现细节而是先扫结构。拿上面气缸程序来说AI通常会生成类似下面这种骨架FUNCTION_BLOCK FB_CylinderSeq VAR_INPUT bManual : BOOL; bAuto : BOOL; bReset : BOOL; bStart : BOOL; bEmergency : BOOL; bSensorA : BOOL; bSensorB : BOOL; bSensorC : BOOL; END_VAR VAR_OUTPUT bValveA : BOOL; bValveB : BOOL; bValveC : BOOL; bAlarm : BOOL; END_VAR VAR eState : USINT; // 0待机 1A动作 2B动作 3C动作 fbTimer : TON; // 超时定时器实例 END_VAR这时候我重点检查三件事一是所有IO信号是否都声明了有没有多出来或漏掉的二是内部变量是否够用尤其是定时器这类FB有没有实例化三是平台兼容性比如USINT在CODESYS里没问题但换到某些国产PLC环境可能要改成BYTE。再看逻辑实现部分AI生成的CASE状态机一般不会出大问题但超时检测经常写错位置。正确做法是让定时器在非待机状态一直计时每次状态切换时重置如果AI把定时器只放在一个状态里就会导致其他状态超时失效。这种问题不是AI语法错误而是控制逻辑层面的错必须有经验的人来把关。审查通过之后才算进入导入阶段。3.4 导入PLC与仿真调试步骤导入这一步不同软件的路径不一样但思路一致。以CODESYS为例在工程树里右键应用选择添加对象新建一个POU类型选FUNCTION_BLOCK把AI生成的代码粘进去。然后在主程序PLC_PRG里声明一个该FB的实例比如VAR fbCylinder : FB_CylinderSeq; END_VAR在循环中调用fbCylinder(bManual : ..., bAuto : ..., ...);之后把FB的输入输出变量关联到真实IO或者先不关联用仿真模式测试。CODESYS的仿真器可以在不连PLC的情况下直接运行手动给变量强制赋值就能观察状态机的跳转。我调试三工位气缸时就是逐个置位传感器确认每个阀门按预期打开关闭再测试超时报警。这一步做完才敢说这段AI生成的ST“被我验证过”。3.5 完整案例三工位气缸顺序控制上面整个流程串起来就是一个完整案例。从需求表到提示词再到AI生成FB_CylinderSeq、人工审查、仿真验证前后大约一个小时。我统计过同样逻辑用梯形图写先画IO分配再铺网络至少半天而且后续复用性差。换成ST的FB之后下一次做一个四工位版本只要把状态枚举增加一个提示词里改个数AI几秒钟就能生成新版本。当然从生成到能用之间还有一道不可省略的工序就是编译和仿真时的报错处理。这也是我把agent闭环加进来的原因——让AI自己看报错自己改比人工来回复制粘贴高效太多。报错信息通常已经指明了行号和原因模型基于这些反馈再生成修复后的代码迭代三轮以内基本就能通过语法检查。4. 常见问题与排查技巧实录4.1 AI生成ST代码最常见的五种坑我在这两个月里让AI生成了一百多段ST代码踩过的坑基本可以归纳成五类。第一变量声明不一致。AI会在声明区写bSensorA在逻辑代码里写成bSensorA_1或者大小写对不上编译直接报“变量未定义”。原因多是模型在长文本输出时记忆漂移。审查函数块时先做一次变量名对比或者用IDE的自动声明功能补全。第二定时器和函数块没有实例化。新手最容易遇到的就是直接写TON(IN : ..., PT : ...)但TON必须先在VAR区声明实例才能用。正确写法是先VAR fbTimer : TON; END_VAR再调用fbTimer(IN : ..., PT : ...)。第三数组边界和索引差异。AI习惯C语言风格的0起始下标但不少PLC的数组定义和访问习惯有差异有些环境还允许从任意下标开始。这类问题编译阶段不一定报错运行起来才越界危害更大。第四平台特有语法串味。CODESYS的ST和博途SCL大体相同但细节不同比如数组初始化、地址表示、时间字面量。AI如果没被告知平台会默认用最通用的写法结果在自己的IDE里编译不过。所以提示词里写清平台版本比事后改代码更省事。第五安全逻辑位置错误。AI会把急停、复位放在程序最后或者让普通逻辑覆盖它。审查时必须要求安全类信号在最前面、优先级最高后续所有分支都不能绕过。这条没有任何商量余地。4.2 现场通信、固件与版本兼容问题搞PLC的老手都清楚很多时候程序本身没问题卡住的却是通信和版本。连接不上PLC时先查三件事IP地址和网段通不通、端口号对不对、目标设备是不是你想象中那一台。多台PLC通过网口组网时我习惯先把每台设备的MAC地址记录下来查询时用MAC和IP双重确认避免下错程序。CODESYS默认端口是11740有些现场会改成别的值改完之后两端必须一致InProShop和信捷软件也有各自的端口设置在设备连接配置里核对即可。固件升级也是现场高频故障点。我遇到过工具软件升级PLC固件时提示“拉取固件包列表网络请求失败”折腾半天发现不是设备问题而是本机网络访问不了软件服务器。解决办法很简单去官网下载对应版本的固件包用离线方式更新绕开在线拉取。还有模拟屏不显示数据多数不是AI生成程序的问题而是驱动版本、通信参数和PLC侧不一致逐一核对就能定位。4.3 安全冗余AI写的程序能不能直接上产线这个问题我被问过很多次。我的回答很直接AI生成的ST程序永远不能直接承担安全功能。急停回路、安全门、光幕这类硬安全必须用硬接线继电器回路实现不能指望控制器里的程序逻辑更不能指望AI生成的代码。AI程序跑在PLC里只负责常规动作控制而安全回路要在它“大脑断电”的情况下也能把设备停下来。验收流程上我给自己定的规矩有三条第一所有AI生成的代码必须经过人工逐段审查签字确认第二先仿真后空载再带载每一步都要有测试记录第三关键联锁和超时报警逻辑单独用测试用例验证不能只看一遍代码就觉得没问题。严格遵守这三条AI生成的代码才能作为日常控制逻辑使用。4.4 问题排查速查表故障现象可能原因处理办法编译报错变量未声明变量名大小写不一致或声明缺失对比声明区和代码区变量补全声明编译报错FB未调用定时器等功能块未实例化在VAR区先声明实例再调用下载后无动作IO映射未关联或端口不对检查设备连接配置确认IP和端口状态机跳不过去传感器信号没到位或地址错用强制变量逐个模拟到位信号超时误报警定时器重置位置不对确认每次状态切换时重置定时器模拟屏不显示数值通信驱动和PLC地址不匹配核对驱动版本、从站地址和协议配置固件升级失败本机无法访问软件服务器官网下载固件包离线升级最后说点我自己的体会。用AI写ST程序这件事真正值钱的不是生成代码那一刻而是你逼着自己把设备逻辑讲清楚的过程。以前我遇到复杂工况脑子里常常是模糊的“大概这么动”现在为了写提示词必须把IO表、时序、异常处理都列明白AI反而成了我整理思路的镜子。对熟手来说这套PLC agent玩法是实打实的效率加速器对刚接触ST的新人来说它又像一个不知疲倦的老师——但记住老师可以帮你检查作业能不能毕业还得看你自己有没有把安全和逻辑的底线守住。