如何阅读没有文档的 PLC 程序？

一台码垛机每班停一次，停在层与层之间。操作工过去按一下复位，它继续跑。这个动作他们做了三个月。

程序里答得出它为什么停——某个步在等一个位。程序答不出的是：那个位为什么有时候是 0，因为它对应的是现场一颗开关，而现场不在文件里。

写这套程序的人早就不在了，注释基本没有，标签大多是 Local:3:I.Data.7 这种裸 I/O 别名。这时候最贵的动作是打开编辑器从第 1 行读到第 3,000 行——你会读到很多细节，但读不出这张地图。

一、读的顺序：由外向内

PLC AI 平台 PLCs.ai 的首席技术产品官 Noam Weisman 在 11 月 9 日写了一篇很实操的文章，给的正是一个阅读顺序：先把 I/O 映射到真实设备，再找安全链，再找驱动机器走步的顺控，然后从报警位往回追。 不要从第 1 行读起。

这四趟走完，你手里有了一张机器地图，和每一个故障的起点。

动手之前有三件事要先做，原文写得很硬：

• 先备份控制器、HMI 和驱动器的配置，在副本上工作。
• 在观察一个活周期之前，由授权人员按现场规程检查控制器的 force（强制）状态。
• 离开时把 force、位和运行中的程序按原样留下。

这三条不是客套。一个不知道从哪继承来的强制位，可以让后面所有的推理都建立在假前提上。

二、七步

原文给的是一张七行的表，比"四趟"细，值得整张搬过来：

1. 映射 I/O。 找的是每个输入输出在物理上是什么。手工做法是硬件组态加电气图，确认一个标一个；AI 能做的是把已组态的点在工程里的所有引用找出来，让你在笔记里用已确认的设备名。

2. 找安全链。 急停、安全门、安全继电器反馈、主控继电器。手工去找安全任务，或外部安全硬件回传的状态位，再看标准逻辑怎么用它；AI 能指出这些许可条件被用在哪些地方、哪些分支会影响到它们。

3. 找顺控。 驱动整机走步的那个整数或那组步位（步 10 待料、20 夹紧、30 伸出）。手工找重复出现的比较，以及往同一个步寄存器写的地方；AI 能把它找到的状态迁移串起来，按输出与退出条件给步起名字。

4. 倒着追报警位。 每条 HMI 报警文字背后那个线圈。手工交叉引用该报警位，置位它的那条梯级会把上一任程序员认为"是故障"的条件全部写在那里；AI 能把它追到置位逻辑。

5. 查旁路与多写点。 手动覆盖、条件调用、被多处写入的标签。手工做交叉引用，并弄清每个例程什么时候运行；AI 能在工程里找出需要复核的写入点与分支。

6. 把 HMI 当文档。 找的是操作工怎么称呼这些东西。一个"启动电机"按钮写的是 B3:0/5，它刚刚告诉你 B3:0/5 是什么；AI 拿到一张画面截图，可以拿画面上的东西和实时标签值对照。

7. 看它跑。 每一步是哪些位在变。机器跑一个周期，用趋势和监视表按工位分组看；有实时标签访问时，AI 能帮着拿当前值和工程里查到的条件做比对。

第 4 步的完整答案往往拆在两个地方：把报警位追到置位它的逻辑，工程里就有；但要把它对到操作工看到的那行文字，得 HMI 组态；要追它上游的许可条件，还得上游控制器的工程。

第 4 步和第 6 步是很多人跳过的两步，也是最能省时间的两步。报警位往回追，等于让上一任程序员把他当时的判断标准复述一遍；HMI 画面则是一份由操作工维护了十年的命名表，它比变量注释可信。

三、走一遍：一台没人讲得清的码垛机

原文用一个 CompactLogix 码垛机演示了这套顺序（作者明确写了：这是示意性的例子，不是客户案例）。场景是每班停一次、按复位就能继续，标签大多是 Local:3:I.Data.7 这种裸别名，例程注释稀疏。

七步走下来是这样的：

• I/O 映射：Local:3:I.Data.7 在图纸上接的是层垫光电，在 I/O 表里记成 PE_LayerPad_Present。
• 安全链：逻辑里用 ESTOP_Chain_OK、Guard_Door_1_Closed、Guard_Door_2_Closed 三个许可条件合成 MCR_OK。
• 顺控：R_Sequence 里的 Seq_Step（DINT）——10 待料、20 进层、30 降货叉、40 放垫、50 升货叉、60 本层完成。卡住永远卡在 Seq_Step = 40。
• 报警位：HMI 上那条"垫板放置超时"是 Alm_PadTimeout，在 R_Alarms 第 9 级置位：Seq_Step = 40 持续超过 T_PadPlace.PRE（8 秒）而 PadPlacer_Home 没变 1。
• 旁路与多写点：PadPlacer_Home 有两个写入点——R_Station4 第 22 级（来自原点接近开关），和 R_Manual 第 3 级（手动选择开关打开时置位）。
• HMI：操作工按的"垫板复位"按钮写 HMI_PadReset，它的作用是把 Seq_Step 直接跳到 50——这就是他们一直在按的东西。
• 看它跑：卡住时 PadPlacer_Home 是 0，但放垫机构物理上在原位。原点开关 Local:4:I.Data.2 的输入在抖；支架松了。

顺控那一步还有个容易忽略的分支：步号不一定是 Seq_Step 这样的整数，很多老程序用一组位表示当前步（Step10、Step20…），或者用整数加一组位混着用。这时候要找的不是"往同一个寄存器写"，而是"往同一组位里写"——同一个道理，形状不同。

最后这一段是整篇文章最值钱的地方：程序把你指到了正确的信号上。它告诉你第 40 步在等 PadPlacer_Home，这个位有两个例程在写，复位命令直接跳到第 50 步绕过了这个等待。而"这个输入在抖"，只能到现场才知道——松掉的开关支架不在任何文件里。

所以 AI 在这条链路上的角色很清楚：它帮你在下一次停机之前，把"要验哪个信号"问清楚。问法是三个问题——第 40 步要成立需要哪些条件？每一个条件在哪儿被写？复位命令改掉了什么？

四、AI 到底能不能读懂一套没注释的程序

原文的答案是"能"，但有一个前提被很多人跳过：要给它完整导出。

有了完整导出，它才有上下文把一条梯级跨例程追下去：指出一个位在哪儿被写，这个位还在哪儿被读，再把它连回对应的顺控步。而你要做的一件事是——让它给出例程与梯级引用，这样你能在自己的编程软件里把这条追踪核对一遍。

原文也说清了产出物的性质：它是给"懂这台机器的人"复核的草稿，而且它会标注哪些描述是从结构推断出来的、哪些是被逻辑证明的。这个区分很重要：推断出来的东西是假设，不是结论。

"完整"这两个字值得多说一句，因为它是这条方法成立与否的开关。

只丢一个块进去，AI 能告诉你这一块里有什么，但拿不到三样东西：谁调用它（上游的进入条件）、它写的那些位还有谁在写（多写点）、它依赖的变量在别处被改成什么（跨例程的数据流）。而这三样恰好是码垛机那个例子里全部的关键。

所以顺序反过来就失效了：先让 AI 读第 40 步那一段，它会告诉你"这里在等 PadPlacer_Home"——这句话没错，但没告诉你这个位有第二个写入点，也没告诉你复位会跳过它。半个工程能解释一块逻辑，解释不了一个故障。

五、程序本身永远看不到的四件事

离线工程描述的是"可能的行为"。要确定机器实际怎么动，得看系统的其余部分。原文列了四项，每一项都可以直接变成点检项：

1. 物理 I/O 与接线。 核对实际接线与器件状态，拿图纸和机器对。

2. 驱动与 HMI 配置。 变频器参数、HMI 脚本、配方数据都会改变行为，它们不在 PLC 文件里。

3. 别的控制器。 上游 PLC 给出的许可条件，在这里只是一个位；它的原因在另一个工程里。产线级工具能读两边，单机工具到这里就断了。

4. 安全功能。 AI 的追踪只能帮你定位该复核的逻辑；安全功能本身的验证与任何改动，走现场的安全流程。

原文有一句话建议直接抄进点检表：用追踪不到的部分，去做你的检查清单。 换句话说，追不到的地方不是工具的失败，是你要去看的地方。

举个具体的：如果第 40 步的退出条件里有一个 Line_Ready 来自上游 PLC，那么这个位在你的工程里只是一个输入，它为什么是 0 必须去上游的工程里查。这就是"单机工具在这里断掉"的实际形状——不是它读不懂，是原因根本不在这份文件里。

六、让下一个人不再从头开始

文章后半段讨论了为什么程序会变成"没有注释"：因为大家学到的东西留在个人身上——某个人的笔记里、某个维修技师的记忆里、某台笔记本上的一个文件里。把程序文档化一次也解决不了，如果那份文档最后又躺在同一个人的机器上。

这一段是原文的产品主张部分（作者所在平台在卖"多人共用一份工程理解"），本文不转述它的功能清单。但它指出的问题是通用的，而且和前面七步是同一件事的两面：

你走完七步得到的东西，如果只是一份 Word 或者一段聊天记录，下一个人还是从零开始。 它能被复用的前提，是它落回到工程本身——哪一块调用哪一块、哪个网络读写哪个变量、哪些引用在工程里根本找不到定义。

七、原文问答里三个能直接用的回答

原文末尾有一组问答。其中三条不是营销，是工程经验，值得单独摘出来。

一、找某个标签在哪儿被写：看目标，不看源。 在编程软件里做交叉引用，然后去看写入点那一列。一个位可能在五十个地方被读，但通常只在一处被写。如果有两个写入点，要查的是：每个例程什么时候运行，哪个值最终到达消费它的那段逻辑。

这是七步表第 5 行的实操版，也是老工程里最容易翻车的地方——两个写入点不一定就是 bug，但一定意味着"这个位有两个来源，而你只看见了一个"。

二、AI 能不能给已有梯形图补注释。 能，前提还是那句：读完整套程序。它先起草标签描述、解释意图的梯级注释、例程摘要，并在逻辑不足以证明的地方标成"推断"。这些是给人复核的草稿，复核过再写回工程。

三、RSLogix 500 与 Studio 5000 的继承工程，读法一样吗。 顺序一样，难点不同。RSLogix 500（SLC 500、MicroLogix）用 B3:0/4、N7:12 这类文件地址，含义只能从符号、注释、电气图和 HMI 标签里找；Studio 5000 有标签名，但从上一任手里接过来的工程常常还是裸 I/O 别名。换句话说，新工程不一定比老工程好读，只是它的钩子换了个地方。

八、我们的整理：为什么"追引用"是分水岭

把上面七步翻译成"要在工程里回答的问题"，会得到一张很像数据库查询的清单：

前六行里，有五行的答案是关系，不是内容。

这就是分水岭。让人读代码，或者让 AI 读代码，读的都是一块一块的内容；而这套方法真正依赖的是块与块之间、变量与变量之间的引用关系。手工做这件事的方法是交叉引用，一次一条；一套跑过十几年的工程，块上千、变量上万，逐条查的代价就是三个月没人敢动它。

这张"谁和谁有关系"的总表，就是项目知识图谱。 它不神秘，就是把这套工程里声明和引用的东西索引成一张可查询的图。

博途这边对应的入口是 TiaLink：它在本机把当前工程索引成一张项目知识图谱——块与接口、谁调用谁、哪些网络读写哪个 DB 成员、哪些引用在工程里找不到定义——智能体按符号搜、走调用链、做影响面分析，走的都是这张图。

三条建议的落地顺序：

1. 先建图，再读逻辑。 图建完先看三个数字：块总数、悬空引用数、有多写点的变量数。老工程里"引用在工程里找不到定义"这一类（来自已删的块、来自没导入的库）手工查最痛，图上是一句话的事。
2. 按七步问，不按七步读。 第 3 步问"谁在写这个步寄存器"，第 5 步问"这个位有几个写入点"，第 2 步问"这个许可条件影响了哪些分支"——这些是查询，不是通读。
3. 改之前看影响面，改之后读回核对。 第 40 步那个 PadPlacer_Home 就是典型：改 R_Station4 之前先查出它还有第二个写入点，比改完在机器上找原因便宜得多。

也要说清这张图的边界，它和原文第五节那四件事正好对上：图谱只覆盖工程里声明和引用的东西。 现场接线、HMI 脚本、上游 PLC 的逻辑、驱动器参数，都不在图上——它们是七步之外的第五、六、七件事，得靠图纸、现场和别的工程。

一个跑过十年的工程，最缺的从来不是"有人再读一遍"。缺的是一张能查的表，和七个知道该往哪儿问的顺序。

来源

• Noam Weisman（PLCs.ai 首席技术产品官），《How do I understand an undocumented PLC program I inherited?》，2026-11-09：https://www.plcs.ai/blog/understand-undocumented-plc-program
• 本文为全文编译：七步表、码垛机走查、程序看不到的四件事均按原文译出；原文后半段的产品介绍与 FAQ 未转述，末节「我们的整理」为本刊补充
• 文中的码垛机为原文标注的示意性例子，非客户案例；文中未包含任何实测数据
• 封面：Wikimedia Commons，KUKA Roboter GmbH / Bachmann，《Factory Automation Robotics Palettizing Bread》，公有领域

相关阅读：接手别人的 PLC 程序：动第一行代码前的 4 步取证——那篇讲动手前的取证与版本基线，这篇讲读的顺序。｜用 TiaLink 为遗留的博途 PLC 项目生成文档——走完七步之后该交付什么：五张表。｜梯形图怎么读：Stop 按下之后，端子还多亮一个扫描

这是「AI × 工业 / PLC」专题的一部分。完整地图见：AI × 工业 / PLC 完全指南