程序读出来了，打开一看三千个 I 点，一个注释都没有。
接过一台 S7-1200 的程序上载 程序读出来了。 打开一看，三千多个 I/O 点，一个注释都没有
原工程师离职两年了。 图纸在档案柜里，还缺页 这种程序，老手读得，新手读不动
先说清楚：程序在哪个存储区
上载到 TIA Portal，拿到的是控制器的用户程序块 S7-1200/1500 的用户程序，存在 CPU 的装载存储器和工作存储器里 上载是把代码块从 CPU 拷回编程电脑。
但符号表和块注释是另一回事 如果原工程师当年下载时，没把注释一起下进去，CPU 里根本没有这些信息 上载出来的，就只有地址和代码
这不是谁的操作失误。 很多老程序当年就是不带注释发布的，图省事 所以你面对的是:一个能跑的逻辑，一份对不上的地址表
人工读法为什么慢
老办法是顺着梯形图追地址。 I0.0 出现了，去看接线图，找它接的是哪个传感器 再翻回去看这个点在 FB 里的用法，来回对照
一个点十几分钟，三千个点就是几个月 厂里没人愿意干这个。 更常见的结局是:读到一半，设备要改造，程序被另一个班次的人重新下载，你手里的分析全作废
还有一种更隐蔽的坑 M 点是中间变量，不接实物，图纸上根本找不到 它是什么意思，只存在于原工程师的脑子里，人走了，线索就断了
我们的做法
我们自研了一套工具，专门干这件事 从 TIA 工程里抽取符号表和地址表。 按 I、Q、M 分区，扫描每个地址在哪些块里被引用
自动生成结构化的 I/O 点表。 再对照图纸和 HMI 画面，生成中文注释草稿 原来按月算的事，压到按天算
工具生成完，再由工程师逐条校对把关 这才是工具的实际用法。
必须说的一条边界
这里要停一下，说一条我们自己定的规矩 工具只负责整理与比对，不能替代工程师对设备工艺与逻辑的判断
举一个例子 I0.0 在图纸上叫"进料检测"，但那台设备的进料检测实际接的是什么、联动逻辑该怎么解读，这是工艺判断，工具给不了
注释草稿出来之后，必须由懂这台设备的工程师逐条校对 确认一条，算一条 不确定的，标注出来存疑，不硬写
机器补的是量，人补的是判断 缺哪一头都不行。
一次差点出事的比对
讲一个我们自己的教训。 有一回，工具把两个设备的点表混在了一起 I 点的注释张冠李戴，草稿看着头头是道，落到现场就是错位
问题出在哪。 两台设备的图纸文件名只差一个下划线。 工具按文件名关联，人没复核，直接采信了草稿
从那以后，我们加了一条硬规矩 点表必须和现场接线一次一次对过，才允许写进正式档案 草稿永远只是草稿
你自己动手时的检查表
没有工具也能做，就是慢一些，按这个顺序来:
- 确认工程版本。TIA Portal V13 到 V19 的工程结构有差异，版本对不上，先别急着上载。
- 先导出变量表和连接表，这两张是骨架。
- 按引用次数排序地址，被十几个块引用的 M 点是逻辑枢纽，先读懂它们。
- 对照 HMI 画面反推，画面上的按钮和指示灯，往往比图纸更新。
- 每确认一批，立刻在工程里写回注释并保存，不要攒到收尾一起写。
第 5 条要单独说一句。 分析到一半丢了，比没分析还让人心疼 每写回一次，就多攒下一份资产
什么时候不必做
如果这台设备还有完整备份、原厂还能响应，或者它两年内就要淘汰，那这份无注释程序不值得投入 备份好，等着换就是了
还有一种情况:程序被加密或者有密码保护 我们明确不做绕过原厂授权保护的事，这条路你另找人
一句实在话:公司是新的，但团队在电气与软件这两行已经做了三十多年 我们接的活，就是这种"程序在、人不在"的硬骨头 你手里如果正好有一份，可以先发我们看看结构，能做的说能做，做不了的说清楚
更多这类工具用法和速查表，我们会持续整理在这个专栏里