咱们搞工控的都见过这个画面同一批进厂的工程师干到第三年差距开始变得很明显。有人还在翻手册找指令有人已经一个人顶着一条新产线的调试。技术基础差不多差在哪差在对新工具的使用习惯上。我下面要聊的是这两年我自己感触最深的一件事——AI 正在重塑 PLC 工程师的工作方式而且速度比想象中快得多。很多人说 AI 写不了 PLC 程序因为它不懂现场。这话我只认一半。AI 确实不知道你那个液压站的加压时序是什么但它懂 IEC 61131-3 的语法懂西门子、三菱、汇川的资料库懂别人踩坑后写在技术文档里的经验。它缺的恰恰是你手里的那根网线和万用表。你把自己掌握的 I/O 表、控制要求、品牌型号喂给它同时你能判断它生成的逻辑安不安全、能不能用那你就能吃到这波红利。这篇内容不聊虚的就讲讲我怎么把 AI 并进 PLC 工作流的顺便把调试现场踩过的几个坑摆出来。1. 行业变局AI 正在重塑 PLC 工程师的工作链路1.1 传统 PLC 工程师每天被什么拖住先说几个最耗时间的活儿。第一是程序架构设计。新设备、新产线的程序从拿到 I/O 表到出第一版可调试的框架老手也要一两周。这一两周里大量的时间其实不在“写逻辑”而在“定方案”程序分几个块、状态机怎么切、报警怎么归组、手动自动怎么互锁。第二是调试排错。现场出个诡异问题报警信息只给一个代码剩下的全靠经验猜。经验的本质是啥是你以前见过类似的坑记得住。但记录在你自己脑子里别人帮不上你。第三是跨品牌学习成本。西门子一个玩法三菱一个玩法汇川 AM 系列又一套欧姆龙还有自己的小脾气。每换一个品牌都要重新适应指令和软件这个成本在很多中小项目里根本没预算。第四是文档工作。I/O 表、功能说明、操作手册、竣工资料项目越大越要命。我见过不少工程师程序写得利索一听到“写文档”就头大最后拖到验收前通宵补。这四件事有一个共同点它们不考验你的逻辑天花板而是考验你的信息检索能力、文本组织能力、模式记忆能力——这些恰好是 AI 最擅长的事情。不是说传统基本功不重要恰恰相反基本功越好的人用 AI 的红利越大。基本功不行的人连 AI 给的代码哪里有问题都看不出来那 AI 之于他就是个加速踩坑的工具。1.2 AI 介入后时间省在哪举个我自己最典型的例子。以前写一个 12 路模拟量采集处理程序——线性换算、超限报警、量程调整、滤波——从查手册到写完大致要半天到一天。现在我把量程、数据类型、报警阈值写进提示词让 AI 先生成功能块的框架代码我再把现场工艺细节填进去整体从写代码变成了审代码一两个小时就进入联调。审代码比写代码轻松因为 AI 已经把 80% 的语法和数据结构搭好了我只需要盯逻辑和安全部分。注意我用的词是“审”而不是“抄”。AI 生成代码的本质是基于大模型训练时读过的海量公开程序库、标准化教程、技术问答按概率生成一段看着合理的代码。它相当于一个读过一万个 PLC 项目的实习生但这位实习生不认设备、不看现场。所以 AI 能生成的是“通用控制逻辑”不能替你做主的是“具体设备工艺”。真正值钱的还是你脑子里的那套现场判断力。AI 拉开的差距是把“重复劳动”压缩掉之后剩下来的纯粹能力差距。这也是我这篇文章最想讲明白的一件事AI 不会让 PLC 工程师失业但会让只会照着老套路干活的工程师越来越难混。2. AI 辅助 PLC 编程的落地路径2.1 让 AI 生成一段红绿灯时序程序说再多不如上手看一段实例。有一次朋友问我十字路口红绿灯的时序控制怎么写我就直接用这个需求当测试用例来试 AI 的能力边界。我的提示词很简单直接把需求、I/O、品牌、语言类型都写清楚你是资深 PLC 工程师精通西门子 S7-1500 与 IEC 61131-3 结构化文本 ST。 请生成一个红绿灯四相位控制程序 1. 启动按钮接 DI0.0停止按钮接 DI0.1 2. 输出分配东西红 Q0.0、东西黄 Q0.1、东西绿 Q0.2南北红 Q0.3、南北黄 Q0.4、南北绿 Q0.5 3. 时序要求启动后东西绿 20 秒、东西黄 3 秒、东西红 25 秒南北绿 25 秒、南北黄 3 秒、南北红 20 秒 4. 停止按钮按下后完成当前周期停在东西红灯、南北红灯状态 5. 使用 TON 定时器不要用累加器代码要能直接粘进博途AI 给我返回了一段典型的状态机代码结构是 CASE state OF 0: 东西绿灯定时等。整体框架是能用的但我改了三个地方一是定时器的实例名AI 把几个 TON 的实例命名得比较随意在博途里更容易和已有功能块冲突二是停止逻辑AI 默认了“立即停止”的写法我改成了“完成本周期再停”的工艺要求三是初始状态AI 倾向于默认全红而实际应用通常要求启动瞬间给一个确定的方向通行权得手动加一个首周期优先置位。这段代码从生成到可以下到仿真里跑总共大概 40 分钟其中 AI 生成只占两分钟剩下的时间全是我在按现场要求做修正。这个例子说明一个关键点AI 怎么写是次要的你怎么“喂需求”是主要的。你给的信息越结构化AI 输出的代码越接近工程可用状态。很多工程师第一次用 AI 说“效果不行”其实是因为它只喂了一句“写个红绿灯程序”信息颗粒度太粗出来的东西当然没法用。你把它当成一个水平不错但不懂项目背景的同事像交代新同事一样把 I/O 表、时序表、安全要求整理清楚它的产出立刻就不一样。2.2 从需求到功能块框架的五步工作流我跑过不少项目之后总结出五步流程现在基本是个人标准作业模式。第一步整理 I/O 表。AI 不知道你的设备有哪些传感器、哪些执行器但你知道。先把点位编号、数据类型、信号范围、别名整理成一段清单。这一步也是 PLC 编程的老规矩只是以前是为了自己画图方便现在是为了喂给 AI。第二步把控制要求拆成三块“必须做什么”“禁止做什么”“异常时怎么办”。比如“必须做的是开机后先自检”“禁止做的是自动状态下手动启动”“异常是超时 5 秒报警并停机”。这比一句“控制设备启停”有效十倍。第三步让 AI 先出程序架构而不是直接写代码。我会让 AI 列功能块清单、程序组织单元划分、接口命名草案。比如电机控制块、阀门控制块、报警块然后告诉它每个块的输入输出参数。这个“先架构后代码”的好处是AI 不会在一个文件里给你塞一个大杂烩而是按工程习惯拆开后续维护和查错都方便。第四步对每个功能块生成接口和骨架代码。我在提示词里要求“只生成变量定义和数据流说明逻辑主体留 TODO”这样我可以看清楚结构再填充细节。第五步手动填充核心现场工艺逻辑。这一步谁也不能替你因为涉及设备安全、工艺参数、操作习惯。AI 生成的代码里如果有互锁、安全回路、急停相关的内容我基本都要自己重新过一遍哪怕它写的和你想要的一样也要确认一遍这习惯能救命。2.3 注释、文档、排错三个被低估的 AI 用法代码生成只是 AI 在 PLC 工程里最表层的能力。日常使用中比代码生成更省时间的其实是另外三个场景。第一个是给老程序写解释。项目交接时拿到的旧代码没有注释梯形图又臭又长以前是找老员工带个三天五天才勉强懂结构。现在我会把程序导出成文本挑几个关键段贴给 AI让它用自然语言描述每个区的功能很快就能建立起一个全局印象。第二个是生成项目文档。我会把 I/O 表、PLC 品牌型号、报警清单扔给 AI让它按固定模板生成操作说明、故障处理手册初稿我再改一遍措辞就行。以前写一版竣工文档要三四个小时现在半小时搞定改的时间还是主要花在核对准确度上。第三个是排查方向。现场出现“气缸伸出延时超时”这种报警时我会把报警文字、设备品牌、动作现象拼成一条 prompt让 AI 列出可能的原因磁性开关位置偏移、气缸漏气、限位接线松动、超时时间设置过短、气源压力不足。AI 不一定说全但它能提供一套框架让我按顺序去排除。这三个用法有个共同逻辑AI 的最大价值不是替你决定而是把你从“从零开始”变成“从 80% 开始”。以前接老项目是从零开始现在只需要审和改以前写文档从零开始现在只需要核对以前排错从零开始现在有了一张可以按顺序排除的清单。这种工作方式的变化三个月积累下来差距就很明显了。3. 打通数据链路让 AI 看见设备实时状态3.1 从 PLC 到 AIOPC UA 与 Modbus 怎么选AI 要发挥作用前提是能看见设备的运行数据。空有程序、没有实时数据AI 就是个写代码工具有了数据它才能做分析、做预测、做诊断。这也是为什么每次有人问我“AI 怎么用在 PLC 上”我会先问一句你的数据通到哪了数据链路的主流做法是分级架构PLC → 采集服务OPC UA / Modbus 等 → 时序数据库 → AI 分析层。不要想着让大模型直接连 PLC那不现实也不安全。PLC 侧只承担数据提供方的角色下游怎么消费数据是它的事。这样才能把“控制”和“分析”解耦。OPC UA 和 Modbus 的选择取决于项目规模和设备品牌。如果是西门子 S7-1500、汇川 AM 系列这类中大型 PLC优先 OPC UA它自带加密认证、跨平台、带语义模型AI Agent 要读变量名也很方便。OPC UA 的地址模型比 Modbus 的寄存器号直观得多比如能直接读到“ns2;sDevice1.Temperature”这种带语义的节点。Modbus TCP 则适合小型系统和第三方设备一个从站地址加寄存器偏移表就能读几乎没有门槛但安全性和语义化程度都弱一些。实际项目经常是两者并存核心 PLC 走 OPC UA第三方仪表走 Modbus由采集层统一汇总。3.2 设备异常检测从阈值报警到提前预判数据打通之后AI 能做的第一件事就是异常检测。传统的 PLC 报警逻辑是阈值判断温度大于 80 度就报警。问题在于很多故障不是突然发生的而是有几十秒甚至几分钟的“前兆”但还没有突破阈值。比如轴承磨损会导致电机电流轻微波动这种波动用固定阈值抓不到只有用模型看趋势才能发现。我自己用过的最容易上手的方案是孤立森林Isolation Forest。思路很简单把历史正常数据作为训练集模型学会“正常长什么样”新数据进来后离群分越高越可疑。我用 Python 的 scikit-learn 跑过一台电机的电流数据模型很快标记出了几个“微小波动点”后来查出来是轴承初期的润滑不良。这种精度靠 PLC 里的模拟量比较是做不出来的。写一段示意代码思路可以借鉴import pandas as pd from sklearn.ensemble import IsolationForest # 假设 df 包含电流、温度、振动三个特征 data df[[current, temp, vibration]] model IsolationForest(contamination0.05, random_state42) df[anomaly_score] model.fit_predict(data) # 异常点的输出为 -1后续可以发给 SCADA 或者 AI Agent 做处理在这个方案里PLC 负责把数据送出来Python 负责建模AI 负责把异常结果翻译成人话“3 号电机电流波动偏高建议检查轴承润滑”。PLC 工程师不需要成为算法专家但要理解能用统计方法解决传统逻辑解决不了的问题这本身就是一种 AI 化转型。3.3 AI Agent 能替工程师做哪些事AI Agent 这个词最近很热我自己的理解是Agent 是能自己调工具、按目标走流程的 AI。在工控场景里它最合适的落点不是替我们改程序而是替我们做“读”和“汇总”的工作。比如设备报故障的时候传统流程是工程师到现场看 PLC、翻历史趋势、查手册然后判断问题。现在我可以让 Agent 自动完成第一步信息收集它拉取 PLC 当前状态、读取时序数据库里最近半小时的趋势、检索维修知识库里相同的故障历史生成一个一句话简报“2 号压缩机排气压力异常最近 20 分钟压力缓慢上升和上周 3 号机润滑不良的历史曲线相似建议检查润滑油路”。整个流程只需要我点一个按钮。还可以做巡检日报。以前每天下班前要手动汇总几十台设备的运行时间、报警次数、温度平均值。现在让 Agent 定时跑一遍数据查询把结果整理成表格和自然语言段落我只需要扫一眼确认。这个看似不起眼但长期积累下来每天至少省出三四十分钟用来干真正有价值的事。不过我有一条红线Agent 只读不写不碰输出点、不写线圈、不自动修改程序。现在的 AI Agent 还没到能在工业现场安全闭环的成熟度任何一次自动控制出错都可能造成设备损坏甚至安全事故。保持“人审机”的方式让 AI 做分析、做建议最后确认人都要用手完成。这一步省不得。4. 仿真与现场AI 时代的调试实战4.1 PLCSIM Advanced 启动不了我这样排查先说说西门子 S7-PLCSIM Advanced。这东西是调试西门子 PLC 程序的利器能跑一个虚拟 PLC用来配合 HMI、SCADA、甚至虚拟调试进行联调。可真要用起来第一步就容易卡住——启动不了而且经常不报错。我遇到过的情况有三类整理了个排查顺序建议先按这个顺序过一遍现象常见原因处理方式点启动后实例状态不动没任何报错虚拟网卡未启用或驱动异常打开设备管理器找到 Siemens PLCSIM Virtual Ethernet Adapter启用并更新驱动报 Error 11虚拟接口初始化失败优先重装虚拟网卡驱动检查许可证服务是否运行软件必须以管理员身份启动实例启动成功但 TIA 连不上防火墙拦截虚拟网卡通信在 Windows 防火墙中为 PLCSIM 相关程序添加入站放行规则加载项目文件失败实例的 CPU 签名与实际不匹配创建实例时选择与实际项目一致的 CPU 类型和签名Firmware补充几个细节。第一PLCSIM Advanced 的版本与 TIA Portal 版本必须匹配安装之前先查兼容性矩阵否则会出现各种诡异问题。第二虚拟网卡设置为“专用网络”有些 Windows 版本默认给虚拟适配器标成“公用网络”会被防火墙策略搞得很惨。第三如果你用的是一台没有真实网卡的环境比如某些公司的内网隔离电脑要先装一个虚拟网卡驱动这也是项目上常见的坑。这条排查表来自我自己的真实经历。最早我在一台工程笔记本上装了 PLCSIM Advanced V5.0不管怎么点实例就是不动任务管理器里看进程也没有报错。折腾了半小时最后发现是 Windows 更新把虚拟网卡驱动的签名搞失效了重新安装网卡驱动后一切恢复正常。类似问题在论坛上问很难问到答案因为这东西太吃本机环境了。4.2 汇川 PLC Codesys为什么更适合接 AI现在做非标项目越来越多同行会用汇川的中大型 PLC尤其是 AM 系列。这套硬件用的是 Codesys 编程环境支持 IEC 61131-3 标准有一个很实际的好处AI 大规模训练过的 ST 语言是国际标准语法Codesys 也是按标准来的AI 生成的代码粘贴进去的语法匹配度比在专有梯形图软件里高得多。我实测的感受是在 Codesys 里让 AI 写功能块生成的代码基本能满足 80%剩下的主要是变量类型和厂家特定功能块的对接。而且 Codesys 自带仿真器不用额外硬件AI 生成 ST 代码后可以直接在本地仿真里验证逻辑。配合它的 OPC UA 服务器组件把变量暴露给 AI Agent 也非常顺手整个“AI 生成 → 仿真验证 → 数据读取 → AI 分析”的链路特别通顺。这里也想劝一句还在只用梯形图的同行梯形图在经典逻辑场景里依然高效但 AI 对梯形图的支持能力远不如 ST这不是大模型不行是梯形图的表达形式和文本语义差太多。长期看懂 ST 的工程师更容易吃上 AI 红利。LC 语言本身是标准文本AI 可以做到语法正确编程效率也有本质提升。4.3 冷库监控项目里的 AI 辅助实例之前帮人分析过一个冷库监控系统的设计思路属于典型的 PLC 中小项目很适合展示 AI 在整条链路里的作用。需求不算复杂冷库分三个温度区每个区有独立的压缩机、化霜加热器、温度传感器和门状态开关要求温度维持在设定范围内超温要报警断电后要支持数据保持。第一阶段用 AI 做需求拆解和点位表。我把设备状态列给 AI让 AI 生成 I/O 分配建议和一个报警清单草案省掉了从零开始画表的时间。第二阶段让 AI 生成主程序和功能块框架包括温度采集模块4-20mA 换算成实际温度、压缩机启停控制、化霜周期逻辑。第三阶段PID 控制逻辑和参数初值参考 AI 给的经验值但现场的整定还是靠手动AI 给的范围只能当起点。第四阶段把温度数据通过 OPC UA 送到数据库让 AI 分析“达到设定温度的时间是不是越来越长”。这个指标如果持续升高说明冷库门封条老化或者压缩机效率下降靠阈值报警是发现不了的。这种“长期劣化趋势”的识别是 AI 在传统自控项目里最容易体现价值的地方。我常用的一张项目分工表可以给大家一个参考项目阶段主要工作AI 能代劳的部分需求分析拆需求、定 I/O 分配生成点位表草案、报警清单程序编写主逻辑、功能块实现生成 ST 框架代码、接口定义参数整定PID 等控制参数调试提供经验值范围、生成整定记录模板调试运维现场验证、异常分析分析趋势、自动生成趋势总结文档交付操作手册、维护手册生成初稿人工校对5. 现场高频问题与排查技巧实录5.1 C# 读 PLC 的轮询频率到底设多少有同行问 C# 读 PLC 的频率设多少合适。答案不是“越高越好”而是“够用就行越低越好”。这里先给一组我实际使用的参考值S7-1200/1500 走 S7 协议如果只是一个上位机读数据轮询间隔建议 100 毫秒起步200 毫秒比较稳。低于 50 毫秒就会明显增加 PLC 通信负载尤其是项目里还有 HMI、SCADA 同时在跑的时候。Modbus TCP 轮询建议 200 毫秒以上。Modbus 协议本身的效率和承载能力不如 OPC UA 和 S7 协议频率太高考验 CPU。OPC UA 优先用订阅模式服务器变化推送不用轮询。设置一个合理的数据变化死区如 0.1 度就能既省流量又不丢失关键变化。还有一个工程层面的经验不要做“单点单读”。C# 里常见的写法是每 100 毫秒循环读一个变量实际这会让 PLC 通信负载翻好几倍因为每条 S7 报文都有固定开销。更合理的做法是批量读取把十几个连续地址的 DB 块一次性读出来解析到本地缓存再用事件通知给界面。这种优化往往比调整协议参数更有效。如果你发现读频率一高博途在线监控就开始卡说明通信负载已经超了。解决办法是统一做一个数据采集服务下游要数据都从服务读而不是每个页面直接去连 PLC。这条经验确实重要我在好几个项目里吃过亏才悟到的。5.2 汇川 AM763 识别不了本地 IO 的检查顺序机床厂的朋友问过我AM763 识别不了本地 IO 模块怎么排查。我没见过这个具体配置但 PLC 本地 IO 识别不了这件事排查套路是通用的按顺序来少走弯路。第一硬件组态和实际模块是否一致。GD 模块订货号、版本型号对不上软件是拉不到地址的。先别急着换模块逐项核对一遍订单配置。第二供电。扩展模块多了24V 开关电源的电流余量不足模块上电不稳定会出现“时好时坏时认时不认”的诡异现场。第三单独模块测试。把可疑模块单独接到 CPU 旁边排除背板通信问题。背板接触不良或者防反插卡扣没到位是 IO 模块识别不了的高发原因。第四固件版本。模块固件和 CPU 固件版本差太多会导致识别不出来需要先用软件升级到匹配版本。第五总线配置。终端匹配电阻要不要手动加、最后一个模块的终端开关有没有拨到正确位置在有些产品里是必须的。用表整理出来更清楚排查步骤检查内容常见坑1. 硬件组态订货号、版本与实物一致同型号 CPU 不同固件批次不兼容2. 供电余量背板 24V 功率够不够扩展多块 IO 后电压跌落3. 单模块测试模块单独连接 CPU背板接触不良、防呆卡扣不到位4. 固件升级CPU 与模块固件版本匹配版本差太多时完全不识别5. 总线配置终端电阻、模块拨码收尾模块未拨对开关这类问题的共性是先硬件后软件先供电后组态。很多人栽在一个“软件里怎么刷都刷不出来”最后发现是 24V 电源电压不够或者模块侧端的接线松了。现场排查别上来就重装软件。5.3 老设备资料缺失怎么借 AI 找线索工厂设备用久了最容易遇到的问题就是资料丢了。说个案例有同行发来一条信息问发那科数控机床 PMC 里 R035.1 这个位是什么意思。这个具体我不懂但我清楚这类问题的排查思路第一步把“R035.1、发那科 PMC”直接喂给 AI让它梳理 PMC 变量区的通用分类规则再结合它的知识库给出这一位的常见用途区间。AI 能很快给出一个最大概率的语义方向但注意它这只是“知识库检索”不是权威手册。第二步找到机床里用到 R035.1 的程序段把相关梯形图逻辑转成文字描述贴给 AI让它结合上下文判断用途。第三步也是最关键的在线监控 R035.1 的翻转规律看它和设备的哪个动作有联动关系。AI 给方向程序给证据实操验证给结论三者合起来才能确定答案。这种排查思路比直接问人要好用。因为老设备资料缺失时唯一可靠的信息来源就是设备本身AI 只是帮我们更快地“猜”和“缩小范围”。你要是把它当成权威手册早晚会在现场翻车。记住一个原则AI 的定位永远是辅助决策不能替代验证。结尾我自己的体会是AI 拉开差距的速度真的比想象中快。同一个项目、同一辆车、同一个品牌有人还在翻手册第一页有人已经用 AI 把两周的架构压到了一个上午。但真正的分水岭并不在于会不会用某个 AI 工具而在于你有没有一套清晰的工程方法论敢于把现场需求交给 AI 去变成雏形也敢于判断它给的逻辑是否安全。PLC 工程师的护城河从来不是背指令而是把现场需求翻译成控制逻辑、把异常变成经验、把经验变成方法论。AI 不会取代这套能力它只会放大这套能力——前提是你去用它。建议别急着追求 AI Agent 之类的概念先拿一台仿真 PLC 练手让 AI 帮你写一个功能块再手动改三处逻辑这是最实在的入门方法。