ARTICLE DETAIL

资讯详情

深耕网站视觉设计与运营推广的一线实战洞察。

AI写PLC程序质量实测:从能编译到可上机运行还有多远

AI写PLC程序质量实测:从能编译到可上机运行还有多远 AI 写 PLC 程序的质量怎么样不同品牌的 AI 在 PLC 编程上的支持性到底差多少实际项目里能不能直接用这几个问题我在接触过一两款 AI 编程助手之后也开始反复问自己。初看之下AI 确实能写出像模像样的梯形图注释、指令表和结构化文本但把代码放进博途、GX Works 或者汇川编程软件里往往会出现指令不存在、变量没有声明、通信报文对不上等问题。真正的问题不是“AI 能不能写 PLC 程序”而是“AI 生成的 PLC 程序距离可上机运行、可维护、可安全运行还有多远”。如果你也在用 AI 辅助 PLC 编程建议先不要只凭一两个品牌的对话输出下结论。下面会从测试方法、常见问题、落地工作流几个角度展开帮助你判断不同 AI 在 PLC 领域的表现以及在你自己的项目里该在哪个环节使用它。1. 先理解AI 写 PLC 程序为什么不能等同于写 C 或 Python1.1 PLC 程序运行模型扫描周期和输出刷新普通后台程序是“从上到下执行完一个函数等待事件触发再执行另一段逻辑”。PLC 不一样它运行在一个固定扫描循环里读取输入映像区、执行用户程序、刷新输出映像区然后进入下一个周期。AI 如果不理解这个模型很容易生成“等待某个条件满足后再继续往下走”的代码。这类代码在 C 语言里是合理的在 PLC 里却很可能导致逻辑在一个扫描周期内无法被正确连续执行。下面是一段 IEC 61131-3 风格的 ST 代码示意用于电机启停自锁。实际项目要按目标 PLC 的标签绑定方式调整地址PROGRAM MAIN VAR b_Start AT %I0.0 : BOOL; b_Stop AT %I0.1 : BOOL; b_EStop AT %I0.2 : BOOL; b_Km AT %Q0.0 : BOOL; END_VAR IF b_EStop THEN b_Km : FALSE; ELSIF b_Stop THEN b_Km : FALSE; ELSIF b_Start THEN b_Km : TRUE; END_IF;这段代码的关键点有两个。第一它是循环扫描执行的每个周期都会重新判断b_Start、b_Stop和b_EStop所以只要启动按钮为 ON接触器输出就会一直被置为 TRUE这就是“自锁保持”。第二停止优先和急停优先放在前面启动条件放在后面避免出现“启动和停止同时按下时启动反而优先”的危险逻辑。AI 写出这种代码并不难难的是它在生成时是否清楚该用“先复位后置位”的顺序以及是否知道停止按钮对应常闭触点还是常开触点。这些细节决定程序能不能安全运行。1.2 AI 对 PLC 编程语言和品牌知识的覆盖PLC 的编程语言从文本角度看大体分几类梯形图LD、指令表IL、结构化文本ST、功能块图FBD、顺序功能图SFC。AI 在生成文本类代码时对 ST 和 IL 的把握通常好于梯形图因为文本类代码的训练语料更多生成结果也更容易被编译器接受。但 PLC 不是一套统一生态。西门子博途的 SCL、三菱 GX Works 的结构化文本、汇川 AutoShop 的 ST、倍福 TwinCAT 的 ST基础语法接近细节差异很大。比如西门子 S7-1200/1500 使用%I0.0这种 I/O 地址表示方式三菱 FX 系列则习惯用X0、Y0直接表示软元件。AI 在生成时如果把三菱的M0辅助继电器写到西门子的程序里编译器会直接报错反过来把西门子的DB数据块概念写到三菱程序里也会让初学者一头雾水。更麻烦的是品牌内部也有新旧差异。三菱 FX2N、FX3U 和 FX5U 的指令集并不完全一致老设备不支持部分 ST 专有指令西门子 S7-300、S7-1200、S7-1500 的地址模型和指令支持范围也不同。实际测试对比时不能只说“让 AI 写一个三菱程序”必须明确到型号和软件版本。1.3 三个适合 AI 的场景和两个不适合的场景从实际应用看AI 辅助 PLC 编程有价值但价值集中在参考、解释和转换层面。适合的场景有三个一是生成功能片段比如一个电机控制块、一个气缸顺序流程、一个模拟量处理程序二是解释陌生指令把看不懂的 STL、ST 代码翻译成自然语言三是做跨语言转换比如把一份三菱的梯形图逻辑改写为西门子 SCL。不适合的场景也有两个一是安全相关逻辑包括急停回路、安全门互锁、光栅保护、超程保护这些不能直接交给 AI 生成后上机二是复杂工艺和通信协议比如多轴联动、PID 参数整定、Modbus RTU 报文地址映射AI 在没有手册的情况下很容易猜测寄存器地址和功能码。2. 搭建一套可复现的 AI-PLC 程序评测方案2.1 测试题目怎么设计要对比不同 AI 在 PLC 编程上的支持性不能只靠一两句闲聊式提问。建议准备一组覆盖不同难度的测试题从基础到复杂逐步递进。题目集至少要包含基础逻辑、时间控制、顺序控制、通信、运动控制五类每类题目都要有明确输入、输出和控制要求。下面是一个最小测试题目集参考题目类型示例题目主要考察点基础逻辑电机启停自锁、正反转互锁指令语法、扫描逻辑、互锁安全时间控制星三角启动、延时启动停止定时器使用、复位行为顺序控制双气缸机械手循环动作状态机设计、步进逻辑、限位开关通信三菱 FX 与变频器 Modbus RTU 读写频率通信指令、寄存器地址、报文格式运动控制伺服电机正弦运动运动指令、轴参数、曲线生成每个题目都要先由人写出“预期行为”再让 AI 生成。比如电机启停预期行为是按下启动按钮后接触器吸合并保持按下停止按钮后接触器断开按下急停按钮后无条件断开。预期行为写得越清楚AI 生成的代码越容易评分。2.2 评分维度我建议用六维评分每个维度 1 到 5 分。总分不是唯一指标分维度的得分更能看出一个 AI 的具体短板。维度评分标准分数1-5正确性是否满足控制要求边界条件是否处理可编译性在目标 PLC 软件中能否编译通过指令准确性指令名称、功能块、地址是否符合目标 PLC逻辑完备性是否处理停止、复位、报警、边沿检测可读性变量命名、注释、结构层次是否清晰安全意识是否包含急停、互锁、手动自动切换保护评分时要注意一个问题AI 生成的代码“看起来能编译”和“真的能编译”是两回事。有些模型会生成一个虚构的功能块名称看起来像官方库实际在软件里根本不存在。这种情况指令准确性一栏应直接打低分。2.3 输入方式和记录表格同一个 AI 在不同输入方式下表现可能不一样。网页对话、IDE 插件、API 接入三种方式提示词解析能力和上下文能力有差异。IDE 插件补全的代码通常比较短适合现场写代码时辅助网页对话适合处理完整功能描述API 接入适合企业批量测试。建议固定一套提示词模板对每个 AI 跑相同题目。同一道题不要只生成一次至少生成三次取中位数或记录最好和最差结果。因为大模型生成具有随机性单次通过不能说明真实能力单次失败也不能说明完全不行。记录表格可以这样设计题目编号、题目名称、AI 品牌、生成用时、能否编译、错误类型、修正后能否运行、实际逻辑是否符合预期。保存这些记录后过几个月再复测能明显看到模型更新带来的变化。3. 用四类典型题目实测能看到大部分真实差距3.1 电机启停自锁基础语法和互锁这是最基础、也最能暴露问题的题目。如果 AI 连启停自锁都写不对后面复杂逻辑基本不用看。提示词建议这样写你是一个熟悉三菱 FX3U PLC 的工程师。请用 GX Works 3 的结构化文本生成一个电机启停程序。要求有启动按钮、停止按钮、急停按钮和一个接触器输出。要求启动保持、停止优先、急停优先并添加完整注释。不同 AI 的差异会在两个地方体现。一是地址写法X0、Y0在三菱软件里是合法软元件但换到博途 SCL 环境就不合法。二是停止逻辑很多人会写出先启动后停止的顺序这样当启动和停止同时按住时启动仍然优先不符合安全习惯。正确做法是把停止和急停放在前面启动放在最后分支。3.2 双气缸机械手顺序控制状态机是关键顺序控制是所有 PLC 项目里最常见的场景也是 AI 最容易“能生成但不可用”的题目。一个典型需求双气缸机械手按下启动后 A 缸前进到位后 B 缸前进B 缸到位后保持 2 秒然后 B 缸后退B 缸退到位后 A 缸后退A 缸退到位后回到初始状态等待下一次启动。每个气缸都有前限位和后限位。用 ST 写顺序控制核心是一个状态枚举变量加一个 CASE 分支。下面只是一个结构示意落地时需要绑定具体 PLC 的标签和地址TYPE T_Step : ( IDLE, A_FORWARD, A_WAIT, B_FORWARD, B_WAIT, B_BACK, A_BACK ); END_TYPE然后在主程序里根据当前状态决定输出并根据条件切换状态。AI 写这类代码经常出现的问题有三个一是状态少写或多余比如没有回到 IDLE 的路径二是转移条件缺失没有等待限位开关三是输出重复赋值同一个气缸电磁阀在多个 CASE 分支里被赋值导致最后一步覆盖前面的结果。3.3 三菱 FX 与变频器 RS485 通信协议细节最考验 AI通信题是判断 AI 能力的重要分水岭。原因很简单通信程序不仅涉及 PLC 指令还涉及变频器寄存器地址、功能码、波特率、站号、 CRC 校验等大量外部知识。比如要求“用三菱 FX2N 连接 PLC与某款变频器通过 Modbus RTU 通信写运行频率并读取当前频率”。AI 可能给出ADPRW指令这是三菱内置定位指令通信设置容易混淆。也可能把变频器频率寄存器的地址写错比如把 0x2001 写成 0x0001导致 PLC 通信正常但变频器不响应。Modbus RTU 是字节流的协议AI 不容易通过自然语言准确记住所有型号的地址表。对此最稳妥的方法是给 AI 提供变频器手册中的寄存器地址表然后让它生成 PLC 发送的数据帧。下面只展示数据帧结构思路写运行频率请求帧 从站地址 01 功能码 06 寄存器地址 20 01 写入数据 0B B8 CRC 校验 低字节在前这里0B B8对应十进制 3000具体是否代表 30.00 Hz取决于变频器手册定义的频率倍率。AI 不读手册时很容易把倍率、符号位、地址偏移量搞错。所以通信类代码必须要求 AI 先列出它使用的寄存器地址和倍率再由人核对。3.4 伺服正弦运动运动控制和轴参数运动控制题目适合考察 AI 对高级功能块的掌握程度。不同 PLC 品牌通常提供不同的运动控制库比如 CODESYS 生态中的MC_MoveAbsolute、MC_MoveVelocity汇川的PlcMove等。AI 生成代码时很可能只给出一个常见的运动控制函数块却不解释轴参数和周期配置。正弦运动是一个比较实用的测试题。假设需要让轴按照正弦曲线运行可以计算一个周期内的目标位置// 假设每个扫描周期计算一次目标位置 // 频率 0.5 Hz幅值 100 mm中心位置 200 mm rPosition : 200.0 100.0 * SIN(2.0 * 3.14159265 * 0.5 * rTime);代码本身很简单难点在于 PLC 如何获得当前时间、用什么周期执行这段逻辑、位置指令如何下发、反馈位置是否参与闭环。如果 AI 只是生成一个公式而不说明执行周期这段代码不能直接用在真实运动控制中。4. 不同 AI 品牌在 PLC 支持性上的差异从哪来4.1 先给结论不要轻信口头对比目前没有统一的公开评测机构给“AI 写 PLC 程序”打分。不同博主、不同社区做的测试题目集、提示词、评分标准都不一样结果不具备直接可比性。你只试过一两个 AI得出的印象可能只是它们在你当前项目上的表现而不是全貌。正确做法是使用上一节提到的测试题目集自己动手跑一遍并记录结果。测试产生的结论才对你的项目有参考价值。4.2 差异来源训练语料、语言壁垒、工控资料覆盖AI 在某个领域表现好不好很大程度上取决于训练语料里有多少该领域的高质量内容。PLC 和工控的开发资料不像通用编程语言那样互联网化大量内容以 PDF 手册、付费课程、企业内部文档形式存在能被公开训练语料覆盖的比例有限。中文工控资料中三菱和西门子的资料相对丰富因此中文大模型对这两个品牌的基础指令理解通常较好。汇川、台达、信捷等国产 PLC 资料少一些AI 生成时更容易出现“看起来有模有样、实际上指令瞎写”的情况。CODESYS、倍福等基于 IEC 61131-3 的国际品牌英文资料相对多对擅长英文编程语料的模型更友好。4.3 支持性概览表下面的表格只是类别层面的观察不能代表某个具体版本。大模型更新很快每个月都可能有变化。模型/助手类别常见优势常见问题通用国外闭源模型对 IEC 61131-3 ST、CODESYS 生态较熟悉对三菱 FX 老指令、国产 PLC 资料覆盖可能不足通用国内大模型中文工控手册理解好三菱/西门子案例处理较自然对较新功能块和复杂通信协议容易编造代码生成专用助手代码补全效率高结构化文本生成较稳定可能只关注语法忽略 PLC 扫描模型和安全互锁私有化/开源模型数据可审计适合企业微调和内部部署基础能力依赖微调数据需要自行准备工控语料概览表的作用是帮你建立预期没有一个 AI 是万能的。适合自己的方式是把常用品牌、常用型号的测试结果沉淀成一份内部对照表。4.4 如何自行获得“支持性”答案获得答案的唯一可靠路径就是复测。每次大模型版本更新后用同一套提示词重新跑这些测试题记录变化。做了两三轮之后你会很清楚地看到哪个 AI 适合生成 ST 函数块哪个 AI 适合解读三菱指令哪个 AI 在处理通信报文时需要额外提供手册。这类结论才值得写进项目团队规范。5. 实际应用中主要问题会出现在哪里5.1 问题一能编译但逻辑不完备这是最隐蔽的问题。AI 生成代码可以在软件里编译通过但业务逻辑并不完整。典型表现包括电机启动后没有保持按钮按下去一次就反复执行动作定时器条件满足后没有复位报警存在但缺少恢复路径。原因在于 AI 是根据语义生成代码不是根据真实 PLC 扫描过程推演每个周期会发生什么。要解决这个问题只有依靠人工审查和仿真。编译通过只能证明语法正确不能证明行为正确。5.2 问题二品牌和型号张冠李戴同一个 AI 在同一段对话里可能先写西门子%I0.0后写三菱M0甚至把两者混在一个程序里。这种错误多发生在用户只给“PLC 程序”而没有写明具体品牌型号的情况下。避免方法是把品牌、型号、软件版本、编程语言全部写入提示词。生成之后还要核对所有 I/O 地址和指令是否属于该型号。处理这类问题要果断只要看到一个指令不属于目标 PLC就属于严重不合格不要指望后续修改。5.3 问题三通信、地址、寄存器靠“猜”通信是 AI 错误率最高的领域之一。AI 在写 Modbus RTU、TCP/IP、CC-Link、PROFINET 程序时经常编造寄存器地址。比如把变频器“运行频率寄存器”写成“输出频率寄存器”把写线圈和写寄存器功能码搞混把 CRC 校验放在错误位置。这类问题不能通过阅读代码本身发现必须用通信调试工具抓包或者查看 PLC 通信状态寄存器。使用 AI 生成通信程序时请提前准备好设备手册把寄存器地址表直接粘贴给 AI并让它生成后单独列出所有地址再让工程师核对。5.4 问题四安全互锁缺失AI 默认的安全意识远远不够。它不会主动想到急停回路、安全门互锁、正反转互锁、超程保护、光栅保护。一个简单的“正反转控制”AI 可能只写两个输出不做互锁结果正反转同时输出导致接触器短路或机械损坏。这是 AI 写 PLC 程序最危险的地方。生产环境中涉及人身安全和设备安全的互锁逻辑不能直接信任 AI 生成结果。更好的做法是让 AI 生成功能逻辑由工程师在外部添加安全回路或者把安全回路直接做成硬接线不放在 PLC 程序里。5.5 问题五老设备和工程现场差异很多工厂还在使用老旧 PLC比如三菱 FX2N、西门子 S7-200、欧姆龙 CPM 系列。AI 对这些老型号的资料覆盖差异很大。同一个 AI给 FX3U 写的代码可能可用换成 FX2N 就报错因为后者不支持某些高级 ST 指令。现场调试还要考虑接线类型、输入极性、传感器输出类型、模拟量信号类型。AI 不知道现场用的传感器是 NPN 还是 PNP不知道模拟量模块是 0-10V 还是 4-20mA。如果提示词里不写这些它只能根据通用经验猜猜错的概率很高。6. 把 AI 接入真实项目的可落地工作流6.1 推荐工作流需求结构化、生成、审查、仿真、现场调试AI 不能替代工程师但可以充当“快速起草员”。真实项目里我建议按下面五个环节使用 AI第一步把控制需求写清楚包括工艺流程、I/O 表、报警表、安全要求。第二步把需求交给 AI 生成初稿。第三步工程师逐行审查代码重点检查安全互锁、输出重复赋值、状态转移条件和通信地址。第四步在 PLC 仿真软件里跑一遍确认动作顺序和时序。第五步到现场用单步调试和强制功能逐步验证。每一步都不要跳过。AI 生成初稿的价值在于减少从空白页开始的成本而不是替代后面的验证。6.2 通用提示词模板给 AI 的信息越完整生成结果越接近可用。下面是一个通用模板请用 [结构化文本 ST / 梯形图 / 指令表] 为 [PLC 品牌型号] 编写一段程序实现 [功能描述]。 项目软件是 [GX Works3 / TIA Portal / AutoShop]。 I/O 和变量说明 - X0启动按钮常开 - X1停止按钮常闭 - Y0接触器输出 控制要求 1. 按下启动后 Y0 置位并保持 2. 按下停止后 Y0 复位 3. 急停按钮 X2 按下时无条件复位 Y0 安全要求 - 必须包含互锁、急停、上电初始状态清零。 请输出完整代码和注释并解释代码在 PLC 扫描周期中的执行过程。模板里“请解释代码在 PLC 扫描周期中的执行过程”这一句非常有用。它迫 AI 检查自己的逻辑是否在循环扫描模型下合理而不是写出一段普通顺序程序。6.3 代码审查检查清单检查项说明变量声明是否完整有没有缺声明、重复、默认值输出是否重复赋值同个输出在多个位置被赋值边沿检测是否正确按钮启动是否需要上升沿避免每周期保持定时器复位是否遗漏TON 的 IN 条件断开是否能复位安全互锁是否齐全急停、门锁、超程、正反转互锁硬件地址是否匹配输入输出点、模拟量通道、通信地址编译和仿真是否通过真机上电前至少做软件仿真异常分支是否处理卡料、超时、通信失败、报警恢复这份清单可以直接打印出来作为每次使用 AI 生成 PLC 代码后的固定检查项。缺少任何一项都不要进入仿真和现场调试。7. 常见问题排查路径7.1 现象、原因、检查方式、处理建议下面是几个高频问题适合对照排查问题现象可能原因检查方式处理建议程序编译不过指令名不存在、变量未声明、地址写错查看编译器报错行号按软件关键字表逐条核对能编译但输出不动输出被后续逻辑覆盖、急停条件写反搜索该输出所有赋值位置重构成单点输出模式动作顺序不对状态机缺少转移条件检查状态变量和分支条件用状态表逐条核对通信失败寄存器地址、波特率、站号错误查看通信状态寄存器或抓包对照设备手册确认地址仿真通过但现场异常输入信号持续时间短于扫描周期检查输入滤波和上升沿加边沿检测或输入中断设备动作但停止不可靠停止按钮常开常闭写反在线监控输入状态按实际接线修改输入逻辑7.2 排查链路从报错到现场如果是 AI 生成代码上不了机建议按下面顺序排查不要一开始就怀疑现场接线。先看编译报错。根据编译器提示逐行检查指令和变量声明。再看地址映射。确认所有 I/O 地址、数据块、寄存器地址与 PLC 配置一致。接下来检查扫描周期和状态转移。用在线监视功能观察状态变量在每个扫描周期的变化。然后检查通信。用调试助手查看 PLC 发出的数据帧确认从站地址、功能码、寄存器地址、CRC 是否正确。最后才做现场最小复现。把这几步写成排查清单可以避免反复改代码却找不到根因。7.3 保存测试记录定期复测AI 模型更新速度很快。今天表现不行的模型可能下个版本就有明显提升。建议把每次对比测试的提示词、代码、编译结果、运行结果保存到一个文档或表格里每三个月复测一次。长期积累后这份记录会成为团队最实用的“AI-PLC 能力地图”。8. 结论与建议8.1 核心判断AI 是起草助手不是审查终点从现阶段表现看AI 写 PLC 程序已经能覆盖基础逻辑、顺序控制、通用 ST 函数块甚至能辅助分析通信报文。但距离“直接生成可上机程序”还有明显差距最大的短板在于对具体品牌型号、通信协议、安全互锁和设备工艺的理解。所以在项目里使用 AI 的合理方式是用 AI 快速生成初稿用工程师经验做审查用仿真软件做验证用现场信号做最终确认。没有工程师审查的 AI 生成 PLC 程序不建议直接用于生产环境。8.2 下一步可以做什么如果你现在刚开始接触这个方向可以先跑一遍基础题目集得到一份自己的测试记录。然后按照项目实际涉及的品牌和型号积累一批提示词模板。最后把这些模板和测试结果整理成企业内部的规范文档让 AI 辅助 PLC 开发成为一个可管理、可复测、可安全落地的流程。如果你已经用过一两款 AI建议把范围扩大一点至少对比三款不同来源的模型并覆盖西门子、三菱、CODESYS 三种常见体系。用同样的题目做横向对比你会很快知道哪个 AI 适合做前期原型哪个 AI 适合查手册哪个 AI 在通信和协议方面需要额外给足上下文。这个结论比自己凭印象“感觉哪个好用”可靠得多。
返回列表