PLC 模块化编程框架全解析：从“散装代码”到“工业乐高”
这是一份基于“老黄自动化”提出的 3层6模块 架构深度拓展的工程实践指南。它将帮助你摆脱“面条式代码”，构建具有高度可维护性和扩展性的工业控制系统。
一、 心智模型：PLC 程序的“行政组织架构” (ASCII)
为了理解这个框架，我们可以把 PLC 程序想象成一家高效运行的工厂：
┌──────────────────────────────────────────────────────────────────┐
│ 第三层：外交部 (外部连接 - Communication) │
│ [模块6：通讯与数据] <───> (MES/ERP, 触摸屏, 其他设备, 数据库) │
└───────────────────────────────┬──────────────────────────────────┘
│
┌───────────────────────────────┴──────────────────────────────────┐
│ 第二层：管理部 (系统调度 - Management) │
│ [模块4：状态管理] <────控制流────> [模块5：报警处理] │
└───────────────────────────────┬──────────────────────────────────┘
│
┌───────────────────────────────┴──────────────────────────────────┐
│ 第一层：生产部 (执行单元 - Execution) │
│ [模块1：初始化] │ [模块2：手动控制] │ [模块3：自动控制(状态机)] │
└────────────────────┴──────────┬──────────┴───────────────────────┘
│
( 物理设备：电机、气缸、传感器 )
二、 场景串联：一台自动贴标机的“一生”
我们通过一台贴标机的运作场景，由浅入深理解这六个模块：
1. 醒来与热身（初始化模块）
- 场景： 早上工厂开电。
- 拟物化： 像运动员赛前拉伸。PLC 检查：急停开了吗？气压够吗？贴标头在原点吗？
- 核心： 确立“安全起点”，清除昨晚没跑完的残余指令。
2. 局部微操（手动模块）
- 场景： 老师傅想测试一下卷标电机转不转，或者气缸顶得准不准。
- 拟物化： 像汽车的“手动挡”模式。
- 核心： 调试专用。注意：即使手动，也得有“互锁”（例如：安全门开着，手动也不能点动）。
3. 全力开火（自动模块）
- 场景： 传送带流过来一瓶可乐，传感器发现后，气缸瞬间下压贴标。
- 拟物化： 像多米诺骨牌。按照 S-F-C（顺序功能图）或状态机一步步走。
- 核心： 状态机算法。第一步干啥，第二步干啥，不跳步。
4. 身份确认（状态管理模块）
- 场景： 机器现在到底是“干活中”还是“偷懒中”还是“生病中”？
- 拟物化： 像红绿灯。给全程序发信号：现在是“自动模式”，手动模块请闭嘴。
- 核心： 避免指令冲突，确保系统唯一性。
5. 紧急抢救（报警模块）
- 场景： 标签卡住了，气缸顶了 2 秒没反应。
- 拟物化： 像工厂的火警器。监测“超时”，一旦出事，立马叫停所有动作并弹窗提示。
- 核心： 安全防护与故障定位。
6. 汇报工作（通讯模块）
- 场景： 厂长在办公室电脑上看今天贴了多少瓶，或者扫码枪把条码传给 PLC。
- 拟物化： 像工厂的秘书。负责打听外部消息，把内部产量报上去。
- 核心： 协议对接（Profinet, Modbus, MQTT）。
三、 知识点与必经之坑 (Markdown)
1. 核心知识点
- 状态机 (State Machine)： 自动控制的核心，用一个变量（如
iStep）记录当前步骤。 - 互锁逻辑 (Interlock)： 比如“手动”和“自动”不能同时使能。
- 上升沿/下降沿： 触发指令的瞬间，防止信号长通导致的逻辑错误。
- 封装 FB/FC： 把重复的动作（如气缸控制）写成标准块，像乐高一样复用。
2. 必经之坑 (Pitfalls)
- 初始化不彻底： 重新启动后，旧的步骤变量没复位，导致机器直接从第 5 步开始跳动（极度危险！）。
- 报警不闭锁： 传感器闪断一下，报警瞬间消失，操作员根本看不见出过什么事。（应做报警保持）。
- 手动控制跳过安全： 很多新手在手动模式下不写急停和限位限制，导致手动调试时撞机。
- 通讯阻塞： 通讯程序写在主循环里且没有超时处理，导致 PLC 扫描周期拉长，动作变迟钝。
四、 核心算法：状态机 (Finite State Machine) 怎么来的？
状态机不是凭空产生的，它源于计算机科学理论。
- 推导过程： 早期工控用“步进继电器”，后来演变为“梯形图”。为了解决“逻辑死锁”和“步骤重叠”，引入了 $Step = n$ 的概念。
- 数学本质： $S_{next} = f(S_{current}, Input)$。即：下一状态取决于当前状态和当前输入。
- 代码体现： 通常使用
CASE...OF(ST语言) 或Jump(梯形图) 实现。
五、 指标意义与生产指导
| 指标 | 意义 | 指导价值 |
|---|---|---|
| 扫描周期 (Scan Time) | 程序跑一圈的时间 | 必须控制在 10ms 以内，通讯模块若太重，需分频处理。 |
| 程序复用率 | 多少代码是直接复制的 | 框架统一后，新项目开发时间可缩短 50% 以上。 |
| 故障定位时间 (MTTR) | 维护人员找到问题的时间 | 结构清晰，报错直接指向“模块 5”，减少停机损失。 |
六、 经典问题 Q&A
- Q：为什么要分层？全部写在一起行不行？
- A： 行，但那是“一次性代码”。分层是为了解耦。客户要换个触摸屏（改模块6），不应该影响到你的气缸动作逻辑（模块3）。
- Q：小项目（几个 I/O）也要用这个框架吗？
- A： 建议用“简化版”。框架是思维习惯，哪怕是小项目，也要分出“手动/自动/报警”，这是职业素养。
七、 最佳工程实践：红黑榜
❌ 反例 (Spaghetti Code)
- 做法： 在自动运行的程序里顺便写了通讯，在报警逻辑里直接写了气缸输出。
- 后果： 增加一个传感器时，发现要改 10 个地方；机器出故障时，不知道是通讯断了还是逻辑卡了。
✅ 正确做法 (Modular Design)
- 定义标准： 所有 I/O 先映射到全局变量（模块 6）。
- 状态隔离：
Manual_Enable和Auto_Enable必须是非此即彼的关系。 - 统一报警： 建立一个专用的报警 DB 块，所有模块的异常都汇总到这里。
- 模块独立： 哪怕没写通讯，也要预留通讯模块的位置，方便后期升级 MES。
八、 如何关联生产？
- 标准化交付： 公司内所有工程师采用同一套框架，A 写的程序 B 能秒懂。
- 模块化调试： 机械还没装好，可以先调试“模块 6”的通讯和“模块 5”的 HMI 界面。
- 快速迭代： 增加新功能（如加个扫码枪）只需在“外交部”（模块 6）加代码，不影响核心“生产部”（模块 3）。
九、 数据来源
- PLCOpen 国际标准： 关于功能块设计的规范。
- ISA-88 / PackML： 国际自动化协会关于包装机械状态管理的标准框架。
- 西门子 TIA 编程指南： 关于模块化和符号化编程的官方推荐。
总结： 框架不是限制你的创作，而是为你搭建了一个安全的舞台。只有在稳固的框架内，你的业务逻辑（工艺算法）才能发挥出最大的生产力。
浙公网安备 33010602011771号