我是程致衡，在华东一片汽车零部件产业园里做自动化集成已经第10个年头了。我的日常工作，说直白点，就是把一堆“冷冰冰的设备”和“脾气各异的工人”协调到一起，用一行行PLC程序，撑起一条条生产线别停、少报错、多赚钱。
很多人搜“plc编程实例”，心里往往有两个愿望：
这篇文章，我就不讲故事，不卖关子，从一个行业从业者的角度，把这些年踩过的坑、写过的典型PLC编程实例，拆给你看：哪些是真能在工厂里跑起来的，哪些只是课堂上的幻觉，以及你要怎样把“看得懂程序”变成“撑得住项目”。
很多人第一次接触plc编程实例，是这样的：三盏红黄绿灯，一个定时器，两段互锁逻辑，几条注释——清爽又标准。
现实工厂里呢？拿我去年做的一个项目说，一个“很普通”的汽车零部件装配线：
- 22台电机
- 18个气缸
- 4套视觉检测
- 120多个传感器
- 三个品牌的变频器混搭
- 上位有MES系统要拉数据
这条线的PLC程序，大致是这样一个格局：
- 设备层：进料、输送、压装、锁螺丝、检测、下料，每个工位一套节拍控制逻辑
- 安全层：互锁、急停、安全门、安全光栅
- 诊断层：故障报警、历史记录、参数调整
- 通讯层：和变频器、扫描枪、视觉、MES对话
而用户最关心的，往往只有一句话：“停机率要低于3%，不良率控制在1%以内。”这就是现实项目和“教程级实例”的差别——不是看梯形图写得漂不漂亮，而是看它支撑的指标能不能交付。
当你再看“plc编程实例”这五个字，心里可以加一个前缀：“能帮助我达成产能/良率目标的”plc编程实例，才有学习价值。
很多初学者会问我：“我已经做过交通灯控制、液位控制、变频调速、步进序列了，怎么还是接不住公司里的项目？”
原因很简单：你练的是“动作”，工厂需要的是“系统”。
拿一个最常见的plc编程实例：多工位自动装配线举例，我给你拆成几个你可以直接对照的“关卡”。
动作层级：
- 控制一个气缸伸缩
- 控制一个电机启动停止
- 做一个简单的顺序：伸→压→回
工站层级：
- 进站检测（有无物料、型号对不对）
- 测位定位（光电/气缸到位）
- 加压/拧紧/点胶等工艺动作
- 结果判定（OK/NG）
- 出站互锁（上游不给，下游堵塞怎么办）
产线层级：
- 全线启动/停止策略
- 堵料逻辑：任意工位出问题，前后怎么联动
- 异常优雅退出：设备在中间状态停机，怎么安全复位
- 报警与追溯：报什么、怎么报、报到哪
你会发现，教科书式的plc编程实例，经常停留在动作层；而工程项目晋级的关键，是你要学着去设计工站层、产线层的逻辑。
这也是很多人学PLC几年卡壳的地方——梯形图会写，但完整的“状态逻辑”不会想。
说个实践中极高频的场景：多工位顺序控制。比如一条简单的输送+装配线：A工位上料，B工位压装，C工位检测，D工位下料。
在真实项目里，这个plc编程实例的核心难点，有三个：
- 节拍怎么压
- 故障怎么停
- 恢复怎么起
一个比较稳妥的工程写法，思路大致是：
给每个工位设计一个“状态寄存器”，比如：
- 0：待机
- 1：等待来料
- 2：加工中
- 3：待出料
- 4：故障中
所有动作逻辑，都挂在“状态→条件→动作”上，而不是简单的输入→输出：
- 状态=1 且“前一工位OK信号”、当前工位到位传感器=1 → 进站
- 状态=2 且“工艺时间到”且“压力/扭矩合格” → 状态跳到3
- 状态=3 且“下游允许” → 出站并清除本工位标志
故障策略：
- 任意关键条件异常，状态跳到4，输出强制关闭
- 报警记录错误码+时间+工位号
这样的plc编程实例有几个好处：
- 逻辑清楚，便于日后改工艺
- 一看状态就能知道设备在干什么，方便排查
- 适合和上位机、MES做数据交互
在2026年很多新建产线的招标文件中，你会看到类似的要求：“需提供完整状态机逻辑、故障码定义及与MES交互说明。”这不是甲方“矫情”，而是工业数字化的基本要求。
你在看任何一个plc编程实例时，不妨问问自己：这个示例，是否在刻意训练“状态思维”？如果没有，尽量别把全部时间砸在上面。
从业这些年，我慢慢发现一个规律：真正优秀的plc编程实例，往往具备三个特征：
- 把安全当作入口条件，而不是附加条件
- 把节拍当作约束，而不是简单延时
- 把维护当作日常，而不是故障后的补救
拿安全来说。一个看起来“能跑”的程序，很可能只是把安全回路接在安全继电器上，然后在PLC里做少量互锁。但真实工程里，我们更关注的是：
- 安全门打开时，是否存在“安全停止类别”的设计
- 紧急停止后，系统能否记住“设备停在什么状态”
- 安全信号和普通信号有没有混乱使用
再说节拍。2026年，不少汽车零部件工厂的规划中，常见节拍要求是：
- 单工位节拍：18–25秒
- 整线OEE目标：75%–85%
- 停线时间占比：低于3%
具体到plc编程实例，你就要考虑：
- 用定时器“粗暴延时”会不会放大节拍离散
- 是否要根据传感器反馈自动缩短多余延时
- 是否要将关键节拍数据上传到MES或SCADA，让工艺工程师可以分析瓶颈
维护方面也是。很多传统PLC程序，报警只有一句：“设备故障，请联系管理员。”这在现在基本顶不住一条有产能压力的产线。一个更实用的plc编程实例，报警逻辑会做得细腻得多：
- 报警分级：提示、一般故障、严重故障
- 报错界面上直接给出“可能原因+检查位置”
- 历史报警至少保留最近1000条，可导出
你在网上遇到的plc编程实例，如果完全没有触及安全、节拍、维护这三块，就可以把它归类为“入门练手”，而不是“工程参考”。
这几年做项目，有个很明显的变化：以前调试完PLC，只要机器自己能跑就行；现在甲方常见的一句话是：“数据能给我吗？我要接到我们的平台上去。”
这直接改变了plc编程实例的形态。
在2026年的新项目里，你会频繁遇到这些要求：
- 支持OPC UA或MQTT这种标准协议，与上层系统对接
- 关键过程数据（扭矩、位移、压力、温度）要有采集与追溯
- 报警、停机原因要分类统计，用于后续OEE分析
我们给某家新能源电机厂做的项目，产线要求：
- 每支电机至少记录20个过程参数
- 每个参数带时间戳和条码
- 所有数据在10秒内可从MES查到
这意味着，原本一个“电机测试工位”的plc编程实例，不再只是：“启动测试→采集结果→合格/不合格”。而是要额外考虑：
- 与测试仪通讯协议（Modbus/TCP、Profinet等）
- 结果数据打包、缓存、重发机制
- MES下发的参数配方如何安全切换
你在练习plc编程实例时，可以刻意加一点“数据味道”：
- 多设计几个工艺参数的配方切换
- 多增加一些数据采集、统计、平均值、极值的逻辑
- 模拟一段“简单的上位机读写”过程这些能力，在2026年的招聘需求中，是被明确写进JD的。许多自动化工程师岗位，都会标注：“了解OPC UA或其他工业通讯协议者优先。”
说到这里，很多人心里大概有一点数了：网上那些五花八门的plc编程实例，有一大半是给你练手感、熟悉指令的，能直接搬进工厂现场用的并不多。
站在一个工程狗的角度，我更建议你带着目的去挑：
目的一：搞清楚“状态机思路”
- 选多工位顺序控制、自动生产线、自动往返小车等实例
- 在每个实例里，强迫自己画出状态转换图
目的二：练“异常处理”
- 专门找带报警系统的plc编程实例
- 看它遇到传感器失败、气缸不到位、急停时，逻辑如何处理
目的三：适应“工程项目结构”
- 寻找完整工程案例，而不仅仅是一两个功能块
- 仔细拆它的程序结构：主程序、子程序、FB、报警、通讯是怎么分的
目的四：提前适应“联网与数据”
- 有余力时，找一些涉及Modbus/TCP、OPC UA、Profinet通讯的例子
- 即便没有真实设备，也可以通过模拟软件理解基本流程
你搜“plc编程实例”时，可以留心一些关键词组合：
- “plc编程实例 自动化产线 状态机”
- “plc编程实例 报警诊断 OEE”
- “plc编程实例 OPC UA 通讯”这样的搜索结果，往往更接近工程环境，而不是纯粹教学。
在行业里久了，看plc编程实例的习惯，会悄悄发生变化。刚入行时，我会盯着指令表、标准的网络划分，琢磨写法优不优雅。这几年，我更在乎的是这些问题：
- 这个实例有没有明确的设备目标？
- 有没有考虑安全、节拍、维护？
- 是否表达了一种可重复、可扩展的思路？
如果你正在转行做自动化，或者已经在工厂里干，只是对PLC这一块还不太有底气，希望你在看“plc编程实例”的时候，给自己设定一个更高的标准：
“这个实例，能不能让我离真正独立撑起一个项目更近一点？”
当你从这个视角出发去挑选、拆解、复刻plc编程实例时，你会发现，那些过去看着挺复杂的项目，慢慢也就变成了一堆可以拆开、可以重组的模块。
那时，你写的就不再只是代码，而是一条条每天都在吐出合格产品的产线。而这，恰好是我们这些自动化工程师，最有成就感的时刻。
