简介面向使用Delphi 12.3的开发者源码包提供Kassl dOPC客户端工具包5.29的完整源代码用于快速搭建与OPC服务器交互的工业通信程序解决自动化设备与业务系统间的数据交换需求。压缩包共含1345个文件包括三百八十八个dcu编译单元、二百零三个hpp头文件、一百五十二个pas源程序、一百四十二个dfm窗体设计文件以及res资源与bpl动态库等覆盖从界面到通信核心的完整工程结构整体大小约五十一兆字节并附有chm帮助文档与多个示例工程便于查阅与二次开发。已有133人学习下载适合具备一定Delphi基础、希望深入定制OPC通信功能的中高级开发者。由于附带全部源代码使用者可以查阅和修改底层实现按项目需要扩展OPC DA、UA等客户端能力。该版本成熟稳定借助源码级控制能够有效提升工业自动化项目的研发效率与维护灵活性对需要深度集成或特殊定制的工业项目尤为适用。1. 把 dOPC Client Toolkit 请进 Delphi 12.3一个带完整源码的 OPC DA 客户端控件到底值不值得装搞工业上位机的人对 OPC DA 应该不陌生——老设备、PLC、仪表几乎全靠它把数据送上来但 Delphi 社区里真正能打的 OPC 客户端控件一直不多。Kassl 的 dOPC Client Toolkit 是少数几个带完整源码、能让你从底层看明白 OPC DA 数据交互的控件包这次拿到的是 5.29 Full Source 版本配合 Delphi 12.3 实测可用。它不是那种装完就扔的黑匣子而是从 OPC 服务器枚举、连接、组管理到数据读写全部裸给你看的一套源码。适合这几类人正在做 SCADA 或设备数据采集的上位机工程师、被第三方商用 OPC 控件授权费劝退的团队、以及想搞懂 OPC DA 通信细节但不想去啃 C 文档的 Delphi 开发者。这套控件能解决的痛点很直接——在自己的 Delphi 程序里稳定地连上 OPC Server、批量读写几百个点位、并且遇到通信异常时能定位到具体环节而不是对着黑匣子瞎猜。2. 安装与编译dOPC 5.29 源码包装进 Delphi 12.3 的正确姿势与三个拦路问题2.1 源码包解压后先看清目录结构别急着打开 groupproj拿到压缩包解压后第一件事不是双击打开某个工程文件而是先梳理目录。5.29 Full Source 的目录结构比早先版本清晰根目录下通常包含 Source、Samples、Docs 三大块。Source 里是控件核心单元Samples 提供演示工程Docs 里的 PDF 是 Kassl 官方手册里面包含每个属性的详细用途。我一般会先把 Docs 翻一遍重点看版本更新说明——5.29 比起之前版本改了什么这是判断这套源码是否适合自己项目的关键参考。打开 Samples 里的 Demo 工程时常见一个坑不加载运行期包直接编译会报找不到 dOPC_*.bpl 的错误。这是因为工程默认勾选了 Build with runtime packages而控件还没安装成包。解决办法有两种一种是把工程选项里的运行时包关掉改成静态链接另一种是把编译好的 BPL 路径加进 IDE 库路径。实际项目里我建议静态链接——发布 exe 时省去带一堆 BPL 的麻烦部署到工控机上更省心。2.2 安装顺序先从设计期包装起dOPC 5.29 在 Delphi 12.3 里的注册细节正确的安装路径是打开 dOPC_DPK.dproj 这类设计期包工程在项目管理器里右键选择 Compile然后 Install。这里有个关键点设计期包和运行期包要分开编译顺序不能反。先编译运行期包再编译设计期包最后 Install 设计期包让控件出现在 Tool Palette 里。这套控件在 Delphi 12.3 下编译基本无障碍但有一个小地方要留意——如果系统里装了多个版本的 DelphiBPL 文件名带版本号后缀注册面板时 IDE 可能读到旧版本残留需要到 C:\Users\你的用户名\AppData\Roaming\Embarcadero\BDS\23.0\ 下清掉旧版本的环境变量缓存。安装完成验证很简单新建一个 VCL 工程在 Tool Palette 里搜索 dOPC如果能拖出 TopcClient、TopcGroup、TopcItem 三个核心组件到窗体上说明安装成功。这三个就是整套控件的骨架——Client 负责找到并连接 OPC ServerGroup 管理一组读写点位Item 代表单个数据标签。2.3 编译期常见报错Unknown type OPCITEMDEF 与 Ancient Version Mismatch编译 Samples 时最常遇到的两个报错值得单独说。第一个是 Unknown type OPCITEMDEF——这类问题几乎都是 OPC 类型声明的单元路径没有加进搜索路径。dOPC 源码里包含 KasslOPC_TLB.pas、OPC_TLB.pas 这类类型库文件需要在 Project Options 的 Search Path 里把 Source 目录加进去。如果加了还报错检查是不是编译器用了一个重名的旧文件——用 grep 搜一下 Source 下有没有重复的 OPC_TLB.pas有就从搜索路径里去掉旧目录。第二个经典报错是编译到一半提示 Version mismatch 之类常见于 Delphi 12.3 的编译器把旧版 RTTI 信息当作不兼容处理。我一般遇不到这个问题因为安装前会先确认 Source 里的头文件注释写的版本兼容范围5.29 官方标注支持到当时的最新 Delphi在 12.3 上是能直接过的。真正遇到过容器类组件版本不对的另说。3. 连接、枚举与管理把 dOPC Client 变成 OPC Server 的透明窗口3.1 枚举本机 OPC ServerTopcClient 的 UpdateOpcServerList 与 ServerClassID控件装好第一个功能要做的是枚举机器上可用的 OPC Server。这一阶段的核心是 TopcClient 组件它负责与 OPC 服务器进行连接、断开、刷新操作。把 TopcClient 拖到窗体上双击它的 ServerList 属性能弹出一个浏览框里面是系统 OPC 注册表里所有可用的服务器 ProgID——这个列表数据本质是从注册表 HKEY_CLASSES_ROOT\OPC.Server 分支读出来的。代码层面枚举动作并不需要自己操作注册表直接调用 TopcClient 的方法就能拿到服务器列表procedure TForm1.btnEnumServersClick(Sender: TObject); begin OpcClient1.UpdateOpcServerList; // 调用后 ServerList 字符串列表里就是本机注册的全部 OPC.ProgID Memo1.Lines.Assign(OpcClient1.ServerList); end;UpdateOpcServerList 这个方法是核心它会重新扫描一遍系统注册表把当前时刻的可用服务器 ProgID 更新到 ServerList 属性里。需要注意它只做枚举不做连接测试——枚举到的服务器可能当前没有启动但方法仍然会把它列入列表。参数方面没有需要额外设置的唯一常见需求是过滤比如只想显示某个厂商的服务器就自己在 ServerList 里做字符串匹配即可。另外一个实用的方法是 OPCEnum 代理dOPC 默认使用系统 OPCEnum.exe 服务完成枚举正式部署到工控机时要确认系统的 OPC 核心组件OPC Core Components已安装否则列表始终为空。3.2 多服务器连接与断开ServerClassID、Host 参数与连接状态的三种判断拿到 ProgID 列表后下一步是真正建立连接。dOPC 支持同一时刻连接多个 OPC Server——在窗体上放多个 TopcClient 实例就能做到每个实例独立维护自己的连接状态。连接代码非常简单只需要指定服务器 ProgIDprocedure TForm1.btnConnectClick(Sender: TObject); begin try OpcClient1.ServerClassID : Kepware.KEPServerEX.V6; // 在同一台机器上连接Host 留空即可远程连接要写主机名或 IP OpcClient1.Active : True; // Active 置 True 后控件内部会创建 OPC 连接并建立回调 lblState.Caption : OpcClient1.ServerStateText; except on E: Exception do Memo1.Lines.Add(连接失败: E.Message); end; end;ServerClassID 是必须指定的控件的内部实现是通过 COM 方式创建 OPC Server 实例因此 ProgID 写错会直接抛异常。Host 参数负责远程连接留空是连本机——本机连接走的是 COM 本地代理如果写成主机名或 IP则走 DCOM 远程调度涉及 Windows 的 DCOM 配置这部分坑很多下面避坑章会展开。连接后判断状态有三种方式读 ServerStateText 看服务器状态监控 OnConnect 事件确认连接建立或者直接访问 OpcClient1.Connected 属性。我一般会同时用前两种——OnConnect 触发时表示 COM 层面的连接已经建立但 OPC 数据能否读写还要等 Group 创建完成。断开连接时把 Active 置 False 即可。但要注意断开前最好把该服务器下所有 Group 全部删除否则 DCOM 远程连接会出现服务器端连接数不释放的问题——这在切换服务器再重连的场景里是必现的坑小心它占着服务器端口不放。3.3 组的本质与参数创建 TopcGroup 的 UpdateRate、DeadBand、IsActive 各管什么OPC 数据交互的最小单元不是单个点位而是组Group这是 dOPC 的架构核心。每个 TopcGroup 负责一组 Item 的捆绑操作——你可以独立控制一组点位的刷新频率、死区、激活状态。这里的设计逻辑是把一批数据变化频率差不多的点放在一个组里统一轮询比每个点单独请求效率高得多。创建组的代码在 OnConnect 事件里做最合适procedure TForm1.OpcClient1Connected(Sender: TObject); var AGroup: TopcGroup; begin AGroup : OpcClient1.AddGroup(MeterGroup); AGroup.UpdateRate : 500; // 毫秒500ms 一轮询 AGroup.DeadBand : 0; // 0 表示不做死区滤波值变就上报 AGroup.IsActive : True; // 组激活后数据流才真正开始走 AGroup.EnableTag : True; // 允许组内新增 Tag 项 end;UpdateRate 的单位是毫秒决定服务器主动上报数据的频率。这里的一个经验是不要一股脑全部设为 100ms——连接几十个点、每 100ms 刷一次是合理的配置但如果组里有几百个点数据风暴会把 CPU 打满这种情况下应把 UpdateRate 放到 1000ms 量级或按点位重要性拆多个组。DeadBand 的作用是数值滤波以百分比表示——当数值变化量超过该百分比才上报这对流量型数据意义不大但对温度、压力这类稳定模拟量是必要的能明显减少无效通知。IsActive 是组的开关置 False 后组内所有 Item 停止数据刷新相当于一键冻结。Enabling Tag 有点绕但很重要——EnableTag 为 True 时允许在运行期动态往组里增加和删除 Item这是做动态变量表排序用的。一个常见错误是想增加 Item 却发现 AddItem 方法报错回头检查 EnableTag 是不是 False这是最容易忽略的参数。4. 点位读写与数据流Item、Callback 与异步读写参数设置4.1 如何把 Item 加到 GroupHandle 与 ItemID 的一次性绑定点位的操作核心是 TopcItem 组件但 dOPC 里的 Item 不是拖到窗体上的可视组件而是通过 Group 的 AddItem 方法在运行期创建的。绑定一个点位的代码虽然短但每个参数都对应 OPC DA 规范的底层字段procedure TForm1.AddMeterItems; var AItem: TopcItem; begin AItem : OpcGroup1.AddItem(Meter_01.Value); AItem.Handle : 1; // 自定义句柄回调时用它识别点位 AItem.IsActive : True; // 激活后该点位才参与数据采集 AItem.RequestedDataType : VT_R8; // 告诉服务器按双精度浮点返回 end;AddItem 的唯一参数是 ItemID即服务器端的数据标签路径路径写法由 OPC 服务器的命名空间决定Kepware 的点位写法通常是通道.设备.标签Siemens 的 OPC 服务器则用斜杠分层需要在服务器端先确认。Handle 是自定义整型句柄不是 OPC 协议里的东西是 dOPC 为了方便你用回调事件配对点位——回调数据回来时你在 Handle 里写上自己的逻辑编号就不必拿字符串去匹配 ItemID。RequestedDataType 是告诉服务器要什么数据类型的值VT_R8 是双精度浮点VT_I4 是 32 位整数VT_BSTR 是文本——如果写错类型或请求类型与服务器不匹配一些严格实现的服务器会返回类型转换错误。4.2 同步读 vs 异步通知OnDataChange 回调的触发逻辑dOPC 支持两种读数据方式主动请求和被动接收。主动请求的代码路径也很简单调用 TopcItem 的 SyncRead 方法数据会同步返回procedure TForm1.btnSyncReadClick(Sender: TObject); var v: OleVariant; q: Word; t: TDateTime; begin OpcItem1.SyncRead(v, q, t); // v 是点位值q 是质量戳t 是时间戳 lblValue.Caption : VarToStr(v); lblQuality.Caption : Format(0x%X, [q]); lblTime.Caption : DateTimeToStr(t); end;SyncRead 一次只能同步读一个 Item如果在 UI 线程里循环几十个点同步读界面会卡的严重。这是因为 SyncRead 是阻塞调用每个点位都要走一次 COM 请求-响应往返。所以我一般在大量点位场景下优先用异步通知——dOPC 通过 OnDataChange 回调自动推送变化数据不需要自己循环请求procedure TForm1.OpcGroup1DataChange(Sender: TObject; Item: TopcItem; Value: OleVariant; Quality: Word; Time: TDateTime); begin // 这个事件在后台线程触发不要在这里直接更新 UI 控件 case Item.Handle of 1: FVoltage : Value; 2: FCurrent : Value; end; end;OnDataChange 是组的回调事件组的 UpdateRate 决定数据变化多久聚合上报一次。需要注意的关键点是回调线程——dOPC 的实现里这个事件在 OPC 服务器的回调线程上触发直接在这里写主界面 Label 的 Caption 大概率会闪退或卡死正确做法是把数据放进内部缓冲再用 TTimer 或 PostMessage 切回主线程刷新界面。之前有同事没意识到这点回调里直接改界面 Caption结果程序在数据刷新频率跑高时直接闪退亏得这源码全开源翻到回调实现才把问题定位到线程上。4.3 写数据到服务器SyncWrite 的参数顺序与数据类型转换写数据的过程比读数据要小心参数顺序写错会直接拿到类型不匹配的错误。TopcItem 的 SyncWrite 方法签名里参数只有一个 Variant 值但内部会按 Item 创建时的 RequestedDataType 做转换procedure TForm1.btnWriteValueClick(Sender: TObject); var val: OleVariant; begin // 从界面上拿到字符串但按 VT_R8 类型写下去 val : StrToFloat(edtValue.Text); OpcItem1.SyncWrite(val); end;这里的一个原则是写入值的数据类型必须与创建 Item 时的 RequestedDataType 对应或者至少能隐式转换。比如建 Item 时指定了 VT_R8却传一个字符串进去有的服务器会接受并转换有的会返回类型错误。安全做法是写之前用 VarType 检查一下值类型或者干脆统一用 StrToFloat/Int 转换后再赋值。另一个注意点是SyncWrite 是同步操作写几十个点位时同样会出现界面阻塞问题——如果需要连续写大量点位用异步写AsyncWrite更合适dOPC 同样提供了对应的异步写方法和回调。5. 把数据落进 SQLite 的完整套路从回调缓冲到批量入库的实现5.1 为什么不能在 OnDataChange 里直接写数据库写库并发的真实代价把点位数据落库是典型的上位机需求但直接在 OnDataChange 回调里执行 SQL 插入是最常见的翻车现场。原因有两层一是回调在 OPC 通信线程里执行写 SQLite 时要获取锁、写文件、刷盘一条插入可能耗时几十毫秒UpdateRate 达到 100ms 时线程会被拖死OPC 通信直接超时二是 OPC Server 的上报有突发性——几十个点同时变化那一下回调会在极短时间内被连续触发在回调里同步写库等于把数据库写操作变成了整个通信的瓶颈。正确做法是引入缓冲队列回调只把数据放进队列由独立线程批量取走去写库。“回调做轻的事、线程做重的事”这条原则在 OPC 通信和数据库处理之间是一条必须画清楚的边界。5.2 队列缓冲 定时批量写FDataQueue 与批量 Insert 的实现我自己的落库结构很朴素效果也最稳定一个 TThreadList 做缓冲一个 TTimer 每 500ms 取一批数据事务批量插入。这样每秒只做两次批量写数据库压力和通信线程的负载能有效降低。// 回调节点里只做入队 procedure TForm1.OpcGroup1DataChange(Sender: TObject; Item: TopcItem; Value: OleVariant; Quality: Word; Time: TDateTime); var Rec: TMeterRecord; begin Rec.ItemID : Item.ItemID; Rec.Value : Double(Value); Rec.Quality : Quality; Rec.TimeStamp : Time; FDataQueue.Add(Rec); // TThreadList 的内部实现带有锁并发安全 end; // 定时器每 500ms 触发一次批量写库 procedure TForm1.tmrFlushTimer(Sender: TObject); var L: TList; i: Integer; SQL: string; begin L : FDataQueue.LockList; try if L.Count 0 then Exit; FDBSQLite.ExecSQL(BEGIN TRANSACTION); try for i : 0 to L.Count - 1 do begin SQL : Format(INSERT INTO meter_data(itemid, val, quality, ts) VALUES (%s, %f, %d, %s), [TMeterRecord(L[i]).ItemID, TMeterRecord(L[i]).Value, TMeterRecord(L[i]).Quality, FormatDateTime(yyyy-mm-dd hh:nn:ss.zzz, TMeterRecord(L[i]).TimeStamp)]); FDBSQLite.ExecSQL(SQL); end; FDBSQLite.ExecSQL(COMMIT); except FDBSQLite.ExecSQL(ROLLBACK); raise; end; finally FDataQueue.UnlockList; L.Clear; // 清掉已落库的缓冲数据 end; end;队列设计的经验是——FDataQueue 用 TThreadList 而不是自己加锁的 TList是因为它自带临界区操作不必自己写 Enter/Leave 的同步代码。格式化成 SQL 字符串再 ExecSQL 这种直接在代码里拼接 SQL 的写法仅适合本地 SQLite 且点位值全部是可信数字的场景因为这里没有用户输入避免了注入风险。如果用的是 PostgreSQL 或 MySQL推荐升级成参数化 SQL——否则拼接时还要处理字符串转义相当繁琐。每个批次取完后 Clear 也很重要不然队列会在内存里不断积压旧值长时间运行内存只增不减。5.3 数据断档处理Quality 戳校验与坏值过滤OPC DA 的质量戳是判断数据是否可信的唯一标准落库前不做质量过滤会导致数据库里混进一堆错误值。Quality 是 16 位的 Word高 6 位表示质量状态常见的三种是 192好、64坏、0通信失败。质量值不是 192 的数据直接丢掉比存进去更干净。const QUALITY_GOOD 192; if (Quality and $C0) QUALITY_GOOD then Exit; // 非好质量直接丢弃不进入缓冲队列前 6 位过滤的常见误区是直接比较整个 Quality 值——OPC 协议中低位还包含限制状态位比如 192 与 194 都是好质量但 192 表示未限制、194 表示高限直接判断等值会把正常的高限数据也过滤掉。用掩码取高 6 位再比较是协议层面对的做法。补充一个经验数值为 NaN 或无限大也是坏数据的典型场景——OPC 服务器在模拟量断线时会输出一个极大值代表溢出这种值质量戳通常是好但数据本身是假的需要用 Float 的最大值范围做二次过滤双保险。6. 避坑指南dOPC 5.29 在真实项目中容易踩的六个坑6.1 回调里更新 UI 控件导致闪退现象程序跑起来后数据刷新频率一高就闪退报错位置还经常不固定一顿排查发现堆栈停在界面刷新相关代码。原因OnDataChange 是在 OPC 通信线程里触发的直接在这个线程里操作 VCL 主线程的控件违背了 VCL 的线程模型等于在通信线程里做非线程安全的操作。解决回调里只做数据入队或存入内部变量界面刷新统一通过 TTimer 在 UI 线程轮询完成。从那以后我每写一个 dOPC 项目强制走这个流程不再出现这种情况。6.2 远程 OPC 连不上本机却正常现象同一套代码连本机 OPC Server 一条就通换成 IP 远程连接要么超时要么拒绝访问。原因DCOM 远程连接的权限配置没到位——OPC 的远程访问依赖 Windows DCOM 组件权限默认配置下远程调用会被拒绝。解决在 OPC Server 所在机器上运行 dcomcnfg找到对应服务器组件的属性把访问权限和启动权限里的 Everyone 加进去然后在“标识”里选“交互式用户”或指定账号。这是几乎所有 OPC 远程连接失败的通用解法。6.3 枚举不到任何 OPC Server现象UpdateOpcServerList 执行后 ServerList 是空的但机器上明明装了好几个 OPC Server。原因系统缺少 OPC Core Components 或 OPCEnum 服务被禁用。OPC 枚举依赖 Windows 服务 OPCEnum该服务停用或损坏时枚举接口返回空列表。解决去 OPC 基金会官网下载 OPC Core Components 安装安装完成后检查服务列表中 OPCEnum 是否处于自动运行状态。6.4 写入值类型不匹配报错现象写入字符串型点位时SyncWrite 抛异常报类型转换错误。原因CreateItem 时 RequestedDataType 定义成了 VT_R8写入时直接传字符串给到服务器服务器不认。解决写入前用 VarType 检查值类型或根据点位实际类型改成对应的 VT_ 枚举。如果需要同时写多类型点位按类型分组在 ItemHandle 回调分支里分别处理。6.5 组很多时 CPU 占用过高现象组创建了很多个、每个组都放了点程序运行后 CPU 占用率高达百分之三四十。原因每个组的 UpdateRate 都设成了 100ms且数据变化量大OPC 回调触发的频率远远超过了实际需要。解决按点位变化频率拆分多组——高频组设 100ms、低频组设 1000ms给模拟量组加 DeadBand 过滤微小波动。改完后同样点位规模下 CPU 占用通常能直接降一半以上。6.6 切换服务器后旧连接不释放现象程序里频繁切换 OPC Server一段时间后新的连接建立变慢甚至报超出系统资源限制。原因断开时只设置了 Active 为 False没有显式删除该服务器的 Group 和 Item。COM 层面连接没完全释放资源越积越多。解决断开前先遍历所有 Group逐个调 RemoveGroup 销毁数据组再置 Active 为 False。顺序反了会报引用计数错误所以必须严格按先组后连接的关系来收尾。7. 进阶玩法用同一套 dOPC 跑通 OPC UA 网关把 DA 老代码盘活了OPC DA 这套协议在现代工业网络里越来越难直接落地——很多新设备、新网关已经切到了 OPC UA但手里这批 Delphi 设备采集程序不能白扔。dOPC 这类的 DA 客户端能力本身没法直接支持 UA 协议但只要引入一个 DA-UA 网关层老代码就能续命很久不用重写一遍采集逻辑。做法是找一台 Windows 机器也可以用单独的工控机装上 OPC UA 网关服务端比如 Kepware 或 Softing 的 OPC DA 转 UA 产品。网关的作用是把上游 OPC UA Server 的数据映射成下游的 OPC DA 接口这样对 dOPC 来说网关暴露出来的仍是一个标准 OPC DA Server——程序里那一套连接、建组、订阅回调和写库流程完全不动只需要把 ServerClassID 改成网关的 ProgID。整个改造的工程量核心就在网关上在网关里配置好上游 UA 的端点地址、连接账户、证书然后把 DA 侧要把标签映射成与旧程序相同的 ItemID 路径。代码层面基本只改一个地方// 改造前直连原始 DA Server OpcClient1.ServerClassID : Kepware.KEPServerEX.V6; // 改造后改成网关的 DA 接口 ProgID上游变成 UA 了 OpcClient1.ServerClassID : Kepware.KEPServerEX.V6; OpcClient1.Host : 192.168.1.200; // 网关机器地址上游在哪不重要这里需要理解的一个概念是“映射关系透明”——网关上游连了什么不同类型的设备、什么型号 PLC 或传感器dOPC 完全不关心它看的只是网关呈现出来的 DA 接口。网关承担的转换任务是把 OPC UA 的证书校验、安全策略、数据模型差异全部消化掉让老客户端原地不动就能跟上新协议。网关部署完成后验证流程必须完整走一遍先看网关的 DA 接口能不能被系统枚举到再确认点位的 ItemID 与旧程序里写死的路径一致最后检查 UpdateRate 是否被网关自身的最小周期限制住了——有些网关响应慢DA 侧 100ms 的请求频率网关承接不了那就在组参数里把 UpdateRate 调大到 500ms代价是数据实时性略微降低但换来的是通信稳定。这个思路还适用于另一种场景——多个产线各自独立 OPC Server想统一汇到一个平台里。在网关里把多个 DA Server 映射成一个 UA Server老程序从不同 ServerClassID 轮询改成只连一个网关代码里多服务器断连重连的维护逻辑直接删掉一大半。从那以后我处理老站点设备升级时都会少走弯路这个思路能帮不少忙希望帮到你。本文还有配套的精品资源点击获取
