DASSIDirect 2.0 驱动详解：InTouch 连接 OPC DA 服务器配置与排障

简介DASSIDirect 2.0 是 Wonderware Intouch 与西门子 S7-300/400 PLC 通信的关键 DAServer 驱动适用于工控组态项目中的设备连接与数据采集场景主要面向自动化工程师和上位机组态维护人员。压缩包共 140 个文件总大小约 23.72MB内含 68 个 DLL 动态库、25 个 EXE 安装与辅助程序、13 个 CHM 帮助文档以及 PDF、INI、HTML、MSI 等类型覆盖安装运行、文档说明与许可配置等用途。目前已有 1147 人学习下载。驱动包内提供了完整的安装向导、前置依赖组件、常用配置文件及帮助手册可帮助规避因缺少组件导致的连接失败其中包含 DASSIDirect 主程序、DAServer 管理器与 LogViewer 日志工具等关键模块便于用户在 Intouch 中快速配置 S7 通道并借助日志排查通信异常。对需要实现 Intouch 与西门子 PLC 稳定通信的工程师而言这是可直接部署的实用驱动资源。 前阵子整理移动硬盘翻出一份 DASSIDirect2.0 Intouch连接驱动.zip。这个包在工控老项目里太常见了但每次都有同行问这个驱动到底是干嘛的怎么装装完怎么配才能让 InTouch 接上外部 OPC 服务器今天我就把这套东西从头到尾捋一遍从驱动定位、安装部署到 SMC 配置、联调排障把能踩的坑尽量先给你指出来。DASSIDirect 2.0 是 Wonderware现 AVEVADAServer 驱动家族里的一个成员核心作用是把 InTouch 上位机软件和外部 OPC DA 数据源连接起来。适合正在维护老项目的工程师看也适合刚接手 InTouch 系统、被一堆 DAServer 术语搞晕的新人。读完之后你至少能独立装好驱动在 System Management Console 里建好通道让 InTouch 画面上的点真正活起来。1. 先搞清楚 DASSIDirect 2.0 在 InTouch 体系里的位置1.1 DAServer 架构与驱动选型InTouch 自身不是一个通信中间件它要通过 IO Server 去访问设备数据。早期是各个独立的 I/O Server后来 Wonderware 统一到了 DAServer 架构。DAS 全称 Distributed Application ServerDASSIDirect 就是这套架构里的一个服务端角色名字里的 Direct 表示它直接走 OPC DA 协议去对接上游数据源。很多刚接触的人会把 DASSIDirect 和 DASIDirect 搞混。DASIDirect 是专门对接西门子 S7 系列 PLC 的驱动走的是西门子原生协议DASSIDirect 则不是面向特定品牌硬件而是面向任何符合 OPC DA 2.0/3.0 规范的服务器。一句话总结DASSIDirect 是一个 OPC DA 客户端 InTouch IO Server 的复合体一边连外部 OPC Server一边把数据翻译成 InTouch 能认的标记名。选型的时候建议先画一张数据流向图现场设备或者第三方软件提供 OPC 数据DASSIDirect 负责订阅InTouch 再通过访问名去 DASSIDirect 取数。中间多了一层看起来绕但这一层恰恰是 Wonderware 推荐的标准做法因为 OPC 连接中那些 DCOM 权限、断线重连、日志诊断等问题DAServer 都能在系统层面统一处理比 InTouch 直接连 OPC Server 干净得多。1.2 为什么用 DASSIDirect 而不直接用 OPC 客户端我知道肯定有人会质疑InTouch 不是自带了 OPC 客户端功能吗在访问名里选 OPC 类型、填上 ProgID 不就行了理论上可以但实际项目里这么干的越来越少原因很现实第一InTouch 自带的 OPC 客户端在跨机器访问时DCOM 配置非常敏感稍有不慎就出现 Access DeniedDASSIDirect 虽然底层还是 DCOM但它有自己的一套连接管理和日志体系问题定位容易得多。第二自带客户端做不了精细的更新周期控制多个 OPC Server 连接时访问名也散。第三老版本 InTouch 对 OPC DA 2.0 支持更好遇到 OPC DA 3.0 的服务器没有驱动层做协议适配兼容性很容易出问题。所以我在项目上一般这么定单机、点少、临时演示可以图省事用 InTouch 自带 OPC长期运行、点数多、需要稳定的系统一律上 DASSIDirect。另外DASSIDirect 连接外部 OPC 时用的是异步订阅方式数据到达后统一上抛给 InTouch这样即使 InTouch 画面刷新频率不稳定底层数据也不会丢。这一点对趋势曲线、历史记录这类功能非常关键。2. 安装部署环境准备与驱动注册2.1 安装包内容与安装前置检查把 DASSIDirect2.0 Intouch连接驱动.zip 解压开里面的内容基本是固定的几样setup.exe 或者 Installer 可执行文件、DASSIDirect 的 MSI 安装包、帮助文档和 Release Notes。如果你想在离线环境下批量部署建议先把 MSI 包单独拎出来准备好静默安装参数后续维护会方便很多。安装前有三件事必须先确认别急着双击 setup操作系统DASSIDirect 2.0 主要支持 Windows Server 2003/2008/2012 以及对应的桌面系统注意 32 位和 64 位的区分部分 2.0 小版本只有 32 位安装包装到 64 位系统时要以兼容模式运行。InTouch 版本这个驱动在 InTouch 2012 R2 及更早版本上最常用新版 AVEVA 系统一般用更新的替代方案但存量项目里老版本工具链非常常见兼容性不用太担心。授权环境DASSIDirect 需要独立的 Feature 授权码装之前最好先确认授权服务器或者本机授权服务已经就绪否则装上之后服务起不来白折腾。安装过程很简单右键以管理员身份运行 setup.exe一路 Next 即可。我习惯在安装前临时关闭杀毒软件和系统加固工具因为这类工控软件经常有注册表写入和系统服务注册动作安全软件拦截会导致组件注册不全。装完去控制面板的“服务”里看一眼能看到 DASSIDirect 相关的服务项说明基础安装成功。2.2 授权与组件注册要点DASSIDirect 安装完以后开始菜单会出现 Wonderware 目录下的 System Management Console简称 SMC这是管理所有 DAServer 的总入口。打开 SMC左侧树里能找到 DAServer Manager安装好的 DASSIDirect2.0 会出现在服务器类型列表里。这个环节最常见的故障是服务启动失败看日志只有一句话Invalid License。遇到这个别慌检查顺序是这样先看授权管理工具里有没有 DASSIDirect 对应的 Feature再看试用授权是不是过期了最后确认授权服务的系统时间是否被改动过。很多老工控机时间漂移改了时间后授权直接失效这个坑我踩过好几次。组件注册方面的经验安装包安装时一般会自动把 DASSIDirect 相关的 DCOM 组件注册好但如果你为了省事直接把安装目录复制到另一台机器那大概率会连不上。DASSIDirect 的 DCOM 配置和系统关联很深建议规规矩矩跑安装包。如果实在要手动迁移至少要在命令行里重新执行组件注册命令比如dasmngr.exe /regserver注册完成后重启一下 SMC再确认服务能正常起来再往下配置。这一步是为了把负责管理 DAServer 的对象管理器重新注册到系统让 SMC 能发现并控制 DASSIDirect 服务。3. 核心配置在 SMC 中建立连接通道3.1 创建 DASSIDirect 对象安装只是第一步真正让 InTouch 能取数的是在 SMC 里创建 DASSIDirect 对象。打开 SMC在 DAServer Manager 下找到 DASSIDirect2.0右键选择 Add Object 或者 Create Object弹出来的对话框里输入对象名。对象名建议起得有意义一些比如 DASDirect_TO_OPC1后面 InTouch 访问名会引用这个名字起得太随意到时候找起来很痛苦。对象创建完成后SMC 里会有这个对象的独立节点下面一般包含 Configuration、Device Groups、OPC DA Client、Diagnostics 这几个子节点。此时先别去动 OPC 配置我把 Configuration 里的几个关键参数单独列一下OPC Client Options包含 OPC 服务器重连尝试次数、重连间隔默认值通常能用但如果对方 OPC Server 是工程机偶尔会重启建议把重连次数调大重连间隔调到 5 到 10 秒。Update Rate这是 DASSIDirect 向上层 InTouch 反馈数据的基准刷新周期以毫秒为单位。默认一般是 1000ms也就是 1 秒如果画面需要更快响应可以适当缩短但不要低于 OPC Server 本身的数据刷新能力否则等于空转。Logging Options日志级别。平时用 Standard 就行联调阶段建议调到 Verbose 或者 Detailed这时候 SMC 的 Diagnostics 窗口会打印每个数据点的通讯明细问题定位全靠它。这里要注意Configuration 是对象级参数多个设备组共享这一套设置改之前想清楚影响面。3.2 配置 OPC DA Client 与设备组OPC DA Client 节点是 DASSIDirect 连接外部 OPC Server 的入口。双击打开属性页需要填两个关键信息节点名和 ProgID。节点名写 OPC Server 所在机器的 IP 或者机器名ProgID 是 OPC Server 在注册表里的唯一标识比如某 PLC 厂家的服务器可能是 CompanyName.OPC.1 这种格式。填完之后点击 Add系统会通过 OPCEnum 服务枚举目标节点上可用的 OPC 服务器。这里如果出现 No OPC servers found大概率是目标机器的 OPCEnum 服务没启动或者两台机器之间的 DCOM 权限没放开这个问题我在第 4 节专门展开。枚举出目标服务器后选中确定OPC DA Client 就配好了。接下来配置设备组。右键 Device Groups 节点新建一个组。设备组的核心参数是数据订阅的刷新粒度Update Rate这个组向 OPC Server 请求数据的周期单位毫秒。如果现场有 500 点OPC Server 扫描周期是 500ms那这里设 500ms 以下没有意义反而增加以太网负担。我一般先设 1000ms跑通了再根据画面响应需求往下调。Deadband死区设置。0 表示不管数值变多少都刷新如果设成 1%那相当于量程的 1% 以内变化不会触发数据上报。这个参数对降低系统负载很有用尤其适合温度、压力这类慢变量。Maximum number of tags这个组能容纳的最大标记数设置时要留出余量避免以后加点数加不进去。关于死区给个直观例子量程 0 到 100 的压力变送器死区设 1%那压力值变化小于 1 就不上报画面数值会保持旧值。对温度这种惯性大、变化缓慢的过程量非常适合但如果你做的是计数或者状态量监控死区请你设 0否则状态跳变一定会被吃掉。3.3 InTouch 侧访问名配置SMC 配完只干了一半活InTouch 里访问名的对应关系必须对上。打开 WindowMaker顶部菜单 Special 里的 Access Names点击 Add弹出对话框需要填四项关键内容Access Name自己起一个名字比如 DASSITest这个会出现在后续标记名的下拉列表里。Node Name填 localhost 或者本机机器名因为 DASSIDirect 就装在本机。Application固定写 DASSIDirect。Topic Name写刚才在 SMC 里创建的 DASSIDirect 对象名比如 DASDirect_TO_OPC1。协议选择那里推荐用 SuiteLink原因很实际SuiteLink 是 Wonderware 自家协议在数据稳定性、重连机制上比 DDE 好也比直接走 OPC 省一层转换。配置完成后InTouch 的 I/O 型标记名就可以选择这个访问名了标记名的项目名Project Name填 OPC Server 里具体的 Item 名比如 Device1.Pressure。注意 Item 名必须和 OPC Server 端提供的完整路径一致大小写、分隔符一个都不能错这是新手最容易出错的地方。4. 实际联调与问题排查实录4.1 最小验证环境的搭建步骤配置全做完别急着把几百上千个点一次性灌进去我每次都是先做一个最小验证环境十分钟内能跑通再放量。步骤很简单第一步在 OPC Server 端准备几个模拟点确保它们本身在刷新数值在变。第二步在 SMC 里把 DASSIDirect 的日志级别调到 Verbose。第三步在 InTouch 里建两个 I/O 标记名一个读模拟值一个是写值通道画面上放一个显示框和一个按钮。第四步运行 InTouch 画面观察显示值是否跟随 OPC Server 端变化点按钮看 OPC Server 端能否收到写入。同时切到 SMC 的 Diagnostics 窗口看到周期性的成功记录说明连接健康如果失败会有错误码沿着错误码去查基本能定位。我习惯按从底向上的顺序排查先确认 OPC Server 在运行再确认 OPC Server 自身报表在刷新然后看 DASSIDirect 的 OPC DA Client 状态是否 Connected最后看 InTouch 标记名的质量位是不是 Good。这个顺序能帮你快速把问题分成设备源、通信链路、上位机配置三段避免瞎猜。4.2 高频故障排查速查表下面这几类问题是我在这些年现场和远程支持里遇到最多的整理成一个速查表现象根因解决办法OPC DA Client 里枚举不到服务器目标机 OPCEnum 服务未启动或 DCOM 权限不对启动 OPCEnum在 dcomcnfg 中给 OPC 相关组件放行访问权限DASSIDirect 提示 RPC unavailable目标机 RPC 服务被优化工具禁用或防火墙拦截 135 端口检查防火墙 135 端口恢复 RPC 服务依赖项InTouch 点显示 #IOERR访问名配置错误或标记名 Item 名不匹配核对 Access Name、Topic Name、Project Name 三项数值质量位 Bad QualityDASSIDirect 与 OPC Server 已连接但数据未刷新检查设备组 Update Rate 是否合理确认 OPC Server 端数据质量服务启动后自动停止授权过期或工作目录占用查看 Windows 事件查看器更新授权或清理进程数据更新卡顿、像掉线一样设备组过多或刷新周期过短系统忙不过来减少设备组数量适度调大 Update Rate开启死区过滤拿 DCOM 权限这条再展开说一句。OPC 早期建立在 DCOM 机制上两台机器互访需要防火墙放行 135 端口并且在组件服务里给 DCOM 配置 Launch 和 Activation 权限。最快解决的方案是把两台机器加入同一个域并把 DASSIDirect 服务运行账户设为域用户如果是工作组环境就得手工给 Everyone 或指定用户放权限否则永远报 Access Denied。这块配置比较繁琐建议把这一步写成操作文档每次新项目直接照着配节省大量时间。4.3 联调避坑经验最后分享几条实操层面的心得这些经验都是项目里真金白银换回来的。第一设备组不要建太多。一个 DASSIDirect 对象下面挂 3 到 4 个组足够用了组多了不仅 SMC 管理界面看着乱运行时还会增加调度负担数据点的刷新时序反而变得不可控。第二Update Rate 的设定要尊重 OPC Server 的实际情况。我见过有人把刷新周期调到 50ms结果 OPC Server 本身扫描周期是 1 秒驱动层只能反复读到旧值还给网络造成了无意义的流量。这种“假高速”对工艺控制来说是非常危险的因为你以为数据是实时的其实底层根本没变。第三联调阶段一定用模拟数据源跑通了再对真实设备。我遇到过现场人员把 OPC 点的 Item 名写错连了半小时没反应最后发现是 OPC Server 那边数据源本身挂了跟 InTouch 配置一点关系都没有。最小验证环境看起来简陋但能帮你把变量隔离得干干净净省去大量无效沟通。我在实际项目里还有个习惯SMC 日志级别跑通后要记得调回 Standard否则 Verbose 级别的日志会飞快占满硬盘运行几个月后系统卡顿排查半天才发现是日志文件把磁盘写满了。这也是很多老系统“越跑越慢”的一个隐藏原因。驱动本身不难难的是这些看起来不起眼的小细节。你把连接关系理顺把日志和授权管好DASSIDirect 2.0 在存量项目里还能很稳定地跑很多年。本文还有配套的精品资源点击获取