企业官网建设流程全解析

简介：Intouch Modbus驱动DASMBTCP1.1面向工业自动化领域的Intouch HMI工程师与系统集成人员，用于建立Intouch与支持Modbus TCP协议的PLC等设备之间的数据通道，解决以太网通信、变量映射与实时监控问题。压缩包共129个文件，约10.9MB，以66个dll动态库和21个exe安装/工具程序为核心，辅以12个chm帮助文档、6个pdf手册、5个hlp说明及配置文件，覆盖驱动安装、参数配置、日志查看与故障诊断等环节。已有2639人学习。读者可依据随附文档完成数据源创建、IP与端口设置、寄存器地址映射，并借助日志工具排查连接中断与重连问题。还能了解驱动对多品牌Modbus TCP设备的兼容方式，适合需要落地Intouch通信配置的初、中级自动化工程师参考。

1. Intouch Modbus 驱动 DASMBTCP 1.1：还在现场跑的老兵

某公司的老产线做过一次小改造：上位机还是那台跑 Intouch 的工控机，底下新加了六台 Modbus TCP 的电表和三台支持 Modbus TCP 的 PLC。摆在面前的选项不多——换 OPC 服务器要动画面，加通讯网关要加预算，最后大家还是把手伸向了机柜里那份 Intouch Modbus 驱动 DASMBTCP 1.1。它是 Intouch 生态里专门跑 Modbus TCP 的 DAServer，版本不新，但现场存量巨大，装完配三个对象就能让 4xxxx 寄存器直接变成 Intouch 标签。这篇就把这套东西从架构、参数、点表到排查完整拆一遍，适合手上有存量 Intouch 项目、需要接 Modbus TCP 设备的人。

2. DAServer 的三层模型：Port、Topic、Item 各管什么

2.1 Intouch 并不直接说 Modbus

很多人第一次配这套东西时会卡在一个认知上：以为在 Intouch 里填个 IP 就能读寄存器。实际不是，Intouch 本身不带 Modbus 协议栈，它只会通过 SuiteLink 或者 DDE 去问一个"数据服务方"要数据。DASMBTCP 就是这个服务方，它跑在 Windows 上作为一个服务常驻，自己去跟现场的 Modbus TCP 设备建立 TCP 连接、发功能码、收响应，然后把结果放进一块内部缓存。Intouch 读的从来不是设备，读的是这块缓存。

这个分工决定了很多现场行为。比如网线拔了，Intouch 画面上数值不会立刻变成问号，而是维持最后一次读到的值——因为缓存还在，只是不再更新。再比如 DAServer 服务没起来，Intouch 里所有相关标签一起挂掉，跟设备好坏无关。我一般会跟新人强调一句话：Intouch 侧的问题先看 Access Name，设备侧的问题先看 DAServer Manager，两边都别混着查。

DAServer 这一层还负责一些 Intouch 做不了的事：把相邻的寄存器合并成一次块读、按扫描周期轮询、设备掉线后自动降级重试、把 Modbus 的异常码翻译成条目质量位。这些东西配置得好不好，直接决定这条通道是"能用"还是"能长期用"。

2.2 Port、Topic、Item 三层对象与命名空间

DASMBTCP 的配置模型是三层，从上到下依次是 Port、Topic、Item，理解这三层比记住任何一个参数都重要。

Port 决定"往哪台设备发"，Topic 决定"以什么节奏、按什么从站号发"，Item 决定"读哪个地址、当什么类型解释"。三层是包含关系，一个 Port 下面可以挂多个 Topic，一个 Topic 下面可以挂几千个 Item。

命名空间也是这么串起来的。Intouch 里的标签写法是AccessName.Item，其中 AccessName 是一个指向"DAServer 应用名 + Topic 名"的别名。也就是说，Topic 名一旦定下来就別随便改，改了之后所有引用它的 Intouch 标签全部要重指一遍。我见过有人在调试阶段反复改 Topic 名，最后画面上几十个标签集体失效，翻了半天日志才发现是名字对不上。

有一点值得单独说：Topic 不等于设备。同一台设备如果寄存器区段差别很大（比如 4xxxx 区和 3xxxx 区扫描节奏不同），完全可以建两个 Topic 指向同一个 IP 和同一个 Unit ID，各自设不同的扫描周期和块大小。这种拆法在后面讲块读失败的时候会用到。

2.3 装完先跑通最小闭环，别急着铺点表

拿到安装包之后，我的习惯是先不碰点表，用最小的三五个点跑通一次完整链路，确认"设备 → DAServer → Intouch"这条路上每一段都是活的。铺完几百个点再回头查，成本会高一个量级。

最小闭环分四步走：

1. 确认服务在跑。装完之后DASMBTCP会注册成一个 Windows 服务，先在服务管理器里看它的状态，再打开 DAServer Manager 确认左侧树里能看到这个服务器并且处于激活状态。
2. 确认网络通。在工控机上对设备 IP 做一次 ping，再单独测 502 端口是否可达。这一步能把"配置错"和"网络不通"彻底分开。
3. 建一个 Port 加一个 Topic，只挂一个已知值的寄存器，在 DAServer Manager 自带的条目测试面板里读一次，看返回值是不是预期的。
4. 在 Intouch 里建一个 Access Name 指向这个 Topic，画面上放一个数值显示，切到运行态看能不能刷出数。

这四步任何一步断了，后面的工作都没有意义。尤其是第 3 步，DAServer Manager 自带的测试面板能直接绕开 Intouch，是这套工具里最值钱的功能之一，可惜很多人不知道它存在。

3. 从零配一条 Modbus TCP 通道：DASMBTCP 参数逐项落地

3.1 建 Port：网络地址、端口号与超时三件套

打开 DAServer Manager，左侧树里展开 DASMBTCP，在 Configuration 节点上右键添加 Port。弹出的对话框里要填的东西不多，但每一项都会在后面咬人。

第一项是网络地址，填设备的 IPv4 地址。这里有一个容易忽略的点：如果设备是通过串口服务器或者协议网关转出来的，填的应该是网关的地址，Unit ID 才是背后那台串口设备的从站号。两层地址别搞混。

第二项是 TCP 端口，Modbus TCP 的标准端口是 502。绝大多数设备用默认值就行，但现场确实存在改成 1502 或者 5020 的设备，遇到连不上先确认这一项。

第三项是响应超时和重试。默认超时通常在 1000 毫秒左右，重试 2 到 3 次。这两个值一起决定了"设备短暂抖动时 DAServer 会不会把这条通道判死"。超时设得太短，网络稍有拥塞就整片报错；设得太长，设备真挂了要等很久才反映到画面上。我一般的取法是：超时 1000 到 3000 毫秒，重试 2 次，然后观察日志里的超时计数，如果稳定运行一天超时计数还是 0，就说明这个值留了足够余量。

配置完成后可以在 DAServer Manager 里对 Port 做一次"测试连接"之类的操作，确认 TCP 层能握手成功。如果这一步就失败，后面所有参数都不用调了，先用命令行确认端口通不通：

# 先确认 ICMP 通，排除 IP 填错、网段不对 ping -n 4 192.168.10.21 # Windows 上确认 502 端口是否可达（PowerShell） Test-NetConnection -ComputerName 192.168.10.21 -Port 502

第一条命令看的是三层可达性，第二条看的是四层端口。两条都通才轮得到 DASMBTCP 出场。如果 ping 通但 502 不通，大概率是设备侧没开 Modbus TCP 服务、端口被改成别的值，或者中间有防火墙策略。这时候去查 DAServer 的日志是没有意义的，它只会告诉你连接被拒绝。

3.2 建 Topic：从站号、扫描周期与 Block Size 的取法

Port 建好之后在它下面加 Topic。这一层的参数比 Port 多，也更容易配错。

Unit ID（从站号）：Modbus TCP 不像 RTU 那样靠从站号寻址，但在网关场景下这个字段依然有意义。如果设备直连，通常填 1 或者 255 都能通；如果是网关后面挂多台串口设备，就必须填对，填错了表现是连接正常但读回的数据全是异常响应。现场的常见错误是照抄别人的配置填了 1，而实际设备是 3。

扫描周期（Update Interval / Scan Rate）：这个值决定 DAServer 多久轮询一次这个 Topic 下的所有 Item。它不是越小越好。一个 Topic 下有 500 个点，按块读合并成 10 次请求，单次往返 20 毫秒，一轮下来就是 200 毫秒；如果把扫描周期设成 100 毫秒，请求队列会永远排满，实际刷新反而更慢。我的经验值是：先按点数估一轮耗时，再乘 2 到 3 倍作为扫描周期。工艺上要求 500 毫秒内看到变化的点位，就别放在这个 Topic 里，单独建一个只挂少量关键点的快通道。

Block Size（块大小）：这是整套配置里最影响成败的一个参数。DAServer 会把地址连续的 Item 合并成一次 Modbus 块读，Block Size 就是单次块读最多带多少个寄存器。协议本身对功能码 03 的限制是 125 个寄存器、对功能码 01/02 是 2000 个线圈，但真正的约束来自从站：如果块读的地址范围里有一段设备不存在的区域，从站会返回非法数据地址异常，整块读全部失败。表现是同一片地址里，有的点好有的点坏，而且坏的点位置固定。

常见的取法是 100 到 120，并且尽量让这个值整除设备寄存器区段的长度。如果设备只有 0 到 99 这 100 个保持寄存器，Block Size 设成 120 就可能越界；设成 100 正好一次读完。我见过一台设备只实现了 50 个寄存器，现场 Block Size 用了默认值，结果每轮都有一半请求报异常，日志里刷满了 Illegal Data Address。

自动降级（Auto-Demotion）：设备离线后，DAServer 会把这个 Topic 的扫描频率降到很低，避免无谓地占用连接。设备恢复后要等降级周期结束才会重新按正常节奏扫。这个机制本身是好事，但如果降级周期设得太长（比如几分钟），会出现"设备早就恢复了，画面上还是旧值"的假象。现场一般把降级间隔设成 10 到 30 秒。

3.3 Intouch 侧 Access Name 与标签命名

DAServer 那边配好之后，切到 Intouch 的 WindowMaker。打开 Access Name 定义，新建一条，几个字段的填法是固定的：

• 节点名（Node Name）：本地访问就留空，跨机器访问才填 DAServer 所在机器的名字。
• 应用名（Application Name）：填DASMBTCP，也就是服务名。
• 主题名（Topic Name）：填第 3.2 步里建的那个 Topic 的名字，一字不差。
• 协议（Which Protocol）：优先选 SuiteLink。它比 DDE 稳定，支持更长的标签名，也不会因为 Windows 的消息机制抽风。只有在非常老的 Intouch 版本上才被迫退回 DDE。

配好 Access Name 之后，标签的写法就是AccessName.Item。比如 Access Name 叫MB1，Item 是40001，标签就是MB1.40001。这里要注意 Intouch 的标签类型选择：

• 离散量（Discrete）对应线圈和输入状态；
• 整型（Integer）是 16 位有符号，范围 -32768 到 32767；
• 实型（Real）是 32 位浮点，用来接仪表的测量值；
• 消息型（Message）用来接字符串，Modbus 场景下很少用。

最容易翻车的是整型。Modbus 的保持寄存器是无符号 16 位，0 到 65535。如果设备返回 40000，而 Intouch 标签是整型，你会看到 -25536。这不是驱动的问题，是符号位解释的问题。解决办法很简单：标签用实型，或者在做工程量转换时加偏移。

3.4 验收：用一条读命令确认链路真的通了

配完之后别急着相信画面上的数字。我习惯用一段独立脚本直接对设备读一遍，把读到的原始值和 Intouch 画面上的值对一下，两边一致才算真的通。

# 用 pymodbus 直接读设备，绕开 DAServer 做交叉验证 from pymodbus.client import ModbusTcpClient client = ModbusTcpClient(host="192.168.10.21", port=502, timeout=3) client.connect() # 读 0 起始的 10 个保持寄存器，slave 对应设备从站号 rr = client.read_holding_registers(address=0, count=10, slave=1) if rr.isError(): print("读取失败，异常码:", rr) else: print("原始寄存器:", rr.registers) client.close()

这段脚本的关键在三个参数。address=0用的是协议层地址，也就是 0 基址，对应 Modicon 编号的 40001，这一点在第 4 章会详细展开。count=10是一次读几个，别超过从站实际拥有的寄存器数量。slave=1是从站号，必须和 Topic 里的 Unit ID 一致，不一致的话在网关上会读到别的设备或者直接异常。

跑通之后再回到 Intouch 运行态，对照同一个寄存器看数值。如果脚本读到 1234 而画面显示 -25536，那问题在标签类型；如果脚本读到 1234 而画面显示 0，问题在 Access Name 或者 Topic 名；如果脚本自己也读不到，那问题在设备侧，跟 Intouch 无关。这三条分支能把排错范围一次砍掉三分之二。

4. 点表映射：把 4xxxx 寄存器翻译成 Intouch 标签

4.1 地址基址、位号与数据类型的三重对齐

Modbus 的地址有两套编号体系，这是新手最容易栽跟头的地方，而且栽了之后现象很迷惑：通讯一切正常，日志干干净净，就是数值全错，或者整体错一位。

第一套是协议地址，从 0 开始，功能码报文里带的就是这个数。第二套是 Modicon 编号，从 1 开始，并且用首位数字表示区号：

也就是说，Modicon 编号 40001 对应的协议地址是 0，40002 对应 1，依此类推。DASMBTCP 的 Item 名支持多种写法，常见的是五位编号（40001）和六位编号（400001），以及带前缀的写法。不同版本对写法的支持略有差异，最稳的办法是打开 DAServer Manager 的帮助文档看本版本的 Item 命名规则，然后用测试面板验一次。

我踩过的坑是这样的：设备手册上写"温度寄存器地址 40011"，现场照着填 40011，读回来的是隔壁那个压力值。原因是设备厂家的手册用的是协议地址 10，他们自己加了个 4 前缀写成 40011，但实际协议地址是 10 不是 10+1。这种"厂家自己发明编号"的情况在老设备上极其普遍。遇到数值整体错位，最有效的办法是找一个已知值的寄存器做锚点——比如让 PLC 往某个寄存器写死 1234，然后从 0 开始逐个地址读，读到 1234 的那个地址就是真地址。这个笨办法我用了很多次，比对着手册猜快得多。

4.2 32 位数据的高低字序问题

仪表类设备经常用两个连续的 16 位寄存器拼一个 32 位浮点数。这里有两层顺序要定：两个寄存器之间谁在前，以及每个寄存器内部两个字节谁在前。Modbus 协议规定寄存器内部是大端（高字节在前），这一层基本不用管；但两个寄存器之间的顺序，各家实现五花八门，常见的有四种组合：

如果顺序反了，读出来的浮点数会是天文数字（比如 1.2e+38）或者接近 0 的极小值，而且不会报任何错误——因为从协议角度看，两次读取都成功了。

处理方式有两条路。一是让 DASMBTCP 在 Item 层面做字交换，配置里一般有字序相关的选项，或者用带修饰符的 Item 名；二是最稳的：用两个 16 位整型 Item 分别读高低字，在 Intouch 脚本里自己拼。第二种方式多占两个标签，但字序完全可控，也不受驱动版本差异影响。点数不多的时候我一直用第二种。

在 Intouch 脚本里拼的时候要注意，Intouch 的脚本引擎对位运算支持有限，通常的做法是先做乘加：value = high * 65536 + low，得到无符号整数，再按设备手册的换算公式转成工程量。如果 high 是负的（因为整型标签有符号），要先加 65536 修正。

4.3 用脚本批量生成与校验点表

手工在 DAServer Manager 里一个个建 Item 是不可持续的。几百个点的时候人会疯，而且必然出错。实际项目里我都是先用 Excel 或者 CSV 维护点表，再想办法导入。

点表至少要有这几列：

tag_name,item,data_type,unit,scale,description TT101_PV,40001,float,degC,0.1,一号罐温度 PT102_PV,40003,float,MPa,0.01,一号罐压力 FT103_PV,40005,float,m3h,1,进料流量 P101_RUN,00001,bool,-,-,一号泵运行状态

第一列是 Intouch 标签名，第二列是 DASMBTCP 的 Item 名，第三列是数据类型，后面是工程量和描述。这份表就是整个项目的单一数据源，Intouch 标签、DAServer 条目、现场核对全都以它为准。

建完之后用脚本做一遍一致性校验，重点查三件事：地址有没有重叠（两个标签指向同一个寄存器，必然是复制粘贴出错）、地址有没有落在设备实际范围内、以及数据类型和地址跨度是否匹配（一个 32 位浮点必须占两个寄存器，下一个标签不能紧挨着它）。

# 点表自检：查重叠、查越界、查 32 位跨度冲突 import csv rows = [] with open("tags.csv", newline="", encoding="utf-8") as f: for r in csv.DictReader(f): rows.append(r) used = {} errors = [] for r in rows: base = int(r["item"]) - 40001 # 五位编号转协议地址 span = 2 if r["data_type"] == "float" else 1 for a in range(base, base + span): if a in used: errors.append(f"地址冲突: {r['tag_name']} 与 {used[a]} 都占 {a}") used[a] = r["tag_name"] if base + span > 1000: # 假设设备只有 1000 个保持寄存器 errors.append(f"地址越界: {r['tag_name']} -> {base + span}") print("\n".join(errors) if errors else "点表自检通过")

脚本里- 40001这一步把五位 Modicon 编号转成 0 基址协议地址，这是整个校验的基础。span根据数据类型决定占几个寄存器，浮点和双字都是 2。used字典记录每个协议地址被谁占了，用来发现重叠。最后那个 1000 是我习惯设的边界值，实际项目里换成设备手册给出的寄存器总数。

这份脚本每次改完点表都跑一遍，几秒钟的事，能挡掉后面几小时的现场排查。

5. 避坑与排查：连不上、读回零、数据跳变

5.1 现象：条目状态全是 Bad，日志里刷"连接超时"

原因通常在三处。最常见的是 Unit ID 填错——尤其是在网关后面挂多台串口设备的场景，网关的 IP 只有一个，从站号才是区分设备的依据，填 1 而设备实际是 3 的时候，网关会把请求转给不存在的从站，表现就是超时。其次是 TCP 端口被改过，或者工控机和设备不在同一网段但能 ping 通（中间有路由但没放行 502）。第三是从站限制了并发连接数，DAServer 建了连接但设备拒绝响应。

解决顺序是先用第 3.4 节的脚本直连设备，脚本能通说明设备和网络都没问题，问题一定在 DAServer 配置；脚本也不通，先去命令行确认端口，再去看设备侧有没有连接数限制或者白名单。这个二分法能省掉大量来回猜的时间。

5.2 现象：通讯正常但数值整体偏一位

这是最经典的一类问题，症状是温度显示成了压力的值，或者整片数据看着都"眼熟但对不上"。原因就是 4.1 节讲的基址错位——手册上的编号、设备内部的协议地址、DASMBTCP 的 Item 写法，三者之间差了一个 1。

解决办法不是猜，是打锚点。让 PLC 或者设备厂家往 40011 这个"手册地址"对应的寄存器里写一个独一无二的数（比如 12345），然后从 40001 开始每 1 个地址读一次，看哪一次读到 12345。读到的那个地址就是真实地址，和手册地址的差就是系统性的偏移量，全套点表统一加减这个值。我一般会把这个偏移量写在点表文件的第一行注释里，后面接手的人一眼能看到。

5.3 现象：32 位浮点读出来是 1.2e+38 或者 0.0000

字序反了。设备用 CDAB，DASMBTCP 按 ABCD 解释，两个 16 位拼出来的 32 位模式完全是另一个数。这类错误不会报异常，因为协议层读的是两个合法寄存器。

处理方式是先在 Item 配置里找字序选项，改成低字在前试试；如果这个版本不支持，就按 4.2 节的办法用两个整型标签自己拼。判断字序有一个快速验证法：把读到的两个 16 位原始值分别记下来，交换位置重新拼一次，看结果是不是落在一个合理的工程量范围内。合理了就是字序问题，不合理就是别的问题。

5.4 现象：一部分点位长期 Bad，其他点位正常

日志里如果出现 Illegal Data Address 或者异常码 02，基本可以确定是 Block Size 越界。DAServer 把地址连续的条目合并成一次块读，块的范围覆盖了设备没有实现的寄存器区，从站整块拒绝，于是同一块里的所有点一起坏，而且每次坏的都是同一批。

解决方式有两条：把 Block Size 调小到能整除设备实际寄存器段，或者把越界的那一段拆到单独的 Topic 里，给它设更小的块大小。第二种方式稍微麻烦，但在设备寄存器分布不连续的时候更干净。我倾向于第二种，因为块大小一旦为了迁就越界区域而调得很小，正常区域的通讯效率也跟着降下来了。

5.5 现象：设备重启后画面一直显示旧值，重启 DAServer 才恢复

这是自动降级机制造成的假象。设备掉线后 DAServer 把这个 Topic 降到低频扫描，设备恢复后要等一个降级周期才会重新按正常节奏轮询；如果降级周期设得很长，看起来就像是"卡死了"。另一种可能是设备侧的 TCP 连接进入了半开状态，DAServer 以为连接还在，实际上对端早就没了。

处理办法是把降级间隔调短到 10 到 30 秒，同时在 Intouch 里加一个心跳点——选一个设备会持续变化的寄存器（比如运行计时或者循环计数器），画面上做一个"超过 N 秒没变化就报警"的逻辑。这个心跳点比任何日志都直观，现场值班的人一眼就能看出通讯是不是真的活着。

6. 上线前的批量校验与长期稳定验证

点数一多，靠人眼在画面上扫是不现实的。我后来固定了一套上线前的自检流程，五分钟左右能跑完，能把大部分低级错误挡在投运之前。

第一步是点表静态校验，就是 4.3 节那段脚本，查重叠、越界、跨度冲突。第二步是通讯层校验，用 pymodbus 把所有 Item 按点表顺序读一遍，统计成功率，失败的地址单独列出来。第三步是对值校验，把关键工艺点位的读数和现场仪表显示对照，尤其是量程和单位。

# 上线前批量校验：按点表逐条读取并统计成功率 import csv from pymodbus.client import ModbusTcpClient client = ModbusTcpClient(host="192.168.10.21", port=502, timeout=2) client.connect() ok, bad = 0, [] with open("tags.csv", newline="", encoding="utf-8") as f: for r in csv.DictReader(f): if r["data_type"] == "bool": # 线圈单独走功能码 01 continue base = int(r["item"]) - 40001 count = 2 if r["data_type"] == "float" else 1 rr = client.read_holding_registers(address=base, count=count, slave=1) if rr.isError(): bad.append((r["tag_name"], base)) else: ok += 1 client.close() print(f"成功 {ok} 条，失败 {len(bad)} 条") for name, addr in bad: print(f" 失败: {name} @ 协议地址 {addr}")

这段脚本的价值在于它和 DAServer 走的是完全独立的路径。DAServer 那边配置错了，脚本照样能读到正确值；反过来脚本读不到，DAServer 那边再怎么调也没用。两边的结果一对比，问题定位基本不用猜。脚本里的slave=1和timeout=2要跟 Topic 里的 Unit ID 和响应超时保持一致，否则对比就没有意义。

长期运行阶段我盯三个指标。一是 DAServer 日志里的错误计数增长率，稳定运行时这个数字应该是平的，如果每天涨几十条，说明某个 Topic 的参数该调了。二是 Intouch 里心跳点的更新间隔，用脚本或者趋势记录它的变化周期，周期明显拉长就是请求队列在积压。三是工控机的 CPU 和网络流量，DAServer 本身很轻，但如果扫描周期设得过密、点数又多，CPU 占用会明显上去，这时候要回头砍扫描频率而不是加硬件。

还有一个容易被忘掉的动作：把 DAServer 的配置文件备份出来。这套工具的配置是存放在文件里的，重装系统或者换机器的时候，直接恢复配置比重新配一遍快得多，也避免了"照着旧画面猜参数"的尴尬。

最后说个我自己的教训。早年做的一个项目，点表是三个人分头建的，谁也没做统一校验，投运当天发现有七个标签指向了同一个寄存器，画面上一片数值跟着一个温度乱跳。查了两个小时才发现是复制粘贴时忘了改地址。从那以后我每次上点表之前都强制跑一遍重叠校验脚本，哪怕只有二十个点也跑。慢三十秒，省两小时。希望帮到你。

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