> ## Content Index
> Fetch the complete content index at: https://www.hubwiz.com/blog/llms.txt
> Use this file to discover other available public pages before exploring further.

# 如何阅读没有文档的 PLC 程序？
- URL: https://www.hubwiz.com/blog/undocumented-plc-program-seven-passes/
- Published: 2026-11-11T07:32:17.000Z
- Updated: 2026-11-11T08:18:31.000Z
- Description: 一台码垛机每班停一次，按下复位就能继续。程序答得出它为什么停，答不出停的是哪个物理信号。
- Author: admin
- Tags: PLC, 遗留工程, 代码理解, 工业 AI, TIA Portal

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

程序里答得出它为什么停——某个步在等一个位。程序答不出的是：**那个位为什么有时候是 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 别名。换句话说，**新工程不一定比老工程好读，只是它的钩子换了个地方。**

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

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

| 步骤      | 要回答的问题            | 在图上的形状          |
| ------- | ----------------- | --------------- |
| I/O 映射  | 这个 %I29.0 被哪些网络引用 | 点 → 引用的反查       |
| 安全链     | 这个许可条件影响了哪些分支     | 从变量出发的扇出        |
| 顺控      | 谁在往这个步寄存器写、谁在比较它  | 同一符号的读写点列表      |
| 报警位     | 谁置位它，它的上游条件谁给的    | 反向调用链 + 跨块追踪    |
| 旁路与多写点  | 这个位有几个写入点，各在什么时候跑 | 多写点识别 + 调用时机    |
| HMI 当文档 | 这个位对应的按钮在哪儿       | 工程内查不到，要 HMI 组态 |
| 看它跑     | 这一刻哪个条件不成立        | 图谱 + 实时值        |

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

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

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

[博途这边对应的入口是 TiaLink](https://tia.hubwiz.com/tia-link?utm%5Fsource=blog&utm%5Fmedium=article&utm%5Fcampaign=undocumented-seven-passes&utm%5Fcontent=cta)：它在本机把当前工程索引成一张项目知识图谱——块与接口、谁调用谁、哪些网络读写哪个 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](https://www.plcs.ai/blog/understand-undocumented-plc-program?ref=hubwiz.com)
- 本文为全文编译：七步表、码垛机走查、程序看不到的四件事均按原文译出；原文后半段的产品介绍与 FAQ 未转述，末节「我们的整理」为本刊补充
- 文中的码垛机为原文标注的**示意性例子**，非客户案例；文中未包含任何实测数据
- 封面：Wikimedia Commons，KUKA Roboter GmbH / Bachmann，《Factory Automation Robotics Palettizing Bread》，公有领域

**相关阅读**：[接手别人的 PLC 程序：动第一行代码前的 4 步取证](https://www.hubwiz.com/blog/taking-over-legacy-plc-program-4-steps/)——那篇讲动手前的取证与版本基线，这篇讲读的顺序。｜[用 TiaLink 为遗留的博途 PLC 项目生成文档](https://www.hubwiz.com/blog/reverse-documentation-tia-portal/)——走完七步之后该交付什么：五张表。｜[梯形图怎么读：Stop 按下之后，端子还多亮一个扫描](https://www.hubwiz.com/blog/read-plc-ladder-logic-scan-cycle-seal-in-timer/)

> **这是「AI × 工业 / PLC」专题的一部分。**完整地图见：[AI × 工业 / PLC 完全指南](https://www.hubwiz.com/blog/ai-industrial-stack/)