企业官网建设流程全解析

简介：这是一份针对DL645-2007电能表数据采集与上位机集成的实操资料，面向从事工业自动化、能源监控及电力数采的工程师和技术人员。资源以KepwareEX的User Configurable (U-CON)驱动为主线，完整演示了从新建通道、配置COM参数、建立LBCD数据标签，到按DL/T 645-2007规约编写发送指令、校验码和响应读取规则的全过程，并重点讲解了余3码数据格式的缩放处理方法，帮助读者打通电能表与Wincc等OPC客户端的实时数据链路。包内为1个PDF文档，大小约1.21MB，内容配有配置截图和关键参数说明，可直接作为现场组态和排错的参考手册。已有2918人学习，适合需要快速上手非标准串口设备接入OPC系统的工程人员。

1. Kepware连接DL645-2007电能表：从驱动选型到数据上云的第一步

工厂某配电间，A同学蹲在电表前拍了一张液晶屏照片发到工作群：电表明明在走字，监控大屏上的电压电流却全是 0。后来把串口线插到笔记本上抓帧，才发现是 OPC 服务器把 DL645-2007 的帧当成了 Modbus RTU 在解析。这类翻车现场在能耗监测项目里非常普遍——DL645-2007 是国标电表最常走的通讯协议，而 Kepware 作为 SCADA 与电表之间的 OPC 网关，驱动选型和参数配置决定了你能不能把表号、电压、电流、电能量稳定读上来。这篇笔记把「Kepware 里建通道 → 配表地址 → 映射标签 → 排查通讯」整条路讲透，适合正在做配电监控、能耗管理、状态运维的系统集成工程师照着落地。

2. DL645-2007协议要点与Kepware的通讯定位

2.1 帧结构：起始符、地址域、控制码、校验与主从握手

DL645-2007 报文以 0x68 开头，以 0x16 结束。帧结构依次是：0x68 + 6 字节地址域 + 0x68 + 控制码 + 数据长度 + 数据域 + 校验 + 0x16。地址域按“低字节在前”发送。把表号 123456 换算成 BCD 码是 12 34 56，但帧内实际顺序是 56 34 12 00 00 00。很多新手第一次抓帧看到地址反着，就以为驱动或电表坏了，其实这是协议特性，不是故障。

控制码是最容易理解错的字段。它的最高位 D7 表示帧方向：0 是主站请求，1 是从站应答。主站发“读数据”请求用 0x11，从站正常应答是 0x91；数据太长需要分帧时，用 0x14 / 0x94 这类“读后续数据”命令，D4 位用来标注是否还有后续帧。数据长度 L 只统计数据域的字节数，不包括校验 CS 和结束符 0x16。如果协议手册里写 L=7，意思是数据标识符 DI 四字节加数据三字节。

CS 是和校验，不是 CRC16。计算范围从第一个 0x68 开始，一直叠到数据域最后一个字节，取低 8 位。算起来很简单，但 Kepware 里报“校验错误”时，原因往往不是算错，而是帧传输丢字节。抓帧时最常见的画面是请求帧完整、应答帧少一个字节，这多半是 RS-485 电平抖动或者波特率不对齐造成的。

下面这个 Python 脚本我一直在用，拿到一串十六进制抓帧数据，贴进去就能判断帧对不对、地址是哪个、控制码是什么方向：

# 解析DL645-2007帧，适用于验证抓包或Kepware日志中的原始报文 def parse_frame(hex_str): raw = bytes.fromhex(hex_str.replace(" ", "")) if raw[0] != 0x68 or raw[-1] != 0x16: raise ValueError("不是DL645帧") cs = sum(raw[:-2]) & 0xFF # 和校验：从起始符到数据域全部字节 if cs != raw[-2]: raise ValueError(f"校验失败: 计算={cs:#04x} 帧内={raw[-2]:#04x}") addr = "".join(f"{b:02X}" for b in raw[1:7][::-1]) # 低字节在前，这里反转 ctrl, length = raw[8], raw[9] data = raw[10:10 + length] return { "表地址": addr, "控制码": hex(ctrl), "数据标识符": data[:4].hex(), "数据域": data[4:].hex(), } # 示例：从站应答读A相电压，数据域为02 31 04，表示231.4V frame = "68 56 34 12 00 00 00 68 91 07 01 01 00 00 02 31 04 3D 16" print(parse_frame(frame))

控制码打印成 0x91，说明这是从站应答；数据标识符是 01 01 00 00，数据域是 02 31 04。脚本里把地址域做了高低字节反转，所以输出表地址是 123456000000。不要把输出里的补位 000000 当成真实表号，它只是地址域的高位空余字节。

还要注意，DL645 地址域全 0 是广播地址，只能用来做广播校时或广播设置，不能拿它轮询一块真实电表。有人把设备地址填成 0，Kepware 一直报无应答——这不叫通讯成功，只是广播发出去没人认领。现场排查时，先确认表号不是 0，换个唯一地址再试。

2.2 专用驱动与通用串口驱动的选型差异

KEPServerEX 新建通道时，驱动列表里有一大串串口协议驱动。很多人图省事，把所有串口设备都挂到 Modbus RTU 驱动下，这个习惯用在 DL645 电表上必然失败。DL645 的帧以 0x68 为起始符，地址域是 6 字节；Modbus RTU 帧以 1 字节设备地址开头，校验是 CRC16。Kepware 的 Modbus 驱动收到电表返回的 0x68，会把它当作非法设备地址，直接判定通讯错误。

所以在驱动列表里要选名称带“DL/T 645”或“DL645-2007”字样的专用驱动。不同版本的 KEPServerEX 驱动显示名略有差异，但关键字逃不开 DL、645、2007。如果装了常见完整版却找不到，可以检查一下安装时是否勾选了全部驱动包，有些精简安装默认不装电力协议驱动。

选对驱动后，标签地址的语义也会跟着变：地址栏填的是数据标识符 DI 的组合，而不是寄存器号。这是和 Modbus 驱动最本质的区别。Kepware 的专用驱动已经把帧组帧、校验、应答判断都封装好了，你要做的只是告诉它“哪个 DI 对应哪个标签”。不理解 DI 的人，即使驱动选对了，标签映射还是会张冠李戴。

2.3 OPC DA与OPC UA出口先规划：通道属性里的“UA可用”开关

Kepware 这层不只是数据采集，它同时对外提供 OPC DA 和 OPC UA 服务。旧 SCADA 系统多用 OPC DA，新平台和云网关多数走 OPC UA。新建通道时，我习惯先看一眼通道属性里的接口开关，把 OPCDA 和 OPC UA 都打开，省得后续接入方换协议时再回来改配置。

OPC UA 访问没打开的典型症状是：OPC UA 客户端能连到服务器，也能看到服务器节点，但浏览不到任何设备标签。这个问题很容易被误判成用户名密码或防火墙问题，实际是服务器侧把 UA 访问关掉了。配电间那边改一下属性重启服务，比在客户端翻半天日志快得多。

3. 在Kepware里配置DL645-2007通道和设备：三步走

3.1 新建串口通道：接线、COM口与波特率参数表

RS-485 现场接线常见做法是从电表的 A/B 或 485+/485- 端子手拉手串到下一块表，最后回到串口服务器或 USB-485 转换器。Kepware 侧在通道目录右键新建通道，驱动选 DL645 专用驱动，接下来进入串口参数配置。

波特率是最隐蔽的坑。DL/T 645-2007 标准里默认通讯速率是 2400bps，但很多电表在出厂或上次调试时被改成了 9600。Kepware 按默认 2400 去轮询，电表收到了但回帧速率是 9600，Kepware 解析不出来，表现就是超时或乱码。我一般先看电表液晶菜单里的通讯参数页，确认波特率和校验位，再动 Kepware。

总线上接的表超过十来块时，还要考虑 RS-485 的物理层。手拉手菊花链，不要拉成星形；距离超过 300~500 米时，在总线末端加 120Ω 终端电阻。某项目后几块表数据一顿一顿，最后在最后一块表的 A/B 间接上匹配电阻才稳定，这跟 DL645 协议无关，但排查时经常被当成协议兼容问题折腾一整天。

提示：RS-485 是半双工，A/B 接反后典型现象是“大部分表能读，个别表超时”或者整条总线都不通。先用螺丝刀确认线色定义，再通电。

3.2 添加电表设备：6字节表地址的填法

通道建好后，在通道下新建设备。设备名称自己写，例如“Feeder_01_UA”；设备地址那一栏填表号。表号就是电表液晶菜单里看到的 6 位十进制数，比如 123456，直接填 123456。Kepware 驱动内部会把它转成 BCD 并按低字节在前的规则组帧。

表号不足 6 位时要小心。比如表号 1234，有的驱动要求补成 001234 才能按 BCD 正确编码，有的驱动会默认高字节补 0。我习惯按 6 位十进制补齐再填，避免不同版本驱动行为不一致。表号超过 6 位的，只看后 6 位，因为地址域总共 6 字节，高字节装不下前导数字。

同一总线上的表地址必须唯一。DL645 的地址是 6 字节，有些现场改表只改了后两位，高字节保持出厂一致，结果两块表地址前四位相同，Kepware 发请求时两块表都会尝试应答，总线直接冲突。加表时养成习惯：把所有表号按 A、B、C 相序整理成台账，检查有没有重复。

提示：地址全 0 是广播地址，不要把它当成“自动寻址”填进 Kepware。真实电表地址不可能全 0。

3.3 请求超时、重试次数与轮询周期：多表总线的稳定性参数

设备属性里有几个参数直接决定整条总线稳不稳：请求超时、重试次数、轮询间隔。只接一块表时怎么设都行，十几块表时这些参数就非常敏感。

请求超时建议不小于 500ms。DL645 从站要求在收到完整帧后很快响应，但带负荷曲线记录的表在整点冻结时，CPU 可能先处理数据存储再回帧，偶尔拖到三四百毫秒。设 200ms 时，表明明回了，Kepware 已经放弃，状态就跳红。我一般先设 1000ms，等总线稳定后再逐步缩小，找到不影响刷新率的临界值。

重试次数设 1 到 2。默认 3 次在这里是个陷阱：某块表离线，Kepware 会连续重试 3 次，每次等满超时，后边排队的所有表都被拖慢。整个总线看起来是“越来越慢”，最后排除下来是一块坏表在拖大家。

轮询间隔默认 100ms 对多表总线来说太短。我的经验值是：表数量 × 250ms 起步。32 块表用 8 到 10 秒一轮，对能耗平台足够。如果你接的是实时监控需求，那应该考虑把总线拆分，而不是把轮询间隔压到 100ms。

4. 把DL645-2007数据项映射成Kepware标签：DI标识符、BCD与缩放

4.1 从电表手册里找数据标识符编码表：DI0到DI3怎么组装

DL645-2007 的数据标识符是 4 个字节，习惯上写成 DI3、DI2、DI1、DI0。DI0 通常表示分项或相别，DI1 表示数据类型，DI2、DI3 进一步限定。国标里有数据项编码表，但是每家电表的出厂协议手册会附一张更直接的“数据项编码表”，这张表才是你配置 Kepware 标签的唯一依据。

Kepware 标签地址栏填的就是 DI 四字节。不同版本驱动写法不一样，常见的有：直接拼四个十六进制字节如“01010000”，也有用点分隔写作“01.01.00.00”，还有驱动直接提供下拉树让你选数据项。以驱动帮助里的示例为准，但 DI 的语义是不变的。

我开工前会先做一张表，把要读的量和 DI 对应关系列出来，类似这样：

表里的编码只是常见形式，实际必须以你手上那家电表的协议手册为准。电表品牌一换，DI 编码就可能完全不同。Kepware 不问“这是哪个品牌的表”，只认 DI。没有这张表，你看到电压读成电流时只能盲猜，试错成本极高。

4.2 BCD解码与小数点缩放：2314还是231.4？

DL645 数据域里传输的数值绝大多数是 BCD 编码，而且不携带小数点。以 A 相电压 231.4V 为例，帧里的三个字节是 02 31 04。如果把整串 BCD 转成十进制是 23104，不是 231.4。小数点在哪一位，由你手上的数据项编码表决定，Kepware 不可能自动知道。

所以标签建好后的第二步是处理缩放。Kepware 里可以在标签属性中配置缩放系数，或者你在上位机侧除以 10、除以 100。电流也一样：数据域读回 02 56 00，按编码表理解成 2.560A，缩放系数就是 0.001。我不建议在 OPC 客户端里临时做计算，最好在 Kepware 标签层就处理成工程值，客户端拿到就能直接用。

字节顺序也是坑。DL645 数据域内部不搞小端大端那套，而是按高位字节在前的 BCD 顺序排列，所以 Word 数据类型的“字节顺序”字段如果可选，优先选 Big-Endian。某项目读上来的电压数值变成了 31.42，看起来像 231.4 的字节被倒着读了一遍，把字节顺序切到 Big-Endian 就好了。

4.3 最小可抄配置：两个标签加一个Python解析脚本

以读 A 相电压和 A 相电流为例。在设备下新建标签，名称写 UA、IA，地址栏按驱动要求填 DI 组合。数据类型根据驱动支持选 Word 或 BCD 类型，数据域 3 字节的量有些驱动用 DWord 读。配置完用 Kepware 自带的 Quick Client 看实时值：UA 显示 231.4，说明缩放系数对；显示 2314，就把缩放系数补一个除以 10。

Kepware 能读，但你想自己验证时用下面脚本处理 BCD：

# 把DL645数据域的BCD字节转成十进制值 def bcd_to_int(raw_bytes): value = 0 for b in raw_bytes: value = value * 100 + (b >> 4) * 10 + (b & 0x0F) return value # 电压231.4V对应BCD字节：02 31 04 raw = bytes([0x02, 0x31, 0x04]) print(bcd_to_int(raw)) # 输出23104 print(bcd_to_int(raw) / 10) # 输出231.4

注意这个脚本假设每个字节都是合法 BCD，遇到像 0xAB 这种非法值会算出错位的结果。真实调试中，如果 bcd_to_int 输出一连串不合理的锯齿值，先去怀疑帧有没有错位，而不是算法问题。

5. Kepware接DL645-2007的避坑指南：五个经典故障现场

5.1 现象：通讯失败但电表液晶正常

电表走字正常、液晶背光亮着，Kepware 里设备状态却是红色。按顺序排查：表号、波特率、奇偶校验、A/B 接线、总线争抢。

先拿一个串口调试工具直接发一帧读电压请求，看电表在不在线。工具能收到应答而 Kepware 收不到，说明问题在 Kepware 通道参数；工具也收不到，那就是接线或电表侧通讯参数被改过。某项目就是前一家集成商把表设成了偶校验，后来接手的没人知道，Kepware 默认无校验，折腾了整整一天。

5.2 现象：读取出来的数值翻10倍或小数点错位

电压显示 2314，实际应该是 231.4V；电流显示 2560，实际是 2.560A。这不是电表坏了，是 BCD 到工程值没做缩放。Kepware 把 02 31 04 读成 23104，你再用无符号整数直接显示，自然变成 2314 或者 23104，完全取决于驱动解析成几个字节。

解决方法是把标签类型和缩放系数一次配对。先看协议手册里这项数据的长度和单位，再设标签的数据类型和缩放。电压是 3 字节 BCD，除以 10；电流是 3 字节 BCD，除以 1000。注意有些字段是 2 字节，缩放系数完全不同，不能拿电压的系数套到功率上。

5.3 现象：校验错误反复出现

Kepware 设备本身没红，但日志里不断刷校验错误，数据偶尔正常偶尔跳变。先查 RS-485 布线：是否和变频器动力线走同一个线槽，屏蔽层是否单端接地，末端有没有接终端电阻。再查总线上是否还有另一个主站设备，比如某个采集器也在按自己的周期轮询同一块表。

两个主站同时发帧，半双工总线直接碰撞，双方都会收到残缺帧，校验错误自然连续出现。解决方法是把其中一边的采集功能关掉，或者用带有主从授权切换的集线器。加“请求间延迟”对这种碰撞只能缓解，不能根治，根因是拓扑或主站冲突。

5.4 现象：Kepware能读但不能写

读电压、读电量都正常，但写时间、写费率时返回失败。DL645-2007 的写命令里有密码区、操作者代码这些字段，不同电表厂家对权限校验的实现也不一样。Kepware 的 DL645 驱动在不同版本里对写功能支持差异很大，有的干脆没有实现写命令。

项目里如果只是要校时，我建议别在 Kepware 层纠结写功能，把校时任务放在采集终端或串口服务器上做，让终端统一用广播校时命令。改费率、拉负荷曲线这类操作直接用表厂的手持单元做，比在 OPC 服务器上折腾写命令可靠得多。

5.5 现象：OPC客户端能读到标签但数据不刷新

标签状态显示 Good，但值一直不变。先看 Kepware 侧标签是否 Enabled，再看通道是不是被置成了 Inactive。这两个是最容易被忽略的开关，配置完通道时默认是 Active，但大项目多人协作时，有人可能顺手把通道停掉调试其他设备，忘了恢复。

还要检查 OPC 客户端的订阅刷新周期。有的客户端默认刷新间隔是几十秒，电表数据每两三秒变一次，你看起来就像“卡住了”。把客户端刷新间隔调到 1 秒，同时对照 Quick Client 看同一标签的值，Quick Client 能更新，客户端不更新，那问题就在客户端参数上。

6. 进阶验证技巧：用串口日志和抓帧给DL645-2007连接上个“后悔药”

6.1 把Kepware的日志打开，看它到底发了什么

Kepware 的诊断日志能看到设备和通道的通讯状态，但默认级别不展示原始报文。调试 DL645 时把日志强度调高，让它输出收发帧记录。对照第 2 章的帧结构人工解析，可以直接判断 Kepware 发的地址对不对、电表有没有应答、应答帧是不是在 Kepware 侧校验失败。这个习惯能省下大量“盲调”时间。

6.2 用串口监听抓真实总线报文，不猜

Kepware 日志有时只显示错误码而不显示原始帧，这时候用 USB-485 转接头并联到总线上，监听模式收发。抓到的十六进制帧贴进第 2 章的 Python 脚本，立刻能确认是表没收到，还是表回了但地址对不上。

抓帧时监听设备只收不发，否则它自己就变成第三个会抢总线的主站。实测中发现不少“通讯不稳定”其实是调试时挂了一堆监听设备在总线上乱发请求，拔掉就正常了。调试完把临时线拆除，保持总线只留一套主站。

我现在做 DL645 项目有一件事已经成了习惯：先做一张最小表台账，把表号、波特率、校验位、DI 编码表、接线位置一次列全，再打开 Kepware 配置。这样留了底，后来的人不用重新抓帧猜参数，跳过的坑不会再踩第二遍。希望这篇笔记能帮到正在调表的你。

本文还有配套的精品资源，点击获取