前面第15讲，我们把手动、自动、急停、复位这些模式逻辑讲透了。
那一讲解决的是一个“设备规则怎么搭”的问题：

手动和自动怎么互斥
急停和复位怎么分层
自动允许链怎么建立
模式切换时状态怎么交接
为什么很多程序不是不会跑，而是运行规则没设计清楚

但 PLC 程序写到一定阶段以后，很多工程师真正开始头疼的，往往还不是“某个逻辑不会写”，而是另一个更现实的问题：

程序越来越长，越来越乱，能跑，但看不懂；想改，但不敢改。

你会发现，很多 PLC 程序前期其实都挺顺。
因为项目小，I/O 点不多，逻辑简单，几页梯形图就能跑起来。
可一旦设备复杂一些，内容开始变多：

有手动逻辑
有自动逻辑
有报警逻辑
有模拟量处理
有参数设定
有通讯数据
有多个电机
有多个气缸
有多个步骤
有模式切换
有急停、复位、延时、计数、联锁

这时候，如果程序还是“一路往下堆”，很快就会出现下面这些典型症状：

找一个输出，翻半天找不到在哪儿控制
改一个条件，不知道会影响哪几段逻辑
这边加了一个报警，那边突然起不来
程序下载后能跑，但接手的人根本看不懂
自己隔一周再回来，也得重新找半天
一个动作相关的逻辑散在十几页里，排查特别累
现场临时改一点小东西，却越改越怕

这些问题背后，很多时候不是你不会写梯形图，
而是你还没有真正建立起一个很重要的工程能力：

程序结构化。

这一讲，我们就把这个特别关键、也特别能拉开水平差距的点真正讲透：

主程序是什么
子程序是什么
功能块是什么
为什么程序要分段
怎么分才合理
怎么让程序不仅能跑，还能看、能改、能接手、能扩展

如果说前面几讲更多是在讲“单个逻辑怎么写”，
那么这一讲讲的就是：

这些逻辑写出来以后，怎么把它们组织成一套像样的工程程序。

这一步非常关键。
因为 PLC 工程师真正往上走，不只是会写，而是会“组织程序”。

一 先把最根上的问题讲清楚：为什么很多 PLC 程序会越写越乱

很多初学者刚开始写程序时，脑子里通常是这样的节奏：

先写启动停止
再写一个定时
再加一个报警
再补一个联锁
再加一个模式
再补一段手动
再加几条报警
再写一段模拟量
再加个延时
再补个按钮功能

每次看起来都只是“补一点”，
可补着补着，程序就慢慢变成了这样：

这边三页是启动逻辑
后面两页又补了停止条件
中间一页夹着报警
再后面又有一个输出被另外一段逻辑控制
手动和自动交叉在一起
参数处理和动作控制混在一起
某个气缸伸出逻辑在前面，缩回逻辑在后面十页
一个故障位先在前面置位，后面两段又各自复位

程序能不能跑？
有时也能跑。

可问题是，它已经不再像一个“工程程序”，
而像一堆逻辑碎片被硬拼在一起。

所以程序越写越乱，根本原因通常不是“代码太多”，
而是：

没有一开始就把不同层次、不同功能、不同对象的逻辑分开。

也就是说，不是你写得不够努力，
而是你没有给程序建立结构。

二 什么叫程序结构化

先别把这个词想得太玄。

所谓程序结构化，说白了就是：

把程序按照清晰的规则拆成不同部分，让每一部分只负责一类事情。

比如：

模式逻辑放一块
报警逻辑放一块
模拟量处理放一块
通讯处理放一块
某个电机的控制放一块
某组气缸的动作放一块
自动步骤放一块
参数处理放一块

再进一步，还可以继续细分：

主程序负责总调度
子程序负责某一组功能
功能块负责某一个通用对象或标准动作

这样做的目标不是好看，
而是为了四件特别实际的事：

好找
好改
好查
好扩展

你以后要慢慢建立一个习惯：

程序结构不是为了写给 PLC 看，
是为了写给“未来的自己”和“接手这个项目的人”看。

PLC 只要逻辑对，它不在乎你程序漂不漂亮。
但人很在乎。
维护人员更在乎。

三 为什么“能跑”不等于“程序写得好”

这个观念一定要建立起来。

很多初学者，甚至一些做了一段时间项目的人，也容易落入一个误区：

能跑就行

这句话在调试初期有时能理解，
因为先把设备跑起来当然重要。
但如果你把“能跑”当成程序质量的唯一标准，后面一定会吃亏。

因为 PLC 程序不是一次性用品。
它往往会经历：

现场调试
客户变更
追加功能
修改动作
补报警
改参数
加通讯
再维护
再升级
再复制到同系列设备

这意味着一个程序真正的价值，不只是今天能跑，
而是：

明天还能不能改
下个月还能不能查
一年后别人还能不能接手

所以“好程序”的标准，至少要包括这些：

逻辑正确
结构清楚
注释清楚
分段合理
变量命名清楚
扩展不容易崩
排查不至于满世界乱翻

也就是说：

程序质量 = 运行正确 + 结构清楚 + 可维护。

这一讲，我们主要讲的就是后面这两项。

四 程序为什么要分段，最直接的好处是什么

先不讲主程序、子程序这些术语，
咱们先讲最直观的感受。

假设你有一个设备，里面有这些内容：

系统模式
全局联锁
4 台电机
6 个气缸
1 套自动步骤
报警系统
触摸屏参数
2 路模拟量
1 路变频器通讯

如果你全部按写到哪儿算哪儿的方式去堆，
很快就会看不见逻辑边界。

而如果你一开始就分段，比如：

第一段 系统模式与全局允许
第二段 手动逻辑
第三段 自动逻辑
第四段 电机控制
第五段 气缸控制
第六段 报警逻辑
第七段 参数与配方
第八段 模拟量处理
第九段 通讯逻辑

那么后面无论你自己排查，还是别人接手，都会轻松很多。

所以程序分段的最直接好处就是：

1 找东西快

想看报警，就去报警段。
想看模式，就去模式段。

2 改东西不容易误伤

你不会为了改气缸动作，顺手把通讯处理也碰乱。

3 排查更有方向

设备不启动，先查模式段、全局允许段、自动启动段，思路很清楚。

4 团队协作更容易

一个人查报警，一个人查动作，彼此不容易打架。

所以程序分段不是“高级写法”，
它是很实用的工程习惯。

五 什么叫主程序

先把最基础的概念讲清楚。

主程序，你可以简单理解成：

整个 PLC 程序的总入口、总框架、总调度层。

也就是说，PLC 一运行，通常最先进入的就是主程序。
主程序决定：

先处理什么
后处理什么
哪些子程序要被调用
哪些公共条件要先整理
哪些功能模块要统一调度

所以主程序不是一定要“写很多逻辑”，
它更像是程序的大骨架。

你可以把主程序理解成一栋楼的大堂。
真正具体的房间在里面，
但所有人都先从大堂进入，
而且大堂决定你往哪边走。

一个成熟主程序常见会放什么

系统初始化
模式逻辑
全局安全与联锁
全局允许条件
子程序调用顺序
重要公共数据处理
关键全局状态监控

也就是说，主程序更偏向“总控层”，
而不是把所有细节动作都塞进去。

六 什么叫子程序

子程序可以简单理解成：

从主程序里拆出去，专门负责某一类功能或某一块设备逻辑的程序段。

比如：

手动控制子程序
自动流程子程序
报警处理子程序
模拟量处理子程序
通讯处理子程序
输送机构子程序
上料机构子程序
下料机构子程序
某工位控制子程序

子程序的意义是什么？

就是把本来会把主程序挤得很乱的大块逻辑，拆出去单独放。
这样主程序就不会变成一条几百页的逻辑长街。

子程序最典型的价值

第一，按功能拆分
第二，按设备单元拆分
第三，按对象拆分
第四，按流程阶段拆分

你可以把子程序理解成“专门房间”。
主程序是大堂，
子程序是不同功能区的房间。
这样人一进来，就知道哪块逻辑在哪儿。

七 什么叫功能块

功能块这个概念，再往前走了一层。

你可以简单理解成：

把某一类经常重复使用、结构相似的逻辑，做成一个可以重复调用的标准模块。

比如：

一个电机控制块
一个气缸控制块
一个报警处理块
一个 PID 处理块
一个模拟量缩放块
一个延时确认块
一个故障锁存块
一个手自动阀门控制块

如果你项目里有很多台电机，
每台电机都要做：

启动允许
运行命令
故障反馈
热继保护
运行状态
故障报警
手自动控制

那你当然可以每台电机都手写一遍。
但如果你会做功能块，就可以把“电机控制的共性结构”封成一个标准模块，
不同电机只传不同的输入参数进去。

这样做的好处非常大：

逻辑统一
不容易漏项
修改一处可复用
同类对象风格一致
扩展时更快

所以功能块更像是“标准件”，
而主程序和子程序更像是“总装结构”。

八 主程序、子程序、功能块，到底是什么关系

这个地方很多人容易混，咱们讲清楚。

主程序

负责总框架、总调度、总入口

子程序

负责某一类功能或某一部分设备逻辑

功能块

负责某一类可复用对象或标准化控制单元

用一个很通俗的比喻来说：

主程序像总导演
子程序像不同部门
功能块像各部门里通用的标准工具

比如一个自动化设备：

主程序里先处理模式、安全、总允许
然后调用子程序：

手动子程序
自动子程序
报警子程序
通讯子程序

而在自动子程序或手动子程序里面，
又会用到很多功能块：

电机功能块
气缸功能块
延时确认功能块
故障锁存功能块

你这样理解，层次就会特别清楚。

九 程序到底应该按什么思路分段，最常见有三种方式

这是特别实用的一段。

程序分段不是只有一种标准答案。
工程上常见有三种主要思路。

第一种 按功能分段

也就是按逻辑类别分。

例如：

系统初始化
模式控制
全局联锁
手动控制
自动控制
报警处理
参数处理
模拟量处理
通讯处理
数据显示与统计

这种分法的好处是：

同类逻辑集中
排查功能类问题很方便
适合中小型设备

比如设备不自动启动，
你大概就知道先看模式、联锁、自动控制段。
不会满程序乱翻。

但它也有一个特点：
如果设备有很多相同对象，比如 20 个气缸、10 台电机，
光按功能分，有时还是会觉得对象太散。

第二种 按设备单元分段

也就是按机械模块或工位分。

例如：

上料单元
定位单元
夹紧单元
加工单元
下料单元
输送单元
成品剔除单元

每个单元里面再放自己的：

输入处理
动作逻辑
联锁
报警
状态输出

这种分法特别适合多工位、多机构设备。
因为一看就知道哪个单元的逻辑在哪儿。

比如某个下料机构不动作，
你就重点看“下料单元”那一组。
不用先把全局所有气缸逻辑都翻一遍。

这种方法很贴近机械结构，
对现场调试和维修特别友好。

第三种 按对象类型分段

比如：

所有电机一组
所有气缸一组
所有阀门一组
所有模拟量一组
所有报警一组

这类分法在对象数量多、控制方式相似时也很常见。
例如一台输送设备里有很多电机、很多阀，
你按对象来归类，也会很清楚。

这种分法的优点是：

同类对象逻辑风格一致
很适合配合功能块
后期复制和扩展方便

十 哪一种分法最好？不是固定答案，关键是“同一个项目要统一”

这个特别重要。

很多程序乱，不是因为你选错了某一种分法，
而是因为你今天按功能分一点，
明天按单元分一点，
后天又按对象分一点，
结果整个项目没有统一原则。

于是就会出现：

模式按功能放
气缸一半按单元放，一半按对象放
报警又单独抽了一块
有些延时写在动作旁边，有些又写在公共区
结果别人完全摸不清你的脑回路

所以最重要的不是“唯一正确答案”，
而是：

你这个项目采用什么结构，要前后一致。

一般来说：

中小型设备，按功能分就很好用
多工位设备，按单元分更直观
对象数量特别多且结构标准化，按对象加功能块会更强

很多成熟项目其实会混合使用，
但它也不是乱混，
而是有层次的混。

比如：

主程序按功能组织
子程序按机械单元拆
单元内部再调用对象功能块

这种就是很成熟的结构。

十一 为什么程序结构的第一步，不是“会不会调用子程序”，而是先把逻辑层次分开

很多人一听结构化，就立刻想到：

我要不要学子程序
我要不要学功能块
我要不要搞很高级的封装

其实真正的第一步，没那么复杂。

第一步是：

先把不同层次的逻辑分开。

比如至少先分出这些层：

模式层
全局联锁层
运行允许层
动作控制层
报警层
参数层

如果这一步都没做，
就算你会子程序、会功能块，程序也未必就清楚。
因为你只是把混乱从一张纸搬进了好几个盒子里。

所以结构化的起点不是“会不会高级语法”，
而是“会不会先把逻辑分类”。

这个观念特别重要。

十二 一个成熟程序，通常至少要分出哪几层

这一段特别实用。
以后你接项目时，可以直接拿来做脑图。

第一层 初始化层

上电初始化
首次扫描
默认值加载
掉电恢复检查

第二层 模式与全局状态层

手动自动
急停
复位
系统待机
系统待复位
系统总允许条件

第三层 公共输入处理层

按钮处理
上升沿下降沿
输入消抖
公共状态整理

第四层 参数与模拟量处理层

工程量换算
参数限制
配方装载
修正值
模拟量滤波

第五层 设备动作控制层

电机
气缸
阀门
加热
风机
泵
执行机构控制

第六层 自动流程层

步骤推进
步骤条件
流程切换
阶段锁存

第七层 报警与故障层

故障判定
报警锁存
报警恢复
停机保护
报警显示位

第八层 通讯与数据交换层

HMI 数据
变频器通讯
仪表通讯
上位机数据交换

第九层 统计与辅助层

产量
节拍
运行时间
故障次数
维护计时

你不一定每个项目都这么全，
但脑子里有这个层次感，程序就不容易乱。

十三 为什么“一个输出的所有直接控制来源尽量集中”特别重要

这个属于程序结构里非常实战的一条原则。

比如某个输出 Y0 是一台输送电机。
它可能受这些东西影响：

手动按钮
自动步骤
急停
停止按钮
故障锁存
安全门
热继保护

如果你把这些东西散在程序各处，
一段写手动启动，
一段写自动启动，
一段又在后面直接复位 Y0，
再后面又来一段故障切 Y0，
那后期排查会特别难。

更好的做法通常是：

先把各种来源整理成内部状态位
最后在相对集中的位置，统一决定 Y0 到底该不该输出

也就是说：

命令分散可以
最终输出决策尽量集中

这样你要查 Y0 为什么不动作，
或者为什么误动作，
就会快很多。

这其实也是一种结构化。

十四 子程序最适合拿来拆什么内容

很多人问，子程序到底什么时候值得用。
其实有几个特别典型的场景。

1 大块独立功能

比如报警、通讯、模拟量处理、配方处理。
这些内容逻辑相对独立，很适合单独拆出去。

2 某个完整机械单元

比如上料单元、搬运单元、夹紧单元。
每个单元都有自己的一套输入、动作、联锁、报警。

3 自动流程特别长

如果自动步骤特别多，可以按流程阶段拆成多个子程序。
例如准备段、加工段、收尾段。

4 可重复调用但又没必要做成完整功能块的内容

有些逻辑比较完整，但复用程度没有高到做成标准功能块，
也可以先用子程序管理。

所以子程序最适合处理的是：

大块、清晰、相对独立的功能。

十五 功能块最适合拿来做什么对象

功能块特别适合“长得像”的东西。

比如：

10 台电机
8 个气缸
6 个阀门
4 路模拟量缩放
12 个报警锁存
多个同类型输送段

这些对象逻辑结构相似，只是地址不同、参数不同。
这时候功能块就特别有价值。

例如一个标准电机控制块，可以包含：

启动命令
停止命令
运行反馈
故障反馈
热继保护
故障锁存
手动允许
自动允许
运行状态
故障状态

以后每台电机都调用同一个结构，
只换输入输出变量。

这样会带来两个特别大的好处：

第一，一致性特别好

每台电机逻辑风格一样，现场很容易看懂。

第二，扩展特别快

新增一台电机，不用重新从头写一套，直接套标准件。

所以功能块最适合处理：

标准化程度高、重复出现多次的对象。

十六 为什么很多初学者程序不好维护，不是不会分段，而是“分了也没边界”

这句话很关键。

有些程序看起来也分了很多页，
但维护起来还是很乱。
为什么？

因为“页面分开”不等于“边界清楚”。

比如：

第一页叫手动控制
第二页又偷偷写了一半自动逻辑
第三页叫报警
里面又顺手写了两个动作输出
第四页叫电机控制
中间又夹了一些模式判断

这说明虽然形式上分页了，
但逻辑边界没守住。

所以真正好的分段，不只是“标题写得好看”，
而是：

这个段只做它该做的事
不轻易越界
跨界条件尽量通过内部位衔接，而不是直接乱插

也就是说，结构化不只是分目录，
还是守边界。

十七 一个特别实用的原则：上层逻辑决定资格，下层逻辑决定动作

这句话非常适合 PLC 结构化。

例如：

模式层决定当前是不是自动
全局联锁层决定当前有没有资格动作
运行层决定当前有没有运行命令
动作层才真正去控制电机、气缸、阀

也就是说：

上层不直接写具体动作
下层不负责决定大规则

你一旦这样分层，程序就会清爽很多。

比如一个气缸伸出逻辑，
动作层不要直接去判断：

是不是自动
是不是手动
是不是急停
是不是故障
是不是安全门正常
是不是系统待复位

这些上层资格最好前面就整理好。
动作层只看：

当前有没有伸出命令
当前伸出是否允许

这样层次就干净了。

十八 注释和命名，为什么本质上也是结构化的一部分

很多人把注释和结构分开看，
其实它们是一体的。

因为结构化的目标就是：

让人快速理解。

如果你程序分了段，但变量命名乱、注释没有、说明不清，
别人还是很难懂。

好的命名会直接体现结构

比如：

M100 自动模式
M101 手动模式
M110 系统总允许
M120 自动运行命令
M200 输送电机1运行命令
M210 输送电机1故障锁存
D300 压力实际值 乘1000
D310 压力启动值 乘1000

你看，这种命名一看就有层次。

好的注释会直接降低维护难度

例如：

这一段负责系统模式切换
这一段负责自动允许运行链
这一段负责输送1电机控制
这一段负责报警锁存与恢复
这一段负责压力换算及上下限报警

这其实就是在把你的结构明明白白告诉后来的人。

所以不要把注释理解成“可有可无的装饰”。
它是结构化落地的一部分。

十九 一个完整小案例：小型自动送料设备的程序怎么分段更合理

咱们用一个很贴近现场的小设备来举例。

设备功能

有手动、自动
有一个输送电机
两个气缸
一个检测光电
一个报警蜂鸣器
一套简单自动流程
一个触摸屏参数页
几个报警

一种比较合理的分段方法
第一部分 初始化与首次扫描

上电清临时位
清运行命令
进入待机

第二部分 模式与全局允许

手动自动切换
急停
复位
系统总允许
待复位状态

第三部分 公共输入处理

按钮上升沿
光电输入消抖
公共输入状态整理

第四部分 手动控制

手动输送
手动气缸1
手动气缸2
手动蜂鸣测试

第五部分 自动流程

步骤 1 等待来料
步骤 2 输送定位
步骤 3 气缸1 动作
步骤 4 气缸2 动作
步骤 5 完成返回

第六部分 单体动作控制

输送电机输出逻辑
气缸1 输出逻辑
气缸2 输出逻辑

第七部分 参数与定时

延时参数
步骤时间
计数参数

第八部分 报警处理

来料超时
动作不到位
气压异常
急停报警
蜂鸣器逻辑

第九部分 HMI 数据交换与显示

运行状态显示
步骤显示
报警状态显示
参数写入

你看，这样一个不算很大的设备，只要结构清楚，
后面找逻辑和改逻辑都会舒服很多。

二十 再往上一步：如果是大型设备，怎么做会更稳

大型设备往往更不能靠“一个总程序往下堆”。

更合理的做法通常是：

主程序

只保留总框架
初始化
模式
全局联锁
关键公共状态
各子程序调用顺序

子程序

按单元拆：

上料单元
搬运单元
装配单元
检测单元
下料单元
报警单元
通讯单元
配方单元

功能块

按标准对象拆：

电机块
气缸块
阀块
报警锁存块
模拟量换算块
延时确认块

这样层次就非常清楚：

主程序管全局
子程序管单元
功能块管对象

你会发现，这几乎就是一套工程化的软件结构思想，
只是放在 PLC 里而已。

二十一 为什么“复制粘贴型编程”后期特别容易出问题

这个问题现场特别普遍。

很多人做 PLC，图快时最常用的方法就是：

这台电机逻辑写好了
复制一份
改几个地址

这个办法能不能用？
短期当然能用。
很多项目初期也确实离不开复制。

但问题在于，如果你没有结构意识，
复制出来的东西很容易带着旧问题一起复制。

比如：

旧注释没改
旧互锁条件漏改
旧报警名没改
一个地址改掉了，另一个相关地址忘了改
一段逻辑里还有原设备名称
原来某个特殊条件不适用于新对象，却也被一起复制过去

这样复制得越多，隐藏错误越多。

而如果你有功能块或至少有清晰结构，
复制就不再只是“整段搬”，
而是“按标准模板调用”，
错误率会低很多。

所以复制不是原罪，
无结构地复制才是问题。

二十二 一个很实用的自检标准：别人接手你的程序，十分钟内能不能找到关键入口

这个标准非常实战。

你程序写完以后，可以假装自己是一个第一次接手项目的人，问自己：

十分钟内，我能不能快速找到这些东西：

模式逻辑在哪里
急停和复位逻辑在哪里
自动启动条件在哪里
某个电机输出到底在哪儿决定
报警锁存在哪里
参数处理在哪里
自动步骤在哪里
通讯处理在哪里

如果这些入口都很难找，
说明程序结构还不够好。

真正好的结构，哪怕逻辑复杂，
别人也能在短时间内建立地图感。
这就是结构化的价值。

二十三 初学者最容易踩的几个坑

这一段你后面看程序时会特别有感觉。

1 所有逻辑一路往下堆

早期看着省事，后期维护非常难受。

2 分了很多页，但没有真正分边界

形式上分段，实质上还是乱的。

3 手动、自动、报警、输出逻辑互相穿插

导致找一个问题要翻很多地方。

4 一个输出有很多直接来源，散在程序各处

排查特别困难。

5 复制粘贴太多，没做标准化

同类对象逻辑风格不一致，还容易埋错。

6 子程序拆了，但主程序还是什么都塞

结果主程序和子程序边界不清。

7 功能块还没准备好时，先硬上复杂封装

反而把自己绕进去。

8 命名和注释跟不上

分段了，但别人还是看不懂。

9 结构不统一

一半按功能分，一半按对象分，一半按单元分，没有总原则。

10 上层资格逻辑和下层动作逻辑没分开

动作层承担了太多全局判断，程序会越来越乱。

二十四 给初学者一个最实用的落地建议：先做到“三级结构”，就已经很强了

很多人学到结构化，会担心自己一下做不到很高级。
其实不用急。

你哪怕先做到最基础的三级结构，程序质量就会明显提升。

第一级 主程序只放总框架

初始化
模式
全局联锁
调用顺序

第二级 按功能或单元拆子程序

手动
自动
报警
参数
通讯
某个工位

第三级 在子程序内部再按对象分段

电机
气缸
阀门
报警点
步骤段

如果你能稳定做到这三级，
已经比很多“能跑但难维护”的程序强很多了。

功能块可以后面再逐步上。
不要一开始就被“高级感”吓住。
结构化最怕的不是不高级，
而是不清楚。

二十五 本课小结

这一课你最少要真正吃透下面这些点。

第一，很多 PLC 程序越写越乱，不是因为逻辑太多，而是因为没有提前建立结构。

第二，程序结构化的核心，是把不同层次、不同功能、不同对象的逻辑分开，让程序更容易找、改、查、扩展。

第三，主程序更像总入口和总调度层，子程序更像独立功能区，功能块更像可重复调用的标准工具。

第四，程序分段常见有按功能分、按设备单元分、按对象类型分三种思路，没有唯一答案，但同一个项目最好前后一致。

第五，结构化的第一步不是会不会高级封装，而是先把模式、联锁、运行、动作、报警、参数这些逻辑层次分开。

第六，真正好的分段不是只写个标题，而是每一段都有清晰边界，不轻易越界。

第七，一个输出的最终控制来源尽量集中，命令可以分散整理，但最终决策最好相对集中，这样更容易排查。

第八，注释和命名本质上也是结构化的一部分，因为结构化的目标是让人快速理解程序。

第九，初学阶段先做到主程序总框架清楚、子程序按功能或单元拆开、子程序内部再分对象，已经是非常实用的进步。

二十六 学完这一课后，你应该能做到什么

学完这一课，你至少应该能做到这些事情：

知道为什么很多程序不是逻辑错，而是结构乱
知道主程序、子程序、功能块分别适合承担什么角色
知道程序可以按功能、按单元、按对象来分段
知道结构化的核心不是“高级”，而是“清楚”
知道为什么输出控制来源要尽量集中
知道为什么命名和注释不是小事
知道以后再写 PLC 程序时，不该再一路往下硬堆，而要先想程序骨架

如果这些你已经顺了，后面你写出来的程序就不仅是“能跑”，而会越来越像真正能维护、能交接、能扩展的工程程序。

二十七 下节预告

下一课如果继续往下接，我建议可以进入更实战的一段，比如：

PLC 基础课 第17讲
联锁逻辑专题：电机互锁、阀门互锁、前后动作联锁怎么写

因为到这里，前面的模式、状态、分段、结构都已经搭得差不多了，
再往后讲“联锁”，会特别顺，也特别贴近现场。

推荐阅读：

PLC 基础课 第16讲 程序分段与结构化：主程序、子程序、功能块，怎么让程序更好维护

PLC 基础课 第14讲 掉电保持、上电初始化、首次扫描：设备重启后，程序为什么会乱？

PLC 基础课 第10讲 比较指令与区间判断：大于、小于、等于，现场逻辑怎么写更稳妥

PLC 基础课 第9讲 PLC 数据类型与寄存器：位、字节、字、双字，M X Y D T C 怎么分工

PLC 基础课 第 8 讲｜一个完整小项目：水泵控制柜，从电气原理图到 PLC 梯形图

PLC 基础课 第 7 讲｜报警与状态：怎么写出一个好用的报警逻辑 + 保留最后一次故障