Aiepco 工业智能体
接手别人的 PLC 程序，先做这 4 件事
拿到一套来路不明的程序 —— 上一任工程师离职了、原始文档找不到了、或者只是「先上线再说」。这种时候最容易犯的错，是打开 TIA Portal 就开始改。
为什么不能先改
一个能跑的程序里，「看起来多余」的逻辑很可能是某次事故后加的补丁。在没有基线、没有证据的情况下动它，等于把上一个问题换成下一个问题 —— 而且新的问题往往更难查，因为是你自己引入的。
先做的 4 件事
- ① 先取证据，不要先改
- 把现在能拿到的东西全部留档：PLC 里上载的程序、诊断缓冲区（Diagnostic buffer）、报警历史、主要 I/O 的实际状态、以及操作人员对「什么时候出问题」的描述。这些是后面所有判断的原料 —— 一旦你开始改，现场状态就回不去了。
- ② 建立版本基线
- 把上载的程序存成带日期与来源说明的归档，并写一句「本版本为 XX 年 XX 月从设备上载，未经修改」。看起来是小事，但这是你后面能说清「改了什么、为什么改」的唯一依据；也是下一次交接时别人能接得住的起点。
- ③ 静态分析 + 逻辑推演，缩小范围
- 先不看现象去猜，用工具过一遍（除零风险、数组越界、块调用层级、未使用变量、命名混乱），把可疑区缩小成几个块。再把可能原因列出来、按可能性排序，而不是逐个试。
- ④ 验证结论后才动手改
- 在仿真或现场单步确认根因之后才改；改完必须跑一遍回归，确认没有连带影响（改 A 坏 B 是常态，不是例外）。每一次改动同样留档。
一条经验：接手老程序时，90% 的时间该花在「搞清楚它现在是什么样」，只有 10% 花在「改成我想要的样子」。反过来做，通常会在两周后回到原点，而且带着更多问题。
需要向对方索要的东西（有就给，没有也要问）
- 程序备份（任何版本都行，越老越有价值 —— 能用来对比）
- PLC 型号与固件版本（订货号最准）
- I/O 点表或电气图纸（哪怕只是草稿）
- 历史上出过什么故障、怎么处理的（口头描述也记下来）
- 有没有人知道「为什么这段逻辑是这样写的」—— 这个人比任何文档都值钱
我们做这类活的方式
程序抢救与故障诊断属于我们的服务范围（改造 · 诊断 · 程序抢救）。我们的做法就是把上面 4 步走完：先证据、后结论，不靠猜。需要说明的是，接线与硬件更换、实机轨迹采集、安全功能独立验证必须现场完成 —— 程序层的排查可以远程，物理层面的问题不能。