可编程逻辑控制器（PLC）应用实录：从入门到崩溃再到顿悟

昨天半夜被电话吵醒——产线又停了。赶到现场一看，PLC的ERROR灯闪得欢快，HMI上全是乱码。查了半小时才发现，是一个接近开关的信号线被老鼠咬断了……这种事，干过工控的肯定都遇过。PLC这玩意儿，理论学得再好，不到现场被虐几回，根本摸不透它的脾气。说实话，可编程逻辑控制器（PLC）的核心其实就是扫描循环读输入、执行程序、写输出，简单到令人发指。但偏偏是这种简单，让新手老手都容易栽跟头。

我最烦那些培训课，上来就讲什么“PLC是现代工业自动化的大脑”……听着就想打哈欠。大脑？？它就是个脾气古怪的黑盒子，你得顺着它的逻辑来，不然分分钟死给你看。

扫描周期：看不见的杀手

以前帮一个饮料厂改造灌装线，程序写好了离线仿真完美。一上电，气缸就乱打，差点把灌装头撞断。我当时冷汗都下来了……❗ 后来抓心挠肝排查，你猜问题在哪儿？扫描周期。那台破旧的CPU模块，扫描一次居然要20多毫秒。我在程序里设了一个互锁，但逻辑上要跨两个网络扫描完才生效，就那几十毫秒的延迟，两个输出同时为ON，气缸顶牛了。说真的，PLC的扫描机制——先读全部输入，再算逻辑，最后刷新输出——这个顺序是铁律。可很多人写梯形图时根本不管，以为电脑上点个在线修改软件就照你的秒比执行？做梦。那次之后我养成了个习惯：凡是时序要求严的逻辑，一定先估算扫描时间，必要时刻意用立即刷新指令。不过话又说回来，用多了会拖慢整个周期，有点拆东墙补西墙的意思。

I/O模块选型：省小钱惹大祸

还记得去年给一个污水处理项目选型。采购那边图便宜，买了批不知名品牌的16点数字量输入模块。到货后我看着那做工……针脚歪歪扭扭，标签都印歪了。硬着头皮装上，头三个月还行。入夏后湿度一上来，就开始闹鬼：好几个点莫名其妙地闪烁，程序里被这些幽灵信号搞得逻辑乱跳。更可气的是，他们的技术支持电话打了十次都没人接。输入模块的滤波时间常数设得再大都没用，因为根本不是干扰，是内部锈蚀漏电。最后还是我拍桌子，逼着换成西门子的原装模块，世界立刻清净了。✅ 所以啊，如果你在粉尘大、油污重的场合，I/O模块的防护等级一定别妥协。三防漆涂覆、带LED诊断的会贵一些，但比起半夜爬起来处理故障，那点钱真不算什么。

问：数字量模块和模拟量模块接地能接一起吗？
答：千万不要！数字量信号是开关信号，干扰大；模拟量是小信号，容易被干扰。如果两地并一起，你会看到模拟量读数像心电图一样跳。我吃过这个亏，恨不得把当初的接线电工揪回来扇两下。老老实实分开接地，模拟量电缆用屏蔽线，屏蔽层单端接地，这是常识，但总有人忘。

梯形图编程：优雅与糟心的混合体

十年前我狂爱用功能块图，觉得梯形图太老土——密密麻麻的线圈和触点，像极了古董继电器柜的图纸。可现在呢？真香。梯形图对维护人员太友好了，尤其是大半夜出故障，电工师傅能看着图大概猜出问题在哪。有一次我去东南亚调设备，当地的维修工不懂英语，但指着梯形图上的常开触点，用生硬的英文说“This, no good”，我马上明白是传感器没信号。这就是梯形图语言的直观威力。💡 不过坦白讲，碰上复杂运算——比如PID调节、字符串处理——梯形图写得我想骂娘。这时候混编才是王道：主逻辑用梯形图，计算部分用结构化文本，各取所长。但你要注意内存分配，两种语言之间数据交互时，地址重叠是地狱级隐患。我曾经一不小心，把MW100同时用作循环计数器和模拟量中间值，结果泵速忽快忽慢，差点把管道憋爆……教训深刻。

问：为什么在线修改程序有时会失败？
答：在线修改这件事，很多PLC品牌限制挺多的。有时候你改了一个功能块的接口参数，它就不让你在运行中下载，必须停机。最坑的是，你以为下载成功了，实际上部分代码没更新，逻辑还停留在旧版本。我一般都会在修改后先冷启动测试一次，再切回在线。另外，下载前养成备份的习惯，否则一旦同步失败，原程序都丢了，哭都来不及。

当PLC遇上工业4.0：痛并快乐着

这几年到处都在喊OT与IT融合，PLC也得学会上网。给老设备加装工业物联网网关，把数据怼到云平台，听着挺酷吧？实际做起来全是坑。首先，那些用了十几年的PLC，通信口还是老掉牙的485串口，协议乱七八糟——Modbus RTU、Profibus DP，甚至还有自定义的。网关厂家说支持，等接上才发现，地址映射表得自己一条条对，几百个变量呀……我当时熬了三个通宵，眼睛都快瞎了。更气人的是，有些老PLC的数据寄存器是16位的，想传个32位的浮点数还得拼字处理，高低位一旦弄错，显示的温度值能吓死人——锅炉温度显示零下200度，明显字节序反转了。💡 小提示：用OPC UA协议可以省不少事，但前提是你的PLC得支持，不行就上加个协议转换器。现在一部分新PLC直接内置Web服务器，远程诊断爽翻，可黑客风险也跟着来了……我强烈建议，任何联网的PLC都必须藏在VPN后面，别直接暴露公网。上次看到某厂PLC的默认密码都没改，管理员还一脸无辜，“哎呀谁会攻击我们呀”，真让人无语。

问：PLC与PAC到底怎么选？
答：简单任务，点数少、逻辑单纯，PLC就够，性价比高。如果又要运动控制又要视觉又要数据库交互，还是上PAC吧，毕竟编程灵活度和处理能力不是一个量级。但得考虑维护队伍的技术水平，我们之前买过一套高端PAC，最后因为没人能改程序，成了摆设……说起来都是泪。所以，技术选型不单看功能，周边配套和人的因素也得算进去，你说对吧？

最后说句掏心窝的：PLC这门手艺，70%靠现场经验。你看书里不会告诉你，某款CPU的某个固件版本会有随机重启的bug；也不会告诉你，接地不良时通讯线感应电压能烧毁通讯口。这些东西，都是踩出来的。学无止境，但至少别怕弄坏东西——只要安全措施到位，出几次错，反而学得最扎实。谨以此文，安慰那些被PLC折磨过无数深夜的同行们。