前几天帮朋友排查一台集中器的抄表失败问题现象很典型电表在系统里建档正常集中器参数也下发了可就是抄不回数据。我用串口调试助手直接接在电表RS485端子上用DLT645的读地址帧发过去三秒钟就定位了问题——不是表坏了而是参数表里的通信地址和表计实际地址差了两位。类似这种问题其实只要会看DLT645和DLT698的报文结构五分钟就能解决。这篇文章就围绕电表地址读取这个最刚需的操作把两类协议的真实指令一条条拆开讲告诉你为什么这么发、返回帧怎么认、校验字节怎么算。适合刚接触用电信息采集的工程师、做能源管理平台对接的开发者以及所有被电表通信搞得头疼的现场调试人员。1. DLT645和DLT698到底差在哪先判断你要面对的是哪一本规约很多新手拿到台电表第一反应是翻说明书翻完更晕——因为现在市面上同时存在DLT645和DLT698两套规约有些新表还同时支持。你不先判断对面是哪一本规约后面的指令全都是白发。1.1 两代规约的定位区别DLT645是国内电能表通信的老牌行标从1997版到2007版统治了电能表RS485抄表十几年。它的核心思路是数据标识也就是用一组4字节的数据标识DI0~DI3去定位某个数据项比如当前有功电能、电压、电流、通信地址。读取就是发读数据命令表计响应就是把对应标识的数据值带回来。DLT698.45则是面向对象的新一代规约思路有点像面向对象编程。它把电表里的数据都抽象成对象每个对象有明确的接口类、对象属性IDOAD和属性序号。你要读什么不是直接说把电表地址给我而是发一个GET请求去取某个对象的某个属性。这种设计的好处是扩展性强但坏处也很明显上手门槛比645高因为你要先拿到表计的数据点表知道通信地址挂在哪个接口类、哪个OAD下面。1.2 上手前怎么快速识别表计规约我在现场判断表计规约一般不依赖铭牌直接看行为特征看空闲报文的特征645-2007在发送用户数据前会先发FE FE FE FE四个前导字节698虽然链路层也以68开头但帧结构里直接带长度L和两个地址域没有那串FE前导。看地址域的字节数量645的地址域固定6字节698的服务器地址是7字节、客户端地址是2字节。你只要收到一帧数一下68后面跟的长度和地址长度基本就能区分。看波特率和校验方式645-1997/2007默认2400bps偶校验也有不少厂家出厂设成9600bps698.45通常默认2400bps或9600bps偶校验但帧长比645长不少响应时间也更慢。我把两套协议的关键特征放在一张表里现场对照着看一眼就知道该按哪套逻辑处理。比对项DLT6451997/2007DLT698.45链路层帧头682007版前加FE FE FE FE68 L L 68地址域6字节表地址服务器地址7字节客户端地址2字节数据定位方式4字节数据标识DI3~DI0接口类对象属性ID属性序号读操作命令控制码0x11读数据应用层APCI GET请求默认串口参数2400/9600偶校验8数据位1停止位2400/9600偶校验8数据位1停止位上手难度较低命令固定较高依赖数据点表2. DLT645读表地址一封广播报文就够了DLT645读电表地址这件事本质上就是问表计你自己叫什么名字表计会在响应帧里把通信地址回给你。读地址时不需要预先知道这个表的具体表号因为可以用广播地址去喊喊完所有挂在总线上的表都会收到但只有被指定数据标识命中的表计会响应。2.1 帧结构逐字段拆解DLT645-2007的完整数据帧长这样FE FE FE FE 68 A0 A1 A2 A3 A4 A5 68 C L DATA CS 16FE FE FE FE前导字节用于唤醒接收方2007版有1997版没有。68帧起始符。A0~A56字节表地址读表地址时填广播地址AA AA AA AA AA AA。68第二个帧起始符表示后面的控制字开始才是真正的报文内容。C控制码读数据请求是0x11正常响应是0x91异常响应是0xD1。L数据域长度不含控制码和长度本身。读表地址时数据域是4个字节的数据标识所以L04。DATA这里就是数据标识DI0、DI1、DI2、DI3。读表地址的常用标识是04 01 01 00不同厂家可能有自己的扩展但大多数标准表用这组。CS校验码从第一个68到DATA最后一个字节所有字节累加取低8位。16帧结束符。这里要注意一个关键点645的数据标识在帧里是低字节在前传输的。比如你查手册看到数据标识是00 01 01 04在报文里要反序写成04 01 01 00。很多新手第一次拿到报文看半天对不上就是栽在这个字节序上。2.2 完整的读地址指令实际发到电表RS485端口的完整读地址指令如下FE FE FE FE 68 AA AA AA AA AA AA 68 11 04 04 01 01 00 E7 16我来逐步解释这条指令FE FE FE FE唤醒。68帧起始。AA AA AA AA AA AA广播地址让总线上的所有表计都接收。68第二个帧起始符。11控制码意思是读数据。04数据域长度后面4字节是数据标识。04 01 01 00读表地址的数据标识。E7校验码。16帧结束符。这条报文对645-2007和部分支持645协议的设备是通用的。如果你遇到的是645-1997老表把前面的FE FE FE FE去掉直接发68 AA AA AA AA AA AA 68 11 04 04 01 01 00 校验 16就行。2.3 校验码怎么算校验码是很多人的卡点。其实计算很简单把从第一个68开始到DATA最后一个字节为止的所有字节累加超过一个字节的部分丢掉只要低8位。以上面的报文为例需要累加的字节是68 AA AA AA AA AA AA 68 11 04 04 01 01 00逐字节累加用16进制算68 AA 112 112 AA 1BC 1BC AA 266 266 AA 310 310 AA 3BA 3BA AA 464 464 68 4CC 4CC 11 4DD 4DD 04 4E1 4E1 04 4E5 4E5 01 4E6 4E6 01 4E7 4E7 00 4E7取低8位就是E7。所以在报文末尾填E7再补一个16结束符整包数据就是合法的。提示实操时不要在纸上手算用串口调试助手自带的校验工具或者写个几行脚本去算省得算错把整包数据带偏。2.4 响应帧怎么解读地址发送成功后表计会返回一帧格式大致是68 A0 A1 A2 A3 A4 A5 68 91 06 04 01 01 00 01 02 03 04 05 06 CS 16这里几个关键位置A0~A5响应帧的地址域已经不再是广播地址而是表计自己的通信地址。这个地址就是我们要读的东西。91控制码表示读数据正常响应。06数据域长度4字节数据标识4字节地址值不对这里要看实际返回通常是4字节标识外加地址数据长度可能是08或者更大。以实际抓包为准。04 01 01 00回显请求的数据标识。后面的若干字节根据数据标识定义返回的就是电表地址对应的BCD码值。拿到响应帧后把地址域A0~A5里的6个字节提取出来注意645的地址是低字节在前存放。比如响应帧地址域是34 12 00 00 00 00实际表号要按字节倒过来理解不能直接读成341200000000。3. DLT698真实报文逐字节拆解面向对象的信息模型怎么读地址DLT698.45几乎没有专用读地址命令这种概念读地址只是读若干个对象属性中的一项。也正因为如此网上能搜到645报文一抓一大把698真实报文却相对少。这里我贴一段从现场抓包整理出的698.45读数据请求帧脱敏后逐字节拆给你看。3.1 698.45链路层结构698.45的链路层帧格式比645复杂68 L L 68 C SA CA APDU CS 1668第一个帧起始符。L L两个相同字节表示从68后面到CS前的总帧长度。两字节相同是为了首尾校验。68第二个帧起始符。C控制字标识帧方向、分帧标志、帧类型。一般客户端发服务器方向和控制帧有其固定取值。SA服务器地址固定7字节通常填表计逻辑地址。CA客户端地址2字节也就是主站/采集器地址。APDU应用层数据单元读地址要用的GET命令就在这里。CS校验码从68到APDU末尾累加取低8位。16帧结束符。3.2 真实报文逐字节说明下面这段报文是我在某品牌能源控制器抓下来的一段读数据GET请求已脱敏字段含义以83版698.45为准不同厂家细节略有差异68 2B 2B 68 10 00 00 00 00 00 00 00 10 01 80 81 01 08 00 00 01 00 02 00 00 00 00 00 00 00 CS 16逐个字段看完你就能明白698报文和645报文完全不是一个画风。字节位置值说明168帧起始符2~32B 2B帧长度43字节从第一个68之后到CS之前468第二个帧起始符510控制字表示客户端请求帧、无分帧6~1200 00 00 00 00 00 00服务器地址7字节这里为全0示例13~1410 01客户端地址2字节主机侧逻辑地址15~1680 81APCI应用层控制信息0x80 0x81组合表示GET请求1701调用/结果标识可以理解为请求序号1808接口类号这里示例为8类表示电表参变量对象19~2200 00 01 00对象属性IDOAD表示具体哪个对象的哪个特征2302属性序号这里是第2属性24~2900 00 00 00 00 00附加数据/时间标签或请求数据区3000结果码或保留字节3116帧结束符真正读通信地址时接口类和OAD要按表计厂家数据点表来填。比如有些表把通信地址放在8类电能表参数的某个OAD里有些表放在资产号属性里没有统一标准。你拿到手的点表里会写清楚接口类几、OAD几、属性几。这也是698最让人头疼的地方——报文结构你懂了但没有点表还是寸步难行。所以现场调698表第一件事永远是找厂家要数据点表第二件事才是连串口。3.3 与645的本质区别645读地址是我喊广播你告诉我你叫什么而698读地址是我要GET某个对象的某个属性你把值给我。后者更灵活但灵活带来的代价是调试链路变长。最直接的差异体现在报文长度上645读地址的请求帧20个字节左右698的GET请求动辄三四十个字节起步响应帧更长。这导致698在实际485总线上更容易受干扰、更需要稳定的物理链路和合理的超时时间。还有一个容易踩的点698的服务器地址是7个字节很多从645转过来的人习惯性只发6字节表地址导致报文直接从校验阶段就错了。4. 5分钟实操路线串口参数、调试工具和完整步骤前面把指令拆完了现在进入真正的5分钟操作。以下是我在项目现场反复使用的路线你按着走一遍基本不会卡壳。4.1 准备清单开始操作前确认手头有这几样东西一台待调试电表确认其RS485端子位置一般在接线端子排的A、B两个端子。一个USB转RS485模块最好带隔离的现场表计共模干扰不小便宜模块容易丢数据。串口调试助手推荐支持hex收发、能自动计算CS校验的工具例如COMTool、SSCOM或者各厂家自己的调试平台。表计的规约版本信息和数据点表698必须645可备一个手册。4.2 从接线到出结果的分步流程第一步接线。USB转RS485的A接表计的485AB接485B千万别接反。很多现场调试失败不是报文问题是A和B反了。如果表计有屏蔽地端子把屏蔽层单端接地。第二步打开串口调试助手设置串口参数。645和698大部分出厂是2400bps、偶校验、8数据位、1停止位现在不少厂家的智能表默认9600bps。参数不确定时先用2400偶校验试没有响应再切成9600偶校验再没有就试9600无校验。第三步在hex发送框里填入645广播读地址报文注意必须是16进制格式FE FE FE FE 68 AA AA AA AA AA AA 68 11 04 04 01 01 00 E7 16点发送然后看接收区。第四步如果表计有响应你会看到一帧以68开头、16结尾的数据。提取地址域6字节再按字节倒序转成实际表号。到这里645这边的读地址工作已经完成整个过程不会超过一分钟。第五步如果你面对的是698表不要走广播读地址路线直接查点表确认通信地址对应的接口类和OAD组一帧GET请求发过去。没有点表的话先和表计厂家要这一步无法跳过。4.3 现场常用参数速查表我把配置参数整理成下面的速查表调试时可以直接抄场景波特率校验位数据位停止位备注DLT645标准表2400/9600偶校验81大部分表出厂2400DLT645老款集中器2400偶校验81无FE前导帧DLT698.45智能表2400/9600偶校验81帧长超时时间建议≥1s不确定时2400偶校验81先发645广播读地址试响应注意调698链路时发送完请求后不要急着判断失败先在接收区等1到2秒。698报文长、处理慢很多表计响应要几百毫秒你只看个几百毫秒的窗口容易误判为设备无响应。5. 我踩过的坑地址正反序、校验和与波特率误判指令会发了不代表现场就能顺利。大部分人的卡点不是不会拼报文而是踩在一些很容易被忽略的小细节上。我挑几个高频坑展开说你遇到过就知道有多痛。5.1 地址正反序最容易看错的陷阱645的表地址是6字节BCD码但它在报文里是低字节在前。举个例子表号如果按常见写法是000000000001实际报文地址域里看到的很可能是01 00 00 00 00 00。当你用串口工具看到地址域是34 12 00 00 00 00时真正的表号大概率是001234000000而不是341200000000。现场很多人犯的错误是用上位机软件读表正常但人工看报文时把地址当成普通十六进制字符串直接录入录进去之后集中器下发又读不回来。排查到最后才发现是字节序镜像问题。我的习惯是不管645还是698只要涉及表地址先在纸上把字节按逆序重排一次再录入。5.2 校验码范围算错一发出去就废645校验码的计算范围我之前强调过是从68开始到DATA最后一位结束。但不少资料和工具会让学生从地址域开始算或者把最后的16也算进去结果就是发出去的帧CS差一位表计直接不响应。判断是不是校验码问题很简单用串口工具打开十六进制监视把表计无响应时的发送帧记录下来用工具重新算一遍CS对比你填进去的CS值。差一个数就说明范围错了。我见过最典型的一种错误是只算了68后面地址域到DATA漏了最开头的68最后一位永远差0x68调试半天找不到原因。5.3 波特率误判报文看着对就是不应答很多智能表支持自动波特率识别但也有相当一部分表是出厂固定值。你用9600bps去问一个2400bps的表发的报文再标准也没用。我摸索出一个快速试波特率的顺序先用2400偶校验发645广播读地址如果没响应切9600偶校验再发一次还没有就切到9600无校验。要是都没有再考虑是接线问题还是表计规约协议不匹配。这个方法效率最高因为645读地址帧很短发一帧才几十毫秒判断响应后立刻切换参数整体也就一两分钟。5.4 链路噪声和负载电阻慢工出细活的地方最后说一个最容易忽略的物理层问题。RS485总线如果只有一台表两个终端电阻不接也通常能通信但距离超过几十米或者现场有变频器、开关电源干扰时丢帧和错帧就出现了。表现很诡异同一个报文发十次偶尔成一次数据还会偶发校验错。处理手段不外乎几个用带屏蔽的RS485专用电缆屏蔽层单端接地A、B间接120欧终端电阻USB转485模块换成带隔离的工业级。大部分现场噪声问题都能靠这三招解决。如果加完终端电阻反而没响应检查是不是总线上挂了两台设备各接了一个电阻这时候等效电阻变成60欧部分驱动能力弱的模块就带不动了。把物理链路搞稳再把字节序和校验码算对DLT645和DLT698的读地址操作其实真就是五分钟的事。我在实际项目里每次排查抄表失败都默认从读地址开始验证链路而不是直接抓应用数据。因为读地址这条命令最简单、返回最快、问题最容易定位链路通不通、参数对不对一帧下去就看明白了。这个思路也推荐给你至少能省下一半的现场调试时间。