聊起托盘输送机程序我第一反应不是代码也不是梯形图而是现场那些莫名其妙的“鬼故事”托盘走到一半不动了、顶升移载机把托盘顶歪了、明明后方没托盘但程序说堵了……这些破事儿十有八九不是机械问题而是程序逻辑设计的时候少了根弦。托盘输送机这东西单看机械结构不算复杂无非是辊筒线、链条线、顶升移载机、阻挡器、光电传感器这些积木但程序一写起来牵扯到的状态管理、时序控制、异常处理水比你想的深得多。这篇东西我想按自己这几年调托盘线的经验把托盘输送机程序从设计思路到落地细节整个捋一遍。适合刚入门干PLC、被分配去调物流线的兄弟也适合那些写了好几年程序但主要在单机设备上、没怎么碰过复杂流转逻辑的工程师。我会尽量用大白话讲清楚托盘输送机程序到底在管什么、核心逻辑怎么搭、哪些细节是坑、真出问题了怎么排查。看完不敢说你马上能写出完美程序但至少现场出毛病的时候你能像个老手一样有章法地找问题。1. 托盘输送机程序的核心不是在控电机是在管状态很多人拿到托盘输送机的需求脑子里第一件事就是“我要控制哪几台电机、哪几个气缸”。这思路对了一半但容易把自己带沟里。托盘输送机和普通皮带线最大的区别在于它运送的不是散料而是带“身份”的载具——也就是托盘。这意味着程序的核心任务从来不是“启停电机”而是“管理托盘的状态”。托盘现在在哪个位置、它要去哪个工位、当前该不该放行、它到了分流口该往哪走、下一段输送机有没有空位这一连串问题才是程序真正要回答的。1.1 把“交通调度”思路搬进PLC我习惯把一套托盘输送系统比作一个多车道的城市道路网。托盘就是汽车输送段是车道阻挡器是红绿灯顶升移载机是立交桥的匝道工位是停车场。你要做的程序就是一套交通调度系统哪个车道能让车走、哪个路口该变灯、哪辆车该从哪个匝道出去、停车场满了要不要让后面的车等着。这么一想你就知道优先级最高的不是电机的启停逻辑而是道路状态的判断。一条输送段能不能让托盘进去要同时满足三个条件第一这个托盘在当前段确实到位了第二下一段是空的没有托盘占着第三下一段没有处于“禁止进入”的状态比如顶升移载机正在动作或者下游工位正在处理。这三个条件缺一个阻挡器就不能抬起来放行。这也就是业内常说的“占位逻辑”和“握手逻辑”。我见过不少新手写程序图省事直接“传感器有信号就抬手放行”结果就是后端一堵托盘全挤在中间段的定位器上要么把机械顶坏要么托盘互相推挤导致货物倾翻。所以程序的第一步永远是把每段输送机的状态搞清楚。1.2 托盘身份的“记忆”问题更麻烦的一点是托盘是有“身份”的。产线上往往有几十上百个托盘每一个可能挂了不同的物料、要去不同的工位、有的需要称重、有的需要贴标、有的需要机器人抓取。程序怎么知道当前过来的这个托盘是什么类型、该干什么这就需要给托盘一个“号码”并在程序里给它建一条“档案”。托盘识别方式常见有三种第一种是物理编码像RFID卡或条码到读码站就扫一下第二种是逻辑编号靠托盘在输送线上固定的流向和位置用PLC内部寄存器记录“几号位现在放的是第几号托盘”第三种是纯粹位置跟踪无法识别具体身份只能靠先后顺序“猜”。程序设计的水平差距往往就体现在这里。你需要在数据块里维护一张“托盘状态表”记录每个托盘号当前所在区段、目标工位、已经完成的工序。每当托盘跨过一段输送机状态表就得跟着更新一次。2. 程序骨架怎么搭先定数据区再写逻辑块讲完了思想落到实际编程。我强烈建议先做数据规划再写逻辑不然到后面逻辑多了数据一乱调试能调到你怀疑人生。托盘输送机程序我习惯拆成五层IO映射层、状态感知层、决策调度层、执行输出层、报警监控层。2.1 IO映射层让你自己好过一点PLC的输入输出地址都是物理地址谁也不想编写程序的时候满脑子都是I0.0、Q0.3这种数字。设备改造或者换点位的时候更是改得头皮发麻。所以第一层一定是把物理IO映射到内部变量比如光电开关拉到“R_F1_Occupied”R1段到位信号阻挡器输出拉到“R_F1_StopperOut”。这样后面写逻辑、看程序、查故障人脑处理的是“R1段有没有托盘”而不是“I0.0到底是哪个传感器”。别小看这一点等到现场排查的时候变量名起得好 效率翻倍。2.2 状态感知层每段输送机就一个“占位”和“放行”这一段是核心中的核心。每一条输送线段无论长短我在程序里都给它定义两个基本状态占用状态Occupied和放行状态Release再加上一个堵塞状态Jam。占用状态来自该段的传感器信号但要注意不能用单个传感器点直接当占用状态因为托盘在输送机上是移动的传感器信号会断断续续。正确做法是“置位-复位”方式当入口传感器检测到托盘上升沿就置位“本段占用”位当托盘离开下一段的入口传感器或本段出口的离开传感器时再复位占用位。这样做的好处是状态稳定不会因为托盘停在两个传感器中间就误报“本段空”。放行状态则是一个综合判断结果我通常单独用一个功能块去算条件大致如下本段已有托盘到位且停止位置已到下一段没有占用或者正在复位下一段的放行禁止信号为假比如下游工位急停、下游设备在动作如果是分流口还要加上“路径已指定且方向切换已完成”这个条件。这些条件全满足阻挡器抬手放行。条件一旦不满足立刻复位放行输出阻挡器保持关闭状态。这个逻辑我用SCL写的简洁并且可读性强现场改逻辑也方便。给一段示意IF DB.HMI_ManualMode FALSE THEN // 自动模式下的放行条件 IF IO_DI.Sensor_F1_Occ AND DB_Status.R2_Occupied FALSE AND DB_Status.R2_Release_Disable FALSE THEN IO_DO.Stopper_F1 : TRUE; // 抬手放行 ELSE IO_DO.Stopper_F1 : FALSE; // 放下阻挡 END_IF; END_IF;2.3 决策调度层分流的入口判断托盘输送线最需要“动脑子”的就是分流位置比如顶升移载机入口。托盘到分流口前程序必须在托盘到达之前就知道往左还是往右而不是等托盘到了才去读条码再决定。那样节拍根本来不及。我的做法是在分流口的前一段就把目标地址算好然后把“路径命令”传给分流口。相当于公交车到站前调度中心已经告诉司机该走哪条道了。具体实现上就是每个托盘在进入分流段之前程序读它的条码或者查表把目标方向存进一个变量“R_Fork_TargetDir”然后当托盘到达分流口定位位置时先执行顶升和方向切换再抬手放行。一定要记住路径切换必须早于放行绝对不允许顶升还没到位、叉臂还没挪过来托盘已经怼上去了。3. 真正的硬骨头几个必须抠死的细节环节骨架搭好之后真正决定一台设备好不好用、调试顺不顺利的往往是细节。我挑几个最典型、最容易翻车的环节细讲。3.1 抬手与积放的微观时序阻挡器Stopper的动作看着就是“抬起来、放下去”但里面的时序坑能让人哭。常见的错误是托盘刚离开阻挡器PLC检测到离开信号立刻把阻挡器放下结果托盘很长尾部还没完全通过阻挡器下降时直接砸在托盘尾部轻则卡住重则把货物颠下来。正确的时序应该是检测到托盘离开阻挡器后延时一小段时间确保托盘尾部完全通过阻挡器位置再下放阻挡器。延时长短取决于托盘长度和输送线速度一般我按“托盘长度 ÷ 线速度 × 系数1.2”来算系数1.2是安全余量。举个例子托盘长度1.2米线速度0.15m/s那么理论通过时间是8秒安全起见延时设置在9.5到10秒比较稳妥。但实际调试时多数工程师直接拿秒表掐在现场抬几次阻挡看视觉效果然后再加个0.5秒保底。积放逻辑同样要注意托盘输送机最头疼的就是“阻塞”状态。当前方工位慢了托盘没地方去后面的托盘就得在中间某段排队。程序要识别这个“排队”状态不能让后面托盘一直顶上来把整条线堵死。我一般会在每段输送机设一个“堵塞憋停”距离当后段的占用信号持续为真且本段也有托盘正在等待那就让前一段停止送出。说白了就是高速公路上的“缓慢通过”和“停车等待”之间的切换逻辑。3.2 顶升移载机的动作连锁顶升移载机是托盘输送线里故障率最高的设备尤其是气动顶升加气缸横移那种结构。程序上最大的忌讳就是“抢动作”上一组动作还没完全复位下一组动作就开始了。我开始做这个的时候吃过亏顶升气缸上升到一半横移气缸已经推出结果把托盘直接掀翻了。后来我给自己定了一条死规矩所有动作都要有“到位确认”之后再进下一步。顶升气缸要装磁性开关上升到位信号给到才允许横移前进横移前进到位才允许顶升下降顶升下降到位才允许阻挡器放行。每一步都在等上一步的反馈绝不让程序“想当然”地认为气缸已经到位了。同时一定要给每个动作加上超时报警。比如顶升气缸上升动作发出后5秒内没收到到位信号程序不能傻等而是要停在该状态、弹出报警提示操作人员去查气缸是不是卡住了、气压是不是不够、磁性开关是不是坏了。没有超时保护的连锁逻辑本质上就是一颗定时炸弹。3.3 掉电记忆摸不清的“断点续传”托盘输送机上最容易被忽略的问题之一就是掉电恢复。试想一下产线正跑着突然啪一下停电了几十个托盘散落在各段输送机上。重新上电之后程序如果从零开始全自动运行可能直接让十几个托盘同时动起来轻则堵在一起重则撞坏设备。正确的做法是在每次托盘状态变化时将关键数据写入PLC的掉电保持区比如S7-1200的保持性DB块。重新上电后程序应该先进入“恢复模式”检测每条输送段上有没有托盘、托盘号是多少、当前位置在哪、之前在干什么。然后通过HMI人工确认后再逐步恢复自动运行。这个逻辑写起来不复杂但很多人偷懒不做最后就是现场每次停电都要人工把托盘一个个搬下来重新排惨不忍睹。3.4 计数器的陷阱别让脉冲信号骗了你托盘输送机上最常见的传感器是光电开关和对射开关。但这些传感器在实际工况下信号并不干净。托盘带着货物跑起来会有振动、会有反光、会有瞬间遮挡传感器输出可能产生毛刺信号。程序里如果直接用这些信号去计数、去判断托盘数量十有八九会数错。处理办法很简单信号滤波边沿锁定。我在程序里对每个关键输入都做了“持续确认”处理也就是信号要连续保持N个扫描周期比如50ms以上才认为信号有效。这样做的好处是抗干扰坏处是响应会慢一点点但对于输送机这种几十到几百毫秒量级都无所谓的场合完全值得。计数上升沿之前先把滤波后的信号拿来“找边”而不是拿原始信号找边这是我早年踩坑踩出来的经验。4. 实操实录手写一套振盘分拣输送逻辑光讲理论比较虚我拿一个实际项目来拆解。这条线是给某汽配厂做的振盘分拣线一共7台振盘上料机每条振盘线把物料输送到主线上托盘的工位就相当于一个移动工装台机器人抓取完物料之后空托盘继续往下走。程序逻辑的关键在于“托盘到位后要顶起、定位、然后给机器人发出抓取信号”而且每台振盘的托盘到位信号要和振盘的出料时机配合好。4.1 IO规划先噼里啪啦列出来我当时先建了一张IO表把所有输入输出列全了——7个工位的托盘到位传感器、7个顶升气缸、7个定位气缸、7个阻挡器主线电机2台分支气缸2个再加上各种磁性开关、急停、模式选择开关。光IO表就列了大几十个点。规划阶段把这表整明白了后面写程序就是在填表格的事。举几个例子工位1到位传感器Sensor_G1_Occ工位1阻挡器输出Stopper_G1工位1顶升气缸上升输出Lift_G1_Up工位1顶升气缸上升到位Lift_G1_UpSNS工位1顶升气缸下降到位Lift_G1_DnSNS工位1定位气缸输出Clamp_G1_Out工位1定位气缸伸出到位Clamp_G1_OutSNS工位1定位气缸缩回到位Clamp_G1_RetSNS4.2 主流程写起来状态机是必须的托盘从主线过来到达工位1定位点后第一步是阻挡器挡住第二步检查工位是否空闲——空闲就执行顶升定位第三步等到顶升定位完成发“托盘就位”信号给机器人第四步机器人抓取完成发“抓取完成”信号第五步程序缩回定位气缸、顶升下降、阻挡器放行托盘离开。这里每一步之间都是严格的状态流转我用顺序功能图SFC来实现就很清晰。如果用梯形图硬写串行逻辑到后来互锁条件一多程序根本没法维护。SFC的好处是你能很直观地看到当前执行到哪一步、为什么停住排查故障的时候友好太多了。部分状态机逻辑示意简化版CASE state OF 10: // 等待托盘到位 IF sensor_g1_occ THEN state : 20; END_IF; 20: // 托盘顶升定位 stopper_g1 : TRUE; IF clamp_g1_outSNS AND lift_g1_upSNS THEN robot_ready : TRUE; // 告知机器人可以抓取 state : 30; END_IF; 30: // 等待机器人抓取完成 IF robot_done THEN robot_ready : FALSE; state : 40; END_IF; 40: // 复位动作并放行 clamp_g1_ret : TRUE; lift_g1_down : TRUE; IF clamp_g1_retSNS AND lift_g1_dnSNS THEN stopper_g1 : FALSE; state : 10; END_IF; END_CASE;4.3 节拍计算程序到底该多快托盘输送机的程序好坏最终看节拍能不能满足产能。节拍计算其实是设计阶段就要做的。我先算出单托盘从一个工位到下一个工位的最短时间然后看能不能满足客户要求的每小时产量。举个例子客户要求每小时240件也就是单件节拍15秒。如果托盘从工位1到工位2的输送时间就要10秒工位2的机器人抓取又需要8秒那么工位2的节拍就是18秒——这已经超了。这时候你就得想办法要么提高线速度缩短输送时间要么做缓存位让托盘提前等待要么抓取动作和输送动作部分重叠。这些虽是设备设计的活儿但程序得留出配合这些方案的控制接口否则设备造出来节拍对不上最后还是程序员的锅。4.4 拿来就能用的“抬手放行”功能块我把一段输送机的抬手放行逻辑打包成了一个功能块输入是“本段到位信号”“下段空闲信号”“下游禁止信号”输出是“阻挡器控制”。核心逻辑就是我一直强调的“三条件握手”。写成一个功能块之后主线每次加一段输送机直接拖一个实例出来简单省事出错的概率也大大降低。这种模块化思维我强烈建议写输送线程序的朋友都试一试。5. 调试现场常见问题与排查技巧实录程序写完了真正的战斗才刚开始。调试现场你永远会遇到各种奇奇怪怪的问题这里我整理了一张问题速查表都是我自己实际踩过的坑。现象可能原因排查思路托盘到定位点不停直接冲过去到位传感器没检测到、传感器位置偏移、放行逻辑提前满足用PLC监控看传感器状态手动模式下让托盘慢速跑一遍观察到位信号有没有上升沿托盘卡在顶升移载机上顶升时序没等确认、气缸不同步、机械卡滞查动作时序把每一步的到位信号都拉出来看是不是抢动作了同时检查气路压力计数错乱托盘“凭空消失”或称“多了一个”传感器抖动、信号滤波不足、掉电数据丢失检查输入点有没有加滤波延时把计数变量改成保持型上电复位逻辑重新做阻挡器下放太早砸到托盘尾部离开信号到释放阻挡的延时太短延长托盘完全通过阻挡器后的释放延时验证托盘尾部完全通过后再放多台上位机通信偶尔中断PLC程序卡死通信状态没做超时监控在程序里加通信心跳监测通信中断后自动停机或等待不要继续跑程序上电后所有托盘同时动没有上电恢复策略加“上电复位状态”先急停所有输出人工确认后再自动恢复5.1 一个真实的“灵异”案例有次调试现场反馈说2号工位定位气缸总会偶尔不伸出导致托盘顶升机构把托盘顶起来但定位销没插进去托盘在空中晃货物差点掉下来。查机械半天没问题看程序每次都觉得逻辑是对的。后来我用PLC的在线Trace功能把整个时序录下来才发现问题出在“顶升气缸上升到位”和“定位气缸伸出命令”之间有大概80毫秒的真空期工控机在中间插了一条指令把定位气缸的阀给短暂断电了。这不是逻辑错误而是程序对气缸“保持输出”的影响——只要某个瞬间输出被其他扫描周期的代码覆盖成0现场就能表现为偶尔抽风。从那以后我给自己定了一条规矩气缸控制输出全部采用“置位/复位”方式而不是每次扫描周期都去“赋值”避免其他逻辑覆盖输出。5.2 别忽略传感器安装位置传感器位置这件事程序调不动但程序能帮你发现问题。很多时候你去看现场发现传感器装得太靠近输送段的边界托盘稍微跑偏传感器就时通时断程序一会儿认为“有托盘”一会儿又认为“没有托盘”。你查程序查到天荒地老最后才发现是传感器位置的问题。所以调试第一步我建议先手动跑一遍确认每个传感器的覆盖范围和盲区都符合要求再开自动。这一遍的功夫省不掉省了后面全是工事。6. 写给刚入行的你程序之外的那几件事说实话托盘输送机程序本身没有太多“高精尖”的东西不会像伺服运控那样让人掉头发。但它的复杂在于“组合爆炸”——几十个段位、几十个阻挡器、十几个顶升移载机互锁条件的数量是几何级增长的。你不可能靠“背下来”搞定它只能靠结构。把数据结构建清楚、把逻辑分层分块、把每一步状态都收干净程序就成功了一半。另外我觉得这行最重要的习惯就是“留后路”。程序中要留手动模式、维护模式、单步模式这不仅是调试需要更是客户以后日常维护的心头好。没有手动模式你就等着每次出故障都被客户电话轰炸吧。写程序的人必须设身处地想一想现场维护的兄弟怎么操作一个好的输送线程序应该让操作工能靠报警文字和功能说明自己解决80%的故障。最后分享一个我自己的习惯每个报警除了文字说明一定加上“处理建议”。比如“R3段堵塞超时请检查R3段是否卡料、传感器是否被遮挡”。别小看这句话现场的人会真的一辈子感激你。程序写得再漂亮没有一套好用的报警体系验收的时候照样被客户指着鼻子骂。托盘输送机这东西看起来是“傻瓜设备”但程序写好了它能替现场省下无数麻烦写不好它就是你们公司售后工程师的长期饭票。希望这篇东西能帮你在设计阶段就躲开那些暗坑少去现场多睡觉。