做了几年的自动化项目，我发现一个挺讽刺的现象：很多 FX5U 项目，程序是在上一个项目基础上删删改改拼出来的，能跑，但三个月后连写程序的人自己都要花半天才能看懂改哪儿。三菱 FX5U PLC 功能样板程序的价值，不在于"拿来就能用"，而在于把整个程序框架、注释规范、软元件分配、调试入口全部固定下来，让新项目从第一天起就看到终点。
这篇文章我打算完整聊聊这套样板程序的思路和玩法：从选型盘点、程序分区、注释命名，到快速移植、结构化文本和 FB 封装、内置定位和以太网通信，最后再把几年现场调试里踩过的坑一并倒出来。不管你是刚接触 FX5U，还是已经在 GX Works3 里折腾了不短时间，这套东西都能直接照搬，省掉大量重复劳动。
1. 样板程序到底解决什么问题，为什么要花力气维护它
先说个我常被问的问题：三菱官方不是给了一堆示例程序和手册吗，为什么还要自己做一套样板？官方示例确实齐全，但它们是"功能演示"，不是"工程组织"。演示程序只告诉你这个指令怎么用，不告诉你整套设备程序该怎么分区、哪些信号放哪个地址、操作工按下启动后逻辑从哪儿一路跑到输出。真实项目里最耗时的不是写一条指令，而是把所有 IO、报警、模式、步序、通信、参数堆在一起之后，系统还能被清晰读懂、快速修改。
样板程序解决的核心问题有三个。
第一是降低重复搭建成本。每台设备都要初始化、手动自动切换、报警互锁、输出映射、触摸屏对接，这些骨架逻辑占整个程序工作量的六成。把它们做成样板，新项目等于先继承六成完成度，剩下的只是工艺段和参数差异。
第二是统一团队的代码习惯。自动化项目经常是今天 A 写、明天 B 改、后天 C 维护。没有统一框架时，每个人的软元件命名风格都不一样，有人用 M0 表示运行，有人用 M100 表示运行，注释爱写不写，修改时全靠猜。样板把这套规则定死，谁进来都按同一个套路走。
第三是把调试入口前置。程序里设计了专门的设备状态区、报警保持区、参数区，设备在现场出了问题，维护人员可以直接通过触摸屏或者 GX Works3 监视界面定位到具体分区，而不是打开一整张梯形图对着触点一个个找。
我见过不少团队喊着"做个样板"，结果做成一个什么功能都往里面塞的大杂烩，最后比不做好。合格的样板必须满足三个条件：结构稳定、注释完整、占位清晰。结构稳定是说分区骨架长期不变；注释完整是说每个软元件、每个网络块都写明白；占位清晰是说预留的备用 IO 和参数区在图纸上一眼能看到。达不到这三点的样板，用一两个项目就会被废弃。
2. 动手前的资源盘点：FX5U 选型决定了样板的天花板
开始写程序之前，先做硬件资源的盘点。同样是 FX5U，不同型号的差异非常大，样板程序如果一开始没留够扩展量，后面会非常被动。
2.1 CPU 型号里的门道
三菱 FX5U 的型号命名看起来一串字符，其实信息量很大。常见的是 FX5U-32MT/ES、FX5U-64MT/ESS 这类。中间的 32、64 指的是本体 IO 点数，比如 32 一般是 16 点输入加 16 点输出。后面的 M 是晶体管输出，R 是继电器输出，最后一个字母组合代表供电方式和漏型源型差异。
选型上我要强调一句：如果设备上有步进或者伺服，一定要选晶体管输出型。晶体管输出响应快，可以输出高速脉冲给驱动器；继电器输出只能做低频开关，脉冲定位想都不用想。样板程序我默认按晶体管输出设计，如果项目确实用了继电器输出，只要把脉冲相关的轴配置删掉，其他框架不动。
FX5U 相对老款 FX3U 的一大优势是通信能力大幅增强。CPU 本体自带以太网口，可以走 Modbus TCP、SLMP 这类协议，也支持 CC-Link IE Field Basic 网络。这意味着触摸屏、上位机甚至远程维护都可以通过网口直连，不用再单独加通信模块。样板程序里通信区的设计，都是基于这个网口展开的。
2.2 本体资源、扩展模块和远程 IO 的取舍
FX5U 本体上有内置的高速计数输入，晶体管型还支持高速脉冲输出用于定位。不同批次和型号的具体通道数有差异，选型时以官方硬件手册为准。我在样板上留了这部分的软元件分配，实际项目按真实硬件调整。
IO 点不够时，FX5U 支持右侧扩展模块的方式增加 IO 和特殊功能模块，比如 FX5-16EX/16EYT 这类数字量扩展，FX5-4AD/4DA 这类模拟量模块。如果点数需求更大或者现场分布比较散，可以考虑 CC-Link IE Field Basic 远程站，网线串联就行，接线量比传统并行扩展小很多。
这里有个经验：样板里默认给本体 IO 地址留出余量，不要一上来就把 X0-X7、Y0-Y7 全部占完。设备调试阶段总会有临时增加近接开关、改个急停回路的情况，预留地址能让你在不动整个框架的前提下完成接线变更。我在每个分区里都留了两到三个备用输入和备用输出，注释直接写成"备用 1、备用 2"，谁看了都知道这里是空位。
2.3 隔离清单：哪些资源属于样板，哪些必须项目自定义
样板程序容易犯的毛病是"过度设计"。我把资源分成两类：一类是设备无关的公共资源，比如模式管理、报警记录、参数区、通信缓冲区，这些必须在样板中定义清楚；另一类是设备相关的工艺资源，比如工位步序、气缸动作、伺服定位表格、模拟量上下限，这些只保留占位和示例，具体内容由项目程序填充。
隔离清楚的好处是移植时有一个明确的"换内脏不换骨架"的过程。骨架错误是全局性的，内脏错误只影响单个设备，调试定位的时候范围一下子就缩小了。
3. 程序框架与地址规划：先在纸面上把整台机器的逻辑铺开
在 GX Works3 里建工程之前，我习惯先在表格里把地址规划和程序分区画出来。这一步看起来费时间，实际是后面省时间最多的一步。
3.1 八个基本分区的划分逻辑
样板程序按功能划分为八个基本区，顺序很重要，因为 PLC 循环扫描是从上到下执行的：
| 分区 | 功能 | 典型位置 |
|---|---|---|
| 初始化区 | 上电首扫描处理，清中间状态、恢复保持参数 | 程序开头 |
| 模式管理区 | 手动/自动切换、运行允许条件 | 初始化之后 |
| 自动步序区 | 各工艺段的顺序控制逻辑 | 模式区之后 |
| 报警与互锁区 | 故障检测、报警保持、急停处理 | 输出映射之前 |
| 手动输出区 | 点动、单步动作的驱动逻辑 | 自动步序之后 |
| 自动输出映射区 | 把自动步序结果映射到实际输出 | 输出前 |
| 通信区 | 以太网、Modbus 数据交换，读写缓冲区 | 中后段 |
| 参数与状态区 | 触摸屏显示、调试监视用的数据集中区 | 任意位置，集中为宜 |
初始化在最前，是因为上电后必须先把中间继电器清零、把上一次掉电遗留的状态处理掉，再进入正常的逻辑扫描。模式管理要在自动步序之前，因为步序的启动条件要先拿到"当前是自动模式还是手动模式"这个结果。报警互锁放在输出映射之前，是为了确保报警发生时能直接掐断输出映射的出口，而不是等输出已经置位之后再补救。
自动输出映射单独拉一个区是我特别想强调的设计。很多新手喜欢在步序里直接写 Y0、Y1，这样看起来直观，但改线时就要翻遍整段程序。样板里做了分层：自动步序只操作中间标志位（比如 M101 表示"工位一前进"），最后由输出映射区统一把中间标志转换成物理输出 Y0。这样接线变更只改一个地方。
3.2 保持区与非保持区：最容易埋雷的地方
三菱 FX5U 的软元件有一部分可以通过参数设置为断电保持。样板程序对这个区域的划分有严格规矩：
- 参数类（速度设定、温度上下限、配方号）放在保持 D 区，断电后不丢，上电后直接使用。
- 累计类（总产量、运行时间）放在保持 D 区，但配合报警历史一起管理。
- 中间状态（当前步号、气缸伸出标志、报警瞬时信号）放在非保持区，上电时先清一次，防止设备停在上次的中间状态导致误动作。
这个规矩执行不到位会出现一个经典故障：设备断电再上电后，步序直接延续断电前的步号，气缸突然按照旧状态动作，现场维护人员往往第一反应是程序逻辑错了，实际上是保持区没规划好。我在样板初始化区写了一段注释很明显的程序：上电后把步序区整段清零，只恢复参数和累计值。
3.3 标签还是软元件地址：我为什么两者混用
GX Works3 里 FX5U 是支持标签编程的，用标签写程序肉眼看着很舒服，随时能跳转定义，类型检查也严格。但纯标签在触摸屏对接和三菱传统习惯上会遇到一些摩擦。很多触摸屏组态软件直接通过地址访问，标签如果没绑定软元件，HMI 那边就要多一层变量映射。
样板里我的做法是全局标签为主、软元件映射为辅。关键 IO 和中间变量定义全局标签，标签名规范可读，同时把它映射到固定的软元件地址；触摸屏和上位机通信时直接访问映射好的软元件，不依赖标签名。
这里有个实际好处：在线修改时，GX Works3 对软元件地址的监视和强制非常直观，现场维护人员不一定熟悉标签跳转，但一定看得懂 M0、D100 的批量监视窗口。
4. 注释体系和命名规范：让"注释全"变成可复制的方法论
样板程序最大的卖点是"注释全"。但注释全不等于每行都加字，更不等于废话连篇。真正有效的注释体系应该是：在关键位置出现、说明状态含义、解释非常规写法的原因、并和软元件命名互相印证。
4.1 GX Works3 的三类注释，各干各的活
GX Works3 中针对梯形图有三种常用注释：网络注释、软元件注释、行注释。样板里对它们进行了明确分工：
- 网络注释写在每个网络块的上方，说明这个块做什么、入口条件是什么。比如"设备空闲判定：无报警、无自动运行、手动无输出，三条件同时成立开放启动许可"。
- 软元件注释写在触点或线圈的下方，说明这个软元件的物理含义和置位状态。比如 X0 的注释是"启动按钮，常开，按下为 ON"。
- 行注释写在指令旁边，一般只用于解释"为什么这么写"。比如某处不是简单读取输入而是先做了滤波，行注释会写"近接开关抖动大，采样 10ms 滤波后再参与互锁"。
实际维护中，我在定位问题时根本不看梯形图主体，先看网络注释和软元件注释。排查路线通常是：报警区看到"设备急停"为 ON，再跳到急停输入确认 X 状态，然后去查硬件接线有没有断开。这一套注释逻辑下来，维护效率比无注释程序高几倍。
4.2 前缀和命名的固定写法
样板里所有软元件和全局标签都采用"前缀_含义_编号"的格式。约定如下：
| 前缀 | 含义 | 示例 |
|---|---|---|
| G_ | 全局标签前缀，跨程序可引用 | G_Main_Started |
| X / Y | 输入输出本体地址，注释写物理含义 | X0 压料到位近接 |
| Alm_ | 报警类信号 | Alm_Overload_1 |
| Para_ | 参数类软元件 | Para_Speed_MM_S |
| Stat_ | 设备状态字 | Stat_Device |
| Cnt_ | 计数器或累计值 | Cnt_TotalQty |
| Tmp_ | 临时计算用 | Tmp_Buf1 |
命名有个容易被忽视的细节：同一类软元件，编号尽量按功能分区连续分配。比如 M0-M99 归模式管理，M100-M199 归自动步序，M200-M299 归报警，M300-M399 归手动。这样在批量监视窗口里，只要扫一眼编号区间就知道属于哪部分逻辑。
单位也要写进注释或命名里。速度参数写成 "Para_Speed_MM_S" 而不是 "Para_Speed"，温度写成 "Alm_Temp_Above_Limit" 而不是简单的 "Alm_Temp"，等于把量纲和阈值方向都固化下来，后面改程序的人不需要再翻工艺文档。
4.3 注释维护的日常工作流
注释最怕写了不更新。样板维护里面有两条硬规矩：
第一，任何一次在线修改，必须同步改网络注释和软元件注释。如果只是临时强制测试而不需要改逻辑，那不动注释；一旦修改了线圈、触点、比较值，注释必须立刻跟随。
第二，定期做注释导出检查。GX Works3 支持把注释导出成文件，在电脑里批量检查哪些软元件有使用没有注释、哪些注释内容超过长度显示不全。我和团队大概每个项目调试末期做一次导出，对照报警表把软元件注释过一遍。
有个小技巧：GX Works3 里可以直接把注释复制粘贴到 Excel 批量编辑，再导回去。硬件接线表在 Excel 里维护的团队尤其适合这个方式，IO 注释先从 Excel 整列生成，再批量导入工程，省掉逐条打字。
5. 快速上手：从样板到实际设备的移植流程
样板做得再好，到了新项目还是要做一次"移植手术"。移植不是复制粘贴就完事，而是有一套固定操作流程，照做能避开大量隐性坑。
5.1 第一步：建立 IO 映射表，先改地址不改逻辑
拿到设备的电气图纸后，先把图纸上的物理信号填进一张映射表：信号名称、图纸线号、PLC 输入或输出地址、对应样板里的逻辑用途。满表之后，逐条把样板里的 X0、Y0 地址替换成实际地址。
这一步我严格要求只改地址，不改逻辑结构。样板的自动步序、互锁关系、报警逻辑都是经过验证的骨架，任何工艺差异都不应该先动骨架，而是先看能否通过参数和地址适配。比如样板上某个工位用了两步动作，实际设备少了一步，那就先保留空的步序，只把没用的步序对应的输出注释掉，等整体跑通后再清理。
5.2 第二步：调整参数区范围和器件参数
开工程前检查 PLC 参数的软元件保持设置，确认保持区域覆盖了参数区和累计区，且没有覆盖到中间状态区。然后根据 CPU 型号调整保持范围，不同型号的默认保持范围不一样，样板里的默认值不一定适用你的 CPU，这一步必须人工比对硬件手册。
模拟量模块也要在这时确认。样板上模拟量通道默认是 4AD 和 4DA 各一个，实际项目可能是 8 路输入或者没有模拟量，那就把对应读取程序整段禁用，不要让模拟量指令在没有模块的情况下报错。
5.3 第三步：把"三段式调试法"变成流程纪律
移植完成后，首台设备调试我坚持按三段走，不允许跳级：
离线模拟：在 GX Works3 的模拟器里跑一遍完整流程，手动切换自动、跑几个步序、触发报警，确认逻辑状态流转符合预期。这一步能拦住六成低级错误。
输出禁止空机测试：下载程序后，先把输出禁止功能打开，意思是 PLC 逻辑照常跑，但所有物理输出被禁住，外部设备不会动作。这时候在触摸屏上把点动、自动模式全部操作一遍，监视软元件状态变化，确认输出映射区的信号按照预期翻转。
单机联动：解除输出禁止，先手动单步动作，再空机自动循环。空机自动循环至少连续跑 20 个周期无异常，才允许接入真实负载。
这套流程的要点在于：输出禁止和强制监视是现场调试最安全的手段。很多人上来就直接解除输出禁止做联动，结果逻辑里的一个互锁写反，气缸直接顶出去，轻则撞夹具，重则伤设备。用输出禁止把逻辑层和物理层切开，是成本最低的安全保障。
5.4 移植中最常见的三个"注意"
移植中还有一些小坑，我单独列出来：
- 触摸屏地址要和 PLC 一致。样板上 HMI 变量已经按 G_ 标签或者软元件地址映射好了，新项目如果改了地址，触摸屏组态同步改，否则看起来"通信正常"但按钮点了没反应。
- 备用地址不要移作他用。样板预留的备用输入输出和备用 D 区，在任何情况下都不得被临时程序占用。一旦占用，下个项目继承样板时会多出一堆看不懂的残留逻辑。
- 首次下载前做好程序备份。GX Works3 工程文件、导出的注释、参数配置各存一份，命名带上项目号和日期。调试期一天改三版是常态，没有备份就只能靠记忆回滚。
6. 高级玩法：ST 混合编程、FB 封装、内置定位和通信扩展
样板程序满足基本设备控制需求之后，我一直在往里面塞"高级模块"，让样板不只是入门框架，还能直接支撑中型自动化设备。
6.1 梯形图为主、ST 为辅的混合编程
GX Works3 里同一个工程可以同时使用梯形图和结构化文本。样板的骨架部分我用梯形图，因为现场电工和维护人员对梯形图最熟；但数学运算、批量数据处理、通信报文解析这类逻辑，梯形图写起来又长又难改，我改用 ST。
举一个滤波算法的例子。模拟量采集值抖动大，不能直接用，需要在程序里写滑动平均：
// 模拟量滑动平均滤波，每 10 个扫描周期输出一次平均值 IF bReset THEN SumVal := 0; CntVal := 0; END_IF; SumVal := SumVal + RawAnalog; CntVal := CntVal + 1; IF CntVal >= 10 THEN AvgAnalog := SumVal / 10; SumVal := 0; CntVal := 0; END_IF;梯形图写这段循环累加很别扭，ST 几行就搞定。关键在于，ST 程序和梯形图程序在同一个任务里顺序执行，数据可以直接复用软元件和标签，不需要做复杂的接口转换。
用 ST 的另一个场景是数组处理。多段温度数据求最大值、把一组报警字按位拆成独立标志，这类逻辑在 ST 里可以写成循环，梯形图只能展开重复写。样板里我把所有报警字的位解析统一改用 ST，报警数量增加时只改数组长度，不用把梯形图复制十遍。
6.2 FB 功能块：把电机、阀门、轴封装成可复用积木
FX5U 在 GX Works3 里支持功能块（FB）和结构化文本函数，这是高级玩法里投入产出比最高的一项。
我在样板里封装了一组常用 FB：
- FB_MotorControl：电机启停控制，输入有启动、停止、过载反馈、复位，输出有运行中、故障、启动许可。内部做好了启动互锁、故障保持、复位延时。
- FB_ValveControl：阀门控制，带开到位、关到位、超时报警，可以适配单电控或双电控阀门。
- FB_AxisMove：单轴定位控制，输入轴号、目标位置、速度、加减速时间，输出定位中、定位完成、报警。
FB 的好处是，内部逻辑只写一次，实例化多个副本时各自占用不同的内部软元件区域。比如设备上有四台电机，就调用四次 FB_MotorControl，每个实例的名字是 FB_Motor_1 到 FB_Motor_4，内部互锁逻辑完全一样，但端子接线和参数相互独立。程序里不再是四段几乎相同的梯形图，而是四个 FB 调用，可读性一下子提升很多。
封装 FB 要注意一个原则：FB 内部不要直接访问物理地址。所有物理 IO 应该从外部通过输入输出参数传给 FB，这样 FB 才能在不同设备上通用。比如电机启动按钮的地址变了，只需要在调用 FB 时改传参，FB 内部一行不动。
6.3 内置定位功能：FX5U 晶体管型的高速脉冲轴
FX5U 晶体管型 CPU 支持内置高速脉冲输出，可以直接驱动步进或脉冲型伺服，定位相关指令在 GX Works3 里集中配置。
样板中轴控制的分层是这样的：触摸屏或 SCADA 给出"目标位置、速度"两类参数，写入参数 D 区；PLC 逻辑判断轴当前状态和允许条件后，触发定位启动指令；定位完成后回读完成标志，再进入下一步工艺。
接线层面，脉冲信号和方向信号要接到伺服驱动器的对应端子，原点信号接到高速计数或中断输入端子，具体端子号和通道号在样板注释里留了醒目提醒。很多新手容易在"脉冲信号接了但方向信号没接"这种问题上卡住，只要两路信号一起检查就很快。
多轴运动时，样板里强制要求"轴间互锁"。意思是任何时候不能直接对所有轴同时发启动指令，而是先判断各轴状态，确认全部就绪后再启动，防止两台伺服带着工件互相撞。
轴数超过 FX5U 本体能力时，不要硬塞。高复杂度轨迹插补、CNC 类应用已经不是 FX5U 的定位范畴，老老实实换运动控制器，样板的通信区可以过渡衔接，但不要在 FX5U 上极限压榨，安全性和稳定性都不划算。
6.4 以太网和 Modbus TCP：让上位机和设备轻松对话
FX5U 自带以太网口，样板上直接把 Modbus TCP 从站功能配好。设备区的 D 寄存器映射到 Modbus 地址，触摸屏、上位机通过网口直接读写，不用额外加协议转换模块。
我习惯把通信数据分成三个区：只读区、可写区、命令区。只读区放运行状态、报警、产量、实时温度，上位机和触摸屏只能读；可写区放参数设定值，比如速度、温度上下限；命令区放启动、停止、复位指令，上位机对命令区写入之后由 PLC 侧判断条件再执行。
三块区分开极大减少了通信冲突。如果所有数据都放在一个区，上位机一顿乱写，可能会把运行状态覆盖掉，出现"明明在运行，触摸屏却显示停止"的诡异现象。分区虽然牺牲了一点地址连续性，但换来的是稳定和可排查性。
对于远程维护，FX5U 的以太网口配合适当的路由配置，可以让厂商远程连到 PLC 上做监控和程序上下载。注意远程维护的安全策略需要提前规划好，不要裸奔到公网，至少做一层访问控制。
6.5 数据记录和简单报表：用样板积累产量的过程数据
FX5U 支持 SD 存储卡和部分数据记录功能，样板里我把关键数据做了周期搬运：产量、运行时间、报警时间戳、温度曲线，通过 ST 程序写入内存缓冲区，再由通信区统一上传到上位机或触摸屏保存。
如果上位机没连，可以在触摸屏上做简单的记录查询，数据源还是 PLC 的 D 区。样板程序在注释里写明了这些数据区的刷新周期和用途，上位机开发工程师拿到注释表就能对接，不用反复问地址。
7. 现场多年攒下来的调试验证经验：让样板程序真正扛住生产
这一章写一些没写在手册里的东西，都是实际项目里踩出来的。样板程序框架合理只是一方面，真正能扛住生产考验，靠的是细节。
7.1 一个定位到崩溃又极其经典的"偶发停机"
说一个我印象很深的排查过程。那台设备运行时偶尔停止，有时一小时一次，有时半天一次，没有任何规律。报警区显示的是"互锁条件不满足"。
一开始怀疑是某近接开关松动，重新紧固后故障依旧。然后在 GX Works3 里对装置状态做了长时间监视，最终发现是触摸屏组态里一个"启动按钮"的地址和 PLC 里"运行中标志"的地址重合了。操作员按触摸屏时，上位机把运行中状态瞬间改成 0，互锁条件断掉，设备停下，但 100 毫秒以后触摸屏又被 PLC 刷新回 1，所以肉眼根本看不出来。
这类问题的排查思路是：先确认报警区里的具体条件，再逐条回看这些条件依赖哪些地址，最后检查这些地址有没有被通信区或触摸屏重复占用。样板里通信区做只读/可写区隔离的原因就在这里，如果当初没隔离，这类故障会更难查。
7.2 强制输出和输出禁止的使用纪律
我见过不止一次调试人员用 GX Works3 强制功能去试输出，结果把继电器控制的气缸给顶出去了。原因是强制功能直接绕过程序逻辑，把 Y 点锁死为 ON，而此时输出禁止未必开启。
样板程序里配了一个专门的"输出禁止开关"软元件，调试时先把它置 ON，程序里的输出映射区就会整体封锁。在这个前提下做强制操作，物理输出不会动作，只会看到软元件状态变化。
现场调试的默认姿势是：先开输出禁止，再做任何强制操作，确认无误后解除输出禁止。这个习惯必须从样板程序使用第一天就养成，不然迟早出事。
7.3 在线修改之后，注释和程序神同步的问题
GX Works3 支持在线修改，调试效率很高。但有个隐蔽问题：在线修改时有时只改了梯形图，忘了改注释，或者注释改了但程序没保存。等第二天重新打开工程，屏幕上显示的程序内容和注释对不上，人就会陷入"信程序还是信注释"的困惑。
我的做法是每轮在线修改结束，立即把工程文件另存一个新版本，命名方式带日期时间。等到整个调试期结束，再把最新版本导出全部注释，和报警表、IO 表做一次联合检查，确保注释里没有残留的旧信息。
7.4 掉电保持带来的"复原"陷阱
前面说过保持区和非保持区要分开，这里再补一个实际案例。某设备参数放在保持区，步序放在非保持区，理论上断电再上电后步序清零，设备应该从初始状态开始。结果上电后设备直接执行了"前进"动作，因为是初始化区没把某个中间标志清干净。
问题出在：步序清零了，但输出映射区使用的缓存标志没有跟着清，而这个缓存标志恰好放到了保持区。所以样板初始化区里我增加了一段**"强制全复位清单"**，把输出映射缓存、步序缓存、报警瞬态标志全部列出来，上电后统一复位，一条都不能少。这个清单每个项目都要检查一遍，新加的中间变量如果忘了进清单，下次就会重现这个坑。
7.5 与上位机通信时最容易忽视的"时间戳"
Modbus TCP 通信时，上位机一般需要知道 PLC 的数据有没有更新，尤其是故障状态这种关键信息。样板里单独维护了一个"数据刷新计数器"，每扫描一次加一，上位机只要发现这个值没有变化，就知道链路或程序出了问题。
这比上位机直接判断数据本身更可靠。因为故障状态在复位之后会归零，光看状态值无法区分"设备正常"和"通信中断导致数据冻结"。数据刷新计数器是个永远增长的软元件，一眼就能看出通信是否活着。
现在再回到样板程序这件事上。一个真正可复用的样板，交付时最重要的不是梯形图本身，而是那几张映射表和注释清单。工程文件会变，软元件地址会换，但"哪个区管什么、每个标志符怎么命名、调试时第一步看哪里"这些规矩不会变。我希望每个拿到这套 FX5U 样板的开发者，都能少走半年弯路，把精力花在解决设备本身的问题上，而不是永远在对地址、猜注释、翻旧程序。
