千钧智品牌推文与公众号发布汇总
上一期信号全链路解析,我们把从传感器到数字显示的“内功”讲透了。但是——信号进入仪表之后,已经变成数字了,然后呢?
然后数字信号要“出门”——到上位机、PLC、DCS、物联网平台……出门靠什么?靠通讯。
工业称重系统里,通讯故障是售后工程师遇到频次最高的问题之一。一台秤,传感器没问题,仪表没问题,接线盒也没问题,可只要通讯出了故障,整套系统就彻底失灵——数据传不出去,一切都是白费。
最让人头疼的是,通讯故障有个特别“磨人”的特点:它不会一直坏着。有时候重启就好,有时候时好时坏,有时候今天坏明天好——导致排查特别困难。
今天这篇内容,我就把称重仪表通讯的这些“疑难杂症”给大家梳理得明明白白。
不管是RS485连不上、数据乱码、跳变、上位机收不到数据、多机组网出问题——一套流程,按图索骥就能找到病根。
这个排查流程,是售后团队在实际现场摸爬滚打,踩了无数坑总结出来的。开头先说一个结论——可能跟你之前的直觉不太一样:
80%的通讯故障不在仪表本身,而在通讯线缆和接线。
通讯不上,等于聋子对话——你说什么对方都听不见。这是最让人崩溃的一类故障。
真实案例:某化工厂采购了一台带RS485的仪表,上位机软件怎么也连接不到。工程师在仪表跟前蹲了三个小时,把菜单翻了几十遍,波特率挨个试了一遍,还是连不上。
后来售后人员到场,啥也没动,就拿螺丝刀把接线端子上AB两根线对调了一下——搞定。
为什么?RS485是差分信号,靠的是AB两线之间的电压差来传输数据。A线(D+)和B线(D-)接反了,差分的极性就反了——上位机收到的是“反”的信号,自然识别不了。
怎么检查?看仪表的接线端子。一般标的是A/D+/485+/P或B/D-/485-/N,对照仪表说明书确认。如果仪表端标注正确,问题可能出在上位机那端。
RS232同理:RXD和TXD接反了也不行。RS232的标准是“交叉接法”——上位机的TX接仪表的RX,上位机的RX接仪表的TX。接成直连也会无法正常通讯,上位机无法接收到仪表信号。
RS485的标准最大传输距离是1200米。但在实际工业环境里,很多因素会让这个距离大打折扣:
RS485 可靠传输距离参考
线径要求:RS485通讯线建议用双绞屏蔽线,线径≥0.5mm²(AWG20以上)。如果为了节省成本使用普通电话线,会为后续的通讯稳定埋下隐患。
仪表和上位机的波特率必须一致——9600对9600、19200对19200,波特率参数不一致就无法建立正常通讯。
这里有个容易踩的坑:购买多台仪表,默认波特率出厂设置可能不一样(部分厂家统一为9600,但某些批次老仪表可能不同)。现场5台仪表,3台是9600,2台是19200——后两台自然通讯不上。
推荐标准:仪表出厂统一配置:9600bps、8数据位、1停止位、无校验(N-8-1),以降低现场配置不一致带来的麻烦。
RS485总线两端必须各跨接一个120Ω的终端电阻。
工作原理:RS485总线是一根“传输线”。信号在线上传输时遇到阻抗突变(像是电线突然断了),就会产生反射——反射的信号往回跑,与后面来的信号叠加,导致波形畸变、数据出错。
终端电阻的作用就是“匹配阻抗”,让信号走到线端时被吸收而不是反射回去。
典型故障症状:总线两端未加装终端电阻时,通讯距离较远就会出现连接中断;会出现总线中间段设备数据可正常通讯,两端设备数据无法连通的情况。
“乱码”的具体表现:仪表屏幕上出现一堆不认识的字符、或者数字显示“花掉”了、或者在不同数字之间乱跳。
这是乱码最最最常见的原因。
RS485/RS232通讯有四个必须匹配的参数:
这四个参数必须完全一致。一个字母都不差。
为什么会产生乱码?假设仪表以9600、8、N、1的格式发送数据,而上位机以9600、8、E、1来接收——校验位对不上,每个字节的校验都错,软件读取到的就是一个“错位”的字节流,屏幕上看就是乱码。
接触不良的通讯线在信号传输时会产生“间歇性中断”——数据包发送过程中断断续续,接收端收到的是“残血”数据,自然解析不出来。
判断方法:上位机显示乱码但并非全部乱码——偶尔有几个数据帧解析正确,大部分都是乱码。将通讯线重新拔插、端子重新紧固后乱码消失,即可确认是接触不良导致的故障。
这是一个比较“高级”的问题,但在工业现场很常见。
情景:仪表A通过RS485连接上位机,通讯正常。仪表B加入同一个总线——B发出数据时上位机能收到,但读出来全是错误的。
原因:仪表B和上位机的“地”之间存在电位差。RS485虽然说是“差分传输”,但共模输入电压范围是有限制的——一般RS485收发器的共模范围是-7V~+12V,只有满足该条件,整个网络才能正常工作,当网络线路中共模电压超出此范围时就会影响通信的稳定可靠,甚至损坏接口。
如果仪表B的“地”和上位机的“地”之间电位差超过这个范围,RS485芯片就“饱和了”,输入级无法正确判断差分信号的“高”和“低”。
解决方案:
部分仪表在工程菜单里预置了“通讯参数对照表”——进入菜单即可查看当前所有通讯参数的状态:
当前通讯配置对照表
现场工程师看一眼这个表,马上就能确认配置是否和上位机、PLC一致,既不用翻说明书,也不用来回调试。
数据跳变是这类误判的重灾区:很多时候看起来是传感器故障,实际上根源是通讯干扰。
通讯干扰 vs 传感器故障对照
一条铁律:仪表屏幕显示稳定但上位机/PLC数字跳变 = 通讯问题。
变频器工作时,输出端会产生强烈的PWM脉冲,会在附近空间的电缆上感应出极强的干扰噪声。
实战策略:
继电器和接触器在断开瞬间产生电弧,产生宽频带电磁脉冲——距离通讯线1米以内的继电器操作就能在RS485总线上产生上千毫伏的尖峰干扰。
对策:在继电器线圈两端并联续流二极管(直流场景)或RC吸收电路(交流场景),既能保护继电器触点,也能大幅削弱电磁干扰。
仪表在通讯抗干扰方面通常做三层防护:
第一层——物理层隔离:所有通讯口标配隔离(隔离电压≥2500V),AGND和数字地完全隔开,阻止地环路干扰。
第二层——软件层校验:收到的每个数据包都做CRC校验,校验不通过直接丢弃。
第三层——重传机制:关键数据采用“发送-应答-确认”机制,超时自动重发。
实测效果:在变频器柜旁边1米处,空载状态下RS485通讯误码率<1×10⁻⁹(在9600bps下,相当于每传输约100GB数据才出1个错误位)。
这是“通讯不上”的一个子类。特殊之处在于:仪表本身可能已经在正常发送数据了,但上位机就是收不到。
售后团队总结了一个“三层排查法”,按顺序来,不走回头路:
第一层:物理层
约60%的问题在这一层就能解决。
第二层:链路层
物理层没问题,链路层大约能解决另外25%的问题。
第三层:应用层
最后15%的问题,到这里基本能定位。
串口调试助手是排查通讯问题的“神器”,但很多人不会用。
正确步骤:
正常回复:`01 03 04 00 00 00 00 FA 33`(设备回答了,通讯链路基本正常)
无回复:物理层或链路层出现问题,请检查接线和通讯参数
回复FFFFFF:设备上电了但MCU不工作——检查电源
回复内容不符:设备地址配置错误——可能是总线上另一台设备响应了该命令
当系统中有多台仪表通过同一根RS485总线连接时,故障排查会变得更复杂。
同一根总线上,每台仪表的设备地址必须是唯一的。
现场的问题:工厂买了10台仪表,出厂默认地址都是01号。不逐台修改地址直接挂到同一根总线上——所有仪表同时响应01地址的查询,数据混在一起,上位机无法读出正确的数据。
出厂默认设置:每台仪表地址默认为01。建议在安装调试阶段按“物理位置+编号”的规则分配地址:
从站地址分配示意
规则:总线最远的两端各跨接一个120Ω终端电阻。
如果RS485总线上接了8台仪表:
常见错误:每台仪表都加了120Ω终端电阻。8台并了8个120Ω——等效电阻只有120/8=15Ω。接收器看到总线阻抗从120Ω变成了15Ω——信号畸变严重,数据错乱。
RS485总线在“空闲”(没有设备发送数据)时,AB线之间应该是确定的“空闲状态”——即A线电平高于B线(逻辑1)。
但如果总线上没有信号时,AB线之间的电压差在0V附近徘徊,接收器拿不准到底是“空闲”还是“数据的第一位”——于是产生误判。
这就是为什么需要偏置电阻。偏置电阻在总线上创造一个微弱的偏置电流,让空闲时A对B的电压差保持在+200mV以上。
常规接法:在总线的一端(通常是上位机侧),从A线接一个上拉电阻(680Ω)到+5V,B线接一个下拉电阻(680Ω)到GND。
症状:总线上挂了8台仪表,有时候某1~2台“掉线”(上位机读不到它的数据),但到了第二天又自己好了。
根因排查清单:
推荐一个经过大量现场验证的“标准化接线方案”:
多机组网标准化接线方案
Modbus是目前工业称重领域应用最普及的通讯协议,但也正因为应用广泛,实际使用中遇到的问题也最多。
Modbus通讯时,发送方发出请求后等待回复。如果在规定时间内没等到,就认为通讯失败。
经验值:
问题出在哪儿?很多上位机软件的默认超时只有50ms。如果总线上某个仪表响应慢了一点(比如正在执行标定操作),50ms后上位机已超时报错——但这不是通讯硬件有问题,只是等待时间太短。
Modbus RTU协议传输数据以“寄存器”为单位——每个寄存器2个字节(16位)。而称重数据通常是32位浮点数,需占用2个连续寄存器。
这就涉及“数据对齐”的问题:
推荐标准:仪表默认使用IEEE754标准浮点数格式,大端序(Motorola格式)。产品手册中每个数据项的寄存器地址和格式都有明确标注。
Modbus RTU协议规定,每帧数据末尾必须带2个字节的CRC校验码。
现场出问题的现象:仪表发送的数据帧正确,但上位机回复“校验错误”。查了半天发现是上位机软件没有校验CRC就直接处理数据——或者校验算法本身写得不对。
常识修正:CRC校验不是“锦上添花”,而是Modbus RTU协议的强制性组成部分。上位机软件不做CRC校验就不算一个完整的Modbus实现。
产品在出厂前经过了CRC计算全模式遍历测试,覆盖所有可能的数据组合。
Modbus 寄存器地图
这个寄存器表在仪表说明书里有完整版。我的建议是:对接前先把这张表存下来,对接时按表索骥——能少走很多弯路。
写在最后
通讯故障看似复杂,其实就是“电信号在线上跑来跑去”的事。只要按着“物理层→链路层→应用层”的顺序来排查,绝大多数问题都能在半小时内定位。
今天的内容,从RS485/RS232连不上、乱码跳变、上位机收不到数据、到多仪表组网、Modbus协议——这套知识,是售后团队在1000多个现场案例里练出来的“排障手册”。
下期——第37期,工业称重全景串联——是“工业称重”模块的大结局。我会把前面36期的知识点全部串起来,从传感器到物联网平台,画一张完整的“工业称重技术路线图”。

