简介面向工业自动化与电力监控人员的Kepware配置文档解决DL645-2007电能表RS485通讯格式特殊、难以接入上位机的问题。文档以KepwareEX的U-CON自定义驱动为主线介绍通过RS485转RS232转换器或泓格7188串口服务器连接电表并最终在Wincc等OPC客户端中实时显示电能数据的过程。内容覆盖U-CON通道与设备新建、TransactionEditor事务配置、LBCD数据类型与BCD反向格式、余3码缩放处理以及DLT645-2007报文中的唤醒帧、控制码、校验码和结束符等关键设置这些正是实际配置中最容易出错的环节。文档还结合完整配置示例指出了物理媒体选择、通信参数、设备地址确认、返回数据起始字节等现场的常见问题并给出校验和计算与事务指令顺序的注意点可有效减少现场调试时的摸索时间。资源为单一PDF文件压缩包大小为1.21MB已有2913人学习/下载适合电气、自动化工程师与系统集成人员用作协议对接和调试参考。1. 用Kepware对接DL645-2007电能表不用自己写协议栈的采集方案现场摆着几十块DL645-2007规约的电能表MES和能源管理平台要实时电量找了一圈发现表计厂家只给了一个最简单的串口调试工具剩下的事全得自己扛。自己写采集程序不是不行但要处理帧校验、BCD码、字节序、断线重连、历史补采开发一周、维护半年最后还会被问“为什么凌晨三点数据少了一段”。标题这份《Kepware连接DL645-2007电能表.pdf》的真正价值是把另一条路讲清楚了KepwareKEPServerEX本身就内置DL/T 645驱动通道一建、设备一配、点位一填电能表数据就能以OPC UA/DA、SNMP或MQTT的形式上送协议栈的事驱动全包了。反直觉的是DL645-2007协议本身并不难真正让工程师翻车的点几乎都集中在两处表号在报文里的字节序以及Kepware地址栏里数据标识的书写格式。这两点驱动文档里写得并不醒目但一旦搞反读上来的数据要么超时、要么数值完全没有意义。这篇文章适合能源管理系统集成商、工厂自动化工程师以及所有要接一批电能表又不想长期维护私有采集程序的人。2. DL645-2007的帧与数据标识不读懂这两张表后面全是玄学虽然Kepware把协议栈封装掉了但配置点位时绕不开两个概念帧里地址域的顺序以及“数据标识DI”的映射规则。先把这两张表吃透后面建通道配参数才不会两眼一抹黑。2.1 请求帧和应答帧每个字节都在干什么DL645-2007的报文结构非常规整读一类数据就是一组固定格式的帧。以最常见的“读总电量”请求为例帧结构如下字段字节数内容说明起始符10x68固定帧头地址域6A0~A5表号低字节在前起始符10x68第二个帧头控制码10x0101H表示读数据数据域长度10x04后面4字节是数据标识数据标识4DI0~DI3要读的对象校验和1CS地址域到数据域累加和取低8位结束符10x16固定帧尾这里第一道坑就来了地址域A0是表号的最后两位A5才是表号的前两位。比如铭牌表号是123456789012帧里地址域的字节顺序是 12 90 78 56 34 12而不是按表号从前到后排列。Kepware的设备ID直接填铭牌表号就行反转工作由驱动内部完成但你自己抓包看日志时看到一帧 68 12 90 78 56 34 12 68 01 04 ... 千万别以为驱动配置错了。控制码的规则也值得记一下请求读数据是0x01应答帧则是0x81也就是最高位置1。所以看到返回帧控制码是0x81第一反应应该是“这是读数据应答”而不是“新的一条命令”。数据域长度L统计的是从数据域开始到数据结束的字节数读请求固定L04应答帧里数据域包含4字节数据标识加真正的数据体比如读总电能量应答L084字节DI 4字节BCD电量数据。校验和CS从地址域第一个字节开始累加一直加到数据域末尾取累加值的低8位。举个例子请求帧 68 12 90 78 56 34 12 68 01 04 00 00 00 00把从第二个 12 开始到最后一个 00 的所有字节累加低8位就是CS。Kepware驱动会自己算但你自己写脚本验证链路时必须会算这一笔否则抓回来的帧永远对不上。提示DL645-2007数据域如果全是FF表示表计无此数据或数据无效。见到 00 00 FF FF 这类字节别当数值处理先按无效数据排查。2.2 数据标识DI与BCD码电能表返回的原始值怎么变成kWh数据标识DI一共4字节协议文档里习惯按 DI3 DI2 DI1 DI0 的顺序写成8位十六进制比如“02010100”代表A相电压。但报文里发送顺序是 DI0 DI1 DI2 DI3也就是反过来02 01 01 00 这个文档写法在帧里实际是 00 01 01 02。这也是第二个高频翻车点。下面是现场最常用的一组DI表配置Kepware点位时直接对照填就行DI文档写法含义返回数据长度帧内字节顺序00000000组合有功总电能4字节BCD00 00 00 0000010000尖峰电量4字节BCD00 00 00 0100020000峰电量4字节BCD00 00 00 0200030000平电量4字节BCD00 00 00 0300040000谷电量4字节BCD00 00 00 0402010100A相电压2字节BCD00 01 01 0202020100A相电流2字节BCD00 01 02 0202030100总有功功率4字节BCD00 01 03 02电量数据的BCD编码方式是每字节的高四位和低四位各代表一个十进制位。例如4字节数据 00 00 12 34展开就是 1234再按电能表默认两位小数处理得到12.34 kWh。电压、电流的分辨率各品牌略有差异电压常见0.1V、电流常见0.001A但最稳妥的口径是DI表决定量纲小数位以表计铭牌或厂家说明书为准。3. 在Kepware里建通道、设备与点位从加驱动到读到第一组数据的完整步骤原理部分就绪这一章直接进入Kepware操作。建议按“通道 → 设备 → 标记”的顺序走每一步都检查一遍不要跳步。3.1 先定物理链路串口直连还是串口服务器透传新建通道的第一步是选驱动。Kepware的驱动列表里搜“DL/T 645”或“DL645”不同版本显示名称略有差异选对应2007协议的那一项。如果只有1997和2007两个选项直接选2007。物理链路通常两种PC直接插USB转485线通道类型选Serial物理端口填COM号另一种是现场已经布好了485转以太网模块走网络传输。第二种情况我一般不用Kepware直接走TCP驱动的路子而是先装串口服务器模块自带的虚拟串口软件把远端TCP映射到本地一个COM口Kepware仍然按串口通道配置。这么做的理由是DL645驱动本身默认就是串口模型虚拟串口方案最省事排障时也能用串口调试工具直接探测总线不用在Kepware和网络驱动之间反复猜。串口参数这里是个关键点波特率以表计铭牌为准常见2400、4800、9600数据位8停止位1校验偶校验。部分老表出厂设置可能是不校验这一项在链路不通时再回头改先按偶校验配。3.2 设备属性表号、通信参数、超时一个都不能错通道建好后添加设备。设备属性里最核心的一项是Device ID也就是站号。DL645-2007的规则是直接填表计铭牌上的12位表号不足12位前面补0。Kepware驱动会自动把表号转换成帧里的6字节地址域你千万别自己先反转一遍再填进去否则日志里看到的地址域会乱套。通信超时Communication Timeout建议从1000毫秒起步。485是半双工总线表计响应需要时间超时设太短会让Kepware误判通信失败。轮询周期在多表共享一条485总线时尤其重要单表500毫秒没问题总线挂了五六块表以后建议放宽到1000毫秒以上给每块表留足响应窗口。设备属性里通常还有协议版本选项确认选到DL/T 645-2007。有些驱动把1997和2007协议做在一个设备类型里选错版本后读请求帧结构完全一样但部分表计固件对帧内保留字段的处理不一样会导致偶发性超时。这个选项在Kepware里藏得比较深配置完最好回来看一眼。3.3 标记地址数据标识在这里以什么格式出现设备配好以后就是建标记Tag。标记名称随意起但地址格式有讲究。常见写法是“表号.数据标识”例如 123456789012.00000000 表示读这块表的总电能。部分驱动版本支持用空格或斜杠做分隔符第一次配置时按F1打开驱动自带的地址帮助Address Help里面会明确写当前版本的地址语法这是最不会翻车的路子。数据标识在Kepware地址里填的是文档写法也就是 DI3 DI2 DI1 DI0不用自己反转。比如读A相电压地址里写 123456789012.02010100Kepware发出报文时驱动会自动换成 00 01 01 02 的帧顺序。提示第一轮验证阶段标记的数据类型优先选字符串或字节数组类型先看原始返回值不要一上来就做缩放转换。链路和数值都对上了再改成数值型并配置工程单位。建好标记后打开Kepware自带的Quick Client右键把标记加进去看Value和Quality。Quality为Good代表链路通、有应答Quality为Bad或Communication Failure回到通道和设备参数排查。3.4 先用Python模拟一发请求不依赖Kepware也能验证整条链路还没接Kepware之前先用一段Python脚本直接对电表发一帧读请求能确认串口线、表号、波特率这些基础项是否正常。这段脚本也适合在Kepware读不到数据时做对比诊断。from serial import Serial def build_read_energy(meter_no: str, di: str 00000000) - bytes: # meter_no 为12位表号每两位一组再反转得到帧内的6字节地址域 addr_pairs [meter_no[i:i2] for i in range(0, 12, 2)] addr bytes.fromhex(.join(reversed(addr_pairs))) # 数据标识同样按每两位反转文档写法 00000000 转帧顺序 00 00 00 00 di_pairs [di[i:i2] for i in range(0, 8, 2)] di_bytes bytes.fromhex(.join(reversed(di_pairs))) payload b\x68 addr b\x68\x01\x04 di_bytes # 校验和从地址域第一个字节累加到数据域末尾取低8位 cs sum(payload[1:]) % 256 return payload bytes([cs]) b\x16 ser Serial(COM5, baudrate9600, timeout0.5) ser.write(build_read_energy(123456789012, 00000000)) frame ser.read(32) print(frame.hex( )) ser.close()脚本里核心就两处地址域反转和校验和计算。meter_no按两位一组切分后反转得到的字节序列就是帧里 12 90 78 56 34 12 的顺序DI同样处理。校验和覆盖范围从地址域第一个字节到数据域最后一个字节注意payload[1:]从地址域开始不包含最前面的0x68。timeout设0.5秒足够9600波特率下帧总长约20字节传输在50毫秒内完成500毫秒是给表计响应留的余量。如果这段脚本能收到完整应答帧而Kepware读不到问题就在Kepware的驱动配置或串口占用上。4. 从原始报文到报表数据数据标识映射、BCD换算与变比处理链路通了、Quality也是Good但Kepware读上来的值经常不是你想要的那个数。这一章解决的就是“原始报文变成报表数据”的最后一公里。4.1 用一张表把常用点位的DI备好现场点位设计阶段就把DI表整理成独立文档别一边配点一边翻协议。常用到的大类就三类电能量DI首位00、瞬时变量DI首位02、参变量DI首位04。电能量覆盖尖峰平谷电量瞬时变量覆盖电压电流功率参变量一般用于读表地址、通信速率这类参数。DI文档写法含义数据长度常见分辨率00000000组合有功总电能4字节BCD0.01 kWh00010000尖峰电量4字节BCD0.01 kWh00020000峰电量4字节BCD0.01 kWh00030000平电量4字节BCD0.01 kWh00040000谷电量4字节BCD0.01 kWh02010100A相电压2字节BCD0.1 V02020100A相电流2字节BCD0.001 A02030100总有功功率4字节BCD0.01 kW上面表格只列了A相电压电流B相、C相对应把DI里第三组字节换成02、03。有功功率和无功功率的标识在0203和0204之后继续排。分辨率一列不同厂家表计可能有差异接表后第一件事是把表计屏显数值和Kepware读到的原始值做一次对比以屏显为准修正倍率。4.2 BCD转十进制把十六进制字节变能入库的数值Kepware里如果直接按原始字节读上来得到一个类似 00 00 12 34 的字节序列这是BCD码不是十六进制整数。最简单的转换方式是把整段字节转成十六进制字符串再当成十进制数解析。def bcd_to_decimal(data: bytes) - int: # 4字节 BCD 00 00 12 34 - 字符串 00001234 - 整数 1234 return int(data.hex()) raw bytes.fromhex(00001234) value bcd_to_decimal(raw) # 1234 energy_kwh value / 100 # 12.34 kWh按两位小数这个方法的优势是不用逐位拆高低四位也避开了大小端混淆。需要注意数据域全FF的情况4字节全是0xFF表示表计无数据或该数据标识无效转换前先判断一下别把FF当成一个巨大的数值入库。另外少数表计实现会在功率、功率因数这类数据上带符号位规则通常是返回数据的最高字节最高位为1时表示负值。判断方法是先看数据标识对应的是哪一类量电能量一般无符号功率类按表计说明书确认后再处理符号位。4.3 变比和大数为什么有的表要乘PT/CT有的表读出来是负的现场表计经常接在PT电压互感器和CT电流互感器后面比如10kV回路配100V电压互感器和200/5电流互感器。表计读到的是二次侧值报表需要一次侧值中间差一个变比乘积。两种处理思路在Kepware里对每个点位做线性缩放或者把原始值上送在后端统一乘变比。我一般建议在后端统一乘变比。原因一是全厂口径统一电量、功率、电压三套变比逻辑集中维护原因二是Kepware里点位几百个每个点都配一组缩放参数后期换表或改CT变比容易漏改。边界情况是数据要直接进SCADA且点位少比如只有十来块表那在Kepware里做缩放也完全可以接受配置方法用Kepware的缩放功能把原始值起始点和终止点映射到工程值即可。还有一种容易误判的情况表计读到的是反向电量或功率比如分布式光伏并网点电能表会记录反向有功。这种情况下读上来的BCD编码本身没问题但方向标识藏在更细分的DI里比如尖峰正向有功电量和尖峰反向有功电量是不同的数据标识。点位设计阶段就把正反向分开建点否则报表里会出现一块表同时累计正反向电量的奇怪现象。5. Kepware连接DL645-2007的常见坑与排查五个现场记录链路通了不代表万事大吉这一章是这几年在现场踩出来的高频问题记录每条都是“现象 → 原因 → 解决”的完整链路。5.1 串口助手能通Kepware连上就Quality Bad现象用串口调试助手手动发帧能收到正常应答但Kepware里Quality一直显示通信失败。原因有两类第一类最常见串口调试助手还开着占用了COM口。Windows下同一个串口不能被两个程序同时打开Kepware拿不到端口权限但串口助手那边收发报文完全正常。第二类是485的A/B线接反有些串口服务器模块带自动极性纠正调试助手用着正常Kepware直连时没有这层容错就露馅了。解决先关掉所有串口调试工具再重启Kepware通道服务。若仍然不通把485的A/B对调一次再试。这个坑排在第一位因为它出现的频率远高于协议本身的任何问题。5.2 读上来的值和表计屏显差100倍现象Kepware读出总电量为123456表计液晶屏上显示1234.56或者反过来。原因BCD转换时小数位处理不一致。表计屏显的小数位是表计自己配置的部分品牌支持把DL645报文里的电量小数位设成0位或1位而协议默认按两位小数。另外还要确认是不是DI选错比如要用组合有功总电能00000000实际却选了别的电量标识。解决到表计跟前抄一次屏显读数按屏显位数调整Kepware或后端的倍率。如果表计菜单里有“DL645小数位”配置项可以直接改成协议默认的两位这样全系统口径统一。5.3 多表总线只第一块表能读现象485总线挂了6块表Kepware里6个设备只有第一块Quality为Good其余全部超时。原因通常是表号重复或存在000000000000广播地址。DL645-2007协议里全0地址是广播地址如果某块表出厂没设置表号它会对所有读命令做广播响应其他表收不到总线使用权。另一种常见原因是485接线成了星型拓扑分支过长导致反射信号严重。解决用表计面板或红外抄控器给每块表设独立表号确认全总线没有全0地址。485总线必须手拉手菊花链分支尽量短总线两端各并一个120欧终端电阻。把Kepware轮询周期从500毫秒调到1000毫秒以上也能缓解总线拥塞导致的漏响应。5.4 串口服务器透传Kepware隔几个小时就断一次现象换成485转以太网模块后Kepware刚开始正常运行几小时或一天后Quality变Bad重启Kepware又恢复。原因串口服务器模块的空闲连接超时设置太短TCP链路被模块主动断开而Kepware侧没有及时重连。很多模块默认空闲超时只有几十秒DL645又是低频轮询链路Kepware两次读请求之间的间隔很容易触发模块的超时判断。解决串口服务器管理页面里把TCP Keep-Alive打开连接空闲时间设到最大值或0同时把Kepware设备属性里的重试次数Retry Attempts从默认3次调到10次。如果模块固件不支持改空闲超时考虑换一台支持“透明传输常在线”模式的模块。5.5 收到应答帧但Quality还是Bad现象在串口服务器或抓包工具上能看到完整的 68 ... 16 应答帧Kepware日志里也记录了收报但标记Quality始终是Bad。原因驱动对返回帧校验后判定字段不匹配。最常见的是表计固件按DL/T 645-1997旧版应答返回帧的数据标识顺序和2007版不一致还有少数厂商在CS校验和之前插入了自己的扩展字节导致Kepware校验和计算失败。解决把抓到的应答帧和协议文档逐字节对照先看数据标识顺序再看CS位置。确认表计固件版本如果是1997版回设备属性把协议版本切到1997。遇到厂商扩展字节的只能换支持该品牌扩展规约的驱动或者用采控终端先把协议归一化这属于少数情况碰到一次就有印象了。6. 进阶验证用Kepware诊断日志加一段解帧脚本把报文读得明明白白点位建多了之后最怕的是“哪个地址对应哪个数值”全凭猜。我的习惯是配置完第一块表后先不急着批量加点位而是把Kepware的诊断日志打开抓几帧原始报文用一段小脚本解一遍确认表号、DI、BCD值全部对上再回头批量配置。Kepware的日志配置工具在安装目录下打开后把通信诊断级别调到Info或Debug重启通道服务让日志落盘。然后触发一次对目标表的读操作在日志文件里找到对应表号的收发帧把帧头到帧尾的十六进制复制出来。这里有一段精简的解析函数核心是还原表号和DIdef parse_dl645_frame(buf: bytes): if len(buf) 16 or buf[0] ! 0x68 or buf[-1] ! 0x16: return None length buf[8] # 地址域6字节反序还原12位表号帧里先出现的其实是表号末两位 meter .join(f{b:02X} for b in buf[1:7][::-1]) ctrl buf[7] # 帧内DI是 DI0 DI1 DI2 DI3反序后才是文档里的 02010100 写法 di_doc .join(f{b:02X} for b in buf[9:13][::-1]) print(表号:, meter, 控制码:, f{ctrl:02X}, DI:, di_doc) if ctrl 0x80 and length 4: payload buf[13:9 length] print(BCD原始值:, payload.hex(), 十进制:, int(payload.hex())) frame bytes.fromhex(68 12 90 78 56 34 12 68 81 08 00 00 00 00 00 00 12 34 D3 16) parse_dl645_frame(frame)这个脚本对Kepware日志和串口抓包都适用。跑完之后做三个比对解出来的表号和Kepware设备ID一致DI和Kepware标记地址一致BCD值换算后和表计屏显一致。三步全对这块表的配置就算闭环了。如果表号对不上回看设备ID是不是填了反转后的字节序这是最常见的低级失误。后面每接一块新表我都先走一遍这个流程而不是直接依赖Kepware的Quality判断。解帧这个习惯救过我好几回凡是遇到“Kepware读上来的数不对”先用脚本还原报文再回头看配置基本十分钟内定位问题。这套方法也适用于其他串口协议设备希望帮到你。本文还有配套的精品资源点击获取