简介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一条网络通道设备 IP、TCP 端口默认 502、响应超时、重试次数一条电话线Topic通道上的一个从站单元号 Unit ID、扫描周期、块大小 Block Size线路上的一台分机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这条路上每一段都是活的。铺完几百个点再回头查成本会高一个量级。最小闭环分四步走确认服务在跑。装完之后DASMBTCP会注册成一个 Windows 服务先在服务管理器里看它的状态再打开 DAServer Manager 确认左侧树里能看到这个服务器并且处于激活状态。确认网络通。在工控机上对设备 IP 做一次 ping再单独测 502 端口是否可达。这一步能把配置错和网络不通彻底分开。建一个 Port 加一个 Topic只挂一个已知值的寄存器在 DAServer Manager 自带的条目测试面板里读一次看返回值是不是预期的。在 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 叫MB1Item 是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(host192.168.10.21, port502, timeout3) client.connect() # 读 0 起始的 10 个保持寄存器slave 对应设备从站号 rr client.read_holding_registers(address0, count10, slave1) if rr.isError(): print(读取失败异常码:, rr) else: print(原始寄存器:, rr.registers) client.close()这段脚本的关键在三个参数。address0用的是协议层地址也就是 0 基址对应 Modicon 编号的 40001这一点在第 4 章会详细展开。count10是一次读几个别超过从站实际拥有的寄存器数量。slave1是从站号必须和 Topic 里的 Unit ID 一致不一致的话在网关上会读到别的设备或者直接异常。跑通之后再回到 Intouch 运行态对照同一个寄存器看数值。如果脚本读到 1234 而画面显示 -25536那问题在标签类型如果脚本读到 1234 而画面显示 0问题在 Access Name 或者 Topic 名如果脚本自己也读不到那问题在设备侧跟 Intouch 无关。这三条分支能把排错范围一次砍掉三分之二。4. 点表映射把 4xxxx 寄存器翻译成 Intouch 标签4.1 地址基址、位号与数据类型的三重对齐Modbus 的地址有两套编号体系这是新手最容易栽跟头的地方而且栽了之后现象很迷惑通讯一切正常日志干干净净就是数值全错或者整体错一位。第一套是协议地址从 0 开始功能码报文里带的就是这个数。第二套是 Modicon 编号从 1 开始并且用首位数字表示区号区号名称功能码编号范围协议地址0线圈01 / 0500001–099990 起1输入状态0210001–199990 起3输入寄存器0430001–399990 起4保持寄存器03 / 06 / 1640001–499990 起也就是说Modicon 编号 40001 对应的协议地址是 040002 对应 1依此类推。DASMBTCP 的 Item 名支持多种写法常见的是五位编号40001和六位编号400001以及带前缀的写法。不同版本对写法的支持略有差异最稳的办法是打开 DAServer Manager 的帮助文档看本版本的 Item 命名规则然后用测试面板验一次。我踩过的坑是这样的设备手册上写温度寄存器地址 40011现场照着填 40011读回来的是隔壁那个压力值。原因是设备厂家的手册用的是协议地址 10他们自己加了个 4 前缀写成 40011但实际协议地址是 10 不是 101。这种厂家自己发明编号的情况在老设备上极其普遍。遇到数值整体错位最有效的办法是找一个已知值的寄存器做锚点——比如让 PLC 往某个寄存器写死 1234然后从 0 开始逐个地址读读到 1234 的那个地址就是真地址。这个笨办法我用了很多次比对着手册猜快得多。4.2 32 位数据的高低字序问题仪表类设备经常用两个连续的 16 位寄存器拼一个 32 位浮点数。这里有两层顺序要定两个寄存器之间谁在前以及每个寄存器内部两个字节谁在前。Modbus 协议规定寄存器内部是大端高字节在前这一层基本不用管但两个寄存器之间的顺序各家实现五花八门常见的有四种组合组合寄存器顺序字节顺序典型设备ABCD高字在前大端多数 PLCCDAB低字在前大端部分电表、温控器BADC高字在前小端较少见DCBA低字在前小端少见如果顺序反了读出来的浮点数会是天文数字比如 1.2e38或者接近 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, encodingutf-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.2e38 或者 0.0000字序反了。设备用 CDABDASMBTCP 按 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(host192.168.10.21, port502, timeout2) client.connect() ok, bad 0, [] with open(tags.csv, newline, encodingutf-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(addressbase, countcount, slave1) 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 那边再怎么调也没用。两边的结果一对比问题定位基本不用猜。脚本里的slave1和timeout2要跟 Topic 里的 Unit ID 和响应超时保持一致否则对比就没有意义。长期运行阶段我盯三个指标。一是 DAServer 日志里的错误计数增长率稳定运行时这个数字应该是平的如果每天涨几十条说明某个 Topic 的参数该调了。二是 Intouch 里心跳点的更新间隔用脚本或者趋势记录它的变化周期周期明显拉长就是请求队列在积压。三是工控机的 CPU 和网络流量DAServer 本身很轻但如果扫描周期设得过密、点数又多CPU 占用会明显上去这时候要回头砍扫描频率而不是加硬件。还有一个容易被忘掉的动作把 DAServer 的配置文件备份出来。这套工具的配置是存放在文件里的重装系统或者换机器的时候直接恢复配置比重新配一遍快得多也避免了照着旧画面猜参数的尴尬。最后说个我自己的教训。早年做的一个项目点表是三个人分头建的谁也没做统一校验投运当天发现有七个标签指向了同一个寄存器画面上一片数值跟着一个温度乱跳。查了两个小时才发现是复制粘贴时忘了改地址。从那以后我每次上点表之前都强制跑一遍重叠校验脚本哪怕只有二十个点也跑。慢三十秒省两小时。希望帮到你。本文还有配套的精品资源点击获取
