PLC工程师必看：90条实战经验，从红绿灯到宕机排查一次讲透
做PLC这行，头三年是最容易产生“我好像会了”的错觉，又最容易在设备面前被现实教育的阶段。我在一线做自动化这些年，把入行以来踩过的坑、翻过的车、调通的项目整理成了90条实战经验，每天更新一条。这篇先不动那90条的完整清单，而是把大家搜得最多、问得最频繁的部分挑出来展开讲，包括红绿灯和电梯程序怎么写、SCADA和触摸屏怎么连、PLCSIM为什么启动不了、现场PLC宕机怎么查、大棚灌溉和包装线项目怎么搭。内容偏实操，带基础原理，也带排查顺序，适合刚入行一两年、正在被项目追着跑的工程师，同样适合准备转行做PLC的朋友提前避雷。
1. 先聊聊前三年的坑：这90条经验是怎么攒出来的
1.1 入行1-3年最容易踩的三种坑
结合我接触过的工程师和自身经历，前三年遇到的绝大多数问题可以归成三类：编程上“逻辑没想清楚就写”，通讯上“协议没搞明白就接”，调试上“没按顺序排查就乱改参数”。这三类问题的共性在于，它们都不是设备本身坏掉了，而是思路没理顺。
编程类最典型的就是定时器混用。很多人写十字路口红绿灯，上来就一串TON定时器串联，最后一个定时器复位第一个，看着能跑，一旦中途切换模式或者扫描周期不稳定，状态就乱了。通讯类最典型的是不知道对方设备支持什么协议，拿着Modbus TCP去连只支持S7协议的设备，折腾半天还对不上。调试类最典型的是一上来先怀疑PLC坏了，把程序清了重新下载，结果问题还在，最后发现是传感器NPN/PNP接错了。
所以90条经验我的整理方式是：按场景分类，一条解决一个具体问题，每条都附上“我当时是怎么发现的”和“下次怎么做能避免”。这样写不是为了凑数量，而是让你在遇到问题时真的能翻到对应条目。
1.2 90条经验的整理方法和使用建议
这90条我是按场景标签来分的，标签包括“编程逻辑”“通讯连接”“仿真调试”“品牌选型”“行业应用”五大类，日常遇到问题就按标签去查。每天更新一条，其实是逼自己把一个模糊的经验讲清楚，而不是停留在“当时搞定了”的层面。
建议你也建立自己的经验库，哪怕只是记在手机备忘录里。格式就三条：现象是什么、原因是什么、操作步骤是什么。重点写“原因”。很多工程师记笔记只记“换了个模块就好了”，这等于白记，因为下次遇到同样现象还是不知道怎么定位。
使用这90条经验时，我的建议是不要死记条目的结论，要理解背后的排查顺序。比如仿真起不来，原因可能是安装路径、许可证、版本不匹配、虚拟化冲突，如果你只记住“重装软件”，那换个机器还是不会排查。理解顺序，比记住结论重要得多。
2. 编程逻辑类：红绿灯、电梯和时间锁机
2.1 十字路口红绿灯程序：套路和反直觉的坑
十字路口红绿灯是PLC入门最经典的题目，但我在面试和带新人时发现，十个人里有八个会掉进同一个陷阱：用定时器串联实现状态切换。比如东西绿灯亮10秒，然后用定时器触发东西黄灯，再触发南北绿灯。这种做法在小程序里确实能跑，但存在两个隐患。
第一个隐患是刷新时序。定时器在扫描周期内是边扫描边刷新的，如果同一个定时器既被输出条件引用，又在后面被复位，就会出现一个扫描周期内的状态不一致，表现在实际设备上就是某个灯闪了一下或者跳变了一下。第二个隐患是扩展性差，一旦要加夜间模式、手动模式、故障闪烁模式，这种状态链就非常难改。
我推荐的写法是状态机方式。先把运行状态划分成几个固定阶段：东西绿、东西黄、南北绿、南北黄、全红过渡，用一个整数变量（比如步号）来记录当前处于哪个阶段。每个阶段的持续时间放到独立的定时器里，定时时间到就切换步号，步号变了就执行对应输出。核心逻辑是“步号决定输出，定时器决定切换”，而不是“定时器直接连输出”。
三菱FX系列的写法，步号用M或D寄存器，配合四个TON型定时器（T0-T3），每个定时器对应一个阶段。西门子S7系列用SCL写更直观，一个CASE语句加四个TON定时器搞定。如果你用的是CODESYS系的PLC，思路一模一样，只是定时器块换个名字而已。
另外一个容易忽略的点是安全要求。十字路口红绿灯的PLC程序，在调试阶段和实际运行阶段的要求完全不一样。实际使用中必须有全红时间，就是两个方向都红灯，给路口清空留出时间，否则绿灯直接切换容易出事故。某些交通项目还要求绿闪功能，就是绿灯结束前闪3秒，这个用定时器加沿检测实现。
2.2 四层电梯控制：呼梯信号和方向仲裁
四层电梯是比红绿灯高一个档次的经典练习项目，也是很多面试官喜欢问的题目。很多人一听到电梯就觉得难，其实PLC实现电梯控制，核心不是电机，而是三个逻辑问题：呼梯信号怎么记、方向怎么选、到站怎么停。
先说话呼梯信号。每一层的上呼、下呼（顶层没有上呼，底层没有下呼）以及轿厢内选层信号，都必须用电保持的方式锁存起来。三菱系列用SET/OUT加自锁，西门子用SR触发器。不能用普通的输出线圈直接连按钮，因为按钮松开信号就丢了。呼梯请求到达后，要一直保持到电梯真正响应停车才能复位。
第二个是方向仲裁。电梯运行方向不是按“当前最远的楼层”来决定的，而是按“运行方向前方是否有请求”来判断。举个例子：电梯在一层，三层有人下呼，二层有人上呼，电梯应该先顺路上行接二层，再停三层，而不是直接冲到三层再回来。这个逻辑用程序写就是先检查同方向前方请求，有就保持当前方向，没有再看反方向是否有请求，都没有就停在当前层。
第三个是平层停车。光电开关或平层感应器给出平层信号后，程序要先停抱闸再开门，顺序不能反。我在调试电梯类教学设备时吃过一次亏，程序里先开门再给停车指令，结果轿厢溜了一下，虽然实验设备没人，但如果是真的电梯，这就是大事。顺序一定是：收到平层信号、断开运行输出、启动抱闸、确认速度为零、再开门。
写四层电梯程序，我建议先用流程图把各个状态画清楚，再动手写。不要直接在一个FC里堆IF语句，拆成“呼梯登记”“方向判断”“运行控制”“到站处理”四个功能块，每个块单独调试，联调时问题会少很多。
2.3 时间到期自动停机：别用临时比较，要用电保持加锁存
热词里有一条“PLC怎么设置时间到期自动停机”，这是设备租赁、分期付款、项目尾款场景里非常常见的需求。实现方式不复杂，但有个关键点：停机条件必须断电保持，不能断电之后重启就失效。
西门子S7-1200/1500的常规做法是读取CPU的系统时间，用READ_RTC或者TIA里直接读写系统时间块，跟设定的截止时间做比较。比较结果一旦成立，就置位一个断电保持的M位或DB位，同时把这个位串到主回路输出控制里。注意这个置位动作本身要考虑保持性，掉电保持区要在硬件配置里勾选保持性，或者用保持型M区地址。
三菱FX系列的做法也类似，用比较指令CMP比较当前时间和设定时间，结果通过SET指令置位一个带电池保持的M继电器，再把这个M常闭点串到输出使能回路里。
容易踩的坑有三个。一是很多PLC默认的系统时间不准，开机后需要手动校准或者用WRITE_RTC写入时间。二是时间比较要考虑边界，直接比较“当前时间大于截止时间”是会有漏洞的，更好的写法是先转成字符串或统一到秒级时间戳再比较，避免日期格式错位。三是停机动作一定要做自锁，最好还能在触摸屏上显示停机原因，比如“使用期限已到，请联系服务商”，不然客户不知道怎么回事。
2.4 AI辅助PLC代码生成：能用，但不能盲用
热词里出现“AI PLC代码生成”，这个我也试过。现在用AI生成PLC程序，对结构化文本（SCL）和ST语言确实有不错的效果，比如给AI一段需求描述“红绿灯东西绿10秒，黄3秒，南北绿10秒，黄3秒，全红2秒”，它能给你生成一个基本可用的SCL框架，省掉不少敲代码的时间。
但我的使用体会是，AI生成的代码只能当参考草稿，不能直接下载到PLC里。原因是AI不懂你的PLC品牌、IO映射、模块地址、安全规范，它只会按通用逻辑给你拼一段语法正确的东西。比如它可能生成一个TIA里不存在的函数，或者变量名用了中文导致编译不过，更麻烦的是它完全不会考虑急停、安全回路、互锁这类现场必需的逻辑。
我的建议用法是分两步。第一步，让AI生成整体框架，你拿来对照自己的思路，看看有没有漏掉的状态，这个过程有点像代码评审。第二步，把AI生成的SCL粘贴到TIA里，逐个功能块手改，把IO地址换成实际的，把安全逻辑补上。这样既提升了编框架的效率，又保证了程序的可靠性。
3. 通讯与上位机：SCADA、触摸屏、第三方读取
3.1 SCADA与PLC连接：先分清协议再动手
PLC和SCADA的连接，是项目里最常被新手问到的。首先要明确一点：SCADA本身不是通讯协议，它是上位机软件，要靠具体的通讯协议和PLC对话。常见的组合有三种。
第一种，西门子自家SCADA（比如WinCC）连西门子PLC，直接用S7协议，不需要额外转接，配置时只要填PLC的IP地址、机架号、槽号就行。第二种，第三方SCADA连西门子PLC，如果SCADA支持S7协议那就直接用，不支持的话就要走OPC UA，或者通过MODBUS TCP。第三种，SCADA连三菱、汇川、信捷这类PLC，多数走MODBUS TCP或各家的专用协议，比如三菱的MC协议。
我在现场见过最多的坑，是大家把IP ping通了就以为通讯没问题。其实IP通只代表网络层通，应用层协议不对照样连不上。排查通讯问题，我的顺序是：第一步确认物理链路，第二步确认IP能ping通，第三步确认PLC侧通讯参数，比如Modbus从站地址、波特率、数据格式，第四步确认SCADA侧变量地址映射，第五步才考虑防火墙和端口问题。
另外，SCADA画面的变量刷新率不是越高越好。有些人喜欢把刷新周期设到100毫秒以内，结果画面上所有的数值都流畅了，但PLC的通讯负载上去了，导致PLC扫描周期被拉长。这个在后面讲C#读取频率时还会展开。
3.2 C#读取PLC频率：轮询周期怎么定
热词里有一条“C#读取PLC频率多少”，这其实是上位机开发中一个非常实际的问题。用C#读西门子PLC，常用的是Sharp7或者S7.NET库，本质都是走S7协议。读频率不是随意定的，它取决于你的业务需求和PLC的通讯负载之间的平衡。
我的经验是：一般性的数据显示和状态监控，200毫秒到500毫秒的轮询周期足够用。因为人眼看到画面数值的刷新，超过10帧每秒就没有明显差别了。如果你要记录生产数据用于统计，可以做到100毫秒。如果要做运动控制级别的实时同步，那就别走普通S7通讯了，那是另一个技术路线，不是轮询能解决的。
高频轮询带来的问题是会拖慢PLC的程序周期。西门子S7-1200的通讯负载是由CPU统一处理的，你每50毫秒发起一轮读取请求，CPU就会频繁处理通讯任务，这时候你会发现PLC里本来5毫秒跑完的程序，被拉到了十几毫秒。所以我对现场工程师的建议是，先确认业务真的需要那么高的刷新率，再确认CPU选型的通讯能力，最后才确定轮询间隔。
还需要注意批量读取。C#读多变量时，别一条一条读，尽量把地址连续的变量打包成一个请求，用S7库的DB读取函数一次读一整块，再在C#侧解析。这样能大幅减少通讯报文数量，刷新频率也可以相应降低，整体效率反而更高。
3.3 触摸屏找不到驱动：威伦通加汇川、MCGS加信捷的排查
热词里有“威伦通触摸屏软件上怎么找不到汇川PLC的驱动啊”，这是汇川和威伦通组合时的经典问题。汇川的PLC分两大体系：AM系列是CODESYS生态，用InoProShop编程；Easy系列是AutoShop编程。对应的触摸屏驱动是不一样的。
威伦通EBPro软件里，新建装置时厂商列表里找“INVT”（汇川的英文品牌名就是INVT），然后型号里面会列出AM系列和Easy系列对应的驱动。如果列表里根本没有汇川，大概率是EBPro软件的版本太旧，需要更新到新版驱动包。另外，连接参数里要选好COM口或者以太网地址，通讯协议要和PLC侧的设置对齐。
MCGS和信捷的组合也是类似的逻辑。信捷XD系列本身就支持Modbus RTU/TCP，所以最稳妥的做法是在MCGS里直接用通用Modbus驱动，把信捷PLC当Modbus从站来连。只要PLC侧把通讯参数配好：从站地址、波特率、数据位、校验位、寄存器映射，上位机就能读。直接用信捷专用驱动也行，但通用Modbus驱动在某些情况下反而更稳，因为少了很多专用驱动的版本兼容问题。
这类问题本质上都一样：触摸屏和PLC是两个品牌的产品，它们之间没有“自动识别的魔法”，只有通过双方支持的协议才能对话。排查时先确认PLC支持哪些协议，再确认触摸屏驱动列表里有没有对应项，最后看参数是否一致。
3.4 变频器与PLC、松下、倍福、Keba的通讯特点
ABB变频器和西门子PLC的组合也很常见。ABB变频器支持Modbus RTU、Profibus DP、Profinet等多种通讯方式。如果是走Modbus RTU，需要在变频器参数里设置从站地址和通讯波特率，然后PLC侧用Modbus主站指令去读写变频器的控制字和状态字。控制字用得多的是ABB的系列标准控制字，比如启动、停止、使能，状态字用来读运行频率和故障码。
松下PLC的通讯设置，老用户比较熟悉的是MEWTOCOL协议，新一些的FP系列也支持Modbus。用FPWIN Pro配置时，要在系统寄存器里把通讯协议设置为MEWTOCOL或MODBUS，然后设置从站号、波特率、校验方式。松下FP系列有些型号是通过编程口、有些是通过扩展通讯模块，别选错通讯通道。
倍福PLC用的是TwinCAT，本质上是把Windows环境变成实时控制系统。刚开始接触倍福的人会不习惯它的“非PLC式”开发方式，所有IO都要通过EtherCAT端子映射到变量。倍福连上位机反而简单，因为它自带ADS通讯协议，也支持OPC UA，和SCADA对接很顺。
Keba这个品牌被问到“Keba是什么PLC”，很多人第一次在项目里看到会觉得陌生。Keba是奥地利一家自动化控制器厂商，在注塑机、机器人集成的周边控制里用得比较多，它自己的开发环境叫KeStudio，语言风格和CODESYS类似，硬件形态常和伺服驱动系统集成在一起。如果在现场遇到Keba设备，别慌，先看它的通信接口支持什么协议，绝大多数情况下都能用Modbus TCP或OPC UA和上位机对接。
4. 仿真与调试：PLCSIM为什么启动不了、PLC宕机排查
4.1 S7-PLCSIM启动不了且没有报错：问题出在实例和版本
“S7-PLCSIM Advanced V5.0 PLC实例启动不了且没有报错”这个搜索词，我一看就想起自己第一次用PLCSIM Advanced时的经历。TIA自带的S7-PLCSIM和单独的S7-PLCSIM Advanced是两套东西，很多人把二者混为一谈。
S7-PLCSIM是基本的仿真器，直接点开始按钮就能仿真程序。但S7-PLCSIM Advanced是一个基于虚拟机技术的仿真环境，它需要你先手动创建虚拟PLC实例，类似在VMware里新建一台虚拟机，然后指定PLC型号、IP地址，启动实例之后，TIA里的下载目标才会出现这个虚拟PLC。很多人以为“启动不了”是软件坏了，其实只是没创建实例。
创建实例时要注意版本匹配。PLCSIM Advanced V5.0对TIA博途的版本有要求，不是所有TIA版本都能配合使用。如果TIA是V15，PLCSIM Advanced V5.0基本没问题；如果TIA是V17以上，可能需要更新版本的PLCSIM Advanced。另外，安装路径不要带中文或空格，这在西门子全家桶里尤其重要。
4.2 PLCSIM Advanced报Error 11：虚拟化冲突排查
PLCSIM Advanced报Error 11，这个错误码很多人在搜索日志里见过。根据我的实际操作经验，Error 11绝大多数和虚拟化环境冲突有关，比如你本机装了Hyper-V、VMware、VirtualBox，或者Windows的Device Guard/Credential Guard占用了虚拟化资源，这会让PLCSIM Advanced无法正常创建仿真环境。
排查顺序我可以给你一个明确的步骤。第一步，打开Windows功能，看Hyper-V、虚拟机平台、Windows虚拟机监控程序平台是否开启，如果开启且你平时不用，可以关闭并重启。第二步，检查BIOS里的CPU虚拟化（Intel VT-x或AMD-V）是否开启，这是PLCSIM Advanced运行的基础。第三步，卸载或退出其他虚拟机软件。第四步，重新启动PLCSIM Advanced，以管理员身份运行，然后重新创建实例。
另外，PLCSIM Advanced对网络配置也有要求，它会自动创建虚拟网卡，如果系统里默认网卡被禁用或者策略限制，也可能出现启动失败但没明显报错。这时候在设备管理器里看虚拟网卡是否正常，如果有黄色感叹号，把网卡禁用再启用一次。
4.3 现场PLC宕机：几个高频原因和定位顺序
热词里直接有“导致PLC宕机”，说明这问题在现场真实发生过不少次。PLC运行中突然停机、模块SF灯亮、或者整个CPU进入STOP状态，常见原因有三个。
第一个是大电流干扰或接线错误导致模块损坏。比如把220V串进了24V信号回路，或者感性负载没有加续流二极管，导致瞬间高压冲击CPU模块。这种问题硬件的痕迹会比较明显，模块上有烧灼点或异味，但有时候表面看不到，需要量电压判断。
第二个是程序原因导致CPU进入STOP。我遇到最多的是除零错误、非法地址访问、数组越界，还有无限循环导致看门狗超时。这类问题在TIA和三菱软件里都能通过诊断缓冲区看到停机原因。排查时不要先改程序，先看CPU的诊断信息，它会明确告诉你停机前最后一个事件是什么。
第三个是通讯阻塞。PLC长时间被大量网口请求轰炸，比如上位机每秒读几百个变量，或者有人用测试工具一直发ARP广播，占满了PLC的通讯处理资源，CPU即使程序还在运行，也会有类似“宕机”的表现。定位方式是断开网线看PLC是否恢复，如果断开就正常了，那就是通讯侧的问题。
我处理这类问题的固定顺序：先看PLC面板指示灯，判断是Power问题、Run问题还是SF问题；再看诊断缓冲区，拿到停机原因；再用排除法区分硬件问题和软件问题，比如拔掉所有IO模块看能否运行；最后才是动手修改。
5. 品牌生态：三菱、汇川、松下、ABB、AB的一些经验
5.1 老设备三菱FX2与FXGP/WIN：兼容模式与串口选择
热词里有一条很具体：“三菱老式PLC——FX2编程软件FXGP/WIN Win7/8/10/XP.zip”。FXGP/WIN是当年给三菱FX系列编程的经典软件，现在很多老设备维护项目还在用它。但它在Win7、Win8、Win10上经常出现安装不了、打不开、无法通讯的问题。
我的经验是，安装时右键选择“以兼容模式运行”，兼容性模式选Windows XP（Service Pack 3），这一步能解决绝大多数安装报错。然后是通讯问题，老设备大多走串口编程线，如果你用的是USB转串口线，优先选CH340或者FTDI芯片的线，并把Windows设备管理器里的波特率设置和PLC侧保持一致，常见是9600或19200。
另一个比较容易踩的坑是，FXGP/WIN的下载线型号很讲究。FX2编程口是圆形8针口，和FX3U的编程口虽然长得像，但引脚定义不一定一样，买线的时候一定要问清支持FX2还是FX3U，买错了插上电脑根本找不到设备。
5.2 汇川AM/Easy与CODESYS生态
汇川这几年在国产PLC里占有率上升很明显。AM系列走的是CODESYS路线，编程软件是InoProShop，界面和CODESYS几乎一样，支持ST、梯形图、FBD几种语言混用。很多人第一次接触汇川AM，最大的感受是“这就是一个封装好的CODESYS”，所以如果你之前玩过倍福TwinCAT、欧姆龙NJ，上手汇川AM基本没有障碍。
Easy系列走的是另一套生态，编程软件是AutoShop，指令风格更像三菱，用起来很亲民，适合替代传统小型PLC。选型时一定要注意：AM的工程文件用InoProShop打开，Easy的工程文件用AutoShop打开，两者不能互通。项目经理在方案阶段如果写“汇川PLC”而不写具体系列，后面采购、编程、调试都会出问题。
汇川和威纶通通讯时，AM系列要选INVT的CODESYS以太网驱动，Easy系列要选对应的串口或以太网驱动。汇川和MCGS通讯时，优先走Modbus协议，稳定而且驱动通用。
5.3 AB PLC里遇到不认识的指令：SWJ的排查思路
“美国AB公司PLC中SWJ指什么”，这个热词说明很多人在看AB老程序时会遇到不认识的指令。AB的PLC型号体系比较多，从老的SLC500、PLC-5到现在的ControlLogix、CompactLogix，每个体系里都有一些“冷僻指令”。
SWJ不是AB PLC里的常用指令，不同处理器甚至不同版本固件里的含义可能有差异。遇到这种情况的正确做法是别猜，去翻对应机型的指令集参考手册（Instruction Set Reference Manual），AB的官方文档网站可以按处理器型号检索指令列表。直接把SWJ这个助记符放进去搜索，通常能找到它的操作数说明和功能描述。
这件事给我的体会是：PLC工程师在调试老外的设备时，不能只靠“看程序猜逻辑”。老设备里的冷门指令非常多，很多程序连注释都没有。看不懂的指令就去查对应处理器的指令手册，这比在论坛上问更靠谱。同时，排查程序逻辑时应该先看整体架构（哪些是主流程、哪些是故障处理），再针对具体指令深挖，效率会高很多。
5.4 西门子PLC输入输出接线：源型漏型与NPN/PNP先认清
“西门子PLC输入输出接线”是一个看起来基础、但实际坑了很多人无数遍的话题。西门子S7-200 SMART、S7-1200的数字量输入点有两种接线方向：源型和漏型。
这里我先说清楚概念。源型输入对应的是PNP传感器，信号高电平有效，电流从信号端流入输入点；漏型输入对应的是NPN传感器，信号低电平有效，电流从输入点流出到传感器。很多人把NPN传感器接到源型输入点上，怎么调都不出信号，其实就是接反了。
接线前先看PLC接线的公共端标记。有的输入模块公共端是1L+，输入点标注是I0.0到I0.x，传感器是PNP的就直接把信号线接到输入点，传感器正极和PLC公共端一起接24V正。传感器是NPN的，公共端接法就反过来了。这个搞错之后，轻则信号不触发，重则烧毁传感器或者输入模块。
输出侧也一样。继电器输出型PLC比较皮实，交直流都能带；晶体管输出型只能带直流负载，而且必须注意是源型输出还是漏型输出。驱动电磁阀时，如果是直流电磁阀，一定要在线圈两端反向并联续流二极管，不然断电瞬间的反向电动势会打坏输出点。这个问题在老工程师看来不算事，但新入行的工程师经常会忽略。
6. 行业项目实战：大棚灌溉和自动包装线
6.1 基于西门子PLC的大棚灌溉：传感器、PID和手动/自动切换
“基于西门子PLC大棚灌溉”是农业自动化里很典型的项目，技术含量并不低，适合作为入行1-3年工程师练手和述职的项目。整体结构是：传感器采集土壤湿度、温湿度、光照、流量，PLC做逻辑控制和PID调节，触摸屏或组态软件做监控，输出控制电磁阀、水泵、施肥机。
项目设计的第一步是划分控制场景。大棚灌溉不是简单“湿度低了就开阀”，而是要考虑一天中的不同时段、植物不同生长期的用水需求、以及雨天停灌等外部条件。我的建议是程序里至少分三种模式：自动模式、手动模式、检修模式。自动模式下，PLC按照内环闭环控制逻辑运行；手动模式供调试和应急使用；检修模式必须能在触摸屏上一键锁定所有输出，防止喷灌突然启动淋到检修人员。
灌溉控制的闭环逻辑，推荐的做法是用土壤湿度作为主反馈，加上一个简单的液位/压力保护。很多新手一上来就上PID，其实灌溉系统惯性很大、滞后明显，PID参数调不好反而震荡。我更推荐的做法是区间控制：湿度低于下限就开阀，达到上限就关闭，中间加一个滞后区间避免阀门频繁启停。这个思路比PID简单，而且在农业灌溉场景下效果足够好。
剩下的工作重点在IO规划和通讯上，传感器用4-20mA模拟量输入，电磁阀用继电器输出，触摸屏通过Modbus TCP和S7-200 SMART通讯。IO规划时一定要预留一倍余量，因为农业项目通常后续还要补充传感器和控制点。
6.2 自动化包装线控制系统：节拍是灵魂
基于PLC的自动化包装线控制系统，是另一个经典项目类型，也是很多工厂改造项目的常客。包装线通常由供料、称量/灌装、封口、贴标、剔除等工位组成，每个工位之间有传送带衔接，PLC负责整线的节拍控制和设备互锁。
这类项目在设计时，第一件事不是画梯形图，而是画节拍时序图。每个工位什么时间动作、动作持续多久、哪个传感器到位后触发下一个工位，要把这些先画清楚，再开始写程序。没有节拍图就直接写程序的项目，后期调试一定乱成一锅粥。
第二件事是防堵料逻辑。包装线上最有价值的程序不是让它顺利运行，而是在堵料时能停下来，在恢复时能自动接着跑。每个工位之间都应该有积料检测，传送带上某个区域堆积过多时，前级工位要自动暂停或减速。这个逻辑没有的话，包装线一分钟堵三次，操作工叫苦连天。
第三件事是报警分级。不是所有报警都值得停线。比如贴标机标签用完，这在很多生产场景下是可以继续跑完当前产品再停的，属于提示级报警；而封口温度异常可能造成整批废品，必须立刻停线，属于停机级报警。程序里要对报警分优先级，再决定输出动作。
包装线项目的程序框架，我建议每个工位一个FB块，工位之间用全局变量或者中间标志位传递状态信息。这样做的好处是，某一个工位要调整动作时，不用去翻主程序里乱七八遭的触点，改对应的FB块就行了，而且每个工位都能单独下装调试。
6.3 这类项目怎么沉淀成经验
做完一个大棚灌溉或者包装线项目，如果只在脑子里记着“我做完了”，那等于白做。我的习惯是项目结束一周内，趁细节还没忘，把项目资料整理成三份：第一份是IO清单和设备清单，第二份是程序架构和关键算法说明，第三份是调试过程中遇到的所有问题和解决方案。
这套资料的意义在校招面试和加薪述职时体现得非常直接。面试官问“你做过什么项目”，如果你只能回答“做过一个大棚灌溉”，那印象分很低；如果你能说“我解决了土壤湿度滞后导致的阀门频繁启停问题，用了滞后区间控制，阀门动作频率从每5分钟一次降到每30分钟一次”，这就完全是两个水平了。
这也是为什么我坚持把经验写成90条的原因。经验的价值不在于数量，而在于你能不能在里面找到解决问题的路径。前三年积累下来的每一条经验，都是后面承接大项目、带新人的底气。
7. 写在最后：一点实际体会
我自己的习惯是，每处理完一个故障，就在本子上写三条：现象是什么、定位过程是什么、最终解决的改动是什么。写完再看一遍，如果能用一句话讲给别人听懂，这条经验就算真沉淀下来了。这90条经验就是这么攒出来的，后面还会继续更新，遇到具体问题搜对应关键词就行。
最后再分享一个小技巧：PLC工程师在调试时，手里一定要有一个小本子或者手机备忘录，记录每一个传感器的当前状态、每一个报警的触发条件。很多疑难故障不是一次定位出来的，而是经过几轮观察、对比、排除之后才找到原因，而这几轮观察的数据，如果不随手记录，很容易就忘了。把数据记下来，把过程写下来，你会发现自己三年后回头看这些记录，很多东西原来早就遇到过。