简介：DASSIDirect3.0驱动程序面向工业自动化编程与上位机组态人员，重点解决西门子S7-200、300、400、1200、1500及400H系列PLC与Intouch之间的通讯连接问题，适合现场调试、老系统维护及通讯链路排错等场景。压缩包共159个文件，约28.39MB，包含68个dll、27个exe、14个chm及若干pdf、xml、hlp等，涵盖驱动运行库、安装程序、帮助文档与配置说明，便于按用途查找所需组件。已有1584人学习下载，说明其在相关工程实践中具有一定参考价值。资源可用于搭建Intouch与西门子PLC的通讯环境，辅助理解DAServer配置、驱动安装及常见连接异常排查，适合需要快速补齐驱动组件与文档依据的自动化从业人员。

1. 现场画面全红，十有八九是 DASSIDirect3.0 这一层没装对

上个月在一台工控机上重装上位机，InTouch 画面打开后所有数值都是红的，通讯日志干净得可疑。PLC 那头 ping 得通，102 端口用工具测也是通的，最后问题落在中间的 DASSIDirect3.0 驱动：OPC 服务没起、设备节点参数填错、Topic 名字和 InTouch 里对不上，任何一种都能让画面干瞪眼。这套组合在老线改造和系统迁移里太常见了——上位机 InTouch，下面挂 S7 系列 PLC，中间靠 DASSIDirect3.0 把 S7 以太网协议翻译成 OPC DA。装它本身十来分钟，麻烦的是系统位数、DCOM 权限、组件安装顺序这几件事，一步踩空，后面全白干。下面按我实际装机的顺序走一遍。

2. 环境清点：位数、DCOM 和安装顺序先定死

DASSIDirect 3.0 属于上一代 DA Server 产品线，安装包对运行环境有明确偏好。硬塞进不合适的系统里，问题不会在安装时暴露，而会推迟到联调那一天，届时你面对的是"能装、能开、连不上"这种最难查的状态。我拿到一台机器一般先做三件事：确认操作系统位数、确认机器上有没有旧的 DA Server 残留、确认 InTouch 是哪个大版本。这三件事决定了接下来是十分钟收工，还是一下午耗在这。

提示：这一章不做任何安装动作，全部是查。查完再动手，能省掉后面 80% 的返工。

2.1 系统位数决定组件落在哪个注册表分支

DASSIDirect 3.0 的驱动核心是 32 位 COM 组件。在 32 位系统上它直接写HKLM\SOFTWARE\Classes；在 64 位系统上，它会被重定向到HKLM\SOFTWARE\WOW6432Node\Classes下面。这个差别在装的时候完全无感，等到某个 64 位 OPC 客户端枚举服务器、列表里空空如也时，才会变成一整天的排查。

先用两条命令把底摸清：

# 看系统版本和位数，决定后面组件注册到哪个分支 Get-CimInstance Win32_OperatingSystem | Select-Object Caption, OSArchitecture, Version # 64 位系统上，32 位 OPC 服务器的 ProgID 落在 WOW6432Node 下 Get-ChildItem 'HKLM:\SOFTWARE\WOW6432Node\Classes' -ErrorAction SilentlyContinue | Where-Object { $_.PSChildName -like 'DAS*' } | Select-Object -ExpandProperty PSChildName

第一条只是确认前提，重点看OSArchitecture是不是 64 位。第二条更关键：它列出来的每一个名字，都是一个已注册的 DA Server 的 ProgID，也就是后面在 InTouch 的 Access Name 里能填的 Application Name 候选值。不要凭记忆填这个字符串，拼错一个字母，OPC 客户端就会告诉你"服务器未注册"，而实际上它好好装在那里。我见过有人把 DAS 和 DA 的顺序写反，查了两小时。

还有一层位数匹配要提前想清楚：InTouch 自身如果是 32 位进程，它调 32 位的 OPC 服务器没问题；但如果现场还有别的采集程序是 64 位进程，那它枚举不到这套 32 位服务器，需要额外挂一层桥接或者换用 64 位版本。这个判断要在装机前做完，不要等联调时才发现两侧位数对不上。

2.2 依赖与安装顺序：框架先行，驱动后装

DASSIDirect 3.0 不是独立跑的，它依托 DA Server 运行框架（DAServer Runtime）工作，配置界面则挂在系统管理控制台（SMC）里。有的安装包把框架和驱动打在一起，有的是分开的两个包，具体看你手里那份介质。顺序上有一条铁律：先框架，后驱动。反过来的话，驱动装完在配置树里找不到挂载点，界面打开是空的，你会以为是装失败了，其实只是顺序错了。

常见的安装顺序是这样，我一般照这个清单核对一遍再开始：

如果机器上之前装过别的 DA Server，先看一眼服务列表，确认旧服务是停着的。多个 DA Server 共存是允许的，但端口和 DCOM 配置会互相影响，装之前心里要有数：

# 列出所有名字里带 DAS 的服务，看有没有旧版本残留 Get-Service | Where-Object { $_.Name -match 'DAS' } | Format-Table Name, DisplayName, Status -AutoSize

Status一列如果是Running，而且对应的是旧版本，先停掉再装。停服务用Stop-Service -Name 服务名 -Force，别直接去任务管理器结束进程，那样配置库可能写坏。这一条是血泪经验：有次我在服务运行状态下覆盖安装，装完配置树里出现了两个同名节点，删都删不干净，最后只能卸干净重来。

2.3 安装包解压与路径约定

介质如果是 ISO，先挂载再装，别在压缩软件里直接双击 setup.exe——自解压程序在临时目录展开时可能丢文件，尤其是带多语言资源的包。路径上守两条：不带中文、不带空格。默认路径一般在Program Files (x86)下，能不改就不改，因为后续的配置库、日志、备份脚本里都可能硬编码了这个位置，改完自己还得记一遍。

# 挂载 ISO 后确认盘符，别猜 Get-Volume | Where-Object DriveType -eq 'CD-ROM' | Format-Table DriveLetter, FileSystemLabel, SizeRemaining # 以管理员身份启动安装程序，避免中途弹 UAC 打断注册 Start-Process -FilePath 'D:\setup.exe' -Verb RunAs

第二条命令的意义在于：安装过程要写注册表、注册 COM 组件、创建服务，全都是需要提权的操作。如果只是双击运行、中途弹窗再点"是"，某些安装引擎在提权后会换一个用户上下文，导致注册写到了错误的配置单元里。用-Verb RunAs一开始就以管理员身份起进程，路径干净得多。

另外提醒一句杀毒软件。这类驱动安装会往系统目录写 DLL 并注册服务，行为特征和某些恶意程序高度相似，被拦截是常事，而且往往拦得无声无息——安装程序照样报"完成"，实际上少注册了一个组件。装之前把实时防护临时关掉，装完再开，比事后查日志省事。

3. 安装 DASSIDirect 3.0：从 setup 走到配置树能展开

环境清点完就可以动手了。整个过程分三段：向导里选对选项、装完确认服务真的起来了、打开 SMC 确认节点挂上了。三段里任何一段糊弄过去，后面配参数都是白配。

3.1 安装向导逐屏：路径、账户、组件勾选

向导本身没什么难度，但有几屏的选择会直接影响后面能不能用。第一屏是安装类型，通常有"典型"和"自定义"两个选项，选自定义，因为典型安装有时会跳过 SMC 或者把驱动装到默认位置，而你需要知道每个组件到底落在哪。

第二屏是服务登录账户。默认是本地系统账户，多数现场够用。但如果你的 InTouch 和 DA Server 不在同一台机器上，或者需要跨域访问，这里选的账户会决定 DCOM 的身份，选错了后面改起来很别扭。我的习惯是现场单机就保持默认，跨机就先规划好一个专用账户，装的时候一次到位。

第三屏是组件勾选，把驱动本体和配置工具都勾上，诊断工具如果有也一起装——那个东西在排查阶段比什么都好用。

安装过程中会弹一次 COM 注册确认，不要点太快。这一步是在往注册表写 ProgID 和 CLSID，点取消的话整个驱动等于没装。装完向导会提示重启，必须重启，不是礼貌性的建议。COM 组件注册和服务注册表项有些要等重启后才生效，跳过后你会遇到"服务在但起不来"的玄学问题。

3.2 服务注册与配置树挂载确认

重启之后第一件事不是打开 InTouch，是确认服务状态。前面那条Get-Service命令再跑一次，看新装的服务在不在、状态是不是Running。如果状态是Stopped，手动起一下：

# 手动启动 DA Server 服务并确认启动类型 Start-Service -Name '你的DAServer服务名' Get-Service -Name '你的DAServer服务名' | Select-Object Name, Status, StartType

StartType这一列很关键。如果是Manual，机器重启后服务不会自己起来，第二天早班一来画面全红，运维被叫到现场发现只是没启动——这种事我遇到过不止一次。改成自动：

# 改成自动启动，避免重启后服务不自启 Set-Service -Name '你的DAServer服务名' -StartupType Automatic

服务起来之后打开系统管理控制台。正常情况在开始菜单里能找到入口，展开后左侧树里应该出现一个形如xxx.DASIDirect的节点，下面挂 Local 分支。如果树是空的，或者只有框架没有驱动节点，先别怀疑安装包坏了，回到 2.2 节核对安装顺序，八成是驱动装在框架前面了。

3.3 装完先核对这三处是否就位

我装完任何 DA Server 都会核对三处，缺一处就先补，不往下走。

第一处是服务，上面已经说了。第二处是注册表里的 ProgID，用 2.1 节那条命令再查一遍，确认能列出新装的驱动名。第三处是配置文件目录，一般在安装目录下有个存放配置的文件夹，里面会有初始的配置文件或者配置库文件。找到它，立刻复制一份到别处当备份。

# 安装目录下找配置文件，装完先备份一份干净的初始状态 Get-ChildItem 'C:\Program Files (x86)\你的安装目录' -Recurse -Include *.xml,*.ini,*.dat -ErrorAction SilentlyContinue | Select-Object FullName, Length, LastWriteTime

这条命令只是帮你定位文件，不修改任何东西。找到之后手动复制一份，命名成backup_初始状态_日期。后面配错了参数、改乱了节点，直接把这份拷回去重启服务，比在界面里一项项恢复快得多。这就是装机时的后悔药，成本两分钟，能救你半天。

三处都对上了，安装阶段才算结束。接下来是配置，也是真正决定能不能连上 PLC 的部分。

4. 配置 DASSIDirect 3.0：设备节点、Topic 和 InTouch 的 Access Name

配置这条链路上有三个环节，缺一不可：DA Server 这边要有一个指向 PLC 的设备节点，节点下要有至少一个 Topic 承载数据项，InTouch 那边要有一个 Access Name 指回这个 Topic。顺序不能反，很多人先在 InTouch 里配好 Access Name 再去配 DA Server，结果两边名称对不上，查起来两头跑。

4.1 建 S7 设备节点：IP、Rack、Slot、TSAP

在配置树里右键新增设备节点，协议选 S7 以太网（ISO over TCP）。核心参数就四个：PLC 的 IP、机架号 Rack、槽号 Slot、TSAP。

IP 不用解释。机架号和槽号是 S7 体系里的物理寻址方式，填错了现象是连接超时，而不是报参数错误——这是最坑的地方，它不会告诉你"槽号错了"，只会一直连不上，让你以为是网络问题。经验值：S7-300 系列 CPU 一般机架 0、槽 2；S7-400 常见机架 0、槽 2 或 3；S7-1200/1500 用 0 和 1。具体以你的硬件组态为准，不要照抄，去组态软件里看一眼 CPU 属性里的槽号，一分钟的事。

TSAP 是传输层服务访问点，用来区分同一 IP 上的不同连接端点。多数情况下填03.02这种形式（03 是连接类型，后面跟着槽号），跟 Rack/Slot 是联动的。如果现场有多个上位机同时连同一台 PLC，TSAP 要区分开，否则后连的会把先连的踢掉——这个现象很迷惑，表现为两台机器轮流掉线。

; 设备节点参数示例，实际字段名以配置界面为准 [Device] Name = PLC_LINE1 Protocol = S7_TCP IP = 192.168.10.20 Rack = 0 Slot = 2 TSAP_Local = 03.00 TSAP_Remote = 03.02 Port = 102 Timeout_ms = 3000

这段配置里Port = 102是 S7 以太网的固定端口，不用改。Timeout_ms我一般先设 3000，联调阶段够用又不至于卡太久；稳定运行后可以放宽到 5000，避免网络抖动造成误判断线。Name这个字段后面会被 InTouch 引用，命名规则我坚持用"位置_设备"的格式，别用中文，别用空格，别超过 16 个字符，某些环节对长度有限制。

配完先别急着建 Topic，用配置界面里的连接测试功能点一下，看状态是不是变成已连接。红了就回 5.1 节看排查。

4.2 建 Topic 与数据项：先把一个点读通

设备节点连上之后，在它下面建 Topic。Topic 是数据项的容器，也是 InTouch 那边引用的对象。一个设备节点下可以建多个 Topic，按工艺段分或者按数据类型分都行，我倾向按工艺段分，方便后期加人接手时定位。

Topic 本身参数不多，主要是刷新周期和是否启用。真正花时间的是数据项（Item）。数据项不是让你一个个手工敲进去的，规范做法是先在诊断页面里手填一个地址试读，读通了再批量加。

地址写法上，S7 体系里最常见的是 DB 块地址、M 区、I 区、Q 区。DB 块地址由 DB 号加偏移组成，比如 DB10 里的第 0 个字。具体语法以你这版驱动的帮助文档为准，不同版本对分隔符的处理有差异，有的用点，有的用逗号。别猜，打开帮助文档里的 Item 语法那一页，照着写一个。

# 诊断页面里试读用的 Item 示例（语法以本地帮助为准） DB10.DBW0 # DB10 的第 0 个字 DB10.DBD4 # DB10 的第 4 字节开始的双字 M0.0 # 位地址

读通一个之后，剩下的就是批量导入。配置界面一般支持从文件导入 Item 列表，把点位表整理成 CSV 再导进去，比在界面里点几百次强太多。我一般会先在界面里配通一个 Topic，把配置文件导出来当模板，第二个项目直接改 IP 和 DB 号，能省掉重复劳动。

有一个坑要特别提：DB 块的优化访问属性。较新的 S7 系列 CPU 默认开启块的优化访问，开了之后 DB 块没有固定偏移量，按偏移去读会读到错位的数据或者直接失败。解决办法是在 PLC 侧把对应 DB 块的"优化的块访问"关掉，重新下载。这个设置不在上位机这边，很多人查了半天驱动配置，问题其实在对面的组态里。

4.3 InTouch 侧 Access Name 与 DCOM 身份

DA Server 这边配通了，转到 InTouch。在访问名（Access Name）配置里新建一条，三个字段要填对：

• 节点名：DA Server 所在机器的机器名。单机就填localhost或本机机器名。不要填 IP，这一条是经典坑，填 IP 在某些环境下 DCOM 解析不了，表现为访问名无效。
• 应用程序名：就是 2.1 节查出来的那个 ProgID，照抄，别自己拼。
• 主题名：DA Server 里建的 Topic 名称，大小写要一致。

三者的关系可以理解成"去哪台机器、找哪个服务、读哪个主题"。填完之后在 InTouch 里建一个测试标记名，指向这个访问名下的一个 Item，看值能不能刷出来。

如果 InTouch 和 DA Server 不在同一台机器上，DCOM 配置就是绕不过去的一关。打开组件服务，找到我的电脑属性，在 COM 安全里把访问权限和启动激活权限都加上运行 InTouch 的那个账户。这一步不需要重启，改完立刻生效。如果两侧不在同一个域里，还得考虑身份验证级别的问题，那种情况建议直接问现场的网络管理员，别自己试。

# 打开组件服务控制台配置 DCOM 权限 dcomcnfg

这条命令打开的是图形界面，没什么参数可讲。要点在于：改完权限后，先在本机用 OPC 客户端测一遍，再跨机测，一层层往外推，出了问题能立刻定位是哪一层。

4.4 关键参数对照表

配置阶段容易拿不准的几个参数，我整理成一张表，装机时对着填：

这张表不是让你抄，是让你在填错的时候知道该往哪查。Rack 和 Slot 那两个"连接超时，无明确报错"是真实情况——驱动不会告诉你参数错了，它只会一直重连，日志里翻来覆去就那几行。所以填之前去组态里确认一遍，比事后猜快得多。

5. 排查：DASSIDirect 3.0 装完连不上的五种现场

装和配都走完了还是不通，是常态，不用怀疑自己。下面这五种情况是我这些年遇到频率最高的，每条按现象、原因、解决写，照着对号入座。

5.1 现象：配置树里设备节点一直是红的

现象很直观，节点图标红色，状态显示未连接，日志里反复出现重连记录。

原因排第一的是网络层。IP 填错、网段不通、PLC 没上电，这几种占了大半。排第二的是 Rack/Slot 填错，前面说过，驱动不会报参数错误，只会一直连不上。排第三的是防火墙，工控机的入站规则里没放行 102 端口，尤其是新装的系统，默认策略是拒绝。

解决办法是从外往内一层层测。先 ping，再测端口，再看配置参数：

# 第一层：网络通不通 Test-Connection -ComputerName 192.168.10.20 -Count 3 # 第二层：102 端口开不开 Test-NetConnection -ComputerName 192.168.10.20 -Port 102 # 第三层：本机有没有监听/发起对应连接 Get-NetTCPConnection -RemotePort 102 -ErrorAction SilentlyContinue | Select-Object LocalAddress, RemoteAddress, State

三条命令依次过，哪一层断了就修哪一层。Test-NetConnection那条如果返回TcpTestSucceeded : False，而 ping 是通的，基本可以确定是防火墙或者 PLC 侧没开服务。PLC 侧还要确认一点：较新的 S7 系列 CPU 需要在硬件组态里勾选"允许来自远程伙伴的 PUT/GET 通信访问"，不勾的话端口通、协议层直接拒绝，现象和防火墙拦截一模一样。

5.2 现象：OPC 客户端枚举不到服务器

打开 OPC 客户端，点浏览服务器，列表里没有你装的那个。或者填了 ProgID 直接报"服务器未注册"。

原因有三种。一是 ProgID 拼错了，大小写和连字符都可能出问题，回 2.1 节那条命令查准确值。二是位数不匹配，64 位客户端枚举 32 位服务器，枚举不到。三是组件注册失败，安装时被杀毒软件拦了，或者提权不彻底。

解决顺序：先用注册表命令确认 ProgID 存在，再确认客户端位数，最后才怀疑注册。如果确实是注册失败，不用重装整个包，用管理员权限重新注册那个 DLL 就行：

# 以 32 位模式注册组件（64 位系统上的关键一步） C:\Windows\SysWOW64\regsvr32.exe "C:\Program Files (x86)\你的安装目录\驱动组件.dll" # 注册完确认 ProgID 出现在 WOW6432Node 下 Get-ChildItem 'HKLM:\SOFTWARE\WOW6432Node\Classes' | Where-Object { $_.PSChildName -like 'DAS*' } | Select-Object -ExpandProperty PSChildName

注意第一条命令用的是SysWOW64目录下的 regsvr32，不是System32下的。64 位系统上这两个同名程序一个是 32 位一个是 64 位，用错了会把 32 位组件注册到 64 位分支，表面成功实际没用。这个细节坑过很多人。

5.3 现象：能连上，但数据全是坏值或者不刷新

设备节点是绿的，Topic 也建了，InTouch 里的值要么是坏的，要么一直停在初始值。

第一嫌疑是 Item 地址写错，尤其是 DB 块的偏移量算错。第二嫌疑是前面提到的优化块访问属性没关。第三嫌疑是数据类型不匹配，按字读的地址当成双字解析，值会变成一个莫名其妙的大数。第四嫌疑是修改变量没更新，PLC 里改了数据但没下载。

排查方法是在 DA Server 的诊断页面里直接读那个 Item，绕开 InTouch。如果诊断页面读出来是对的，问题在 InTouch 侧的访问名或者标记名定义；如果诊断页面也是坏的，问题在 Item 地址或者 PLC 侧。这一步能直接把问题切成两半，比两头猜快得多。

数据类型这块给个对照：S7 里的 WORD 是 16 位无符号，INT 是 16 位有符号，DWORD 是 32 位无符号，DINT 是 32 位有符号，REAL 是 32 位浮点。在 DA Server 里建 Item 时声明成什么类型，InTouch 那边就得按对应类型接。类型错位不会报错，只会给你一个看似合理的错误数值，最难查。

5.4 现象：重启后 InTouch 连不上，手动起服务就好

现象很典型：白天运行正常，第二天早班来了画面全红，运维手动启动一下服务就恢复。

原因是服务启动类型是手动，或者服务依赖的组件启动顺序有问题。前一种改启动类型就行，2.2 节给过命令。后一种要检查服务依赖关系，有时候 DA Server 服务比网络栈起得还早，起来时网卡还没就绪，连接自然失败。

# 查服务依赖，确认启动顺序没问题 Get-Service -Name '你的DAServer服务名' | Select-Object -ExpandProperty ServicesDependedOn | Format-Table Name, Status # 给服务加一个延迟自启，避开开机时的网络初始化窗口 sc.exe config "你的DAServer服务名" start= delayed-auto

第二条命令用delayed-auto把服务改成延迟自动启动，开机后等系统把网络、DCOM 都初始化完再起，能避开很大一类"第一次连不上、手动重启就好"的问题。这个参数改完立即生效，不用重启。

还有一种情况容易被忽略：机器上装了安全软件，开机时扫描占满 IO，服务启动超时被系统判为失败。这种就在服务属性里把失败恢复策略设成"重新启动服务"，给它几次机会。

5.5 现象：卸载重装后配置残留，新装的起不来

想升级或者重装，结果装完发现配置树里有两个同名节点，或者服务启动报配置库损坏。

原因是卸载不干净。DA Server 的配置库、注册表项、服务注册信息，卸载程序往往只清一部分，剩下的残留会让新版本读到旧配置。特别是覆盖安装，最容易出这个问题。

彻底的清理顺序是这样：先停服务，再卸载，然后手工清残留，最后重启再装。

# 1. 停服务 Stop-Service -Name '你的DAServer服务名' -Force # 2. 卸载（走控制面板或者安装包自带的卸载程序） # 3. 清残留：先看安装目录还在不在 Test-Path 'C:\Program Files (x86)\你的安装目录' # 4. 清注册表项（先导出备份，再删） reg export "HKLM\SOFTWARE\WOW6432Node\你的厂商键" backup.reg

第四条命令一定要先导出备份再动手。删除注册表是不可逆操作，导出那一秒能省掉重装系统的风险。清理完重启机器，让系统和 COM 注册状态归零，再重新安装。我现在的习惯是每次卸载后都走一遍这个流程，虽然多花五分钟，但比装完发现起不来再回头查强太多。

6. 交付前的验证：三条链路逐个打通再放手

装完配完不等于交付完成。我在现场给自己定了一条规矩：交付前必须按链路顺序验证三遍，每一遍都用不同的工具，任何一遍不通就不签字。这么做不是为了走流程，是因为这套东西的故障会延迟暴露——今天演示正常，明天早班就全红，到时候再回现场，成本是现在的十倍。

第一条链路验证本机通信。在 DA Server 所在机器上，用诊断页面或者本地 OPC 客户端，读一个已知会变化的点位，比如一个计数器或者心跳位。观察一分钟，看值是不是持续刷新。这一步排除了协议层和配置层的问题，只要这里通了，说明 DA Server 和 PLC 之间的对话是正常的。

# 顺带确认 TCP 连接处于已建立状态，而不是反复重连 Get-NetTCPConnection -RemotePort 102 -State Established -ErrorAction SilentlyContinue | Select-Object LocalAddress, LocalPort, RemoteAddress, State, CreationTime

State应该是Established，CreationTime应该是一个较早的时间点。如果这个时间一直在变，说明连接在反复断开重连，虽然当前是通的，但不稳定，交付前必须查清楚。这个细节从画面上完全看不出来，只能从连接状态看。

第二条链路验证跨机访问。在 InTouch 所在机器上，用 OPC 客户端远程连过去，读同一个点位。这一步验证的是 DCOM 配置和网络访问权限。跨机不通而本机通，问题百分之百在 DCOM 权限或者防火墙，别往别处查。这里有个经验：改完 DCOM 权限后不用重启，但要让改动生效，最好把客户端程序完全退出再启动，有些客户端会缓存连接上下文。

第三条链路验证 InTouch 内部。建一个测试标记名，指向 Access Name 下的 Item，打开画面看数值和 quality 字段。quality 是Good才算真正通了，只是"有数值"不算——坏值状态下 InTouch 也会显示一个数，那是上次的残留或者默认值。这一步通过之后，再把测试标记名换成实际的工艺点位，批量导进去。

三条链路都过完，我会做一份简单的验证记录：验证时间、验证人、每条链路的验证结果、当时的关键参数快照。这份记录不是给谁看的，是为了两周后出问题时能对照——是当时就没通，还是当时通了后来变的。有过一次教训，交付一周后现场说数据不准，翻记录发现当时验证的就是那个点位，参数快照一比对，是对方在 PLC 里改了 DB 块地址，跟我这套环境无关。要是没有那份记录，这锅就得背上了。

从那以后我每次装完这套环境，都强制走一遍"本机通、跨机通、InTouch 通"的三步验证，哪怕现场催得再急也不跳过。这套流程多花二十分钟，能挡掉后面几天的扯皮。希望帮到你。

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