企业官网建设流程全解析

简介：Intouch驱动_DAServer_DASSIDirect3.0是一套面向工业自动化HMI开发与集成运维人员的驱动资源包，可用于打通Intouch人机界面与PLC、SCADA、远程I/O等底层设备之间的数据通信链路。资源核心围绕DAServer数据访问服务器和DASSIDirect3.0直连驱动展开，前者负责多数据源接入与转发，后者提供面向特定硬件的高效通讯协议。压缩包共155个文件，大小约28.39MB，主要文件类型有dll动态运行库、exe安装程序、chm帮助手册、pdf技术文档、xml配置文件，以及用于驱动注册与装载的aacfg、aapkg、aarul文件，基本覆盖从安装部署、参数设置、连接测试到故障排查的完整流程。已有3927人学习/下载。借助该资源，用户可实现与多种品牌PLC和I/O模块的高速数据交换，获得快速响应、硬件兼容、简化配置和稳定安全等能力；同时，包内提供的DAServerManager管理手册与DASSIDirect安装说明，有助于深入理解驱动工作机制、通讯脚本编写和系统集成要点，适合需要提升自动化监控系统实时性与可靠性的工程师参考使用。

1. 为什么还要选DASSIDirect：SCADA直连PLC这盘棋的落子逻辑

做工业上位机这行当的，十有八九都绕不过Wonderware Intouch。而Intouch要和西门子S7系列PLC通信，驱动选型就成了第一个需要较真的问题。早年间S7-300/400走以太网，大家习惯用DASSIDirect这个DAServer；后来S7-1200/1500大行其道，有人转向S7+协议或者用Siemens的S7A、S7C驱动，但DASSIDirect 3.0在老项目改造和新项目里依然有相当高的出场率。为什么？因为它在S7-300/400、部分S7-1200（固件版本允许的情况下）通过TCP/IP直连的场景下，稳定性和部署成本实在太有优势。

这篇内容不是官方手册的翻译，而是我基于多个实际项目的踩坑经验，把Intouch驱动 DAServer DASSIDirect 3.0从选型、安装、配置到运维的完整链路捋一遍。适合三类人看：一是刚接手老产线、需要把Intouch和现有S7 PLC对接的维护工程师；二是做系统集成、正在评估驱动方案的项目经理；三是单纯想搞明白DAServer体系原理的自动化爱好者。

先说一个最关键的认知：DASSIDirect本质上是Wonderware（现在归Aveva）的IO Server，它工作在Intouch和S7 PLC之间，负责把Intouch的读写请求翻译成S7 TCP/IP协议。3.0这个版本针对西门子以太网模块（比如CP343-1、CP443-1）和集成PN口做了大量适配，性能比早期版本稳定得多。后面所有操作都建立在“你已经装好Intouch和DAServer Runtime、并且PLC端以太网通信已经打通”这个前提下，否则就像没打地基就盖楼，后面全是坑。

2. 安装部署前的关键准备：许可证和版本兼容性最容易翻车

2.1 许可证配置的常见误区

DASSIDirect 3.0安装包本身不大，但它的许可证（License）配置是新手翻车重灾区。很多人把DAServer装好了，Intouch也识别到了，但一启动通信就报“License Invalid”或者“Server Not Licensed”。我遇到过一次最典型的：现场工程师在授权管理器里只勾选了Intouch运行版许可证，把DAServer的授权完全忘了。DASSIDirect属于单独的IO Server授权，必须在Wonderware License Manager（也就是现在的Aveva License Manager）里确认存在对应的DAServer条目。

实操建议：装完驱动后，先在License Manager里过滤“DAServer”相关项，确认显示已激活；如果没有，就手动添加授权文件。别等到画面仿真跑起来才发现采集不到数据，那会儿排查成本就高了。

2.2 硬件和系统兼容性的底层逻辑

DASSIDirect 3.0支持Windows 7/10的32位和64位系统，但在64位系统上安装时，要注意Intouch本身的版本。如果Intouch是2012 R2之前的旧版本，在64位系统下跑DASSIDirect可能会遇到组态环境无法加载驱动的现象，这是因为旧版Intouch的WindowViewer是32位进程，而DAServer虽然是独立进程，但组态时需要和Intouch的SMC（System Management Console）通信，系统架构不一致会引发问题。稳妥的组合是：Intouch 2014 R2及以上 + DASSIDirect 3.0 + Windows 10 64位（关闭UAC或调整为管理员运行）。

2.3 S7通信端口和PLC端的前提条件

DASSIDirect通过TCP 102端口和PLC通信，这是西门子S7通信的固定端口。但在实际项目中，现场工程师在配置PLC侧以太网时忽略了一个关键点：PLC的CPU属性中需要允许“PUT/GET通信访问”，否则DAServer连上了CPU却无法读写数据。S7-300/400在硬件组态里有个“允许通过PUT/GET进行通信”的勾选项，S7-1200/1500则在CPU属性的“防护与安全”里设置“允许从远程伙伴（PLC、HMI、OPC UA、S7通信）进行PUT/GET访问”。这个不打开，DASSIDirect读到的永远是超时或访问拒绝错误。

3. 不借助额外工具的通信准备：从零测试S7 TCP/IP链路

3.1 用命令行工具验证基础连通性

在配置DASSIDirect之前，强烈建议先抛开Wonderware体系，独立确认从运行DAServer的电脑到PLC的TCP/IP链路本身是通的。这步看似多余，但能省掉后面90%的排错时间。

第一步，用ping命令测IP可达性。ping通只代表网络层通，不代表S7协议通，但ping不通就一定有问题。注意S7 PLC的IP地址不要和电脑网卡的IP冲突，子网掩码和网关要合理，尤其当PLC和上位机跨VLAN时。

第二步，用telnet测试102端口是否开放。打开命令行窗口，执行以下命令：

telnet 192.168.0.1 102

如果端口开放，窗口会变空白或显示一些不可读字符，然后停留住；如果端口不通，会提示“无法打开到主机的连接”。这个测试能确认PLC的S7通信服务确实在监听。很多现场问题其实出在防火墙拦截了102端口，Windows自带防火墙在“专用网络”和“公用网络”的规则不同，测试不通时优先检查防火墙出站入站规则。

3.2 判断PLC侧通信资源是否耗尽

有一个实际项目中遇到的案例：DAServer配置完全正确，但运行几个小时后偶尔报“Connection reset by peer”。排查到最后，发现是PLC的通信资源被大量HMI面板和编程电脑占满了。S7-300的通信资源有限，CP343-1最多支持16个S7连接，如果现场同时有编程器、触摸屏、其他上位机都在抢连接，DASSIDirect就会周期性掉线。这种情况下可以适当减少并发设备，或者在PLC硬件组态里为上位机保留专用连接资源。这块虽然和DASSIDirect配置无关，但直接影响驱动稳定性，属于典型的“配置没问题但环境有问题”。

4. 核心配置实操：DASSIDirect 3.0的安装、建点与跑通

4.1 安装DASSIDirect 3.0的标准流程

安装过程本身不复杂，但有几个细节值得留意。运行安装包时选择“典型安装”就能覆盖大多数需求，它会自动把DAServer运行时、SMC管理插件和协议映射文件装好。安装完成后，在开始菜单的Wonderware/Common文件夹下能找到DAServer Manager（也就是SMC的DAViewer），这是后续所有通信配置的主战场。

这里提醒一个容易忽略的点：安装完成后最好重启一次系统，让DAServer的服务注册和系统环境变量完全生效。我第一次装完没重启，结果在SMC里加载DASSIDirect时一直报“Failed to create object”，重启后问题消失。

4.2 在SMC中新建DASSIDirect端口

打开SMC（System Management Console），在左侧树形菜单中找到“Default Group”下的“DAServer Manager”，右键选择“Add DAServer”，在协议列表中选择“DASSIDirect 3.0”，确认后系统会自动创建一个默认实例（通常名为“SIDirect”）。

接下来右键这个实例，选择“Configuration”，进入端口配置界面。这里需要新建一个端口，参数如下：

• Name：自定义，建议直接写PLC的用途或IP，例如“S7_300_Line1”
• Network Address：PLC的IP地址
• Local TSA Address：通常保持默认
• Partner TSA Address：填Rack（机架号）和Slot（插槽号），格式是“0,2”或“0,4”。这个参数必须和PLC硬件组态里的机架号、插槽号一致，S7-300的CPU通常插在Slot 2，S7-400通常在Slot 4。填错的话连接会在建立阶段直接被拒绝。
• Connection Type：选“Configured”或“Dynamic”，一般用Configured，系统会自动建立通信连接。
• 通信超时和重试次数：超时建议5000ms，重试3次，不要太小，否则PLC在繁忙时容易判定超时。

4.3 配置Topic并绑定Intouch访问名

端口配好后，还需要在端口下新建Topic（主题）。Topic是DASSIDirect逻辑上的数据集合入口，Intouch通过访问名（Access Name）关联到具体的Topic。

在SMC的端口下点击右键，选择“Add Topic”，输入名称（例如“DB_PLC1”）。然后在Intouch的WindowMaker里，进入“访问名”配置：

• 节点名：运行DAServer的电脑名称（如果是本机可填localhost）
• 应用程序名：DASSIDirect
• 主题名：刚才SMC里创建的Topic名（DB_PLC1）
• 选择“使用数据字典”，并指定DASIDirect的协议映射文件。

协议映射文件（.csv）用于把Intouch点位名和S7地址对应起来，这一步如果做不好，后面所有点都会显示“#BAD”或“通信失败”。最简单的方式是在Intouch的“标记名字典”里直接建点，每个点的“访问名”选刚建的DB_PLC1，然后“项目名”按DASSIDirect的地址语法填写。

4.4 地址格式的准确写法

DASSIDirect的地址格式和S7的绝对地址对应关系必须记牢。以S7-300的DB块数据为例：

• DB10.DBW0（数据块DB10的字0，16位无符号整数）在DASSIDirect中写作：DB10,INT0或DB10,W0
• DB10.DBD2（数据块DB10的双字2，32位浮点数）写作：DB10,REAL2
• DB10.DBX6.0（数据块DB10的位6.0）写作：DB10,BIT32（位地址从0开始，所以第6字节的第0位对应第48位，但DASSIDirect用BITx语法表示位序号，需查阅驱动手册）

更常见的是使用“S7:[连接名]DB块号，数据类型偏移量”的通用格式。比如：

S7:[S7_connection_1]DB10,INT0 S7:[S7_connection_1]DB10,REAL2 S7:[S7_connection_1]M0.0

如果你在SMC里配置了连接名，就统一用带连接名的写法；如果没配置，直接用“DB块号，类型偏移量”也能被识别。需要特别注意的是，DASSIDirect对数据类型的映射有一套自己的规则，比如Intouch的Message类型和S7的字符串类型转换，容易踩坑，建议先从小块数据测试，验证字节顺序无误后再大规模建点。

4.5 启动通信并验证数据链路

所有配置完成后，在SMC里启动DASSIDirect实例。启动后观察状态栏，如果显示“Running”且端口状态为“Active”，说明驱动已正常连接。接着在Intouch WindowMaker里打开一个测试画面，放几个显示标签绑定到刚才建的点位，切换到运行模式（WindowViewer）观察数值变化。如果数据显示“#BAD”，回到SMC里查看“Diagnostics”面板中的通信日志，绝大部分问题都能从日志里找到直接原因，比如“Access denied”“Timeout”“Bad address”。

5. 踩坑过程完整复盘：一个M0.0布尔点读不出来引发的排查链路

5.1 现象描述和初步假设

有一个改造项目，Intouch画面都做得差不多了，DASSIDirect也连上了，PLC侧能看到通信资源被占用，但画面上所有M区布尔点全部显示“#BAD”，而DB块的数值点完全正常。这个现象组合非常典型——部分点好、部分点坏，说明驱动本身没问题，问题出在地址映射或数据类型转换上。

我的第一反应是地址语法问题。M区是位存储区，S7里M0.0是最常见的布尔变量地址，我在Intouch标记名字典里写的项目名是“M0.0”，理论上DASSIDirect应该能直接翻译成S7地址。但仔细一想，DASSIDirect对M区的访问格式可能和DB区不一样。果然，查了驱动自带的地址映射帮助文档后发现，M区的布尔变量推荐写法是“M0,0”格式，而不是“M0.0”。前面用的点号语法在西门子编程软件里通用，但在DASSIDirect里被解释成了另一个含义，导致地址解析失败。

5.2 定位过程：从SMC日志到逐条测试

通过SMC的诊断窗口查看日志，能看到每条读写请求的详细错误。日志里明确记录“Invalid address specification: M0.0”。这时候我做了两个验证：第一，把地址改成“M0,0”测试，数据立刻正常；第二，用一个已知正常的DB位地址对比，比如“DB1,0.0”，发现能通。于是确定是地址分隔符问题。

5.3 修复方案和验证结果

把所有M区布尔点从“M0.0”规范改成“M0,0”（或者按驱动文档语法“M0/BIT0”），保存并重启通信后，画面数据全部刷新。这次排查链路大约花了四十分钟，绝大多数时间浪费在反复看配置界面而非直接查日志，所以我把诊断日志放在第一步，后来遇到类似问题基本能在五分钟内定位。

5.4 从M区错误举一反三的教训

这次踩坑引出一个通用原则：DASSIDirect的地址分隔符统一用逗号，不要按TIA Portal或者STEP 7的习惯写点号。不仅仅是M区，I区、Q区也同理。数据块内的位访问地址“DB1.DBX0.0”在DASSIDirect中应写作“DB1,BIT0”或按驱动文档定义。建议在项目启动初期就制定好地址规范，写成Excel映射表，方便以后批量导入和排查。

6. 数据采集成功之后：从“通”到“好用”的进阶处理

6.1 字节顺序那点事：Word vs Byte Swap

很多工程师第一版画面跑起来时会发现真实数据和PLC里看到的不一致，比如数值大得离谱或者符号不对。典型是浮点数高低字节颠倒。S7-300/400在默认情况下是按大端方式存储数据，而Intouch在Windows上运行，处理器通常是小端。DASSIDirect理论上会在通信层处理这个转换，但在某些PLC配置或软件版本组合下，可能存在字节顺序错位。

DASSIDirect的配置项里有一个“Byte Order”或“Swap Mode”设置，可以选择No Swap、Word Swap或Byte Swap。实际项目中，当读到的浮点数是完全错乱但整数正常时，尝试把Swap Mode改为Word Swap；当整数也乱序时，尝试Byte Swap。这个试探过程需要在线验证，对比PLC编程软件和Intouch的数值是否一致，直到完全匹配。

6.2 通信性能优化：扫描周期和分组策略

DASSIDirect默认的扫描周期是1000ms，但Intouch标记点的“更新频率”可以在访问名属性里设置。如果现场需要毫秒级响应，建议将访问名更新频率设为100ms，并同步调整DAServer端的“Block Read Size”参数。需要注意的是，S7通信本身有PDU大小限制，一次请求最多读写若干字节。如果点位很多，DASSIDirect会自动拆包，但拆包越多，CPU负载越高，现场实测下来，把同类型、连续地址的点位放在一起会显著提高性能，减少DAServer与PLC之间的报文数量。

6.3 断线重连机制和冗余配置

工业现场总有网络闪断的突发事件，DASSIDirect自带断线重连机制，但默认的重试间隔可能过短，导致PLC通信资源被频繁占用。在端口配置里把“Reconnect Attempts”设为0（无限重试）或根据实际需要设为3-5次，重试间隔建议在5-10秒。如果你有冗余PLC或双网卡环境，DASSIDirect还支持配置Primary和Secondary通信路径，实现链路级冗余。配置方法和单链路类似，只需增加一个冗余端口并配对关联，这样主链路故障时，驱动自动切换到备用链路，Intouch画面完全无感知。

7. 长期运维中的几条观察和操作习惯

项目交付后，DASSIDirect的长期稳定性很大程度上取决于日常操作习惯。以下几点是根据我多年维护经验总结的，不是官方手册里会写的内容。

第一，不要随意修改PLC侧硬件组态。DASSIDirect连接建立依赖于机架号、插槽号和TSAP地址，PLC组态一变，驱动就会异常。现场设备改造前一定要和技术员确认，不能只改IP地址就算完。

第二，定期备份SMC里的DASSIDirect配置。这个配置以XML文件形式保存在DAServer安装目录下，Windows重装或系统迁移时，直接备份整个DAServer配置目录，恢复速度比重新配置快得多。

第三，日志的切割策略。SMC诊断日志默认是单文件累积，长时间运行会产生巨大日志文件，影响磁盘空间和读取效率，建议在日志配置里开启按天切割。

第四，多站点现场要特别注意Intouch访问名中的节点名。当Intouch和DAServer不在同一台机器上时，节点名要填DAServer所在机器的计算机名（NetBIOS名），不能填IP地址。我踩过一次跨机器访问失败的坑，就是把节点名填成了IP，DAServer列表始终识别不到。

第五，DASSIDirect进程偶尔会“假死”。现象是SMC里状态显示运行中，但Intouch数据不再刷新。这种时候先尝试在SMC里执行“Stop”再“Start”，如果还不行，直接在任务管理器里结束WSDA进程并重启服务。这个操作我在几个项目中都遇到过，重复性概率不高，但一旦发生，影响面很大，建议监控系统对DAServer进程做心跳检测。

8. 如果你用的是更新版本的S7 PLC，DASSIDirect的边界在哪

现在S7-1200/1500已经是主流，很多新项目中会问“DASSIDirect 3.0能不能直接接入”。我的回答要分情况。对于S7-1200，部分早期固件版本（比如V2.0及以下）和DASSIDirect兼容性还不错；但新固件版本默认启用了更严格的S7通信安全机制，DASSIDirect可能无法建立连接，或者需要额外配置。对于S7-1500，DASSIDirect 3.0原生支持程度一般，建议优先考虑Wonderware官方的S7A或S7C驱动，或者通过S7-1500的OPC UA服务器功能接入。

所以我的建议是：老项目、S7-300/400继续用DASSIDirect完全没有问题；新项目选型时，先确认PLC型号和固件，再决定是否沿用DASSIDirect。别为了省事强行用老驱动，最后通信不稳定才是最麻烦的。

从选型到配置，再到踩坑复盘和长期运维，DASSIDirect 3.0其实是一条很成熟的技术路线，核心就是理解地址语法和通信底层，把这两块吃透，你基本可以应付90%的现场问题。希望这篇经验整理能让你少走一段我当年走过的弯路。

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