摘要：上个月去客户现场调系统，看着工人熟练地戳了一下墙上的按钮，然后AGV小车慢悠悠地驮着一车料走了。说实话，那一刻我觉得，干这行还蛮有成就感的。简单聊聊这套系统的设计门道，给正在踩坑的你一点参考。
车间里最容易被忽视的，反而是决定产线能否流畅运行的物料配送。物料员推着车跑断腿，生产线等了十分钟，班长拿着对讲机嘶吼……这种场面我见得太多了。后来大家想了个办法：装个呼叫按钮，让工人按一下，仓库就知道该送什么料了。听起来挺原始，对吧？实际上，这套“智能物料需求呼叫系统”远比想象中复杂。别急，我从头捋一遍。
一、现场到底乱在哪？
先说个具体场景。去年某零件厂，装配线有12个工位，每种物料有3种型号，每次换型都得重新配料。工人们用对讲机呼叫物料员，对方既要听清工位号，还得自己猜型号。结果要么送错，要么漏送。后来上了这套呼叫系统，但第一步就卡住了——怎么让工人简单操作？用PDA扫码？太麻烦，工人嫌啰嗦。用触摸屏？成本高。最后选了带物理按键的呼叫终端，每个工位装一个，旁边贴着物料卡片，按一下就好。
这个“按一下”背后是逻辑：每个按钮必须绑定工位号+物料号，按下后生成唯一的呼叫记录。关键点在于防抖动——工人可能按压时间很短，也可能长按不松。硬件得做去抖处理，软件也要有超时重发机制。以前有个项目就没做，结果系统偶尔漏触，被车间主任骂了一周。
另外，响应时间是硬指标。行业里一般要求从按下到看板显示不超过2秒，到AGV接收任务不超过3秒。我们当初用过Modbus RTU轮询64个站点，波特率9600，一旦有站点呼叫需要1s左右才能反应，这显然不够。后来改成RS485中断方式，或者干脆上CAN总线，实时性就好多了。
二、硬件架构：按钮、主控、看板，一个都不能少
系统分三层：现场终端层（呼叫按钮、指示灯、急停）、主控层（PLC或嵌入式控制器）、执行反馈层（看板、AGV、仓库系统）。每一层都有坑。
先说终端。别小看那个按钮，里面学问大了。工业环境，按键寿命至少得100万次以上，外壳防护等级要IP65，不然油污粉尘一旦渗进去，微动开关就会接触不良。我们第一次用的机械式微动，三个月就出问题，后来换成霍尔传感器式的，非接触，寿命长，但成本多了40%。怎么选？看现场环境，如果车间油雾大，还是老实霍尔吧，但别忘记做静电防护（ESD），按照GB/T 17626.2过一遍测试，否则冬天静电就可能让按钮重启。
再看主控。起初我们用西门子S7-1200，通过Profibus连远程IO，后来发现站点一多，编程复杂，而且和MES对接困难。换了嵌入式控制器，跑Linux，直接跑Modbus TCP，跟扫码枪、看板通讯都很顺畅。好处是灵活，但抗电磁干扰不如PLC。这里提醒一句：现场总线一定要用带隔离的RS485，并加TVS管保护，雷击浪涌、变频器干扰什么的才扛得住。
看板，很多人以为就是个显示器。实际上，车间振动大，用普通商用电视会闪屏，半年就电容爆浆。我们后来换工业级高亮屏，用HDMI输入，还做了金属外壳屏蔽。刷新频率不用太高，30Hz足够，但响应要快。另外，看板的位置最好能让整个工位区的人都看到，我们一般用LED大字显示呼叫工位号，再加声音提示，否则现场噪音盖过了。
三、无线通信选型：LoRa、Wi-Fi、4G，谁也别吹牛
有线最可靠，但改造麻烦。工位位置经常调整，或者有些是移动料架，就必须用无线。无线选型是新手重灾区。
先说LoRa。我们用的SX1278，433MHz频段，国内允许最大发射功率20dBm，接收灵敏度标称-140dBm，空旷直线距离确实能到2公里以上。但车间里到处是金属架和立柱，实际覆盖半径往往不足300米。在8000平米的车间里，一个网关根本盖不完，必须加中继器。LoRa的优势是功耗低，一节18650电池用半年不是梦，缺点就是速率低，只有几kbps，传个几十字节的数据包没问题。
Wi-Fi呢？2.4GHz干扰太严重，工业平板、手机、AGV都在抢信道，我们实测丢包率能到10%。5GHz穿墙能力又差，除非部署大量AP做漫游，成本直接起飞。4G蜂窝网络延迟不稳定，而且SIM卡流量费不便宜。5G？说实话，现阶段工厂的5G覆盖还不成熟，模块价格接近千元，功耗也高，用在呼叫系统上纯属杀鸡用牛刀。
我们的最终方案是：固定工位走RS485总线，移动料架用LoRa。然后给LoRa节点加电池电压监控，因为电池电压掉到3.3V以下时，模块发射功率会明显下降，丢包概率成倍增加。实际测试中，两节18650串联，每天按200次，每次发射0.2秒，待机电流约10uA，理论寿命超过500天。但低温环境下容量衰减快，实际300天左右就得换。所以建议在系统里提前设置低电量告警，别等彻底没电了才去处理。
这里有个血泪教训：LoRa模块瞬间发射电流可达100mA以上，如果电源内阻稍大，电压瞬间跌落会把节点MCU打复位。一定要在电源入口加大电容，最好用电池管理芯片。我们第一版就是偷懒没加，结果工人一按按钮，终端重启——那叫一个尴尬。
四、软件逻辑：别让数据丢在最后一米
通信永远不可靠，这条铁律在车间现场尤其正确。所以软件层面必须有确认重传机制。我们采用MQTT协议，把QoS级别设为1，保证至少送达一次。但网络拥塞时，重传也会延迟。这时候，我建议在边缘控制器上做队列缓存，等网络恢复后再补传，保证呼叫记录不丢。
还有，重复呼叫处理。工人可能因为没看到反馈，又按了一下。系统得判断同一工位、同一物料、3秒内的重复请求，直接忽略。这个逻辑很简单，但总有人忘了写。
另外一个关键点是到达确认。看板显示“配送中”还不够，最好在工位上加一个到达确认按钮，物料送达后按一下，呼叫才算闭环。否则系统里永远挂着一条未完成的记录，时间久了就会混乱。当然，有些工人会嫌麻烦懒得按，我们后来设置了配送完成后5分钟自动关闭，但这会掩盖真实问题。最后还是靠管理手段，让工位组长负责确认，毕竟质量是管理出来的。
再说协议对接。我们和MES系统之间用OPC UA，和AGV调度用HTTP/REST API。实际项目里总会遇到各种老系统，什么RS232口、什么自定义TCP协议，最好在中间加一个协议转换网关，别让上层业务代码被协议绑架。日志记录也不能省——每一条呼叫从发起到确认的时间戳都要存下来，这样当车间主任质疑“为什么这料送晚了”的时候，你能甩出一串数据怼回去。可以说，日志是工程师最后的尊严。
五、一点心得
好了，就聊这么多。智能物料需求呼叫系统不是黑科技，但每个细节都决定它好不好用。从按键寿命到无线选型，从防抖去重到日志留存，这些才是真正需要较劲的地方。如果你正准备上这套系统，希望前面这些踩坑记录能帮你少走几步弯路。工程师嘛，就是在无数个“小坑”里长大的。
