简介：这份 Intouch Modbus 驱动 DASMBTCP1.1 资源包面向工业自动化 HMI 组态工程师、PLC 通讯调试人员及需要为 Wonderware Intouch 接入 Modbus TCP 设备的学习者，重点解决 Intouch 与支持 Modbus TCP 的 PLC、仪表等设备之间的数据采集与控制通讯问题。压缩包共 129 个文件，约 10.9MB，以 dll 动态库和 exe 可执行程序为主体，辅以 chm、hlp、pdf 等帮助文档与手册，并包含配置文件、安装脚本及少量网页说明，便于完成驱动安装、参数配置与运行维护。已有 2639 人学习下载，说明其在 Intouch 通讯调试场景中具有一定参考价值。内容围绕 DASMBTCP 驱动展开，覆盖数据源创建、设备地址与端口设置、寄存器与变量映射、周期读写及断线重连等主题，并借助随包文档辅助排查安装与通讯故障，适合作为现场调试和自学查阅的资料。
1. 凌晨两点，画面全变成星号：DASMBTCP 1.1 是干什么的
凌晨两点，一条跑了八年的老线停在上位机画面上：所有数字变成灰白的星号，操作工只能靠对讲机问现场仪表读数。PLC 侧的以太网口灯正常闪，用调试工具直接读寄存器也一切正常——问题出在上位机和 PLC 中间那一层，Intouch DASMBTCP 这条链路断了。DASMBTCP 1.1 就是这套老架构里的 Modbus TCP 驱动：它作为独立的 DA Server 进程跑在后台，把 Modbus 的四个寄存器区翻译成 InTouch 认识的 Item，画面上的 Access Name 只要指向它，就能读到 502 端口背后的数据。这套包适合还在维护早期 InTouch 项目、现场一堆 Modbus TCP 从站、又不想为了几个点整体重构的人——它版本老、参数少、链路短，但摸清几个关键开关，就能把一条线救回来。
2. 驱动站在哪一层：从 InTouch 的 Access Name 到 502 端口
2.1 三层链路：Tag、Topic、Unit ID 各管一段
InTouch 本身不会说 Modbus。它只会通过 SuiteLink（早期还有 DDE 那条老通道）去找一个叫 DA Server 的进程要数据，至于这个进程背后是串口、以太网还是别的什么协议，画面这边完全不管。所以一个 Tag 从画面到寄存器，中间要过三道门：Access Name 决定找哪台机器上的哪个 DA Server、哪个 Topic；Topic 决定进哪一个从站；Item 决定读哪个寄存器。
这三道门对应到配置界面上就是三个字符串。Node Name 填 DA Server 所在的机器名，本机也可以留空或者填本机名，但不要填127.0.0.1——某些版本对回环地址的处理不一致，我见过填回环之后连接能建立但永远读不到值的现场。Application Name 填 DA Server 的注册名，1.1 这个分支安装完之后，SMC 树里显示的名字通常带版本后缀（形如ArchestrA.DASMBTCP.1），而 Access Name 里填简名DASMBTCP也认，因为安装时同时注册了短名。血泪经验是：这两个名字别凭记忆敲，从 SMC 里那个节点的属性页复制出来，少一个点都连不上。Topic Name 对应你在 SMC 里建的 slave 节点，名字是自己起的，起名时别用空格和中文。
协议那一栏选 SuiteLink。选 DDE 也能通，但 DDE 是消息机制，点数一多、扫描一快就开始堵，几百个点跑起来画面刷新肉眼可见地掉帧。这不是玄学，是那套老机制的固有代价。真正决定数据能不能上来的，其实是排在后面的 Unit ID 和寄存器编号，Access Name 只是敲门砖。
2.2 1.1 这个版本号意味着什么：选型与替代方案
看到版本号是 1.1，第一反应应该是"这套东西有年头了"。它最直接的后果是位数限制：这个分支是 32 位时代的产物，安装程序在 64 位系统上要么直接拒绝，要么装完服务起不来。所以拿到这份包，先看目标机器是多少位，别急着双击。
| 方案 | 适用场景 | 需要付的代价 |
|---|---|---|
| DASMBTCP 1.1 | 老 InTouch 项目、32 位系统、点位数几百以内 | 只能跑在 32 位环境，新系统装不上 |
| 同系列 2.x / 3.x | 新机器、需要更细的诊断项和更多并发连接 | Topic 配置要重做一遍，授权类型可能不同 |
| 现场已有的 OPC Server 加一层网关转换 | 已经有现成 OPC DA 数据源，或者要接非 Modbus 设备 | 多一个进程，多一个故障点，排查链变长 |
| 干脆换掉上位机通信层 | 项目本来就要重构 | 画面和脚本要重新对点，工作量最大 |
如果只是维护，1.1 是最省事的：装一个包，配一个 Topic，画面不动。如果要新搭一套，直接上高版本，别为了省一次配置把自己锁死在 32 位机器上。另外提一句授权：这类驱动通常按"设备连接数"授权，一个 slave 算一个设备，建了十个 Topic 就要有十个设备的额度，额度不够时节点能建、能保存，但激活那一步会失败，现场表现就是 Topic 一直灰着，很容易误判成网络问题。
2.3 安装顺序：先有 DA Server 基础设施，再谈驱动
这类驱动的安装包不是独立程序，它只是往已有的 DA Server 框架里注册一个"设备集成对象"。所以顺序错了，SMC 树里根本看不到节点。我一般按这个顺序走：
- 停掉 InTouch 运行态，关掉 SMC 控制台，避免文件占用。
- 确认 SuiteLink 协议栈在（装 InTouch 时勾选的那一项），没有的话先补。
- 装 DA Server 基础设施，这一步会注册后台服务和 SMC 里的管理节点。
- 再装 DASMBTCP 1.1，安装程序负责把驱动注册进去。
- 打开 SMC，展开 DAServer Manager，确认本地节点下面出现了这个驱动的名字。
- 装授权，然后重启一次机器。
第 6 步的重启不是形式主义。老安装包里有几处注册表写入要等服务重新加载才生效，我吃过一次亏：装完不重启，SMC 里节点在，Activate 之后状态一直停在 Starting，日志里只有一行"等待服务响应"，折腾了半小时，重启完三秒钟就好了。
提示：装之前把机器名、IP、从站清单记在一张纸上。后面配 Topic 时逐个核对，比事后靠
netstat反推快得多。
3. 从装完到点亮：SMC 里建 Port、Slave、Topic 的完整顺序
3.1 装完先做的三个连通性动作
配置之前先证明物理链路没问题。这一步省掉，后面所有异常都会指向错误的方向。
# 1) 从站在不在线：把 192.168.10.20 换成现场从站 IP ping -n 4 192.168.10.20 # 2) 502 端口开没开。没有 telnet 客户端时用 PowerShell，输出里 TcpTestSucceeded 要是 True powershell -Command "Test-NetConnection 192.168.10.20 -Port 502" # 3) 本机有没有跟 502 建立会话，以及是哪个进程占着 netstat -ano | findstr :502第一条只是证明 IP 层通，不代表 Modbus 服务在跑——很多网关的 ICMP 是常开的。第二条才是关键，端口不通就说明从站侧没开 Modbus TCP 服务，或者中间有防火墙策略。第三条在配置完成后再跑一次，正常情况下应该能看到本机 IP 跟从站502之间处于 ESTABLISHED，如果只有 SYN_SENT，说明握手被拒或者对端根本没监听；如果一个连接都没有，那多半是 DAServer 没激活，问题在软件层不在网络层。
顺便看一眼后台服务：
# 名字里通常带 Service Manager 或 Bootstrap 字样的那两个服务，必须是 RUNNING sc query state= all | findstr /i "archestra"服务是 STOPPED 的话，SMC 里的节点会显示成不可用，这时候点多少次 Activate 都没用。
3.2 建 ModbusTCPPort：IP、端口、超时四个字段怎么填
在 SMC 的驱动节点下展开 Configuration，先建 Port。Port 是"一台从站设备"的抽象，不是网卡。名字自己起，建议用PORT_从站编号这种能一眼对上的格式，别用New_Port_1，三个月后没人记得它是谁。
| 字段 | 建议值 | 说明 |
|---|---|---|
| Port Name | PORT_LINE1 | 本机内唯一，InTouch 不直接引用，但日志里会打印 |
| IP Address | 从站实际 IP | 不要填回环地址，也不要填网关的虚地址 |
| Port Number | 502 | 少数网关改成 5020、8502，按手册改 |
| Response Timeout | 1000~3000 ms | 设 200 ms 在网络抖动时会批量掉 Bad |
| Retry Count | 2~3 | 设太高会把一次失败拖成全组卡顿 |
超时这个参数值得单独说一句。它指的不是"通讯周期"，而是"发出去一个请求等多久算失败"。设得太短，网络稍微拥塞就判定超时，画面上数值闪烁；设得太长，一个掉线的从站会把整个组拖住，因为请求是排队发的。我一般先设 2000 ms 跑一天，看日志里有没有超时记录，再往下压。
同一个 IP 加端口的组合，一台机器上只能建一个 Port。重复建会导致连接数翻倍，某些从站的连接数上限只有 4~8 个，翻倍直接把后面的设备挤掉，现场表现是"有的设备好、有的设备一直连不上"，非常迷惑。
3.3 建 Slave 与 Device Group：Unit ID 和扫描周期
Port 建好之后在它下面建 slave，再在 slave 下面建 Device Group，最后往 group 里加 item。这四层结构对应：物理设备 → 协议从站 → 扫描策略 → 数据点。很多人把 item 直接堆在一个 group 里，几百个点全按 100 ms 扫，结果 CPU 上去了、画面还是卡。
| 参数 | 取值 | 怎么定 |
|---|---|---|
| Unit ID | 1~255，直连 PLC 多为 1 | 网关后面挂多个串口从站时，这个字段是路由键 |
| Update Interval | 200~1000 ms | 快变点单独建组，慢变点合并 |
| Group 数量 | 2~4 个 | 每组独立排队，组太多等于并发太多 |
| Item 数量 | 单组建议 ≤ 200 | 超过 125 个寄存器会自动拆包，周期随之变长 |
Unit ID 是最容易填错的一项。直连的 PLC 把它当从站号，随便填个 1 通常就行；但如果中间是串口转以太网的网关，网关背后的每个串口设备有自己的站号，这个字段必须跟站号对上，填错的表现是"连接正常、读出来全是 0"或者 Quality 直接 Bad，而netstat里连接明明好好的。
分组的原则是按变化速度。电流、压力这类快变量放 200 ms 的组；累计量、报警字、参数设定值放 1000 ms 的组。这么拆完，网络上的请求数能少一大半，扫描周期的余量也就出来了。
3.4 InTouch 侧 Access Name 与点名的对应表
配置完激活，回到 InTouch 建 Access Name：
| Access Name 字段 | 填什么 | 备注 |
|---|---|---|
| Name | ACC_LINE1 | 自己起，脚本里引用这个 |
| Node Name | DA Server 所在机器名 | 本机可留空，别填回环 |
| Application Name | DASMBTCP | 以 SMC 属性页显示的为准 |
| Topic Name | SMC 里的 slave 名 | 大小写敏感，别加空格 |
| Protocol | SuiteLink | 别选 DDE |
| Advise | 勾选 | 不勾就变成轮询读，效率差一截 |
Item 那一栏填寄存器编号，具体写法在下一章展开。建完 Tag 之后最快的验证方式不是看画面，是打开 SMC 的 Diagnostics，切到对应 slave 的 Item 列表，看 Quality 那一列。那一列是Good才说明数据真的上来了；画面显示***只说明读失败，不告诉你失败在哪一层。
注意：改完 Access Name 或者 Topic 名之后，InTouch 需要重新激活窗口才会重新连接，光按保存看不出变化。
4. 地址与数据类型：400001 之外还有三处容易翻车的地方
4.1 四个寄存器区与六位编号的偏移问题
Modbus 有四个独立的地址空间，驱动用编号前缀区分。这份驱动的 item 写法是六位编号：
| 区 | 前缀 | 六位写法 | 读 | 写 |
|---|---|---|---|---|
| 线圈 Coil | 0 | 000001~065536 | 可 | 可 |
| 输入状态 Input Status | 1 | 100001~165536 | 可 | 不可 |
| 输入寄存器 Input Register | 3 | 300001~365536 | 可 | 不可 |
| 保持寄存器 Holding Register | 4 | 400001~465536 | 可 | 可 |
坑在于手册和驱动用的不是同一套写法。设备手册上写40001，是五位；驱动要400001，是六位。两者指的是同一个物理寄存器，补两个零就对了。但还有更绕的一层：有些手册上的4xxxx已经是"协议地址加一"之后的结果，也就是它本身已经做过一次偏移，这时候直接补零反而错一位，得减 1 才对。
判断方法很土但很有效：找一个你确定值的寄存器，比如设备的心跳计数或者固定版本的固件版本号，用400001和400002各读一次，看哪个对得上。对不上的那一位，就是偏移量。
4.2 32 位整型与浮点：四种字序，用一个脚本试出来
这是现场最高频的"数值不对"来源。一个 32 位浮点占两个 16 位寄存器，谁在前谁在后，协议本身没规定，各家设备自己定。四种排法都存在：高字在前、低字在前、字内字节再对调，组合起来就是 ABCD、CDAB、BADC、DCBA。
别猜。拿两个原始寄存器值，用脚本把四种排法都算一遍，哪个等于真值就配哪个：
import struct # 从两个保持寄存器读回来的原始值（示例值，实际用时换成现场读到的数） reg1 = 0x42F6 reg2 = 0xE979 def decode(name, a, b, swap_bytes=False): if swap_bytes: # 字内部高低字节对调 a = ((a & 0xFF) << 8) | (a >> 8) b = ((b & 0xFF) << 8) | (b >> 8) raw = struct.pack('>HH', a, b) # 按"字在前"拼成 4 字节 val = struct.unpack('>f', raw)[0] print(f'{name:6s} {a:04X} {b:04X} -> {val:.6f}') decode('ABCD', reg1, reg2) # 高字在前，字内大端 decode('CDAB', reg2, reg1) # 两个字对调 decode('BADC', reg1, reg2, True) # 字内字节对调 decode('DCBA', reg2, reg1, True) # 全反跑出来会得到四个完全不同的数，其中只有一个接近你能用万用表或者设备面板核对上的真值，比如 123.456。记住那个名字，回到 Topic 的属性里改字序选项；有些版本的选项叫 Word Swap / Byte Swap，两个开关组合起来就是那四种排法。改完不用重启整个服务，重新激活 slave 就生效。
如果驱动版本不带字序选项，那就退回脚本拼接。整数的情况好办，InTouch 里两个 I/O 整型变量拼一下就行：
' InTouch QuickScript：把高字、低字拼成 32 位有符号整数 ' TagHi / TagLo 是两个 I/O 整型变量，Result 是内存整型 IF TagHi >= 32768 THEN Result = (TagHi - 65536) * 65536 + TagLo; ELSE Result = TagHi * 65536 + TagLo; ENDIF;逻辑不复杂：无符号高字超过 32767 时，说明这个 32 位数的符号位是 1，要先把高字减掉 65536 变成有符号，再乘 65536 加上低字。浮点就麻烦得多，得在脚本里按 IEEE754 手动拆位，一般不建议这么干，宁可换一个支持字序配置的版本。
提示：字序配错的时候数值不会变成 0，而是变成一个看起来"像是合理量程"的数，比如温度显示 0.0034 或者 812.7。越是这种似是而非的值，越容易被当成传感器漂移。
4.3 位、字符串与批量读的边界
位读取。有些同事喜欢给每一个报警位单独建一个 item，一个 16 位字拆成 16 个点。这么做能通，但点位数翻十几倍，扫描周期跟着涨。常见做法是读整字，在脚本里用取模和整除取位，一个 item 顶十六个。
字符串读取。Modbus 没有字符串类型，就是把 ASCII 码塞进保持寄存器，每个寄存器装两个字符，高字节在前。两个坑：一是长度是奇数时，最后一个寄存器的低字节是填充的 0，直接显示会带出乱码尾巴；二是字符串跨寄存器，起始地址必须是偶数字符边界，从奇数字符开始读会整体错位一个字节，表现出来就是"中文变乱码、英文首字母丢失"。
批量读取的边界在 125 个寄存器。一次请求最多读这么多，超了驱动会自己拆成多次。拆包本身不报错，但周期会翻倍，而且如果点的地址不连续（比如 400001 和 401001 混在一个组里），拆出来的请求数比你想的多得多。整理点表的时候，把地址连续的点放在同一个 group，这一条能把扫描周期压下来一半。
5. 排查与避坑：Topic 灰掉、Quality 变 Bad 的五个现场
5.1 通信层三条
现象一：SMC 里 slave 一直是未激活状态，右键激活没反应，或者状态卡在 Starting。
原因：后台服务没起来，或者授权额度不够。老安装包在没装授权的情况下允许你把节点建完、保存，但激活时直接失败，日志里只有一行很含糊的等待信息。
解决：先sc query看服务，STOPPED 就手动起一次，起不来去看系统事件日志里的服务启动错误；服务正常的话查授权，看设备数是否已经用满。额度不够时最省事的做法是把不用的旧 slave 删掉，而不是加授权。
现象二：ping通，Test-NetConnection显示TcpTestSucceeded: False。
原因：从站侧没开 Modbus TCP 服务，或者端口不是 502；也可能是本机和从站之间隔了防火墙，ICMP 放行了但 TCP 没放。
解决：先换成从站手册里写的端口再试一次；还不行就在从站侧用调试工具直连确认服务在跑。这一步不要在上位机侧反复改配置，改不出结果。
现象三：白天正常，夜里批量掉线，早上又自己好了。
原因：网络里有别的设备在扫端口，或者交换机上做了端口安全；也有可能是从站的连接数被占满——上位机重启后旧连接没释放，从站那边还挂着，新连接被拒。
解决：在从站侧看当前连接列表，清掉僵死会话；上位机侧把 DAServer 的连接数固定住，别让它反复重建。这种情况用抓包看最直接，能看到一堆 SYN 重传。
5.2 数据层两条
现象四：连接状态正常，Quality 全是 Good，但所有数值都是 0。
原因：Unit ID 填错，或者寄存器区选错。把输入寄存器3xxxxx写成保持寄存器4xxxxx，读到的就是一片空；网关后面挂多个串口从站时，Unit ID 不对，网关会返回全零而不是报错。
解决：先核对 Unit ID 和设备站号，再核对寄存器区。用一个确定有值的地址（比如设备的运行时间计数）做单点测试，比一次读一片快。
现象五：单个数值对得上，一批数值全乱，或者数字在小数点位置上飘。
原因：字序或字节序配错，或者把 32 位浮点当 16 位整型读了。还有一种少见情况是两个 Point 的地址重叠了——一个读400001长度 2，另一个从400002开始，后者读到的是前者的低字。
解决：用 4.2 那个脚本先把字序试出来；再检查点表里有没有地址重叠。重叠不会报错，只会让两个值互相串。
5.3 日志与诊断入口：先看哪里
SMC 里每个 slave 都有 Diagnostics 页，分 Message 和 Item 两块。Message 里记的是连接、激活、超时这类事件，Item 里是逐点的 Quality 和最后更新时间。排障顺序建议反过来：先看 Item 的 Quality，确定是全部坏还是个别坏；全部坏往通信层查，个别坏往地址和类型查。
文件日志一般在安装目录下的 Logs 子目录，按日期分文件。日志级别默认只记错误，要抓细节得把级别调到调试，但别长期开着——调试级别一天能写出几百兆，磁盘满了会连累整个上位机。抓完现场就调回去，这是我接手别人机器时经常要收拾的烂摊子。
注意：日志里出现的是端口名和 slave 名，不是你起的那个好记的中文备注。所以前面说名字要起得有规律，排障的时候能省很多对表时间。
6. 上线前的冷启动验证：断一次电、拔一次网线、跑满 200 个点
配置通、画面有数，只说明"热态能用"。真正让这条线活下来的，是冷启动之后还能自己恢复。我上线前固定做三件事，缺一件都不敢交付。
第一件，整机断电重启。关掉上位机，从站也断一次电，然后先给从站上电，等它就绪再给上位机上电。起来之后不看画面，直接开 SMC 看 slave 的激活状态和 Item 的 Quality。有些现场热态配置完一切正常，冷启动之后驱动服务比网络起得早，握手失败一次就再也不重试，画面永远停在星号。遇到这种情况，把服务的启动类型改成自动（延迟启动），或者加一个开机后延迟激活的动作。
第二件，拔网线。断 30 秒再插回去，看数值多久恢复、恢复之后值对不对。这一条能暴露两个问题：一是驱动的重连策略是不是死等，二是断线期间那些累计量有没有被写成 0。第二种最坑，画面上看不出异常，等对账的时候才发现数据被清零过。
第三件，满负荷跑。把所有点都建上，按最终的分组和扫描周期跑满两小时，同时开着任务管理器看 CPU 和网络。下面这张表是我一般会对照的验收线：
| 检查项 | 合格线 | 不合格时的动作 |
|---|---|---|
| 冷启动后自动激活 | 5 分钟内全部 Good | 改服务启动顺序，加延迟激活 |
| 断网 30 秒恢复 | 60 秒内回到 Good | 缩短超时、减少重试次数 |
| 200 点满负荷 CPU | 单核不超过 30% | 拆组，降低快变组的点数 |
| 单次扫描周期 | 与设定值偏差 < 20% | 合并连续地址，减少拆包 |
| 连续运行 8 小时 | 无批量掉 Bad | 查交换机端口安全和连接数上限 |
这三件事做完，才算真正把这套 1.1 的驱动摸清了。我最早的教训是只做了第一件，结果现场投运第三天，一条产线的交换机重启，画面再也回不来，半夜被叫过去重配 Topic——从那以后每次交付前，我都会把断电、拔线、满负荷这三步强制走一遍，哪怕甲方催得再急。希望帮到你。
本文还有配套的精品资源，点击获取
