入行第14个月我在凌晨三点接到过一通电话。车间主任说传送带停了屏幕上一片红色报警最后补了一句“是不是你那个PLC程序写的有问题”。我赶过去连上电脑一看程序明明在RUN状态输出模块的灯也亮着变频器就是不动。折腾到天快亮才查明白不是程序是通讯线被货架压断了。那一次之后我养成了一个习惯但凡踩过的坑无论大小都记成一条经验按天往下攒。现在我手头一共攒了90条都来自入行这三年里真实碰上、亲手处理过的问题。这个系列我打算每天更新从接线、仿真、通讯、触摸屏驱动到程序结构和宕机排查一条条讲清楚来龙去脉。如果你是1到3年的PLC工程师这些经验应该能帮上不少忙。新手看接线和仿真部分可以少交一些看不见的“学费”做了一年左右的人通讯和上位机那些章节大概率能对号入座两年到三年这个阶段更值得关注的是程序架构和系统宕机的问题。我尽量不写那种“教程式”的套话就以实际干活的口吻说事。1. 为什么我用“一条条记录”的方式复盘头三年的PLC生涯1.1 经验这种东西隔一周不写就真的没了很多PLC工程师都有这个体会现场解决问题那会儿思路特别清晰连线怎么接、参数怎么改、现象怎么反复全都刻在脑子里。但只要回到办公室开个周会再补两天的图纸上个星期那个“灵光一现”的排查思路就模糊了再过半个月连故障代码都想不全。我之所以坚持记录就是因为90%的现场问题第二次遇到时留下的遗忘成本远大于解决成本。我通常会把经验记成固定格式现象是什么影响面有多大排查过程按什么顺序走的中间哪些判断是错的最后根因是哪一句话能讲清的。格式越简单越好因为复杂格式根本坚持不下去。很多朋友喜欢整理成精美的知识库配流程图、配截图结果每整理一条要花半小时三天就放弃了。我的方式是直接在手机备忘录里写想到什么写什么一周之后统一归到PLC实战笔记里。1.2 1~3年这个阶段最缺的不是资料而是判断顺序做过一年以上项目的同仁应该明白入行前三年真正的问题不是“不会”而是“不知道该先查哪里”。同样是PLC不上电可能是电源坏了也可能是输入公共端没接对还可能是保险丝被烧了。经验不足的人容易一上来就怀疑程序改来改去问题反而越改越多。90条经验里的每一篇我尽量把“排查顺序”放在第一位原因就在这里不是告诉你标准答案而是告诉你我从“错误答案”里试出来的安全路径。比如后面会写到的S7-PLCSIM启动问题网上很多人第一反应是重装软件。可实际上大部分情况只是虚拟网卡配置、实例残留或端口冲突根本不到重装那一步。这个道理放到硬件接线和通讯协议上也一样——大多数故障的根因都藏在最不起眼的基础环节里。1.3 关于AI写PLC代码我的态度有保留但开放最近“AI PLC代码生成”这个话题很热。我也试过用AI生成红绿灯程序、四层电梯控制逻辑甚至让它按我的习惯给梯形图块写注释。坦白讲用来搭模板、梳理顺序功能图、生成某段标准算法的参考代码效率确实高。但1到3年的工程师千万不要把AI当“老师”因为它给的程序看起来结构特别规范往往缺了现场真正要紧的东西急停逻辑放在哪一级、机封漏水联锁要不要做冗余、复位按钮需不需要同时清除报警和联锁标志位。这类隐含条件AI不会替你问也不会替你想。所以我写这些实战贴的时候也会尽量把“程序背后那一层设计逻辑”讲出来而不只是提供一个能跑通的梯形图。2. 接线和选型第一步最容易吃暗亏错得也最隐蔽2.1 NPN和PNP先讲清楚再动手我在上一个项目里给一条包装线换传感器厂家发过来的是PNP三线制。接上去之后PLC输入灯全不亮查了半小时发现上一任用的是NPN传感器PLC模块对应的公共端接法两边正好相反。这个错在1到3年工程师里特别常见原因很好理解大部分人接输入信号时默认“有信号就有24V”很少去区分传感器的输出晶体管到底是NPN还是PNP。所谓NPN型传感器输出端是集电极开路信号导通时把负载拉到0V所以你必须在PLC输入点与24V之间形成回路PNP型则是把输出拉到24V。选错以后PLC输入点要么永远为0要么直接烧掉模块端子。动手前先确认三个东西传感器的型号标签、PLC输入模块的漏型/源型定义、公共端COM的接法。宁可花两分钟查手册也不要凭经验猜。传感器类型导通时输出状态适合的PLC输入公共端接法NPN输出对0V导通漏型输入SINK公共端接24VPNP输出对24V导通源型输入SOURCE公共端接0V2.2 西门子PLC输入输出接线里的高频错误西门子PLC的接线问题在热搜词里常年排在前面说明这是大家普遍遇到的坎。S7-1200的输入模块一般支持源型或漏型但不同型号的公共端定义不一样CPU本体上的M端和模块上的M端到底谁接0V、谁接24V必须对照端子图看。我见过有人把220V串进24V输入点模块当场冒烟也见过把继电器输出点当成干接点外接了一个大功率接触器结果触点寿命不到两周。更隐蔽的是输出侧感性负载的问题。控制接触器线圈、电磁阀、小型电机接触器时线圈断电瞬间会产生反向电动势。接交流负载最好并联阻容吸收接直流负载则在负载两端反向并联续流二极管。不加这些保护直观结果是模块晶体管被打坏间接结果是CPU莫名其妙复位排查起来特别费劲。2.3 通电前的万用表三查这是我给自己定的硬规矩也建议所有刚入行的工程师照抄第一查电源用万用表确认24V电源的输出电压稳定在24V附近正负极没有接反第二查输入点把每路传感器的信号状态逐个短接测试确认输入点对应的地址能正常翻转第三查输出点在断开负载的前提下用万用表测输出触点通断确认PLC输出地址和实际端子一一对应。这三查看着慢其实做熟了十分钟就够但能挡掉一大半的通电后“惊魂时刻”。3. S7-PLCSIM Advanced启动故障没有报错的报错最磨人3.1 现象描述点了Start就是不起来很多人用S7-PLCSIM Advanced V5.0跑PLC实例遇到一个很头疼的现象新建实例、配置好IP勾选Start之后界面没有任何报错但实例状态一直显示停止或者点了半天只弹出一个一闪而过的小窗。最麻烦的是它不像普通软件那样弹个错误码而是“安静地失败”让人无从下手。我一开始也差点走上重装系统的路。后来仔细对照自己和网友复现的情况发现问题通常不在软件本体而在仿真器运行所需的“外围环境”。S7-PLCSIM Advanced本质上是在Windows上虚拟出一块带网卡的PLC它的启动依赖虚拟网卡、底层服务和端口分配。这三个环节任何一个出问题都会导致实例起不来且没有明确报错。3.2 排查链路从进程、路径到虚拟网卡面对这种“没报错”的故障我的排查顺序是固定的先从最廉价的检查开始检查所有S7-PLCSIM相关进程是否完全退出。最常见的情况是上次非正常关闭PLCSIM进程还驻留在后台占用了实例名称或端口。打开任务管理器把所有带PLCSIM或Siemens字样的进程全部结束再重新打开。检查安装路径是否有中文或特殊符号。这一步太容易被忽略。仿真器对路径里的非英文字符比较敏感一旦装在“D:软件S7-PLCSIM”这类路径下启动逻辑就会异常。卸载后重装到纯英文目录就能解决。核对TIA博途版本和S7-PLCSIM Advanced版本是否匹配。V5.0对应的是博途高版本如果你电脑里跑的是老版本项目实例就会启动失败。版本匹配关系表在安装说明里都有但很少有人会真的逐条核对。检查虚拟网卡。S7-PLCSIM Advanced安装时会创建虚拟网卡如果系统网络管理工具把它禁用了或者IP被改成了和实体网卡相同的网段也会出现实例不起动的情况。到网络适配器里找到Siemens PLCSIM Virtual Ethernet Adapter确保启用状态并给它一个独立网段的IP比如192.168.200.1。最后再去看事件查看器。Windows日志里可能有PLCSIM的底层异常记录很多时候比界面上的沉默靠谱得多。3.3 Error 11的常见诱因和处理如果你不是“无报错启动不了”而是明确弹出“Error 11”或者类似的错误号那重点就转向许可证和实例状态了。Error 11在PLCSIM Advanced里往往和授权、实例文件冲突有关。常见的处理是先删除出问题的实例文件夹一般在Documents或ProgramData下的Siemens相关目录里然后重新创建一个实例而不是复用旧实例。如果还不行就用官方安装包做一次修复安装许可证管理器里确认相关授权处于已启用状态。还有一种情况是PLC实例IP和电脑物理网卡IP冲突。仿真PLC同样需要通讯如果它分配的IP被其他网卡占用底层握手就失败。给仿真器分配一个像192.168.100.1这种专用地址并且和物理网卡的网段错开能省掉很多莫名其妙的坑。3.4 一句话总结仿真器故障的优先级仿真启动问题的排查优先级我个人排成这个顺序先杀残留进程再查路径字符再查虚拟网卡和IP冲突然后看版本和许可证最后才谈重装。按这个顺序走下来十次里至少有八次能在前两步解决。重装永远是最后的手段因为重装之后你需要花大量时间重新配置环境而且问题大概率还在。4. 触摸屏和驱动之间的“语言壁垒”威纶通为什么找不到汇川PLC4.1 所谓“找不到驱动”其实是没看对眼网上有个高频问题威纶通触摸屏软件里找不到汇川PLC的驱动。很多人的第一反应是“威纶通不支持汇川”但实际情况往往不是硬件不支持而是大家在驱动列表里找错了名字。威纶通的EBPro软件里驱动名称通常按照协议或系列命名不会直接写“汇川PLC”四个字。你搜“厂家”是搜不到的但搜“INOVANCE”或者“H1U/H2U/H3U/Easy”就能翻出来。汇川PLC早期很多型号走的是三菱兼容协议所以部分机型用三菱FX系列的驱动也能通讯。但我要提醒这不等于可以所有型号都偷懒。Inovance不同代际的产品在底层协议上有差异比如Easy系列、H1U、H3U、AM系列与触摸屏对接时选择的驱动是不完全一样的。我自己的处理方法是先在设备型号手册或触摸屏的驱动列表帮助文件里确认支持型号再决定选哪个协议绝不在列表里瞎碰。4.2 添加汇川驱动的正确姿势以一个典型的威纶通加汇川H3U项目来说操作路径大致是新建工程时选对触摸屏型号然后在“设备列表”里添加PLC设备厂家那里选“INOVANCE”在型号列表里找到对应的协议项。接下来要跟PLC侧保持一致如果是串口连接必须核对COM口号、波特率、数据位8、停止位1、校验方式两边任何一项不一致都连不上如果是以太网连接就要给触摸屏和PLC分配同网段的IP并填上目标PLC的站号或端口。很多新人栽在“明明驱动选对了还是连不上”上原因通常是忘了检查PLC侧通讯口参数。PLC默认的通讯参数可能和触摸屏默认值不一致必须到PLC程序里确认底层通讯协议配置。这种问题最迷惑人的地方在于触摸屏上一切设置看起来都是对的程序也能下载但就是通讯不上。4.3 MCGS与信捷、以及更多“品牌对不上”的情况同样的坑在别的触摸屏上也存在。MCGS昆仑通态连信捷PLC时很多人到驱动列表里找“信捷”结果看到的却是“XC系列”之类的名称。这很正常因为触摸屏驱动本质上是“协议驱动”它关心的是通讯协议能不能对上不关心品牌叫什么。信捷XC和XG系列的协议有所不同选错也会通讯失败。所以我的经验是遇到任何“找不到驱动”先不要急着吐槽软件去查PLC支持哪几种通讯协议再在触摸屏驱动列表里按协议关键词搜索。Modbus RTU、Modbus TCP、串口自定义协议、以太网协议这些才是列表里的“真实身份”。4.4 通讯连不上的硬件侧检查把软件参数全核对完之后还是不通就该摸线了。串口通讯最常见的问题是接线收发交叉触摸屏的发送要接PLC的接收触摸屏的接收要接PLC的发送不是一一对应直连。很多串口线做起来要交叉没有交叉就直接沉默。以太网通讯则要检查线缆是否通、交换机端口有没有亮起来、防火墙是否拦截了目标端口。检查项目串口通讯以太网通讯参数一致性波特率、校验位、停止位IP地址、子网掩码、端口号物理链路2/3线是否交叉参考地是否连接网线、交换机、指示灯干扰因素长距离用屏蔽双绞线不能走强电管与变频器线槽保持距离软件验证用串口助手看原始报文用Ping测试目标IP可达性5. 通讯与上位机三菱协议、SCADA轮询和C#读数的坑5.1 三菱PLC通讯协议别被“协议详解”吓退“三菱PLC通讯协议详解”是热搜词说明大家都很想搞懂这套东西。三菱目前常见的上位机通讯方式包括MC协议、QnA兼容协议以及Modbus。MC协议帧格式乍一看很复杂又是子头又是块号但实际用起来只需要抓住核心先判断是ASCII模式和二进制模式再按协议把请求帧填对。举个例子读D100这个数据寄存器二进制模式下请求帧的长度是固定的命令名、起始地址、读取点数都有明确字节位。新手最容易犯的错误是地址换算。D100对应的软元件编号换算到MC协议的地址时需要按区块偏移量来算而不是直接填100。如果地址错一位PLC要么返回异常码要么默不吭声。我的建议是不要凭记忆写帧格式直接去PLC编程手册的通讯章节里查地址映射表然后再对着实际返回的数据做一次验证。5.2 SCADA连接PLC先搞清楚你的SCADA走什么通道SCADA和PLC的连接方式大体上分三种组态软件自带驱动直连、走OPC UA/DA、走Modbus协议。很多人集成SCADA时连不上不是因为网络不通而是没有搞清楚该用哪条“通道”。自带驱动最省事但必须在SCADA的驱动管理器里装对应的PLC驱动OPC UA最通用但需要PLC固件和SCADA都支持并且证书配置得当Modbus则要PLC侧把数据映射到Modbus寄存器区。如果SCADA只提供Modbus TCP通道而PLC那边没有开好Modbus服务器那不管你在SCADA里怎么填IP地址都没用。反过来也一样。所以我通常建议项目初期就确定通讯架构谁来当主站谁做从站走什么端口数据区是哪个地址段。SCADA连PLC根本不复杂复杂的是头三天没人愿意把这几个参数定下来。5.3 C#读取PLC读取频率与线程占用有人问C#读PLC频率设多少合适。这个问题没有唯一答案但有通用经验。假设你写了个循环每50毫秒去调一次通讯函数读取几十个点位初看很快但一旦PLC那边响应慢了一点线程就开始堆积。用不了多久你的上位机界面卡顿PLC通讯模块也可能出现过载。做上位机开发我的建议是把“读取频率”和“数据用途”挂钩如果只做监控画面500毫秒到1秒的刷新完全够眼睛看不出延迟如果要做趋势曲线和报警记录200到500毫秒也够了只有在伺服位置追踪或者高速数据采集之类的场景下才需要考虑50到100毫秒级。另外千万不要在循环里反复创建新的连接对象C#里应该维持一个长连接用一个独立线程去定时轮询把结果写入共享变量或者缓存UI线程只负责显示。这个坑项目上线时间越长体会越深。5.4 ABB变频器与西门子PLC从站编号和尾电阻ABB变频器和西门子PLC的通讯不管是USS协议、Modbus RTU还是Profinet首先要解决的是“地址对不上”的问题。ABB变频器的参数表里有专门的通讯地址参数比如站号要和PLC侧配置的从站地址完全一致。其次串口通讯的两端要约定好波特率、校验方式、数据格式包括ABB变频器的某些参数要设置为“允许写入”否则PLC发过来的控制指令会被变频器拒绝。还有一个很“物理”的坑RS485总线的终端电阻。走Modbus RTU时总线上必须在物理末端接终端电阻否则通讯信号会发生反射。很多项目通讯时好时坏报故障代码一会儿是一会儿没排查了一圈发现就是终端电阻没接。ABB变频器有些型号自带终端电阻跳线使用前一定要看手册确认跳线位置。6. 程序结构里的“老套路”红绿灯、四层电梯和抢答器教会我的事6.1 十字路口红绿灯时序图画清楚再写定时器红绿灯程序为什么总被当成经典入门题因为它涵盖了两个核心能力时序拆分和输出互锁。很多人一开始就开好几个TON定时器结果绿灯切换的时候闪烁混乱问题往往出在“相序”没有理清楚。正确做法是先画一张时序图把南北直行、南北左转、东西直行、东西左转这几组信号的起止时间列出来再决定定时器的连接关系。我特别想提醒的是双线圈问题。在梯形图里同一个输出点如果被多个网络赋值程序扫描到最后一次赋值的网络才生效前面写的相当于白写。红绿灯这种程序里稍微没注意就会出现“红灯亮一下就灭了”的怪现象。解决方式很笨但很管用每个输出点在全程序里只保留一次“线圈赋值”语句或者把所有判定条件合并到一个输出控制网络里。6.2 四层电梯把状态机思想用起来四层电梯控制程序也是经典项目。刚入行时我很喜欢用一长串中间继电器和定时器去模拟电梯逻辑写得又长又难调。后来才明白电梯程序最适合的模型是状态机待机、运行、减速、开门、保持、关门、再出发。每个状态对应一组允许条件状态切换必须有明确的事件触发。这样编写出来的程序可读性高排障也容易得多。状态机不一定非要用SCL或者GRAPH来实现。梯形图里完全可以用一个字节型的“当前状态”寄存器配合多个比较指令和置位复位指令来建模。当电梯在某层触发限位时先判断当前状态是什么再决定合适的目标楼层和运行方向。这样做的好处是任何时刻你都知道电梯到底“在干什么”而不是面对一圈“辅助继电器像一团乱麻”看不清楚。6.3 抢答器和数字孪生互锁与刷新节奏抢答器程序的核心是“抢先锁定”。多个按钮同时或几乎同时按下时系统只能接受第一个有效信号并且之后所有迟到信号都失效。关于这个逻辑梯形图的执行顺序有天然优势先扫描到第一个置位信号的网络后续网络因为互锁触点已经断开就无法再覆盖。很多新人在抢答器项目里看不明白为什么已经锁定的应答还能被别的信号“冲掉”其实就是因为在后续网络里对该输出点再次做了非互锁的赋值。现在很多实训项目会把抢答器做成数字孪生场景即PLC程序控制3D模型里的灯和声音。这类项目要注意的不是PLC逻辑而是上位机和PLC之间的“刷新节奏”——数字孪生场景的动画帧率通常在30到60帧。如果你的上位机以100毫秒周期去读一次PLC画面看起来就是一顿一顿的。串口或以太网读写周期、3D渲染帧率、PLC扫描周期三者之间要有一个协调机制而不能各跑各的。6.4 包装线和灌溉项目中的结构化编程自动化包装线控制系统设计这类项目看起来复杂拆开其实就是“顺序控制”。不同工位有各自的起始条件、动作命令和下位机状态反馈。我推荐的方法是把整条线的工艺拆成若干个设备功能块每个块封装成独立FB然后在OB1里按设备启停顺序调用。几个功能块之间的互锁逻辑单独写在另外的网络里不要让它们互相打扰。基于西门子PLC的大棚灌溉项目则多了模拟量处理和PID调节。温湿度传感器的模拟信号经模块转换成数字量后在程序里先做工程量换算再做上下限报警和PID输出。这里有个新手经常忽略的点PID输出之前一定要做好量程匹配否则控制阀门的开度不是偏大就是偏小调节过程震荡得厉害。6.5 关于AI生成PLC代码的现实体会AI生成的PLC代码确实能提升效率但只能用在“人工可控”的场合。我试过让它生成包装线顺序控制的骨架得到的功能块划分基本合理直接修改起来比完全手写快不少。但AI很容易忽略急停之后的复位顺序也会把上位机关联地址写得凭空臆造。我的做法是把AI当成“高级代码片段库”让它出结构、出模板、出注释但所有工艺逻辑和联锁条件必须自己人工对照图纸逐行检查。7. PLC宕机排查先别急着怀疑程序从这几个地方入手7.1 先看灯RUN、SF、BATF各自的指向PLC“宕机”这个词在网上很火但很多人把不同现象都叫宕机。有人是RUN灯灭了有人是SF灯闪烁有人是模块上的端子灯不亮。接到现场第一件事一定是看灯灯比报警文本诚实得多。RUN灯熄灭说明CPU停止运行可能是程序写入了停机指令、硬件组态错误或者看门狗超时。SF灯点亮或闪烁说明系统自诊断发现故障如模块组态与实际不一致、外设总线错误等。BATF灯亮则是电池电压不足或背板总线问题。我见过最典型的“假宕机”就是操作员急停拍下之后没有复位导致CPU跳到STOP状态。这时候不要急着改程序先把急停回路复位再用钥匙把CPU拨到RUN。灯不亮但通讯也不通的场景更要先确认电源侧是否真的送电不要被某个开关的位置骗了。7.2 程序写崩PLC的两种典型方式第一种是指针或地址越界。使用间接寻址、数组索引、指针操作时如果索引超出了定义范围CPU可能直接进入STOP。这个问题在做配方管理和履历跟踪时容易出现。第二种是看门狗超时。OB1的执行时间如果超过设定值比如默认150毫秒系统会认为程序卡死并触发停机。常见诱因是FOR循环里套了死循环或者某个通讯指令在等待响应时阻塞了程序扫描。排查时可以把OB1的执行时间监控打开看扫描周期是不是异常升高。如果扫描周期从10毫秒暴涨到300毫秒就要重点检查最近新加的通讯块和循环块。先回退版本等系统稳定后再逐个功能块地加回来这条经验看着笨但能最快锁定问题。7.3 外部干扰和接地最容易被忽略的凶手随机宕机里更常见的是外部因素。变频器启动瞬间、大型接触器吸合、电焊机工作时一旦PLC宕机十有八九是干扰串进了信号回路。典型路径是信号线缆和动力电缆同槽走线接地线松动或接地电阻过大通讯总线缺少屏蔽层屏蔽层单端没接地。有些项目抗干扰做得不行现场变频器一启动PLC就莫名其妙重启。处理方法是把通讯线改用屏蔽双绞线并单端可靠接地PLC机柜单独接到接地铜排上和变频器保持足够的空间距离。信号线和动力线分开走线看起来是常识但在很多紧凑线槽里被直接忽略了。7.4 随机宕机的标准排查清单我把“随机宕机”的排查动作整理成一个清单供大家贴在机柜门上参考现象优先检查验证方法RUN灯熄灭且SF不亮电源、急停回路量电源输出查看DI点位状态RUN灯熄灭且SF亮模块组态、程序故障查诊断缓冲区核对实际模块运行中周期性重启电源容量不足、地线松动用示波器盯24V波形变化变频启动时停机干扰、屏蔽、接地变频器停机后是否恢复正常通讯中断但不是CPU停机通讯线、终端电阻、端口配置抓包分析检查总线物理状态我给自己定了一条纪律随机故障一律先看诊断缓冲区。西门子PLC的诊断缓冲区会记录最近几次停机的原因很多时候能直接指出是模块故障、程序看门狗还是外部故障。1到3年的工程师只要习惯性地先看诊断再推理排障时间能缩短一半以上。8. 后记这90条经验我会怎么更新下去8.1 更新节奏这个系列我计划每天更新几条按80条左右的经验内容倒推九十个编号里有相当一部分会结合最近项目重新修订。更新顺序大致按照“硬件接线—仿真调试—触摸屏—通讯—程序—运维排查”的路线走有条件的话会把真实故障代码、通讯报文和程序片段贴出来供参考。因为涉及不少现场信息我会做脱敏处理但原理部分不求“全面”只求“有用”。8.2 留下一句话给一起成长的同行我个人在这三年里的最大体会是PLC工程师的价值不在于背下来多少指令也不在于手速多快能画完一张图而在于面对一个“说不清楚的问题”时能不能快速缩小范围。这个能力的养成靠的正是平时一条一条的记录、一次一次的复盘。如果你也刚入行不久我建议你也从今天开始把每天遇到的第一个技术小坑记下来一个月后回看就会惊讶于自己的进步。下一篇更新我会先从“现场故障记录表怎么设计”这条写起因为有了统一格式的记录后面的排查经验才有地方沉淀。
