最近在帮客户做一批自助终端的控制改造功能本身并不复杂用户拿手机扫一扫支付平台扣款成功终端设备执行放行或者出货。但真正动手才发现支付盒子、PLC、执行机构三者之间怎么稳定可靠地打通坑远比预想多。尤其是PLC这种工业现场的老兵要跟商业支付设备“对话”绕不开串口和Modbus这套组合。这篇文章就把我实际项目中“PLC对接扫码支付”这一段完整拆出来讲重点放在串口接入、Modbus RTU协议解析、PLC轮询逻辑和现场排障上。项目用的是西门子S7-200 SMART PLC扫码支付盒支持RS485接口和Modbus从站协议这套方案在自助售卖机、自助洗车、充电桩、门禁道闸、工位物料柜里都有现成参考价值。无论你是刚入门的PLC编程新手还是被现场通信问题折磨过的老手这篇应该都能给你几条能直接抄作业的思路。1. 项目整体设计与方案选型1.1 为什么用PLC做对接而不是单片机或者工控机扫码支付的业务逻辑本身很清晰收银终端或支付盒拿到二维码、用户完成支付、平台回调、设备动作。难点从来不在支付本身而在“支付成功后如何让一台设备可靠地执行动作”。如果只做一个原型用单片机最省事串口直接解析支付盒的报文驱动继电器就完事。但一旦进入批量交付要考虑的就多了现场环境温度、电源波动、外部干扰、程序升级维护、操作人员误触、设备长期运行稳定性。PLC在这类场景里有天然优势梯形图逻辑直观现场电工能看懂能改抗干扰能力强故障排查手段成熟一个Modbus轮询循环只要写对就能稳定跑几年。用工控机当然也可以但成本高一个数量级而且Windows/Linux系统一旦死机重启现场维护成本不可控。相比之下一台小型PLC加上一个带串口输出的扫码支付盒总成本可控可靠性也够。项目里也测试过网关型方案让支付盒先上云PLC通过MQTT走网关获取支付结果但从设备响应速度看本地串口直连远快于云链路而且断网不影响支付结果读取这个核心环节。1.2 为什么选串口加Modbus而不是网口或者IO硬接线支付盒对接常见有几种方式IO电平信号直连、Wi-Fi/4G云平台回调、串口报文输出、网口TCP/UDP通信。初始设计时我们先排除IO直连原因很简单IO只能表达“支付成功/失败”一个状态支付金额、订单号、流水号全部拿不到后续做订单追溯、金额核对、远程对账都无从谈起。网口方案虽然信息量大但PLC选型就得带以太网口程序里还要处理TCP连接管理很多老设备现场布线也不方便。最终选了串口里面的RS485加Modbus RTU原因有三个。第一RS485是工业现场最成熟的物理层接口抗干扰能力强传输距离理论能到1000米以上设备间用双绞线串接就行。自助终端和支付盒之间通常就隔半米到两米RS485绰绰有余。第二Modbus RTU是工控圈的事实标准PLC自带主站功能开发调试工具极其丰富。扫码支付盒如果支持Modbus从站协议就意味着它内部的一组寄存器可以直接被PLC读取不需要解析厂商自定义的ASCII帧大大降低开发工作量。第三这个方案对PLC的硬件要求很低。带一个485口的入门级PLC就够用不需要额外扩展模块。我在项目中就是用一个标准CPU自带的Port 0口用S7-200 SMART的Modbus RTU库指令实现主站轮询成本非常友好。1.3 通信链路与数据流整套系统的通信链路是这样的扫码支付盒是一台带扫码镜头、语音播报、4G/Wi-Fi通信模块和RS485接口的终端设备。用户扫码后支付盒自己跟支付平台完成交易支付平台把钱从用户账户结算到商户账户支付盒收到平台回调后把支付结果写入本地的一段寄存器空间同时播报“支付成功”的语音。PLC作为Modbus主站按照固定周期去读取支付盒从站的寄存器读到支付成功的标志位和金额后置位内部状态输出控制信号驱动继电器或者接触器让终端设备执行开门、出货、启动等动作。这个桥接结构中PLC只关心支付盒的寄存器值支付盒只负责把支付结果准确塞进寄存器。两者之间不需要互相感知复杂业务流程通信协议简单出错面小这也是Modbus方案最大的优点边界清晰。2. 硬件准备与接线从支付盒到PLC的物理链路2.1 设备选型与接口确认这个项目里我用的是西门子S7-200 SMART SR20这是一台带以太网口和两个串口的小型PLC其中一个串口是RS485。如果选其他品牌比如汇川、台达、三菱FX系列原理完全一样只是Modbus库指令的名字和调用方式不同。扫码支付盒的选型要特别注意接口参数。市面上很多消费级扫码支付盒只支持TTL串口或者USB本身不带RS485。TTL电平跟PLC的RS485接口电平不兼容直接对接会烧接口。项目里用的支付盒是工业款明确标注支持RS485和Modbus从站协议订货时一定要跟厂家确认两个参数物理接口是不是RS485协议是否支持Modbus RTU从站。千万不要默认所有支付盒都带485很多盒子只是引出了TTL调试串口不能直接连PLC。另一个容易忽略的参数是波特率。支付盒默认波特率通常有两个常见档位9600和115200。Modbus RTU在PLC场景里多数用9600或者19200工业现场环境噪声大115200虽然快但抗干扰能力差。我这边统一把支付盒和PLC都配成9600、8数据位、无校验、1停止位也就是9600 8N1稳定压倒一切。2.2 RS485接线A/B端、共地与终端电阻RS485接线看着简单翻车的概率却相当高。标准做法是A接A、B接BA对应DB对应D-。但不同厂家的标法可能不同有的标A、B有的标D、D-还有的标485、485-。接之前务必用万用表确认一旦A/B接反现象是通信完全无响应或者随机乱码容易被误判成设备故障。支付盒和PLC之间走双绞屏蔽线屏蔽层单端接地。我这边现场布线距离在3米以内用的是RVSP 2芯屏蔽双绞线没有加终端电阻。如果传输距离超过50米或者现场有大功率变频器、接触器这些干扰源建议在链路两端各加一个120欧终端电阻。注意终端电阻不是随便加的链路上只有两个设备时两端各加一个超过两个设备时只在物理链路最远的两端加中间设备不能加。共地问题也要提一下。RS485是差分信号理论上不依赖参考地但实际工程中支付盒供电电源与PLC供电电源之间如果没有共地通信口电压可能漂移导致偶发通信失败。我在项目里把两个设备的直流电源负极做了等电位连接问题就彻底消失了。一些隔离型485口不需要外部共地如果设备自带隔离可以不用操作具体看设备手册。2.3 供电隔离与现场抗干扰支付盒是商业设备电源适配器往往用的是很普通的开关电源输出纹波大如果直接跟PLC的24V电源并在一起可能把噪声耦合到通信线上。我建议给支付盒单独配一个质量好一点的24V直流电源或者用隔离型DC-DC模块把动力电源和通信电源分开。变频器和接触器的动力线也一定要远离RS485通信线不要走同一根线槽线间距起码保持10厘米以上条件允许的话穿金属管屏蔽。3. Modbus协议核心读懂扫码支付盒的报文3.1 从一帧RTU报文说起Modbus RTU报文结构非常规整一帧数据包括从站地址、功能码、数据区、CRC校验。举个例子PLC读取支付盒中地址0x0000开始的2个寄存器如果支付盒站号是1那么PLC发出的查询帧是01 03 00 00 00 02 C4 0B拆开看01是从站地址03是功能码读保持寄存器00 00是起始寄存器地址高字节和低字节00 02是寄存器数量C4 0B是CRC16校验值。支付盒正常响应时返回的帧类似01 03 04 00 01 00 64 7A 3B其中01是站号03是功能码04是后面数据字节数00 01和00 64就是两个寄存器的值。如果前一个寄存器表示支付状态1代表支付成功后一个寄存器表示金额0x0064换算成十进制就是100也就是1.00元具体单位看支付盒协议手册定义。新手最容易犯的错是混淆寄存器地址的十六进制和十进制比如把0x0000当成十进制0去发结果发出来一样但如果起始地址是10号寄存器就要搞清楚协议文档写的是10还是0x0A。另外不同厂家的Modbus地址映射可能带偏移有的文档里写“40001对应寄存器地址0”发报文时还要减1这个在项目联调时特别容易踩。3.2 功能码与寄存器映射支付盒当从站怎么设计扫码支付盒作为Modbus从站时厂家通常会把关键状态按一定地址排布。以我们项目用的盒子为例寄存器表大概是这样寄存器地址读写属性内容说明0x0000只读设备在线状态0x0000离线0x0001在线0x0001只读支付状态0x0000等待0x0001支付成功0x0002只读支付金额单位分0x0064100分1元0x0003只读支付类型0x0001微信0x0002支付宝0x0010只写订单确认写0x0001清除本次支付状态0x0011只写重启设备写0x55AA重启支付盒这个表是调试时我自己整理出来的厂家文档可能很零散建议每个项目都自己画一张这样的表后续写PLC程序对着寄存器表来不会乱。关键点在第3个寄存器金额单位。有的盒子用“分”有的用“元”还有的用“角”必须从协议手册里确认。如果单位搞错实际收了1块钱设备却以为收了100块这种事故在自助设备里很常见。联调时最好拿一笔一分的支付做测试看寄存器值到底是多少用实测结果敲定单位。3.3 CRC16校验手算、代码与常见坑Modbus RTU区别于ASCII模式的最重要特征就是CRC校验。CRC16的计算规则是初始值0xFFFF低位在前、高位在后多项式0xA001。如果PLC的Modbus库已经内置了CRC计算你不需要自己写但调试时用串口助手或写脚本模拟报文手算CRC就逃不掉了。我习惯用Python写一个几十行的小函数串口调试时直接算校验值。代码如下def modbus_crc(data: bytes) - int: crc 0xFFFF for byte in data: crc ^ byte for _ in range(8): if crc 0x0001: crc (crc 1) ^ 0xA001 else: crc 1 return crc # 示例读取站号1、功能码3、起始地址0x0000、读取2个寄存器 data bytes([0x01, 0x03, 0x00, 0x00, 0x00, 0x02]) crc modbus_crc(data) # 低字节在前所以先发低字节 frame data bytes([crc 0xFF, crc 8]) print(frame.hex().upper())注意CRC在报文中是低字节在前比如算出来是0x0BC4帧里要写成C4 0B写反了从站会直接丢弃这一帧。现场很多“通信时好时坏”的问题根源就是CRC字节序写反了但偶尔又因为某些调试工具自动纠正而看起来能通。实测经验串口调试助手抓到的报文如果CRC总是在变但其他字段稳定这通常是正常现象因为CRC本就跟数据内容强相关。如果发送的查询帧CRC算错从站根本不会响应这是排查时最快的判断路径之一。4. PLC程序实现以S7-200 SMART为例4.1 库指令MBUS_CTRL与MBUS_MSGS7-200 SMART的Modbus RTU主站功能是通过调用两个指令库实现的MBUS_CTRL用于初始化串口和设置通信参数MBUS_MSG用于发送单条读写请求。STEP 7-Micro/WIN SMART里需要先安装指令库默认安装包里自带不需要额外收费。MBUS_CTRL指令每个扫描周期都要执行一次。关键参数是Mode、Baud、Parity、Timeout。Mode固定为1也就是Modbus RTU模式Baud设9600Parity对应无校验填0Timeout是通信超时时间单位毫秒我一般填1000。如果现场从站设备响应慢Timeout可以适当加大但要注意超时时间太长会导致整个轮询周期变长支付结果的响应也会变慢。MBUS_MSG指令是每次触发一个读写任务。它通过edge引脚触发不能持续置1否则同一消息会被反复发送。工程上标准的写法是先用一个定时器比如每500毫秒产生一个脉冲每次脉冲触发一条MBUS_MSG去读取支付盒的支付状态、金额等寄存器。4.2 轮询多寄存器状态机与地址切换如果支付盒的寄存器少可以一次MBUS_MSG把所有关心的寄存器都读回来。比如从0x0000读4个寄存器相当于一次拿到在线状态、支付状态、金额、支付类型。这比多次读取要省时间也降低总线拥堵风险。项目里我就是这么做的一次轮询读4个保持寄存器PLC侧用MOV指令把读取结果存到V区// MBUS_MSG配置示例 // First 1, Slave 1, RW 0读, Addr 0x0000 // Count 4, DataPtr VB100读出后数据依次存放在VB100到VB107这8个字节中。前两个字节对应0x0000寄存器的值再两个字节对应0x0001寄存器以此类推。因为Modbus寄存器是16位占用两个字节而读到的高低字节顺序取决于PLC指令库实现S7-200 SMART默认方式下数据放到V区后需要进行字交换操作也就是把Dword高16位和低16位互换。这一块是梯形图编程里最容易看晕的地方建议先用模拟软件把寄存器值写死不等于0的小数再观察V区数据分布确认高低字节序后再写解析程序。轮询多条消息时建议用状态机而不是一窝蜂发。比如一个周期读状态另一个周期写确认用M0.0、M0.1表示当前轮询步骤每次MBUS_MSG完成后切换。这样逻辑清晰不会两条MSG指令打架。4.3 支付结果处理与确认清零读到的支付状态是一个字我们用比较指令判断是否等于1。如果等于1置位一个内部支付成功标志M10.0同时把金额寄存器的值传送到一个掉电保持区VW200里用于后续对账。关键动作来了PLC确认已经处理完这笔支付后一定要主动向支付盒下发“订单确认”或者“清除状态”命令。否则支付状态寄存器一直是成功PLC会认为又有一笔新订单导致设备重复动作。这里的确认不是可选项是必须项。写操作可以用MBUS_MSG的RW1写入0x0010寄存器值为0x0001。写完后再读一次确认状态已经清零这样形成一个闭环比单纯延时后忽略状态可靠得多。4.4 在线状态判断与掉线保护支付盒掉线是现场最常见的问题。如果PLC只轮询支付状态盒子离线了PLC也不知道用户扫码没反应体验极差。我在轮询组里专门加了一条读在线状态寄存器的消息用一个掉电保持计数器记录连续读取失败的次数超过三次就认为支付盒离线PLC这边置位一个“支付盒故障”报警位同时语音提示和上位机告警都联动起来。另一个注意点是掉电保持。支付成功的金额和订单号如果存放在普通V区PLC重启后数据就丢了。项目里我把订单号、金额、设备编号都映射到掉电保持区VB0开始的区域内确保任何情况下都能追溯。S7-200 SMART的V区可以配置保持范围在系统块里把要保留的地址段勾上即可。5. 常见问题与排查技巧实录5.1 串口没反应先查这四件事通信一帧都不通的时候先别急着翻程序按顺序检查物理层。第一用万用表量一下485A和485B之间的电压正常应在0.2V到6V之间如果接近0说明总线没驱动检查是否有设备供电。第二把A/B线对调再试排除接反。第三查站号PLC发起的请求帧里从站地址必须跟支付盒的手拨码或配置一致比如支付盒设站号2PLC请求帧地址还是1必然没有响应。第四查波特率、校验位最常见的就是PLC设成偶校验、设备设成无校验两边都自认为配置正确结果谁也听不懂谁。用串口调试助手直接连到RS485总线上抓包是最高效的定位手段一抓便知PLC有没有发出请求、支付盒有没有应答。我项目里常备一个USB转RS485调试器芯片是CH340或者FTDI的都行但是驱动必须先装好Windows下CH340驱动没装或者版本不对插上设备根本识别不到串口号还容易被人误判成硬件坏了。5.2 收到报文但CRC错误或乱码串口助手显示收到了响应但PLC侧一直报错误码或者抓包看到大量乱码这种通常是电平或者干扰问题。重点是观察乱码的规律如果每次收到的都是固定几个字符大概率是波特率不匹配如果时好时坏大概率是干扰或者接线松动。现场处理思路先把通信速率降到9600增加报文抗干扰能力然后把屏蔽层接好单端接地再看供电用示波器量一下通信时电源轨有没有毛刺。还有一次我碰到过奇葩问题USB转RS485调试器本身是好的但是跟PLC共用了同一个USB延长线电压掉得厉害换了根短粗的USB线就正常了。5.3 偶尔能通偶尔不通轮询周期与超时竞态这种症状最折磨人。很多人第一反应是干扰但有时候问题出在程序里。如果PLC发了两条MBUS_MSG间隔太短前一条还没收到响应后一条又顶上来通信就冲突了。S7-200 SMART的库指令要求同时只能有一个MBUS_MSG处于激活状态调用时必须用上一个Done位结束才能发起下一次请求。我建议轮询周期的定时器设至少300毫秒以上给从站留足响应时间现场响应慢的盒子500毫秒更稳。另外支付盒收到查询后如果内部正在执行其他任务可能延迟响应。Modbus超时时间设置太短PLC已经判定超时但实际响应只是晚到下一轮请求又发出去两帧就会撞车。我最终的方案是Timeout设为1000毫秒轮询周期800毫秒实测稳定运行几个月没有丢包。5.4 支付成功但PLC没动作别忽视字节序和位状态程序逻辑没问题、通信也正常、寄存器也读到值了但设备就是不动这个坑十有八九出在字节序上。Modbus寄存器的高字节和低字节在PLC里存储顺序取决于指令库实现有的库是低字节在前有的是高字节在前。比如我读取0x0001寄存器得到的原始字是0x0001但如果字节序弄反变成0x0100十进制就是256比较等于1就永远不成立。高位字节和低位字节的处理可以通过移位或字交换指令解决。调试时我在支付盒后台设置一笔一分的测试单先确认金额寄存器读出来是0x0001而不是0x0100再往下写逻辑。这个习惯帮团队省了很多排查时间。5.5 调试工具清单与虚拟机连PLC的小经验调试Modbus通信我常用的工具按用途分三类。串口抓包用USB转RS485加串口调试助手用来确认物理层有没有数据协议调试用Modbus Poll作为主站工具直接读支付盒寄存器快速验证从站功能是否正常模拟从站用Modbus Slave电脑模拟一台支付盒PLC程序开发阶段直接对着电脑调不需要把真机搬到实验室。关于“TIA用虚拟机连PLC”的问题很多人用VMware跑博途或者STEP 7联网模式选桥接还是NAT经常搞不明白。实际经验是如果PLC和物理机在同一个局域网虚拟机网卡用桥接模式IP设为跟PLC同网段就能正常在线访问。用NAT模式的话虚拟机是另一个网段PLC访问不了。如果下载程序一直超时先ping一下PLC的IP通不通一眼就知道。顺带提醒安装CH340、FTDI这类USB转串口驱动时要把驱动映射进虚拟机VMware里需要在“虚拟机设置-USB控制器”里把USB兼容性调成2.0否则设备可能识别不了。最后再分享一个项目里我觉得特别值的小习惯现场联调前先在办公室搭一套最小模拟环境电脑用Modbus Slave模拟支付盒从站PLC程序直接用模拟器跑把通信逻辑全部验证完再去现场接真机。这套流程已经把三次现场联调时间从一天压缩到两个小时而且避免了反复跑现场改程序。扫码支付对接这件事物理层、协议层、业务层各管一块每一层都有确定的验证方法按层排查问题跑不掉。