入行PLC不到三年的朋友我估计你跟我当初一样最怕的不是写不写得出程序而是现场一通电就“噼里啪啦”冒烟或者设备运行时好时坏查了半天都不知道问题出在哪。这个系列我打算按场景把这几年攒下的90条经验逐条拆开讲每天更新几条不追求高大上只求每条都能直接用在工地上、电柜里和程序里。今天先说说那些最容易让新人栽跟头的硬经验——接线、打点、IO检查这些东西做扎实了后面写逻辑才有底气。很多人觉得IO点检查就是拿螺丝刀捅一下、看指示灯亮不亮其实远没那么简单。我见过太多项目最后调试时间全耗在“查线”上源头就是打点这一步偷了懒。PLC工程师入行前三年如果能养成一套严谨的接线检查和点位核对习惯后面会省下无数个加班深夜。1. 现场接线与IO点检查这些基本功决定了你调试时是闲是忙1.1 别急着通电先带着图纸和万用表把柜子“读”一遍PLC控制柜安装完毕很多人第一件事就是合闸看看触摸屏亮不亮、PLC指示灯亮不亮。我建议你把这一步往后放一放先在断电状态下拿图纸把柜子从头到尾过一遍。注意几个容易出错的位置开关电源的输入输出端子有没有接反、24V和0V有没有接错、PLC输入公共端是接正还是接负、继电器底座有没有卡到位。这些低级错误一旦通电轻则烧保险重则把PLC的输入点直接干报废。另外信号线的线径和颜色也要看一眼。有些施工队习惯用同一色号电线走完全场调试时查线能查到怀疑人生。我自己的习惯是24V用棕色或红色0V用蓝色或白色急停和安全回路的线单独用黄色和普通信号物理分开。这不算什么标准但能让你在排查故障时少猜很多。1.2 打点不是“捅一下看灯亮”而是核对每一个信号的“源”和“目的地”所谓打点就是逐个短接输入点确认PLC的输入指示灯能对应点亮同时在程序里监控到状态变化。但成熟的做法要更细——不仅要看灯亮不亮还要确认这个点在实际设备侧是由什么驱动的是按钮的常开触点还是常闭触点是光电传感器的NPN输出还是PNP输出是干接点信号还是有源信号。这里有一个很容易被忽略的坑**传感器的NPN和PNP搞反了。**NPN输出是低电平有效接法通常是传感器输出接PLC输入的0V侧负载接24VPNP输出是高电平有效传感器输出接PLC输入的24V侧负载接0V。如果你不清洗现场用了哪种传感器或者供货时换了一批型号很可能出现“信号怎么都不亮”“亮了一直不灭”这类怪现象。打点之前先把传感器型号查清楚比什么都重要。1.3 输入点、输出点、公共端的关系决定了你后面改线的工作量PLC的输入输出分组在一开始就要规划好。很多人习惯随手分配地址结果现场接线时发现同一根电缆里的信号被分配到了不同组的公共端只能额外拉线丑且乱。我的建议是按区域和功能分组分配IO比如一条生产线的传感器集中占用X0.0-X0.7下一组从X1.0开始尽量和现场接线排布一致。这样以后查故障、改程序脑子里能直接映射物理位置。输出点则是另一个重灾区继电器输出和晶体管输出的区别要心里有数。继电器输出带载能力强、响应慢、适合交流和直流负载晶体管输出只能带直流负载、响应快、适合脉冲信号和高速频繁动作。用PLC直接带电磁阀、接触器线圈的时候一定确认输出点的容量标称2A不代表你能拿它直接驱动一个启动电流七八安培的接触器。中转继电器很多情况下是必须的——不是浪费成本是保护你的PLC输出点。1.4 24V电源的分配与压降现场故障的隐形制造者开关电源的容量选型很多入门工程师是拍脑袋选的结果现场大量传感器同时动作时电压被拉垮PLC莫名其妙复位或者模拟量信号跳得厉害。你要学会估算每个传感器按30-50mA算每个中转继电器线圈按50-80mA算加上触摸屏、PLC本身的功耗再留30%的余量。这是一道简单的加法但真到现场你会发现好多人根本没算过。还有一个隐蔽问题电源的远端压降。24V电源在一头远端设备在几十米外线径细一点负载一多到设备端的电压可能只有21V左右。传感器在低压下工作不稳定输出信号时有时无——这种故障很难查因为万用表量电源输出端是正常的。解决方法是把24V供电做成环形或者在中途加电源同时注意0V也要保证连通别只拉了一根正线就让信号自己找路回来。2. 程序逻辑编写里那些“当时觉得没毛病”的隐患2.1 双线圈输出程序能跑但设备行为诡异地反复很多新人写梯形图喜欢在一个输出地址上重复写OUT指令比如正转接触器在手动模式下写了一次自动模式里又写了一次。这不一定会报错CPU也不会提醒你但两个线圈在同一个扫描周期内互相覆盖最后的输出状态取决于谁在程序的后面扫描。结果就是设备动作和你的按钮指令完全不同步甚至抖动。排查起来非常隐蔽——程序“看起来”每一段都对。我的写法是**全程序只允许一个位置带线圈输出其他所有条件都通过中间变量内部继电器/标志位来控制。**这样强迫你把逻辑理清输出点永远有唯一、明确的控制源。改起来也方便后续加条件只在前面“与”一下不用满世界找线圈。2.2 上升沿和下降沿丢了触发信号设备纹丝不动PLC扫描周期是毫秒级的但外部机械信号可能只有几十毫秒比如一个快速转动的接近开关。用普通常开点去捕捉这个信号扫描周期如果错过了高电平区间程序就“看不见”它。正确做法是用上升沿指令比如RLO Edge、P或EU把瞬变状态锁存成内部标志。这里有个教训上升沿信号在手动调试阶段往往看不出来因为你会慢慢短接、慢慢松开信号宽度够长。一旦切到自动高速运行问题就全暴露了。所以只要信号源本身可能是脉冲式触发的不管现场看起来多“慢”一律用沿触发或置位复位逻辑绝对不要直接读电平。2.3 定时器和计数器编程手册里不会写的那些细节坑定时器分很多类型接通延时、断开延时、保持型接通延时。选错类型常见但更隐蔽的是定时器的分辨率。同样是“T37”不同品牌不同指令对应的时基不一样有的是10ms有的是100ms。写个定时值“10”你可能以为是1秒实际是100ms或者反过来。编程前先查一下当前指令的分辨率养成习惯。保持型定时器还有个特点线圈断开后定时值不归零重新接通会接着累加。这在需要“累计运行时长”的场景有用但如果只是想做暂停功能用错了会让你反复调试。我自己习惯把所有跨模式累积的时间量都用系统自带的断电保持寄存器实现用普通定时器做单周期控制选择上很清晰就不会乱。2.4 断电保持和初始化一上电就跑飞的问题根源PLC里有一部分寄存器默认是断电保持的上一轮程序修改的数据、中间标志位、计数器的当前值断完电再上电全都还在。很多新项目上电后设备自己动起来就是因为输出标志位被保持了下来程序一扫描到True就直接驱动执行机构了。解决思路是程序开头必须有一个“首次扫描脉冲”用它来做初始化——复位所有输出、清除关键中间变量、把轴参数设回默认值。首次扫描脉冲在多数PLC都有专门系统位别自己猜。还有一个细节上电瞬间设备处于什么姿态必须提前想清楚。是默认停在原地还是先回到原点这直接影响你的程序初始化逻辑怎么设计。我见过项目因为初始化顺序没考虑气缸位置一上电气缸自己伸出差点造成事故。2.5 结构化编程别把几十个Network全塞在主程序里梯形图最怕写得像流水账几百行全在一个OB里后面加个子程序都找不到地方。入门时我强烈建议你养成“功能块化”的思维把每个独立动作比如某个工位的夹紧、旋转、检测封装成子程序或功能块主程序只做调用和分段调度。这样做的好处不只是好看。第一单个子程序里的逻辑相对独立调试时可以单独强制变量、单独观察第二复制到其他项目时直接拖拽整个块省去重新录入第三团队配合时每个人负责一个块合并时少打架。我这里说的封装不需要面向对象那些高级玩法就是最朴素的“块划分”——按工位、按功能、按模式拆开新手阶段绝对够用了。3. 伺服与运动控制的实战经验方向、回零和加减速的那些坑3.1 方向搞反了不是因为接线错而是因为概念没理清伺服电机转向不对新人第一反应是换任意两相线。这对异步电机可能有用但伺服驱动器通常不允许随意换相乱换可能报警甚至损坏编码器。正确做法是看驱动器参数里的方向设置正逻辑/负逻辑确认脉冲方向、指令方向与机械机构的运动方向一致同时要考虑机械传动比皮带、丝杠、减速机对方向的影响。调试方向问题有一个快招先把速度设成非常慢的JOG模式点动正转看丝杠或皮带的移动方向是否和程序预期一致再带负载小距离运行验证。千万别在高速状态下测方向万一反转顶到机械硬限位损毁的是设备而不是参数文件。3.2 电子齿轮比那一堆参数不是摆设算错会直接飞车电子齿轮比用于匹配PLC发脉冲数和实际移动距离之间的关系。比如你要求每毫米1000个脉冲但你电机编码器是2500线丝杠导程是5mm驱动器内部的电子齿轮比就要按“电机每转所需指令脉冲数”来设。设错了要么定位距离差好几倍要么移动速度超过预期直接触发跟随误差报警。我建议你把这组参数单独放一个笔记里记录每个轴的以下信息丝杠导程、减速比、编码器线数、电子齿轮比分子分母、每毫米脉冲数。换设备、换驱动器的时候直接对照不怕丢。这一条属于“省得了一时麻烦一世”的经验——别问我怎么知道的。3.3 回零不是选个模式就完事原点开关的位置才是关键回零方式有近原点开关Z相、直接找Z相、硬限位反推等方式。很多新人选了“近原点Z相”结果回零精度忽高忽低因为原点开关的安装位置和Z相脉冲的相对位置不固定每次停止在Z相的位置都不一样。正确的做法是近原点开关只做减速信号真正的零点基准靠电机Z相编码器零脉冲来找。机械安装时让原点挡块覆盖的位置恰好让电机停在Z相可检测的区域内这样每次回零停的位置才完全一致。另外回零方向、回零速度也都要考虑——先快后慢碰到原点开关后减速到爬行速度找Z相这样尽量减小机械惯性带来的过冲。3.4 加减速时间设置定位抖动和撞机的另一个隐蔽因素伺服定位抖动不一定是PID没调好很可能是你的加减速时间设得太短。举个例子从0加速到3000rpm只用20ms电机实际速度响应跟不上指令速度曲线驱动器和电机之间会产生很大的跟随误差要么报警要么走完定位后机构来回晃动。入职头几年我建议所有轴参数开始都往保守设加速时间先给300-500ms跑起来看曲线再逐步缩短。这里有一个看似反直觉的点加减速时间太长节拍变慢不等于“稳”。有时慢速长距离移动反而更容易出现低频抖动因为伺服电机在极低速度下的刚性特性不同。你需要的不是单纯快或慢而是让加减速曲线和负载特性匹配这只能靠现场试。4. 通讯与上位机对接参数一致、地址映射和断线处理4.1 连不上时先查人通讯参数永远不要只靠“默认”串口通讯连不上的九成原因根本不是设备坏了而是两边参数不一致波特率、数据位、校验位、停止位这四项被称为“通讯四要素”。你PLC这边设了9600,8,N,1上位机那边是19200,8,E,1神仙也连不上。我踩过的坑是自动化测试时改过参数但没保存生效结果查了一下午。给个建议所有通讯参数必须白纸黑字记录在项目通讯方案文档里现场调试时对着核对不要凭记忆。对于以太网通讯还要额外确认IP地址在同一网段子网掩码一致端口号没有被防火墙挡掉这几件事虽基础但每个项目总能碰上一次。4.2 Modbus地址映射PLC内部地址和寄存器地址别搞混做上位机组态或触摸屏通讯时Modbus寄存器地址和PLC内部地址经常差一个偏移。比如PLC的保持寄存器区从40001开始上位机读4x-01对应PLC里的D0但如果你在触摸屏里填了40000就读到了地址偏移一位的地方。这种问题症状特别诡异数据显示时对时错而且不同品牌触摸屏的偏移规则还不一样。通用做法是先在触摸屏上建立一个“假的”调试页面直接读取几个已知值的寄存器比如PLC里写死的常数或计数器当前值确认映射对不对再继续做画面。千万别在几十个变量都做完之后才发现地址全偏了返工量会让人崩溃。4.3 通讯断线后程序必须“死给你看”不能默默无声上位机和PLC之间的通讯一断很多时候PLC程序还在运行设备还在动作但画面上的数据不动了。这时候操作工如果没注意到报警很可能按了启动后设备没反应或看起来有反应但动作逻辑混乱。危险。我处理这类情况的思路是在PLC里做一个通讯心跳监控——上位机每隔一定周期比如500ms写一个固定寄存器递增PLC检测到该寄存器的值长时间不变则认为通讯中断立即停止生产流程并触发报警。这种方法不依赖特定协议任何品牌都适用是工程上非常成熟的保底手段。5. 故障排查五步法把“玄学”变成查线、查点、查逻辑5.1 观察-分段-替换一套不靠运气的排查流程现场设备出问题最忌“哪里都动一动”的盲修。我整理了一套五步流程第一步观察故障现象问清楚是“启动时”“运行中”还是“停机后”出现第二步根据现象锁定区域是先查输入信号还是先查输出执行第三步在PLC上用监控表判断是程序逻辑问题还是外部信号问题——如果程序里标志位没置位说明前面条件没满足继续追输入第四步万用表量信号实际电压区分是断开还是信号根本没发出第五步替换可疑模块或传感器确认故障源。有一次现场检测信号时好时坏我按这套流程查到第三步就锁定到某个传感器在高温环境下间歇失灵的结论换掉之后问题消失。整个过程不到半小时而同行的师傅还在拿着螺丝刀一个个端子拧。5.2 用程序监控表代替猜想学会看“状态变化”的全过程很多新人不喜欢用PLC的监控表格觉得打开麻烦更喜欢直接用万用表量。但程序监控能让你看到信号的“前因后果”比如按钮按下了、对应输入点却始终为0那问题大概率在接线输入点为1但内部标志位没置位那问题在前置互锁条件没满足标志位置位了输出却没动作那问题在输出接线或负载本身。每一个“断层”都精确指向问题区域这比量线高效得多。单个循环扫描周期内的状态变化也是排查要点。你可以打开强制表同时观察几个关键变量的True/False变化节奏判断设备卡在哪个等待条件上。这里想说一句强制变量在调试时很有用但强制完一定要记得复位我带过一个项目因为有人忘记解除强制设备一上电就狂转差点冲床。这类事情谁忘一次谁长记性。5.3 学会看报警代码和LED状态少走80%的弯路伺服驱动器、变频器、触摸屏、PLC本身都有报警代码或LED状态指示。很多人一报警就慌直接查程序白白浪费时间。我给你的建议是每种设备买回来之后先把操作手册里的报警代码表抄一份放在项目文件夹里现场报错时先对代码再决定下一步。伺服报警里的过流、过压、编码器异常几乎都能从代码直接看出方向不需要瞎猜。另外PLC的硬件LED指示灯也有丰富含义RUN/STOP状态、电池低压报警、模块总线错误、输入输出通道状态。特别是I/O模块上信号灯是打点排查的第一手信息源——优先相信它再相信万用表最后才靠程序猜。6. 入行头三年建议你这样“接活”和“记笔记”6.1 现场记录本比手机相册好用一百倍的工程师“外挂”干PLC调试我强烈建议随身带一个硬壳笔记本和两支笔而不是只靠手机拍照。手机照片确实方便但现场环境复杂手套油污、屏幕反光、接线端子密集照片往往看不清线号。更重要的是笔记本上能记录“时间、现象、判断、结果”四要素的完整排查链路这种信息密度是照片给不了的。我的本子通常分三栏左侧记录设备信息和报警代码中间画简易接线草图或时序波形右侧写我自己判断的可能原因和验证结论。项目收尾后这本子就是你的个人故障案例库。哪个传感器在哪个位置容易坏、哪台伺服的参数被人调过、当初是怎么排查出来的别人再问时你根本不用回忆直接翻记录就行。6.2 版本管理和注释习惯未来返工时的救命稻草程序不是写完就完了它要经过多次修改和优化。很多新人一个文件名存到底改完就覆盖等甲方提个“以前那样其实也行”就彻底抓瞎。我的做法很简单每个版本存一份带日期和修改说明的文件比如“某项目_V03_20250615_增加急停联动”只保留最近三到五个版本。PLC程序通常没有Git那么高级的版本管理但这个习惯足够用了。注释也值得强调。梯形图里的每个Network、每个子程序块开头至少写清楚“这段是干嘛的、受什么条件控制、改的时候注意什么”。我见过太多程序逻辑写在注释里比图里还明白——不是骂人是真心建议。三年之后你回头看自己的程序会发现当初的注释写得有多值得。6.3 安全回路在线修改和强制信号要万不得已才用最后单独说一条底线经验涉及安全回路的程序段比如急停、门联锁、光栅保护不要图方便去短接或强制。在线修改PLC程序时很多人会把安全条件临时强制成True试完忘了恢复这是非常危险的。真出了事情追责时程序里留下的强制痕迹是无法解释的。我这些年坚持的原则是安全信号缺失时宁可停机查原因也绝不绕过逻辑直接让设备动作。等有一天你亲眼见过设备因为强制信号而误启动就明白这条经验的分量了。这90条经验我还会按调试、交付、维修等场景逐条拆开继续更新。当场调试时喝口水的间隙翻到哪条都能接上用也就不算白写。