PLC在邮件分拣机中的应用：位置跟踪与通信调试全解析

分拣准确率要做到99.9%，当用户把这句话丢给我的时候，我就知道这个项目没那么简单。智能邮件分拣机，表面上看就是把一封邮件从入口送到对应格口，快一点、准一点、别丢件、别送错。可真正做起来才知道，每一次扫码、每一个脉冲、每一格气缸动作，都是环环相扣的，而控制这套动作的“大脑”就是PLC。这篇文章我想用一个实际项目的拆解方式，把选型、IO规划、程序逻辑、通信协议、现场调试这些环节全部摊开讲一遍，尤其是那些踩过的坑和调了几天才弄明白的细节。如果你正在做物流自动化项目，或者刚上手PLC系统设计，这篇应该能给你省不少摸底的时间。

1. 智能邮件分拣机的工艺场景与控制需求拆解

1.1 一台分拣机到底在干什么

先把场景说清楚。邮件从供件台放上来，经过皮带或滚轮输送，在扫描区被识别出地址信息，随后继续在输送线上前进，到达对应格口时，执行机构把它推进格口。这就是分拣机最朴素的工作模型。看起来很简单，但在“推进去”之前，系统必须回答三件事：这件货是谁、它要去哪、它现在走到哪了。这三个问题的答案，最终会在PLC内部被打成一连串的状态位和数值。

我在实际项目里见过不少“简化理解”的同事。比如有的觉得，扫码器读出来之后，拿一个计数器延时一下再推气缸不就行了？逻辑上没错，但如果你面对的是连续上件、邮件间距只有三百毫米、皮带速度可以到每秒一米的分拣线，这种“延时多久”的算法马上会出问题。因为每件邮件的尺寸、贴标位置、检测点触发的早晚都不一样，不做位置跟踪根本稳不住。

1.2 控制系统必须回答的五个核心需求

第一个需求是触发扫码。邮件到达扫描区前，PLC要通过光电传感器捕捉到位信号，再给扫码器一个触发命令，而不是让扫码器一直开着循环读码。一直读码的问题在于容易重复读、读串货，尤其在两件邮件靠得很近的时候。

第二个需求是位置跟踪。这是整个系统的灵魂。PLC需要实时知道每一件在输送线上的邮件走到哪了，这样才能在正确的格口触发执行机构。第三个需求是执行机构控制，也就是根据目标格口驱动气缸、摆轮或者伺服机构。第四个需求是异常处理，比如扫码失败、格口满、卡件。第五个需求是数据统计与通信，把每一件邮件的分拣记录传到上位机或者信息系统，方便后续追溯。

这五个需求是互相咬合的。位置跟踪出问题，执行机构就会推错口；扫码触发时序不对，跟踪表里就缺数据；通信断了，所有分拣记录都会丢。任何一个环节掉链子，用户看到的都是一句“分拣错了”。

1.3 为什么控制核心选择PLC而不是单片机或者工控机

智能分拣机可以用单片机、视觉工控机，也可以用PLC。我赞成用PLC做控制核心，不是因为它性能最强，而是因为它的实时性、抗干扰性和可维护性最匹配这种场景。分拣动作的响应在毫秒级，PLC的扫描周期稳定，数字量输入输出的响应是确定的。工控机一旦卡顿、死机或者后台自动更新，信号就可能丢，这在产线上是不能接受的。

再说维护。现场电气维修人员对PLC的梯形图和在线监控基本都熟，不管谁值班都能上手排查。自己写的单片机固件出了问题，有时候连写程序的开发员自己都要翻半天代码才想起来当初为什么这样写。分布式场合还有远程IO、总线诊断这些手段，维护门槛能压得很低。

2. 硬件选型与IO规划——先把底子打好

2.1 控制系统的硬件拼图

一台分拣机的控制柜里通常有这么几个部分：PLC控制器、数字量输入输出模块、以太网通信口，有些场合还会加远程IO模块、伺服或者变频器、开关电源、断路器和继电器。传感器方面，输送线上散着装多组光电开关，扫描区至少有一台读码器，格口位置还要有满格检测或者气缸到位检测。执行机构是气缸或伺服拨轮，气路上有电磁阀。人机界面一般是一块触摸屏，用于状态显示和手动调试。

选型时有一个特别容易被忽略的点：PLC的高速输入数量够不够用。位置跟踪如果依赖编码器，编码器信号要接高速计数器输入，普通数字量输入跟不上那个频率。我见过有人选型时只数点数，结果发现高速计数器只有两路，输送线有两条，最后只能硬凑，把程序写得十分别扭。所以选PLC之前，先把哪些信号是脉冲、哪些是电平、哪些要中断理清楚。

2.2 IO清单与地址规划

整理IO清单是设计的第一步，也是后面接线和编程的依据。下面是一张典型的邮件分拣机IO表，地址只是示例，具体以实际PLC型号为准。

地址分配时有一个原则，把高速计数器输入放到专用通道，把故障急停类信号放在独立模块上。这样即使后续增加点位，也不会影响原来的脉冲通道。很多人不在意地址规划，等程序写一半发现模块点数不够或者高速通道被占了，再改就麻烦了。

2.3 继电器输出还是晶体管输出

分拣机执行机构动作频繁，气缸电磁阀如果直接用继电器输出点控制，继电器触点寿命是个问题。按每分钟三十件的节拍算，一个格口的电磁阀一天动作上万次，继电器很快就不行了。所以我更推荐用晶体管输出加中间继电器，或者干脆用总线阀岛，由阀岛直接驱动电磁阀，PLC只通过总线发指令。

选晶体管输出就要注意负载电流和浪涌抑制。电磁阀线圈属于感性负载，断开瞬间会产生反向电动势，线圈两端要并续流二极管，否则容易损坏输出点。还有一个细节：给扫码器、光电传感器供电的24V开关电源，和给电磁阀供电的电源尽量分开。电气柜里干扰大的时候，就知道这一步值多少钱了。混在一起供电，读码器偶尔被干扰死机，排查起来非常痛苦。

3. 分拣控制核心逻辑：从“读码”到“落格”的完整闭环

3.1 用状态机代替一杆子到底的时序

写分拣控制程序，最忌讳的是把整个流程写成一整段顺序执行。因为现场信号出现的先后不是永远一致的，今天这一批连续三件相隔很近，明天换班后供件速度慢了，顺序流程就会出问题。所以主流程要设计成状态机：空闲态、读码态、跟踪态、执行态、返回态。每个状态之间通过信号条件触发跳转，而不是“延时到时间就往下走”。

这个思路我一直在用，每次接手类似设备的第一件事就是画状态迁移表。别看是基础工作，它能帮你把所有异常情况列出来。比如在跟踪态，编码器脉冲数已经到了分拣位置，但气缸反馈没有到位，这个异常怎么走？有了状态机，这类问题就有了固定的归宿，不会让程序跑到一个谁也不知道的状态里去。

3.2 位置跟踪用什么实现

位置跟踪有三种常见做法：用定时器做延时、用变频器运行频率换算、用编码器计脉冲。前两种方案在实验环境里看着都能用，但到了真正的产线，皮带打滑、负载变化、启停加减速都会让“时间”和“实际位置”脱节。最后我选择的是编码器脉冲跟踪。输送线电机上装旋转编码器，皮带每走一小段，PLC高速计数器就加一次计数，PLC用数组把这些脉冲坐标记为“包裹的位置坐标”。等包裹对应的数值到达格口坐标区间，就触发执行。

这里要搞清楚一个概念，位置跟踪跟踪的不是“时间”，而是“位移”。编码器脉冲和皮带位移是线性对应的，这样即使皮带速度有波动，脉冲数和实际距离的比例关系保持不变。方案的好处是，邮件间距小也能处理，因为每件货都有独立的坐标记录。皮带偶尔打滑导致位置误差，还可以用光电传感器信号做校准，把坐标表清零或修正。

3.3 结构化文本示例：包裹跟踪表

下面用结构化文本写了一个简化的包裹跟踪表逻辑。实际项目中可能用数组、结构体或者FB块实现，但核心思路是一样的。

// 邮件跟踪表，每条记录代表输送线上的一件邮件 TYPE MailRecord : STRUCT valid : BOOL; // 记录是否有效 targetGate : INT; // 目标格口号，0表示未识别 enterPulse : DINT; // 进入输送线时的编码器脉冲数 lastPulse : DINT; // 最近一次更新的脉冲坐标 scanOK : BOOL; // 读码是否成功 END_STRUCT END_TYPE VAR mailList : ARRAY[0..19] OF MailRecord; pulseCount : DINT; // 编码器当前累计脉冲 END_VAR

每次邮件经过上件口光电，就在mailList里找第一个valid为FALSE的记录，填入enterPulse。扫描区收到读码结果后，更新对应记录的targetGate和scanOK。主循环里不断把pulseCount的差值累加到每一条有效记录的lastPulse上，同时判断lastPulse是否落入格口动作区间，一旦到达就输出DO，并设置valid为FALSE。这个逻辑就像在一条线上给每件邮件发了一本“护照”，每到一站就翻一下护照看该不该下车。

3.4 边界情况：急停恢复后邮件怎么办

最怕的是设备运行中急停。急停恢复之后，输送线上还有好几件货没有分拣完，位置表已经乱了。因为急停时编码器停了，皮带可能因为惯性继续滑行一小段，恢复后位置参考就丢了。我常用的处理办法是，急停恢复后强制进入“重新清线”流程，所有跟踪记录先标记为无效，然后让输送线低速点动，用每一组光电信号重新确认线上是否还有残留包裹。能识别的重新扫码，识别不出来的走回流口。不要去猜原来的位置，猜一次错一次。

这个细节特别重要。有的同事图省事，急停恢复后直接把跟踪表继续往下跑，结果皮带滑行那一下就让所有包裹的位置整体偏移，后面连续错好几个口。宁可多花半分钟清线，也不要赌那几厘米的误差。

4. 通信架构与数据交互：让分拣机不再是信息孤岛

4.1 PLC、读码器和上位机之间怎么通信

读码器是分拣系统的“眼睛”，它读出来的条码内容必须快速交给PLC。常见的接法是读码器通过以太网或串口输出字符串，PLC用TCP或UDP接收。这里要注意时序：读码器一般工作在“触发模式”，PLC输出一个触发信号，读码器拍照解码，然后回传一帧数据。一帧数据通常包含起始符、条码内容、校验和，PLC收到后要校验，确认无误才写入跟踪表。

下面是一个常见的帧格式示例：

如果只是单向发数据，PLC收到什么就信什么，一旦读到错误条码，系统就会把邮件送错格口。所以校验这步不能省，尤其是条码内容里如果带有字母、横杠，更要防止解析错位。我在一个项目里遇到过读码器把字母O和数字0混淆的情况，后来在程序里加了白名单字符校验，才彻底解决。

4.2 心跳与断线重连

通信最怕“假死”。PLC和读码器之间如果只是数据收发，哪天读码器死机了，PLC根本不知道，还傻等着数据。所以我会在通信程序里加心跳机制：PLC周期性发送心跳指令，读码器必须回应，连续几个周期无回应就触发报警。这个机制看起来简单，但救过我好几次。

分拣记录要上传到信息系统或者数据库时，用Modbus TCP比较方便，但要注意PLC侧寄存器的刷新周期和上位机的读取周期不要刚好重合，否则容易偶然读到半组数据。最好是PLC把数据放在连续寄存器区，上位机每次读取一个块，而不是逐个寄存器读。这样哪怕某一次读到了数据更新中的中间状态，下一轮读取也能覆盖修正。

4.3 现场总线选型

如果分拣机格口多、IO点分布远，用传统硬接线会拉出一大束电缆，柜内接线端子排密密麻麻，查一根线都要半天。这时要优先考虑远程IO总线方案，比如在格口区域放几个远程IO站，用总线连回主PLC。这样做的好处除了省线，更重要的是诊断方便。某个格口的IO出问题，总线诊断可以直接定位到具体站号，不用再一条线一条线查通断。

我印象很深的一次，现场查一个气缸没动作，传统硬接线检修花了半小时，后来换了总线方案，看站状态两分钟就锁定是远程IO站的一个输出模块坏了。这个对比足以说明通信架构选型的重要性。不过远程IO也要注意总线刷新周期，分拣动作快的场合，通信周期必须足够短，不然气缸动作会感觉“慢半拍”。

5. 现场调试实录与故障排查速查表

5.1 踩过的坑：读码漏读和误读

读码器偶尔漏读是正常的，关键是要在程序里给它“第二次机会”。我的做法是：如果第一次读码结果NG，PLC自动控制输送线在扫描区后方的“等待位”停一下，再次触发读码，仍然NG才判定为异常，走回流口。这个逻辑虽然简单，但能把漏读率明显压下去。但要注意，重读逻辑不能随便加，如果分拣线节拍很快，每次重读都会挤压后续包裹的间距，所以要设定重读次数上限，并且只允许对跟踪表中“距离最近的那件”重读，防止重读指令落到后面那件货上。

另一个容易被忽视的问题是反光。新装的输送线罩板光洁度很高，读码器补光灯打上去会出现高亮区域，导致条码对比度不够。我们当时调了好久，后来把扫码器安装角度从垂直改成了大约三十度倾角，问题立刻改善。读码器安装角度和现场光照条件，一定不要只在实验室里拍板，必须到现场去试。

5.2 误分拣：位置漂移为什么难查

误分拣是最让人头疼的故障，因为问题往往不是“没动作”，而是“动作偏了”。比如本来该推到五号格口的邮件，却提前落到四号格口。这种情况十有八九和位置跟踪漂移有关。皮带打滑会让编码器脉冲数和实际位移失去对应关系，如果输送线是皮带传动，这个问题尤其明显。我后来在关键位置加了一组光电校准点，每当包裹经过校准点，就把跟踪表的脉冲坐标重新修正一次。这招非常管用。

具体做法是，在输送线中段放一个对射光电，当包裹遮挡光电时，PLC把当前编码器脉冲数设为该物理位置的已知脉冲值，然后用这个值去修正跟踪表里所有记录的坐标偏移量。这样即使皮带累计误差越来越大，每经过一个校准点就清零一次，位置误差不会累积。

5.3 通信掉线：不一定是网线松了

现场通信掉线，往往不是网线松了，而是干扰。分拣机气动电磁阀动作频繁，阀岛和通信线走同一个线槽时，电磁阀开关瞬间的浪涌会耦合进通信信号。我处理过一例：某条生产线的电磁阀一动作，读码器就偶尔掉线。后来把通信电缆移出动力电缆线槽，并换成了带屏蔽层的网线，屏蔽层单端接地，问题彻底消失。别小看布线，这算整个项目里最便宜却最见效的整改手段。

还有一类掉线是IP地址冲突。现场调试时手机、电脑、触摸屏都接在同一个交换机上，如果读码器用固定IP，容易和某个临时设备撞地址。建议所有设备规划好独立网段，上位机和调试电脑用不同VLAN，或者至少把IP段错开，能省去很多莫名其妙的通信问题。

5.4 故障排查速查表

调试和售后阶段，我习惯在手边放一张故障速查表，遇到问题先按表对一遍，能加快定位速度。

要善用PLC的在线监控。调试时不要只看程序里的变量，要同时观察高速计数器的当前值、跟踪表里每一个有效记录的坐标值。把异常发生前几秒的变量变化记录下来，故障原因基本能锁定在哪个环节。我习惯在程序里放一个“影子表”，每处理一件邮件就把关键数据推到里面，这个表不参与控制，专门给事后分析用。调试阶段它帮我省了至少一半的时间。

最后再说几句体会。做完这套系统，我最大的感受是，分拣机控制系统的难点从来不在单个功能，而在多个功能同时跑起来的时候不乱。PLC程序从写完到稳定运行，中间隔着无数个现场问题，只有把每个细节都按最朴素的方式做扎实，才能在量产线上扛得住。如果再让我做一次，我会从第一天就把位置校准点和通信诊断功能做进去，而不是等出了问题再回头补。