做物流自动化项目的工程师应该都有同感一条料箱输送线真正难的从来不是把电机转起来——正反转、变频调速、光电互锁这些东西随便一个老牌PLC的技能树都能覆盖。真正让人掉头发的是WCS和PLC之间那条Socket接口以及建立在它之上的合流、分拣控制逻辑。我最近刚从某仓储项目的料箱输送线调试现场撤回来趁着细节还热乎把这条线从布局分工、通信协议到分拣跟踪的完整思路写下来。这篇文章不会讲基础概念重点放在“精华部分”——WCS和PLC的Socket接口设计、分拣控制程序的跟踪与命中逻辑合流也会单独拿出来讲因为在物理上合流就是分拣的前置战场合流逻辑搞不顺分拣再聪明也白搭。适合正在做或准备做输送线项目的电气工程师、上位机开发、现场调试人员参考看过之后你能直接借鉴报文格式、状态机划分和排障思路。1. 先从现场说起料箱输送线到底在干什么1.1 一条典型料箱线的基本物理组成和任务项目是某电商仓配中心的人工拣选改造线。上游是两片拣选区A区负责日百商品B区负责大件商品两边的操作人员把订单商品投进料箱料箱通过各自的支线汇入主线主线走一段之后进入分拣区按订单/波次分到12个滑道滑道末端对应打包工位。整个过程用一个通俗的说法就是箱子从“四面八方”来最后必须准确站到自己的队伍里。物理设备层面输送线由皮带机、顶升移载、摆轮分拣机、光电传感器、读码相机、急停与安全光幕组成。主线速度设计为1.2m/s支线速度0.8m/s分拣区摆轮速度1.5m/s。电机数量超过60个加上气缸、变频器、传感器PLC的I/O点差不多800点出头。这套规模在国内的仓配线里属于中等偏小的项目但麻雀虽小五脏俱全合流、分拣、堵包、满滑道、任务回退这些场景全撞上了。1.2 WCS和PLC的职责边界谁说了算很多第一次做这类项目的团队栽就栽在“职责边界不清”上。WCS仓库控制系统和PLC之间的分工如果定不清楚调试现场就是互相甩锅的修罗场。我在这条线上的切法是WCS管“任务和意图”。它知道每个料箱是哪个订单、应该去哪个滑道、当前任务优先级、滑道是否已满。它负责把“宏观指令”发给PLC并接收PLC回报的设备状态和任务结果。PLC管“动作和时序”。它负责电机的启停和速度、传感器信号的采集、料箱间距控制、合流让行、分拣执行、安全联锁。PLC不需要理解“波次”和“订单”——它只需要知道“某箱子的目标滑道是几号”。简单类比就是WCS是导航员告诉车“去哪个目的地”PLC是司机负责踩油门、刹车、打方向盘和躲避行人。导航员不告诉司机发动机怎么点火的司机也不需要理解导航的路径规划算法。这个边界的核心原则是一切实时性要求高、周期短于200ms的逻辑必须放PLC一切涉及业务上下文和全局优化的逻辑放WCS。Socket接口传输的任务指令到达PLC后后续几百毫秒内要完成的动作绝不能再回去问WCS否则一旦网络抖动箱子就会冲过头。2. Socket接口WCS和PLC之间的“哑巴协议”2.1 为什么选TCP Socket而不是其他方案项目最早有过两个备选方案一个是直接走PLC厂商的上位机通信库比如走S7协议另一个是OPC UA。最后全被我毙了理由很现实。OPC UA强在跨平台和数据建模但对PLC侧的程序负担重尤其老一点的中端PLC跑OPC UA服务器会让扫描周期不稳定而且授权费不便宜。厂商私有协议以S7为例确实稳定但它把双方耦合在特定品牌上。这个项目的WCS是甲方的某第三方物流软件公司做的他们手头同时要对接不同品牌的PLC统一走TCP Socket反而省事。TCP Socket本质就是两个设备之间的一条TCP连接按约定的字节流收发数据。它不挑品牌不挑语言WCS端用C#写的PLC端用结构化文本加数据块处理两端各维护一块收发缓冲区协议是自定义的“哑巴协议”——就是双方约定好每个字节的含义仅此而已。选TCP还有一个好处是调试直观。我在PLC侧把接收数据打印到调试口WCS侧开个Socket工具就能看到收发的原始报文问题定位比黑盒的OPC UA方便太多。2.2 报文格式帧头、长度、命令、数据、校验自定义报文的核心是“让双方永远不会读错”。不管上层业务多复杂报文结构必须简单、固定、可解析。我在这条线上用的报文格式如下表字段字节数说明帧头2固定0xAA 0x55用于识别报文起始防止数据流错位长度2整帧长度含长度字段本身范围限制在256字节内命令字2区分请求和响应比如0x0001表示下发任务、0x8001表示回报成功任务序号2每笔任务在WCS侧的唯一IDPLC原样带回用于两边对账数据区0~240按命令字约定不同的数据结构体校验2CRC16校验从长度字段到数据区末尾的字节防传输误码长度帧头CRC这三个加起来基本可以杜绝粘包、错帧、误码三个通信最常见的坑。WCS侧发往PLC的主要命令有三条0x0001 下发任务数据区带料箱条码、目标滑道号、优先级。PLC确认后把料箱信息映射到跟踪表。0x0002 取消任务用于WCS发现滑道已满或订单变更主动撤回指令。0x0003 查询状态WCS周期性2s一次查询线体各段的堵塞程度和任务执行状态。PLC侧回报给WCS的命令也是三条0x8001 任务回报成功命中滑道/超时异常把任务序号、结果码回传。0x8002 设备状态分拣机、提升机、输送段的运行、故障、满位状态。0x8003 心跳应答收到心跳请求后的固定应答。2.3 心跳、重连、应答通信层的三个保命机制Socket通信最大的隐患是“半连接”——网络设备或程序异常导致连接看起来还在实际已经收不到数据。TCP本身有保活机制但默认超时按小时算这对输送线完全不可接受必须自己做应用层心跳。我设置的机制是WCS作为服务端监听端口PLC作为客户端主动连接连接建立后WCS每3秒发一次心跳请求0x0004PLC必须在2秒内回复0x8004连续3次心跳无响应WCS就把这条连接关闭并重新监听。PLC侧则每50ms检查一次TCP连接状态发现断开立即尝试重连重连失败次数和时间都记录到报警区。这里有个非常容易忽视的坑重连后WCS和PLC两侧的缓存和任务状态必须做一次全量同步。否则WCS以为某个任务还在执行实际PLC早把它丢了或者PLC内存里还有某个料箱的跟踪信息但WCS那边已经把它标记为完成。我在重连逻辑里加了一个固定步骤——连接恢复后PLC先把所有还滞留在线体上的任务列表、分组器的位置状态主动上报一遍0x0005全量状态WCS据此重建现场之后再恢复业务下发。应答机制也值得一提。TCP推数据是有ack的但那是链路层的确认不代表业务层已经处理了。我要求每条业务命令都必须在处理完成之后回报结果0x8001而不是收到就立刻回。比如“下发任务”命令PLC要先判断跟踪表有没有空槽位、再写入条码和目标滑道最后才回“成功”。如果跟踪表满就回“失败-跟踪表满”WCS看到后会主动重试或分流任务。这个语义上的“收到”和“处理完成”的区分是避免线上丢数据的关键。3. 分拣控制程序从“读码”到“命中滑道”的完整追踪链3.1 分拣逻辑的核心问题箱子在哪儿分拣控制的本质是对“每个料箱当前处于什么位置、下一步该干什么”的持续跟踪。只要这个位置信息是准的命中滑道就是执行一个动作的问题位置信息一旦失真分拣机就会把货打飞或者漏打。最常见的方案有三类方案A在分拣读码点装一个读码相机/固定式扫码器读到码后立刻把目标滑道传给后方的分拣控制器分拣器看到箱子到达时按最近一次读取的目标码执行。方案B全程RFID料箱贴RFID标签沿途多个RFID读点实时刷新位置。方案C读码只负责“绑定”后续位置靠编码器/光电计数跟踪载物台跟踪表。方案A看着简单但有个大坑读码相机读码需要时间箱子高速通过时有可能漏读而且读码点与分拣执行点之间如果有积放段多个箱子同时排队控制器根本分不清哪条码对应哪个箱子。方案B成本高且RFID在金属箱上的表现不稳定。最终我用的是方案C这也是市面上最主流的做法。3.2 跟踪表和位置微调分拣程序的大脑跟踪表是一块固定长度的PLC内存数组每个表项对应线体分拣入料段上的一个“位置槽位”。我用的是每300mm一个槽位的方式主线1.2m/s的速度下一个长度600mm的料箱会跨占2~3个槽位跟踪表用队列滚动更新。当料箱通过读码点时WCS下发的任务里已经带了目标滑道PLC把条码、目标滑道、任务序号存入跟踪表的表头队尾。此后每来一个编码器脉冲我按10mm一个脉冲配置跟踪表整体向后移动光电传感器在沿途几个关键点做“校正”——比如在分拣机前3米处有个校正光电如果跟踪表预测箱子应该到校正点但光电没有触发说明跟踪计数丢了或箱子被堵了PLC会立刻把该箱标记为异常同时上报WCS。到达分拣位置时PLC判断表项目标滑道与当前滑道是否匹配匹配则触发摆轮动作同时把“命中”结果返回WCS。整个过程用伪代码描述大概是// 分拣主循环每编码器脉冲执行一次 for each tracking_slot in track_table: slot.position pulse_distance // 读码绑定事件 if barcode_readed then: task_id barcode target_lane get_target_from_wcs_task(task_id) track_table.append(task_id, target_lane, current_position) // 校正事件 if correction_photo_triggered: track_table.adjust(expected_slot.index) // 分拣执行 if slot.reaches_switch_position and slot.target_lane current_lane: start_swing_action() wait_action_done() report_result(OK)这里最容易被忽视的是“分拣动作等待”。摆轮从启动到完全摆到位需要150~200ms如果PLC认为箱子到了就直接打动作很可能摆轮还没到位箱子已经冲过去了。我的做法是在目标滑道前设置一个预动作光电提前200ms触发摆轮预摆等箱子真正到达分拣位时直接走“通过/拦截”两个动作效率高不少。3.3 读码失败和分拣异常的兜底策略无论跟踪表做得再好读码失败、条码污损、滑道满这些现实问题总是会来。我在程序里设了三层兜底读码失败时料箱走到分拣区末尾的“回收”滑道上报异常由人工处理绝不允许无目标箱进入主分拣区乱跑。目标滑道已满时WCS会在下发任务时通过0x0002取消命令改派备选滑道或者PLC在分拣位前把料箱导入缓存段等待。跟踪表位置校正失败连续3次说明该段传感器或编码器大概率出了硬件问题PLC置故障并停机报修防止后续箱子继续排队等待导致堵塞。这些兜底看起来都是些“小逻辑”但在现场它们才是真正省钱的——因为一旦出现异常箱子直接冲到滑道口造成堵包整条线停机损失按分钟算。4. 合流段的让行逻辑排序和避碰的权衡4.1 合流为什么难两条支线都认为自己有优先权主线合流点出现在A区和B区支线汇入主线处。两个支线各带缓存段每条缓存段能存4个料箱。料箱到达合流点前如果主线恰好有箱子通过支线就必须等待。这个逻辑看起来简单但真正的难点在于双方都可能是“先到”的那一方——哪个先放行直接决定下游分拣段的箱子密度和排序。最粗暴的轮流交替放行不可取因为两条支线的来料速率本来就不平衡A区订单波动大时A线可能一分钟来12箱而B线只有4箱。轮流放行会人为造成A线缓存堵塞。我采用的策略是“先到先得优先级队列”的组合支线缓存区的入口处和出口处各装一个光电出口光电检测到箱子压在合流等待位时PLC在软件层维护一个请求队列先来先排同时候选区域内如果主线有空档可以放行的瞬间队列中最靠前的箱子通过。但光有“先到先得”不够。实际操作中主线上的箱子可能是一个连一个连排的支线口很难等到一个足够长的空档。如果死等空档支线会堵到拣选区里。我在合流控制里加了一个“最小间隔放行”参数允许支线箱在主线上两箱之间插入前提是前一个主箱尾部已经越过合流点后2米、且间距不小于1.2米。这个参数根据下游分拣段的处理能力计算——分拣机每秒最多通过2.5箱所以合流释放的箱子节奏绝不能超过这个上限。4.2 合流排序对分拣命中率的影响为什么合流逻辑必须和分拣做整体考虑因为合流顺序直接决定了下游分拣读码点的来箱序列。如果合流段只想着“让行”可能出现一种情况主线和支线的箱子交替进入主线两个箱子间隔过近读码相机对第二个箱子来不及拍照漏读率直接上升。我在这条线上的处理是给合流后的主线加了一段“排序缓冲”——箱子离开合流点后以略低于主线速度通过一段约5米的平皮带利用皮带速度差自然拉开间距。同时在缓冲段出口的光电位置检查前后箱间距若小于设定值让后段皮带短暂停转等前箱走远再启动。这个过程非常像高速公路匝道处的“车速控制间距保证”只不过搬到了PLC的程序里。这个间距校验逻辑还有一个隐藏价值它能提前发现物理层面的故障。比如光电本身响应慢、皮带打滑导致箱子位移错位都会在间距数据里暴露出来。我在调试期间就靠这个排查出了两处皮带张紧不足的问题这个后面单独讲。4.3 合流段的状态上报和对账合流段里有些箱子只在缓存区等待就退回有些箱子真正上了主线。这两种状态必须区分上报WCS否则WCS侧的任务取消逻辑会误判。我的做法是箱子一旦通过合流段的出口光电PLC就把它标记为“已进入主线”并增加一条0x0006状态上报WCS更新线体上的全局任务地图若箱子因故被退回到支线缓存段比如主线连续拥堵每个周期超时PLC同样上报0x0007WCS才知道这个任务还得等。很多团队把这部分当作纯硬件逻辑处理不走状态上报结果就是WCS的线体监控画面上“主线堵塞”状态和实际物理位置对不上。对账式设计从一开始就做后面调试和运营都能省一多半精力。5. 调试实录三个让我整夜睡不着的现场问题5.1 Socket断连秒恢复任务却丢了第一次联调时出现一个诡异现象WCS侧日志显示连接断开不到1秒又自动重连成功看起来一切正常但重连之后WCS认为之前下发的任务还在执行PLC却已经把它们全部遗忘了——因为PLC的程序一段时间内没有收到任何数据就做了“现场清空”处理。排查链路是这样的先怀疑网线接触不良检查交换机端口和网线水晶头正常再看防火墙和杀软没有拦截记录最后把抓包工具接在PLC侧发现断连前的一段时间内WCS心跳周期变长——原来WCS侧的心跳发送逻辑是在一个低优先级的业务线程里某段时间它的数据库写入线程把CPU占满心跳发不出去PLC侧的看门狗误判超时直接断开了连接。修改方案有两处一是把心跳发送提升到WCS服务的独立定时器线程保证间隔稳定二是PLC侧把“无数据超时清空现场”的阈值从8秒放宽到30秒避免偶发的几百毫秒延迟直接触发清场。前者治本后者治标两处都做了才彻底解决。5.2 两个箱子几乎同时到读码位后一个箱子没读到码就被放行分拣跟踪表的一个漏洞读码事件按照光电触发顺序逐个处理时如果两个箱子间隔小于某个阈值前一个箱子的读码绑定还没写入跟踪表后一个箱子就触发了校正光电跟踪表误以为后一个箱子就是前一个结果是后箱带着前箱的目标滑道信息跑了。定位到这个问题时我很生气——其实就是“信号竞态”。解决办法有两个一是在读码点前增加一个接近开关用它先触发一个占位标志让跟踪表先为“未知箱”占一个槽位等读码结果回来再补写条码和目标滑道二是把读码相机换成“连读两次比对”的模式同一个条码连续两次读得一样才确认把偶发误码率从万分之几降到更低。两个方案我全上了从此再没出现过这个故障。5.3 合流段释放参数不合理下游分拣位提前触发分拣位前预动作光电偶尔会提前一个箱子距离触发。检查跟踪表发现预动作的触发条件是“跟踪表某槽位距离分拣位小于设定值”但合流段释放的箱子如果间距不匀跟踪表中两个槽位的物理距离可能小于实际间距导致后箱的“距离”先达到阈值。根因还是前面说的间距问题——合流出口释放间距按1.2米控制但主线皮带轻微打滑导致实际间距只有0.9米。我把“合流释放最小间距”从固定值改成动态计算参考当前主线上最近两个箱子的跟踪表间距如果连续3个周期实际间距都小于目标值就把合流释放参数临时增大0.3米。这样系统在皮带打滑、来料波动等异常情况下能自愈调优。6. 如果还有下一次我会直接改掉的设计6.1 通信层的升级方向这次Socket协议设计整体没翻车但有几处我下次一定会改报文里的任务序号用16位整数调试后期发现WCS侧的极端情况下会撞号。下次直接上32位序号反正每个报文也就多两个字节。PLC侧通信与逻辑处理这次是顺序执行通信解析和分拣主循环共用同一个扫描周期高峰期偶尔出现50ms抖动。下次改为双任务结构通信任务独立一个中断周期分拣主循环另一个彻底隔离。双机热备没有做WCS服务一台机器挂了整条线只能停机等它恢复。下次至少做个主备切换PLC侧用两个Socket连接分别连主备主连接断开自动切备用。6.2 状态机的语义要更细这次WCS与PLC之间的任务状态只有“下发、执行中、完成、取消”四个篇幅少但语义不够。比如“执行中”里完全没有区分“已在缓存区等待”“已进入主线”“正在分拣”这几个环节导致WCS的线体监控画面粒度很粗。下次我把状态码拆成八个每个关键位置一个状态码这样远程排查问题的时候看着屏幕就能判断箱子卡在哪一段不用跑到现场去一对光电看。6.3 分拣滑道满的决策权下放这次滑道满的处理是WCS定期查询滑道状态满了就不下发新任务。但WCS查询频率是2秒一次在这2秒内PLC可能已经把新箱子送入分拣入口了。下次我在PLC侧直接加一条“滑道满预警”逻辑当滑道入口光电显示连续堆积超过3箱时PLC主动暂停往该滑道的分拣动作同时发一条0x0008预警上报WCSWCS收到后紧急切换目标滑道。必须承认把部分决策权重放到PLC侧之后系统的实时性才能真正匹配现场的物理节拍。调试了这么多条输送线我的体会是合流和分拣程序写得好不好不取决于PLC指令用得有多花哨而取决于对“料箱位置”和“任务状态”这两种信息的建模是否准确。WCS和PLC之间的Socket接口本质就是这两种信息吞吐的桥梁——接口语义清楚现场就不会乱接口语义含糊再快的摆轮也会把箱子打到地上。这套料箱输送线系统运行至今单日处理峰值已经过万箱合流、分拣、通信三块核心逻辑没有再动过一行代码。