上周帮朋友看一台老设备的程序去之前他反复强调“程序应该是好的就是动作乱”。我到现场打开在线监控一看整个OB1里塞了两千多行梯形图启停、报警、手动自动全揉在一起启动条件被二十多个中间继电器反复引用改一个点牵一发动全身。这种情况我见过太多次。PLC编程难吗指令也就那么几十条真正拉开差距的是思路。设备动作乱、调试累、售后头疼绝大多数不是指令不会写而是拿到需求后没有系统性地梳理上来就拖触点。这篇我不打算讲指令手册直接用三个真实项目实例把PLC编程从需求拆解、地址规划、状态机设计到通讯调试的完整思路捋一遍会涉及西门子S7-1200、汇川EVO523、信捷等不同平台也顺便聊聊这些年现场踩过的坑。适合刚入行的电气工程师、售后调试人员以及那些能把继电器电路画明白、但一写程序就发懵的朋友。1. 拿到一个控制需求先做什么再做什么很多人拿到项目就急着打开编程软件这是第一个坑。PLC程序本质上是把工艺需求翻译成机器能执行的动作工艺你都没吃透程序写得再花哨也是空中楼阁。我接到任务后的第一件事永远是开个文档把需求拆成三块。1.1 需求大会工艺过程、操作习惯、故障处理一个都不能少先把现场操作工、工艺工程师、设备主管拉到一起开会。这一步看着像废话但真能帮你避免后面三个月反复改程序。要问清楚的问题大致有几类。第一类是设备怎么动单机运行还是联机生产动作顺序是什么节拍要多少秒有没有手动/自动切换需求第二类是操作习惯操作工习惯按钮启动还是触摸屏启动停止后要不要记忆当前状态断电再上电是继续还是从头跑第三类是故障处理哪些信号参与联锁报警后是按复位继续还是必须停机急停按下后重新启动要不要回原点我遇到过最典型的教训一台设备设计成“门打开必须停机”结果操作工为了看料位经常开门一开就停机产能直接砍半。后来改成“开门降速声光提示”这才被现场接受。这些细节写程序之前不提写完之后全是麻烦。1.2 从设备动作里提炼“I/O信号表”和“地址规划表”需求理清楚之后第二步是把所有输入输出信号列出来做成一张I/O表。拿最简单的搅拌机项目举例信号大致是这样信号名称类型PLC地址说明启动按钮数字量输入I0.0常开上升沿有效停止按钮数字量输入I0.1常闭按下即停止全部动作急停按钮数字量输入I0.2常闭硬件回路串联程序参与高料位开关数字量输入I0.3常开闭合表示料位高低料位开关数字量输入I0.4常开闭合表示料位低电机过载信号数字量输入I0.5常闭断开表示过载搅拌电机正转数字量输出Q0.0驱动接触器线圈搅拌电机反转数字量输出Q0.1驱动反转接触器与正转电气互锁报警灯数字量输出Q0.2报警时闪烁蜂鸣器数字量输出Q0.3报警时鸣响这张表不只是为了接线更重要的是帮你提前发现硬件资源够不够。比如数字量输入不够用了后面再加传感器就比较麻烦。顺便说一句PLC地址的表示方式各品牌有差异西门子用%I0.0、%Q0.0、%M0.0其中%MB2000这类地址指的是M区第2000号字节8个位是%M2000.0到%M2000.7汇川、信捷的表示法又不一样基本规则都是“区域尺寸偏移量”上手前先看一眼对应软件的手册别照着西门子的习惯去套其他品牌。1.3 把连续动作切成状态时序图与状态表是最值钱的图纸I/O表只回答了“有哪些信号”接下来要回答“信号之间什么关系”。很多人画时序图时习惯按时间轴画正转10秒、停2秒、反转10秒。这个没错但只画到这一层写程序时还是容易乱。我建议多画一张“状态表”。拿搅拌机自动循环来说动作是按下启动后正转10秒停2秒反转10秒停2秒重复3次后自动停止。状态表可以这样列状态号状态名称进入条件该状态执行动作离开条件S0空闲上电或循环完成电机停止按启动且料位正常 → S1S1正转从S0来正转10秒计时到 → S2S2暂停从S1来电机停止2秒计时到 → S3S3反转从S2来反转10秒计时到 → S4S4暂停从S3来电机停止2秒循环次数未到 → S1次数到 → S0这张表画完程序基本已经写完一半。PLC的扫描机制天然适合“当前处于哪个状态”这种离散逻辑而不是像继电器回路那样靠线圈互锁硬凑。把连续动作切成一连串离散状态每个状态只做一件事转移条件清清楚楚这才是PLC编程里最核心的思维方式。2. 实例一搅拌机自动循环程序状态机在PLC里的落地需求拆完状态表画完下面才进入写程序的环节。这个实例我以西门子S7-1200为例因为博途里支持SCL语言写状态机比梯形图直观得多。但思路对任何PLC都通用三菱、欧姆龙、信捷、汇川都是同一套东西。2.1 手动/自动双模式公共逻辑怎么搭设备一般都有手动和自动两种模式。手动模式用于调试、单步操作、检修自动模式用于生产。两类模式如果搅在一起写程序很快就会变成蜘蛛网。我的做法是公共程序放最前面负责处理急停、模式选择、报警汇总、复位逻辑。手动程序和自动程序分别放在模式判断之后二者互斥执行。IF 急停未按下 AND 模式_自动 THEN // 自动程序跑状态机 Auto_Run(); ELSE // 手动程序或停机逻辑 Manual_Control(); END_IF;注意手动模式不等于可以胡来。手动时正转和反转也要互锁该有的限位保护、过载保护一个不能少。手动只是把状态机暂停不是把安全逻辑全关了。2.2 用转移条件驱动状态而不是用定时器硬凑以前见过一个同行写的自动循环一个定时器T37正转10秒时间到T38暂停2秒时间到T39反转10秒……五个定时器串起来看着也能跑。问题在哪如果中途急停再恢复时这些定时器状态全乱了程序不知道当前跑到哪一步可能直接又从某个中间状态继续设备动作完全失控。状态机就不怕这种问题。当前状态编号是唯一的中断后从状态编号就能判断设备现在该干什么。用SCL写一段核心状态切换CASE #Step OF 0: // 空闲 IF 启动按钮 AND 低料位正常 AND 急停未按下 THEN #Step : 10; #CycleCount : 0; END_IF; 10: // 正转 搅拌正转 : TRUE; 运行指示 : TRUE; IF #Ton1.Q THEN #Step : 20; END_IF; 20: // 暂停 搅拌正转 : FALSE; 搅拌反转 : FALSE; IF #Ton2.Q THEN #Step : 30; END_IF; 30: // 反转 搅拌反转 : TRUE; 运行指示 : TRUE; IF #Ton3.Q THEN #Step : 40; END_IF; 40: // 暂停 搅拌正转 : FALSE; 搅拌反转 : FALSE; #CycleCount : #CycleCount 1; IF #CycleCount 3 THEN #Step : 0; ELSE #Step : 10; END_IF; END_CASE;定时器在这里只是“状态停留够久”的判定条件不决定程序下一步去哪。状态下一次去哪完全由状态转移逻辑决定。这样即使从中间某个状态掉电上电后也能根据当前状态恢复程序的行为是可预测的。2.3 联锁、报警、急停把“安全逻辑”单独放这个是很多入门程序最薄弱的地方。搅拌机两个方向的接触器如果同时吸合轻则跳闸重则烧电机。所以除了程序里互锁硬件上必须把正转接触器和反转接触器的常闭触点互相串在对方线圈回路里这叫电气互锁。程序互锁加电气互锁两道保险缺一不可。报警逻辑要单独放不要散在每一步状态里。做法是做一个报警处理FC或FB把高料位、过载、急停、变频器故障全部汇总进去输出一个通用“故障”标志再配合一个故障代码字。这样触摸屏上报故障直接读故障代码就行不用去翻几十个中间继电器。急停逻辑我建议在硬件回路上直接串急停常闭触点切断动力电源PLC程序里只做状态复位和故障显示。真正的安全保障靠硬件软件是第二道。PLC程序可以在急停按下时把输出最终全部置为FALSE但接触器能不能断开还是要看硬件回路。2.4 什么时候需要封装成FB/FC顺带聊信捷和西门子的区别项目里如果有多台搅拌机逻辑一模一样图省事的做法是复制粘贴。但改一个参数时得改好几处漏改一处就麻烦。正确做法是把搅拌控制逻辑封装成一个FB功能块带背景数据块实例化三次每台设备一个背景数据块。封装FB的思路是输入变量给启动、停止、模式、料位等外部信号输出变量给正转、反转、报警等输出内部的定时器状态、步号存在背景数据块里互不干扰。信捷PLC现在也支持FB块操作方法和西门子博途很像新建FB定义引脚变量把逻辑写进去然后在主程序里调用并分配实例。汇川基于CODESYS的InoProShop也是类似做法。所以我现在写程序前会先想想这个逻辑以后会不会被重复使用会的话第一次就封装成FB。这东西不怕多做就怕项目后期想改却发现全是一坨重复代码。3. 实例二伺服定位工位PLC控制伺服电机的完整思路搅拌机偏逻辑控制伺服定位工位则更偏运动控制。很多工程师一听到伺服就紧张其实伺服控制拆开来看也就是“回原点、定位、复位”这几件事关键是参数和思路。3.1 动伺服之前先把这几个参数定死伺服系统由PLC、伺服驱动器、伺服电机三部分组成。PLC负责发脉冲或走总线指令驱动器负责闭环控制。动手写程序前必须先把机械传动链的参数算清楚。最常见的脉冲控制模式下要先确认几个东西PLC输出脉冲形式是“脉冲方向”还是“双脉冲”输出是NPN还是PNP伺服驱动器的输入接口匹配哪一种方向信号是高电平有效还是低电平有效这些不确认接完线大概率方向反或没反应。再就是电子齿轮比这个直接决定定位准不准。举个例子伺服电机编码器是2500线4倍频后每转10000个脉冲丝杆导程10毫米也就是电机转一圈工作台移动10毫米。如果希望PLC每发1000个脉冲工作台移动1毫米那么驱动器电子齿轮比就要按照“电机实际需要的脉冲数/上位机发的脉冲数”去换算。每个驱动器参数定义不同但计算逻辑都是这样拿到项目先算这一步不要凭感觉填。3.2 回原点三种方式怎么选伺服定位工位开机第一件事基本都是回原点。回原点方式用得最多的是三种近点狗方式设备上装一个原点开关回原点时先快速往原点方向跑碰到原点开关后减速直到离开开关或找到电机Z相脉冲停止。这种方式行程大、精度好适合大多数设备。Z相方式不装原点开关靠电机编码器每圈一个Z相脉冲定位。回原点速度可以做很快因为Z相脉冲重复精度很高但要保证每次停止位置和机械原点有固定对应关系。直接回零方式直接往限位方向开撞到限位后回退一点把机械限位当前位置当原点。简单便宜但精度一般适合原点精度要求不高的场景。不管用哪种方式回原点一般分两段速度先高速接近再低速找原点。高速提高效率低速提高重复精度。这段逻辑用状态机写同样清爽回原点本身就是一个状态机。3.3 轴启动、位置到位、异常复位三段逻辑怎么组织伺服控制程序我习惯分成三段独立逻辑使能管理、运动使能、异常处理。使能管理负责伺服上电、抱闸释放、急停时断电。这里注意顺序使能没建立之前绝对不能发脉冲抱闸没打开之前垂直轴绝对不能运动。很多垂直轴设备掉料就是程序在抱闸没打开时就松了使能。运动使能负责具体执行定位动作。以S7-1200的工艺对象为例定位指令一般是MC_MoveAbsolute指定目标位置和速度运行前要判断轴是否已回原点方向对不对。到位判断不要只看“速度为零”或“Moving信号消失”最好同时比较实际位置和指令位置的差值是否在允许范围内这样能避免电机堵转时误判到位。异常处理负责伺服报警、跟随误差过大、限位触发的复位。伺服报警信号一般要接入PLC的输入点或者在总线报文里读取报警状态。程序里要有个“报错清除”机制故障排除后操作工按复位先清除轴报警再重新回原点然后才能继续生产。3.4 现场调试伺服时最容易翻车的三件事第一件方向全反。第一次试跑先用手轮或点动功能让电机慢速转一小段距离确认方向。别一上来就输一条很长距离的绝对定位方向反了可能直接撞机构。第二件电子齿轮比算错。现象是位置偏一点点或偏很多但速度始终对不上。重新按编码器分辨率和机械传动比算一遍用笔写在纸上再填到参数里。第三件脉冲频率超过PLC和驱动器允许的上限。高速运行时丢步定位偏差时有时无。把速度和加减速时间算好确认最高脉冲频率低于PLC高速输出口的极限也别超过驱动器光耦输入的最大频率。加减速太猛也会丢步伺服不是步进但匀加减速时间给得太短同样会出问题。4. 实例三PLC和外部设备的通讯程序不能按扫描周期去理解现在越来越多的项目不是PLC孤军奋战上面有MES、视觉相机旁边有变频器、机器人。通讯程序是新手最容易卡住的地方因为它和普通逻辑控制有个本质区别PLC扫描是周期的通讯数据却是异步到达的。4.1 通讯和逻辑控制最大的不同数据是异步的PLC执行程序每秒钟扫描很多次一次扫描从第一行跑到最后一行。但通讯不一样外部设备什么时刻把数据发过来完全是随机的。如果你在程序里假设“上一条指令读到的数据下一条指令再用时一定还是那串数”那通讯一旦抖动逻辑就会抽风。正确的处理方法是把通讯收发和业务逻辑分开。通讯程序只管收到数据放到缓冲区发送数据时从缓冲区取业务逻辑只和缓冲区里的稳定数据打交道。接收缓冲区最好定义成独立的字节数组或结构体收到一帧完整报文后再整体校验、解析不要一边收一边用。4.2 汇川EVO523做TCP客户端的程序组织连接管理、心跳、数据帧汇川EVO523做TCP客户端典型场景是连上位机MES系统或者视觉电脑。程序组织看起来不难但要把连接状态管理好。我是这样组织的第一步初始化建立连接设定远程服务器的IP和端口PLC主动去连。第二步连接成功后PLC作为客户端周期性地往服务器发送数据同时接收服务器的下行报文。第三步维护一个心跳机制比如每500毫秒发一次心跳包连续几次没收到服务器的回复判断通讯断开置位通讯故障同时尝试重连。这里分享一个实际工作经验不要去写那种“连不上就死循环重连”的逻辑一旦服务器宕机PLC会卡在重连逻辑里连现场操作都受影响。正确做法是重连也要有节制的周期比如每2秒尝试一次并把“通讯故障”这个状态交给操作界面显示让维护人员知道是通讯断了而不是设备程序死了。数据帧格式一定要在写代码前和上位机工程师定死大小端、浮点格式、帧头帧尾、校验方式、数据长度。项目里一半的通讯问题其实都是格式理解不一致不是代码问题。4.3 康耐视相机与西门子S7-1200走Profinet的通讯要点视觉检测和PLC通讯同样绕不开数据格式的坑。康耐视InSight相机与西门子PLC走Profinet和普通PN从站一样鼎鼎有名的流程是在博途里安装相机的GSDML文件设置唯一的设备名称和IP地址然后组态输入输出区长度。这里最容易弄错的是“设备名称”。Profinet通讯认的不是IP而是设备名称。相机侧填的Profinet设备名必须和博途组态里分配的名称完全一致大小写都得一样名称对不上哪怕IP通了也进不了运行状态。我用过不少相机和PN远程IO遇到过不下三次“明明网络能PING通但PLC就是报从站故障”最后查出来都是设备名不一致。通讯组态完成后相机触发结果怎么到PLC一般来说PLC往输出区写一个字节某一位作为触发信号相机检测完成后把结果OK/NG、测量值、图片编号等映射到输入区PLC读取输入区对应字节或字解析。程序里最好做一次数据有效性判断比如连续读到两次相同结果才认定检测有效避免相机通讯瞬时抖动导致误判。4.4 通讯联调的铁律先通链路再验数据最后再接业务通讯程序调试我有个铁律分三步走绝不跳过。第一步先单独验证两端。用网络调试助手之类的工具模拟服务器PLC先试试能不能发数据、收数据相机那边用相机自己的软件单独触发测试确保相机本身能出结果。不要PLC、相机、上位机三台一起上出了问题根本不知道是谁的锅。第二步两端物理连起来但不做业务。先看PLC和相机Profinet通讯状态是不是绿色再在PLC监控表里直接看输入区字节是否跟着相机输出变化。数据能对上了再进入第三步。第三步才把通讯数据接入业务逻辑比如检测结果为NG时把不良品剔除。接业务前先在实验室把各个分支动作都模拟一遍确认没问题再上产线。这套流程多花不了多少时间但能帮你从“不知道哪坏了”变成“一看就知道是哪个节点的问题”。调试通讯最忌讳的就是跳着步骤来一通乱试。5. 程序能跑只是第一步调试与信号问题排查链路程序写得再顺到现场总会冒出各种稀奇古怪的现象。尤其是“程序明明没问题设备就是不动”这种十有八九出在信号链路而不是程序逻辑。5.1 NPN/PNP输出接PLC公共端接线前要搞懂的电流方向这个话题老生常谈但现场依然天天踩坑。先记住一条根本原则NPN输出是低电平有效电流从外部负载流进输出管PNP输出是高电平有效电流从输出管流到外部负载。以外部设备输出NPN脉冲接到西门子PLC为例NPN输出管导通时把信号线拉到0V。如果PLC的输入公共端接在电源正24V那么电流从PLC公共端流出经过输入信号灯流入NPN输出管到0V形成回路PLC输入点才会亮。这也就是热搜里说的“NPN输出PLC公共端接电源正”的接法依据。反过来如果你接的是PNP输出公共端就得接0VPNP管导通时把信号线拉高到24V电流回路才能建立。实际接线前最稳妥的办法还是翻PLC输入手册看这个型号到底支持源型输入还是漏型输入再结合传感器/驱动器输出类型决定公共端怎么接。别嫌麻烦接错一根线轻则信号不亮重则烧输入点。5.2 急停和故障信号到底用常开还是常闭这个问题现场几乎每周都会有人问。急停按钮我强烈建议接常闭触点。急停回路用常闭触点串在硬件接触器回路里正常时触点闭合急停按下时触点断开整个动力电源被切断更关键的是如果急停线断了回路同样断开设备一样会停这叫断线安全。如果接常开线断了反而发现不了急停就形同虚设。PLC程序里对急停信号的处理逻辑要反过来输入信号为1表示急停正常未按下信号变为0表示急停被按下或断线。然后把这个信号用于状态复位、输出封锁。普通故障信号比如过载、限位一般用常开。传感器不动作时触点断开动作时触点闭合。但要注意常开信号无法识别断线。对安全等级要求高的设备现在会采用安全PLC或双通道检测对普通单机设备常开信号配程序判断已经能满足绝大多数需求。5.3 设备不动时的排查链路信号、接线、地址、逻辑遇到“设备不动”先别急着怀疑程序。我一般按下面这个顺序查每一步都等一下再下结论先看输入信号有没有进PLC按启动按钮看PLC输入点的指示灯亮不亮或者在线监控里对应Bit位有没有跳变。灯不亮就是信号没进来查传感器、开关、接线。再看地址映射对不对信号亮了对但程序里用的地址是不是这个输入点很多人程序里写I0.3实际接到I0.4信号怎么按都没反应。交叉引用查一下最直观。再看输出有没有发出逻辑通了但Q0.0有没有输出用万用表量PLC输出端子有没有电压。有输出但电机不转大概率中间继电器、接触器或者接线问题没输出才往程序里查。最后才查程序逻辑前面的都没问题那再回头看状态机卡在哪一步联锁条件是不是被某个报警触发了。这个顺序看起来傻但真能节省大量时间。我见过有人花了两个小时找程序Bug最后发现是PLC输出端的保险丝烧了。5.4 在线监控的活用监控表、程序状态、交叉引用在线监控不是只看梯形图有没有变蓝。“监控表”是我用得最多的工具可以把关键状态、关键地址、要观察的数据放在一个表里集中看。调试搅拌机时我会把当前步号、循环次数、各个报警条件放到监控表一眼就知道设备卡在哪一步、差哪个条件。“交叉引用”用来查地址的可视化是最强的怀疑一个中间继电器到处被引用点一下交叉引用所有调用它的网络全列出来。程序改起来也不怕漏。“程序状态”在线时可以看到每个触点当前是TRUE还是FALSE但注意在线看的是程序执行前的状态还是执行后的状态不同PLC显示逻辑有差异别被瞬时值误导。对于边沿信号用监控表配合“示波器”功能才能抓到脉冲过程单纯看常亮状态会误判。6. 编程习惯和工具选型PLC程序员和电气工程师的分水岭同一个设备两个人写的程序都能跑但三个月后谁的程序能被别人顺利接手差别非常大。编程的思想、习惯和工具选择决定你能走多远。6.1 命名、注释、地址档案三个月后的你还能看懂吗程序里最怕“I0.0”“M0.0”满天飞没有任何注释。自己的程序三个月后自己都可能看不懂更别说同事。我的习惯是变量名必须能读出来含义不要叫A001、B002注释写“这个触点干什么的为什么这样写”不要说没用的话I/O地址规划表、状态表、通讯协议文档全部放进项目文件程序可以换人写文档不能丢。还有一个细节程序里所有报警、步号、设备状态尽量做成符号名统一管理。比如“电机过载”“急停未按下”“状态_正转”以后触摸屏组态、上位机通讯对接都会方便很多。6.2 梯形图、SCL/FBD怎么选PLC到底有没有开源IDE语言选择没有绝对标准我的经验是纯逻辑控制、现场维护电工经常看的程序梯形图最友好因为它和继电器电路长得像复杂计算、数组处理、通讯报文解析用SCL/ST类语言写效率高得多模拟量处理和PIDFBD图形化更直观。很多人问PLC有没有开源IDE。坦白说现在主流工业PLC的编程环境基本还是厂家生态西门子博途、三菱GX Works、欧姆龙Sysmac Studio、信捷XDPPro、汇川InoProShop等等都是商业软件。开源社区有OpenPLC这类项目可以拿来学习PLC编程思想、做实验室原型但真正上工业现场的项目用厂商IDE仍然是主流和稳妥的选择。从趋势看CODESYS这类开放式开发环境在国产PLC上用得越来越多汇川、信捷都在靠拢对工程师来说是好事会一种CODESYS风格的环境换平台上手会快很多。但底层思路没变状态机、结构化编程、FB封装走到哪里都用得上。6.3 程序架构的通用套路公共程序打底、状态机做骨架、手动自动分离最后总结一下我自己用下来的通用程序框架。最外层是主程序OB1尽量简洁只做块调用。里面按顺序摆四块公共逻辑模式选择、急停、报警汇总、复位、手动逻辑、自动逻辑状态机或工艺动作、通讯逻辑。设备级的动作尽量封装成FB/FC电机、阀、伺服轴都可以封装外部信号全走接口内部状态全存在背景数据块。这样主程序看起来就是一张目录调试时能点进对应功能块细查维护时也能快速定位。这套架构唯一的问题是前期搭建要花点时间但项目越大后期省的时间越多。我做过的几十个设备项目凡是前期结构搭得好的后期全是平稳交付凡是“先写两行试试”的后期基本都在补洞。做了这么多年PLC项目我最深的体会是程序写得漂亮不漂亮是次要的能不能在断电重启后保持清晰状态、能不能被别人快速接手、能不能在设备出故障时快速定位这才是关键。以上这些思路是我接到新项目时固定会走的流程先开会捋需求再画I/O表和状态表然后搭程序框架最后才写具体逻辑。每一步看起来都在“浪费时间”但恰恰是这些时间换来了现场调试时的心安。如果你也有类似的调试经历或者更好的编程思路欢迎一起交流这行就是靠着一次次的实战经验往前走的。