接手一套没有注释的程序，变量全是 X0、Y1、M50，难受的地方不是程序跑不起来，而是根本看不出它想干什么。这类程序通常有三个共同点：没有符号表，查故障要对着 IO 表一个个数点位，数错了就满柜子找线；中间继电器从 M0 一路用到 M800，没有分区，两段逻辑撞地址是常事；几千步逻辑全堆在主程序里，没有子程序也没有功能块，改一个动作要翻半天。三样叠加，结果是调试期被拉长，维护时定位靠猜，写程序的人一离职，整套设备就变成黑盒。
现场处理过一台老设备的停机故障，步数不多，但逻辑缠在一起，末了只能把输出分成五段逐个屏蔽，才锁住问题点，单这一步就花了大半天。规范这件事听起来像写文档做样子，实际决定的是调机速度和后续维护要烧掉多少人力。
动手写逻辑之前先做两件事。一件是把物理点全部映射成带含义的符号名，程序里不再直接出现裸地址。命名统一成「部位_动作_性质」的格式，比如气缸 A 伸出写成 Cyl_A_Out，主电机运行写成 Motor_Main_Run，启动按钮写成 Start_Btn。另一件是整理一张 IO 映射表，Excel 存一份、程序注释里存一份，线号与符号能一一对上，查线效率差别很大。
中间继电器和数据寄存器是失控的重灾区，按用途提前划段能省掉大量回头核对：
分区原则是性质相近的放一起、范围宁可留多。后加功能时直接去对应区间领空闲地址，不用翻全篇担心撞车。用标签编程的软件，命名再加类型前缀区分，b 开头是布尔、i 是整型、r 是浮点，截图进文档时一眼能看出类型。
结构上按三层走：主程序做调度，子程序做功能，功能块做复用。主程序只干三件事——上电初始化、按顺序调用各功能子程序、汇总报警。实际的动作逻辑一律不进主程序，避免变成一锅粥。设备动作按机构拆开，上料机构、夹紧机构、分度转盘各是一个子程序，各自只管自己那摊事。
这样拆的直接好处是调试能单独监控某个子程序，出问题知道去哪一段找；新增功能不动老逻辑；多人协作各写各的，合入时冲突面小。功能块这一层要注意实例：同一个块在一套程序里调用多次，每次必须用独立实例。两次调用共用一个实例名，前一次的内部状态会污染后一次，表现就是指令该触发不触发，查半天查不出原因。把运动类、阀类功能块的实例统一纳入对应机构的结构体里管理，一条机构一套实例，从根上避开冲突。
凡是有顺序动作的设备，用状态机而不是一串置位复位往下串。每一步有单独的激活位，靠转移条件驱动当前步复位、下一步置位，任何时候都能回答「现在在第几步、卡在哪个条件上」。曾经在半自动装配线上做过改造，原程序用置位复位一条条串，中间夹着跳转，查断点时误复位了一个关键输出，整线乱套；改成状态机后每一步边界清楚，排查就是看当前步和转移条件。
转移条件建议只用「输入条件 + 延时确认」。气缸伸出到位，除了看磁性开关信号，再加 50~100ms 的滤波延时确认，抖动导致的误判基本消失。完成信号还有一个坑：功能块的 Done 往往只保持一个扫描周期，流程判断稍慢就漏掉，轴明明到了程序却不往下走。做法是给 Done 做置位保持，上层确认收到后再清，流程跳转也尽量用沿触发，而不是直接比瞬时值。
程序体量上来之后扫描周期会变长，高速 IO 的响应跟着变差。处理思路还是结构：主程序只做调度；实时性要求高的逻辑放进定时中断按固定周期跑；初始化这类只执行一次的内容放到上电脉冲里，不要每个扫描周期都跑一遍。调优不要凭感觉，用编程软件的块执行时间监控找出耗时大户，逐个改，扫描周期缩短一半以上是常见结果。
输入侧也要配合。普通按钮的输入滤波 10ms 足够，高速编码器必须走高速输入口；模拟量用屏蔽双绞线、屏蔽层单端接地；24V 感性负载两端并续流二极管，否则关断时的反电动势直接串进输入回路。
还建议把上电自检写成标配：开机先查急停回路是否正常、关键传感器信号有没有冲突、气缸是否在初始位置，全部通过再进待机。这一层逻辑能挡掉相当一部分因开机位置不对造成的撞机。版本管理同样属于结构的一部分，改程序前先导出备份，文件名带版本号和日期，另存一份变更记录写清改了哪个块、为什么改；到现场先做一次程序比对，确认设备里的版本和备份差在哪，再决定动作。
当前位置：
热门课程
