简介：在工业自动化项目中，Modbus TCP 是最常见的工业以太网协议之一，用于 PLC、仪表与上位机之间的数据交换。而 InTouch 组态软件要访问 Modbus TCP 设备，通常需要借助专用的 DAServer 驱动——DASMBTCP 1.1 就是这类驱动中的典型代表。它作为 InTouch 与设备之间的翻译层，负责地址映射、轮询调度和报文读写。理解它的工作原理，有利于快速解决地址错位、字节序异常、超时以及刷新缓慢等现场问题。借助 SMC 配置通道与设备组、合理设置轮询周期和超时参数，并通过日志诊断报文异常，是稳定通信的关键路径。无论是对接温控器、变频器还是其他 Modbus TCP 从站，掌握这套配置和排障方法，都能显著提升工程调试效率。
1. 用 DASMBTCP 之前，先搞清楚这是什么东西
如果你手头有一台只走 Modbus TCP 的 PLC 或仪表，而组态用的是 InTouch，那 DASMBTCP 1.1 就是你绕不开的一个驱动。它负责把 InTouch 的标记名变量翻译成 Modbus 报文，再通过以太网发到设备侧。很多第一次接触这个驱动的人，卡在最开始的三分钟：装完驱动、建了 Channel、加了 Device，但 InTouch 里变量全是坏值，日志报一堆 Timeout。这篇笔记就是围绕 DASMBTCP 1.1 这个驱动资源的安装、配置、排查和进阶验证顺序写的，适合正在做设备接入、准备把 Modbus TCP 数据拉到画面的工程师参考。它不解决协议选型问题，只解决你已经有 Modbus TCP 设备、并且决定用 InTouch 来监控时，那一条最直接的链路该怎么走通。
2. DASMBTCP 在通信链路里的角色与初始配置
很多新手把 DASMBTCP 当成一个“万能网关”，以为装上就能自动识别设备。实际上它只是 InTouch 与 Modbus TCP 设备之间的翻译层，不负责组态画面，也不负责历史存储。搞清楚它在这条链路里的位置，后面所有配置才能对得上号。
2.1 DASMBTCP 在 InTouch 通信链路里的位置
InTouch 访问数据的路径通常是：画面或脚本 → 访问名（Access Name）→ DASMBTCP 驱动 → 以太网 → Modbus TCP 从站设备。访问名是 InTouch 侧的入口，它绑定到 DASMBTCP 上的 Channel 和 Device。Channel 对应一个通信端口或一条物理链路，Device 对应具体的从站设备，每个从站设备有一个单元标识符（Unit ID，通常也叫 Slave ID）。
DASMBTCP 1.1 属于老的 DAServer 架构，它跑在系统管理控制台（SMC）环境下。相比后来 ArchestrA 集成的那套，1.1 的配置界面更直接，所有 Channel、Device、日志都在 SMC 里管理。它最大的优点是结构简单，配置项不复杂，适合单机或中小规模项目。缺点是它不提供像 ArchestrA 那样的集中式设备模板，所有参数都得在 SMC 里逐项手填。
从通信模型上讲，DASMBTCP 会主动轮询设备。它维护一个内部缓存区，InTouch 标记名通过访问名绑定到缓存区的某个数据项上。也就是说，InTouch 取数据时不直接向设备发请求，而是从 DASMBTCP 的缓存里读。这个设计的好处是多个画面标记可以共享同一次串行或网络请求，坏处是如果缓存刷新周期设置太长，你会感觉数据延迟明显。理解这一点，后面排查“数据不变”“刷新慢”这类问题时就能少走弯路。
2.2 安装与初始配置：Service Manager 里该怎么做
DASMBTCP 1.1 的安装包通常是一个自解压文件，里面包含驱动文件、SMC 的管理插件和帮助文档。安装时需要注意，必须先装好 InTouch 的主程序，再装驱动，否则 SMC 里不会出现 DASMBTCP 的管理节点。装完之后，打开 SMC，左侧会多出“DASMBTCP_1.1”这一大类，下面可能还没有任何服务器实例，需要手动新建。
我在模拟项目X里做过一次完整安装，步骤大概是：
- 以管理员身份运行安装包，安装路径不要带中文或空格，默认路径即可。
- 打开 SMC，找到“ArchestrA.System Management Console”下的“DASMBTCP”节点。
- 右键选择“添加服务器”（Add Server），输入一个逻辑服务器名，例如“MBTCP_SVR”。
- 添加后，服务器状态默认是“已停止”，右键点击并选择“启动服务器”。
- 启动后，右键服务器名 → “配置”（Configuration），会打开 Channel 和 Device 的配置树。
这里有一个容易翻车的点：SMC 的版本必须和 InTouch 版本兼容。比如某些老 InTouch 版本自带的 SMC 太老，无法识别 1.1 驱动，此时需要单独升级 SMC 的补丁包，否则添加服务器时会提示“未注册的组件”。我一般会在装完驱动后，去 SMC 的“关于”里确认 DASMBTCP 的版本号，再核对一下补丁级别。
配置界面的核心路径是：Configuration → 选中 DASMBTCP 服务器 → 右键 → “Add Channel” → 然后在 Channel 下添加 Device。Channel 是设备连接的通路，Device 是具体从站。每个 Channel 可以挂多个 Device，但同一时刻一个 Channel 只能使用一个网络接口和一组通信参数。如果你的设备分布在多个网段，就需要建多个 Channel。
2.3 设备组、Modbus 地址映射与标记名绑定
DASMBTCP 的地址映射规则遵循标准 Modbus 约定，但具体写法有点绕。它把 Modbus 区域分成四类：线圈（0x）、离散输入（1x）、输入寄存器（3x）、保持寄存器（4x）。在 DASMBTCP 的 Device 配置里，地址通常使用“区域前缀 + 偏移量”的写法，例如：
- 保持寄存器：4x 前缀，对应 Modbus 功能码 03（读）和 16（写多个寄存器）
- 输入寄存器：3x 前缀，对应功能码 04
- 线圈：0x 前缀，对应功能码 01 和 05/15
- 离散输入：1x 前缀，对应功能码 02
但要注意，很多 PLC 厂商的 Modbus 地址是 0 起始，而 DASMBTCP 的偏移量有时是 1 起始，这就容易造成 1 个地址的错位。我遇到过不止一次：设备文档里写“保持寄存器 40001 对应实际地址 0”，但 DASMBTCP 里如果直接填 40001，会读到地址 1 的内容，导致数据对不上。常见的做法是在地址映射表里统一注明“设备地址 = DASMBTCP 地址 - 1”或者相反，并在点表里做校验。
标记名绑定发生在 InTouch 侧。你需要在 InTouch 的访问名配置里新建一个访问名，协议选“DASMBTCP”，服务器名填 SMC 里新建的逻辑服务器名，访问名对应的应用名和主题可以空着，但“设备组”必须填对。在 DASMBTCP 中，每个 Device 默认有一个设备组（Device Group），名称通常是“_DEFAULT”或自定义的名字。InTouch 访问名里的“设备组”字段要填这个组名，否则驱动不知道你要访问哪个具体设备。
我一般会在设备组里定义两组：一组用于读取保持寄存器，一组用于写操作。因为 DASMBTCP 允许对同一个 Device 配置多个设备组，每个组可以设置不同的刷新周期和读写权限。这样做的好处是，高频读的数据可以放在刷新周期 100ms 的组里，低频或不重要的数据放在 1000ms 的组里，避免驱动把所有点都按最高频率轮询。
3. 实战：把 Modbus TCP 设备数据读到 InTouch 画面
这一章直接照做。我以一个实际场景为例：有一台温控器，Modbus TCP 从站，单元标识符为 1，保持寄存器起始地址为 0，里面存储当前温度、设定温度和运行状态。需要用 InTouch 画面实时显示这三个值，并能修改设定温度。
3.1 建立 Channel 与 Device 的关键参数
在 SMC 中，右键 DASMBTCP 服务器，选择“添加 Channel”。Channel 名称我习惯用设备类型加网段，例如“TEMP_101”。配置项并不多，但几个参数会影响通信质量：
- 端口号：默认 502，除非设备侧改过，否则保持默认。
- 超时时间（Timeout）：一般设置 3000ms，太短容易误报超时，太长会导致故障切换迟钝。
- 重试次数（Retry Count）：建议设 3 次，重试太多会拉长故障恢复时间。
- 轮询间隔（Poll Interval）：这个参数决定了驱动向设备发送请求的最小间隔，默认 100ms，具体看设备能承受的请求频率。
Channel 配置完后，右键 Channel，添加 Device。Device 配置里最关键的是“单元 ID”和“IP 地址”。单元 ID 要填设备的 Modbus 从站地址，IP 地址填设备网口地址。注意，DASMBTCP 1.1 不支持通过域名访问设备，只能填 IPv4 地址。
下面是一个典型配置示例，我把它整理成表格：
| 配置项 | 推荐值 | 说明 |
|---|---|---|
| Channel 名称 | TEMP_101 | 自定义，便于识别 |
| 设备 IP | 192.168.1.20 | 温控器网口地址 |
| 端口 | 502 | Modbus TCP 默认端口 |
| 单元 ID | 1 | 设备侧 Modbus 从站地址 |
| 超时时间 | 3000 ms | 超过此时间视为本次请求失败 |
| 重试次数 | 3 | 失败后重试次数 |
| 轮询间隔 | 200 ms | 两次请求之间的最小间隔 |
设置完这些，就可以用 SMC 的测试功能直接读数据了。右键 Device → “测试”，在弹出的窗口里能手动输入地址并读取，不必等到 InTouch 配置完。这一步强烈建议做，能提前把地址映射问题隔离在驱动层，而不是等 InTouch 画面上出现坏值再猜。
3.2 用 DASMBTCP 读保持寄存器：从地址到 InTouch 标记名
假设温控器的保持寄存器地址规划如下：0 号保存当前温度（浮点数，占两个寄存器），2 号保存设定温度（浮点数，占两个寄存器），4 号保存运行状态（整数，占一个寄存器）。在 DASMBTCP 里，需要把地址翻译成带区域前缀的写法。
DASMBTCP 1.1 对浮点数的处理让我吃了不少苦头。它默认按“寄存器顺序”解析 32 位数据，也就是先读低 16 位寄存器，再读高 16 位。但很多设备是高位在前（Big Endian），也有的是低位在前（Little Endian）。配置 Device 时如果找不到字节序设置，那大概率是在 Channel 或 Device 的“数据格式”里调整。我印象中 DASMBTCP 1.1 在 Device 配置里有一个“Word Order”选项，可以切换高字在前还是低字在前；后来版本又增加了“Byte Order”选项，专门处理 16 位内部字节交换。
我在那个温控器项目中，最终读取设定温度的 InTouch 标记名是这样绑定的：
访问名：MBTCP_ACC
服务器：MBTCP_SVR
设备组：_DEFAULT
标记名：TEMP_SET
项目名：即 DASMBTCP 地址，填4x2（表示保持寄存器，偏移地址为 2）
对，你没看错，DASMBTCP 的地址写法不是 40002，而是区域前缀加偏移量。偏移量 2 对应设备侧的寄存器地址 2，和民用的 40001 起始方式不同。这里就是最容易出偏差的地方，一定要和设备的 Modbus 地址表对照，弄清楚设备侧是 0 起始还是 1 起始。
再强调一次：如果设备手册写的是“保持寄存器 40001 对应温度”，那 DASMBTCP 的写法很可能是4x0而不是4x1，因为 40001 的偏移是 0。这个差异让我在另一个项目中排查了半天，最后发现是地址差一位，数据错位后读出来的温度完全对不上。
3.3 写操作与线圈/寄存器区别
写操作比读操作多一层风险。DASMBTCP 支持写保持寄存器、写线圈。在 InTouch 里，写操作通常用赋值脚本，例如：
TEMP_SET = 25.0;这时 InTouch 会根据访问名把TEMP_SET的当前值写入 DASMBTCP 对应的缓存项，驱动再通过 Modbus 功能码写回设备。但这里有个隐蔽的问题：如果你在 InTouch 里对只读的输入寄存器标记名赋值，驱动可能会悄悄忽略这次写，也可能直接报错。所以要在设备组里区分读写权限。
我建议对写操作单独建一个 Device Group。例如：
_READ组：刷新周期 200ms，只读_WRITE组：刷新周期 500ms，读写
写组的标记名地址仍指向同一个寄存器，但该组内的标记名允许写。InTouch 访问名里设备组就填对应的组名。千万别把所有标记都放在同一个组里，否则画面上的输入框如果绑定到只读组，用户输入值后看起来没反应，实际上数据根本写不进去。
另外，写线圈和写寄存器在功能码上完全不是一回事。线圈用的是 05（单线圈）或 15（多线圈），寄存器用的是 16（写多个寄存器）。DASMBTCP 1.1 会根据你配置的区域前缀自动选择功能码，比如地址0x10就会走线圈写，4x10就会走寄存器写。但前提是设备支持对应功能码，有些仪表只开放读功能码，写功能会被拒绝，需要到设备侧开通权限。
3.4 验证通信：DAS diagnostic 与日志
配置完成后，第一件事不是打开 InTouch，而是看 DASMBTCP 的诊断窗口。SMC 里右键服务器 → “Diagnostic”，可以看到通信状态、本次会话的读写计数、错误计数。如果“Read Count”在持续增长，说明驱动已经在正常轮询。如果“Error Count”增长，说明有请求失败，点开某项还能看到具体错误码。
日志是另一个调试利器。DASMBTCP 1.1 的日志分为通信日志和系统日志，可以在 SMC 里配置日志级别。我把通信日志级别调到“详细”（Detail），就能看到每一条报文的收发情况。日志里会显示类似“Tx: 00 01 00 00 00 06 01 03 00 00 00 02”的十六进制数据，这是 Modbus TCP 请求帧。通过对照功能码和寄存器地址，可以确认驱动发出的请求是否符合预期。
我在模拟项目X里验证时，就靠日志发现设备返回了异常码 02（非法数据地址），原来是寄存器地址越界。如果没有日志，单凭 InTouch 画面上显示坏值，根本不知道是地址问题还是通讯问题。所以先看日志，再调参数，效率会高得多。
4. 避坑指南：DASMBTCP 高频翻车点与排查方案
这一章记录我实际踩过、以及带新人时他们反复踩的坑。每条都按现象、原因、解决的顺序写，希望能帮你省掉几晚上。
4.1 现象：驱动总是连接不上设备，日志里报 “Timeout”
这是我见过最多的问题。现象是 SMC 里 Device 状态显示“Comm Fail”，日志里每条请求都是超时。
原因往往不是协议问题，而是最基础的网络不通。有人会在设备侧改了 IP，但 DASMBTCP 的 Device 配置里还留着旧地址；也有人把设备接在交换机上，但电脑网线插错了网口。
解决方法是，先在命令行用 ping 确认网络连通性，但要注意 Modbus TCP 端口 502 不一定能被 ping 通，所以更靠谱的是用端口测试工具，或者直接看 DASMBTCP 的诊断窗口。如果 ping 通但连接失败，检查 Windows 防火墙是否拦截了 502 端口。我遇到过一次很诡异的情况：杀毒软件后台拦截了 InTouch 进程访问网络，换一台电脑就好了，后来给杀毒软件添加信任目录才解决。另外，超时时间设太短也会导致看似“连不上”，尤其设备响应慢时，永远会在超时边缘徘徊。我一般先把超时设到 5000ms，通了之后再调低。
4.2 现象：读上来的数据全部为 0 或明显不对
设备通信正常，日志也没有错误，但 InTouch 显示的温度是 0，或者和一个固定值绑在一起不动。
原因多半是地址映射错误或字节序错误。地址差一位、区域前缀写错、浮点数高字低字反了，都会导致读出来的值“看起来正常但实际上是错位数据”。
我解决这类问题的顺序是：先用 SMC 的 Device 测试功能读一个已知值（比如设备铭牌上的型号寄存器），确认地址正确。如果读出来是 0，换一个地址试，或者用日志里的原始报文反推。字节序的问题更隐蔽，需要把读到的值拆成两个寄存器人工拼一次，看看哪种拼法合理。DASMBTCP 1.1 的“Word Order”选项如果弄反了，浮点数会变成天文数字，而不是 0。所以一旦出现异常大值，优先检查字节序。
4.3 现象：标记名变量变化慢，刷新周期达不到预期
有些点的实时性要求不高，但 DASMBTCP 的轮询周期设成了 1000ms，画面上看起来就是慢了半拍。还有更隐蔽的情况：设备组下挂了十几个标记，但驱动默认采用“顺序轮询”模式，一个请求只读一个寄存器，那每个寄存器的实际刷新周期等于“请求间隔乘以寄存器数量”。比如轮询间隔 200ms、10 个标记，最后一个标记要等 2 秒才刷一次。
解决方法是利用 Modbus 的批量读功能。DASMBTCP 支持一次读取连续寄存器，只要标记地址连续或通过数据块定义。把连续的地址放到同一个设备组，并让驱动使用“读取多个寄存器”功能，比如一次读 20 个寄存器，整个组的刷新间隔就能压缩到一次请求的时间。我在做变频器数据采集时，把压力、温度、转速共 16 个连续寄存器放到一个组里，刷新周期从 3 秒降到 300ms，效果立竿见影。
4.4 现象：更换设备 IP 后，原配置仍然连旧地址
项目调试后期，设备 IP 经常要变。很多人直接在 SMC 里改了 Device 的 IP，但过一会又发现驱动还在连旧地址。
原因可能是没有重启服务器或没有重新应用配置。DASMBTCP 1.1 的某些版本在运行时修改 IP 不会自动生效，需要先停止服务器，再修改，再启动。而且 SMC 的配置界面可能会缓存旧值，需要先右键服务器 →“刷新”再查看。
我一般换 IP 后，会执行一遍完整流程：停止服务器 → 修改 Device IP → 应用 → 启动服务器 → 观察诊断窗口。如果这样还连旧地址，那就要检查是否有多余的服务器实例，或者 SMC 里同一台机器上建了两个相同名称的 Device，新的配置可能加到了另一个设备上。最笨但也最有效的方法，就是把服务器配置导出，搜索所有旧 IP 字符串，全部替换后再导入。
4.5 现象：InTouch 在某些系统上启动时访问名报错
换了电脑或重装系统后，InTouch 打开历史画面，所有标记名都显示不可用，访问名配置里测试连接失败。
原因通常是 DASMBTCP 服务没有设为开机自启动，或者访问名里填的服务器名与 SMC 中实际服务器名不一致。1.1 版驱动的服务名在 Windows 服务里如果启动类型是“手动”，会在 InTouch 启动时来不及加载。
解决方法是，在服务管理里找到 DASMBTCP 对应的 Windows 服务，把启动类型改为“自动”。然后确认 InTouch 访问名里填写的“服务器名”完全等于 SMC 中新建的逻辑服务器名，一个字符都不能差。还有一个小坑：访问名里的“应用程序名”和“主题名”不能留空，很多老版本要求至少填一个占位符，比如 “App”、 “T1”，具体看驱动的默认要求。
5. 进阶：用 DASMBTCP 自带的日志过滤功能快速定位通信瓶颈
前面提到用日志验证通信，但 DASMBTCP 1.1 的日志如果全开详细级别，会产生海量数据，刷屏速度快到看不清。我后来摸索出一个技巧：先在诊断窗口里确认 Channel 和 Device 的编号，然后去日志配置里仅记录该 Channel 的报文，或者把日志输出级别调到“错误”级别，只记录失败请求。这样既能保留下现场证据，又不会被正常报文淹没。
更具体的做法，是在 SMC 的日志属性里，把“日志文件大小上限”设成 5MB，并勾选“自动覆盖”。否则日志文件会撑爆硬盘，导致驱动性能下降。我见过一次，某个现场日志文件涨到好几 GB，InTouch 画面操作都开始卡顿，删掉旧日志后立刻恢复。所以分久必合，合久必分，日志这东西必须定期清理或不间断轮转。
如果你需要分析报文中的功能码，可以用十六进制搜索。打开日志文件，找到一条发送帧，重点看第 7 个字节（从 0 开始数是第 7 位），它代表功能码。例如03是读保持寄存器，06是写单个寄存器，10是写多个寄存器。返回帧中如果功能码最高位被置 1（比如83），说明设备返回了异常码，紧接着的字节就是异常码。通过异常码能快速判断是地址越界（02）、不支持功能（01）还是从站忙（06）。
从那以后，我每次配置完 DASMBTCP 1.1，都会强制走一遍“SMC 测试 → 访问名绑定 → 日志过滤 → 异常码对照”这条链路，至少能省掉 80% 的现场调试时间。这套流程也适用于其他 DAServer 驱动，比如 DASABCIP 和 DASS7，只是地址写法和功能码不同。希望帮到你。
本文还有配套的精品资源，点击获取
