简介：Simple VB .NET OPC Example 是一份面向工业自动化方向开发者的入门级示例包，围绕在 VB .NET 环境中接入 OPC 技术展开，适合需要了解 OPC 客户端基本用法、或希望为自有上位机程序补充数据通信能力的初、中级开发者参考。压缩包共 38 个文件，约 194KB，包含 VB 源码、vbproj 项目与 sln 解决方案文件、OPCAutomation 互操作 DLL 及可执行程序，另有配置、资源和升级报告等辅助内容，便于直接查看项目组织与编译结果。目前已有 198 人学习。示例重点演示创建 OPC 客户端、连接服务器、浏览数据项以及读写与事件处理等基础流程，并保留备份版本与说明材料，可作为搭建 OPC 通信原型的参照模板，帮助读者快速理解 VB .NET 调用 OPC 自动化接口的代码结构和调试入口。

1. 先说人话：OPC 到底是个什么东西

车间里常见这样的场面：一台老设备只会说自家方言，新买的仪表又是另一套说法，想把温度、转速这些数字搬进电脑，光是对接就能耗掉半个月。OPC 就是给这些设备规定的一种“普通话加标准插座”：不管底下是什么牌子、什么协议，只要它支持 OPC，上位机就能用同一套写法把数据读上来、把参数写下去。而 Simple VB .NET OPC Example 这份资源，就是这套东西的最小可运行样板：一个 VB.NET 小程序，连上 OPC 服务器，读一个点、写一个点、断开。它不能让你成为高手，但能让你第一次亲眼看到数据从设备里跑进窗体。刚接触工业自动化、想做上位机又不知道从哪下手的人，最适合从这里开始。

2. 为什么值得学：一份 VB.NET OPC 例子能解决什么问题

2.1 现场真正的麻烦：十台设备十套说法

做过产线对接的人都懂那种无奈：一号工位的控制器走一种协议，二号工位的新仪表走另一种，三号工位那台用了八年的老设备连说明书都找不到了。如果每个设备都单独写一套驱动，工作量会非常大，而且随时可能返工：现场换一个品牌，你的程序就得推倒重写一遍。这就是“血泪经验”里最常见的一条，很多人第一次做数据采集都栽在这。

OPC 的价值就体现在这里。它把“怎么跟设备说话”这件事，交给一个专门的服务器程序去处理，你的程序只跟这个服务器打交道。服务器认识现场所有方言，但对外统一说普通话。于是你的代码里永远只有那么几个动作：连接、加点、读、写、断开。换设备的时候，改的是服务器的配置，不是你的代码。“换设备不改程序”这六个字，就是它最实际的吸引力。

对新手来说，这意味着学习成本可以大幅降低：你不需要先学会十种现场总线，也不需要看懂设备厂家的私有协议手册，只要搞懂一套接口，就能对接一大片设备。

2.2 为什么偏偏用 VB.NET 起步

一提到“要学就学主流语言”，很多人会被劝去啃一堆语法糖，结果两周下来连个窗口都没弹出来，热情先凉了。VB.NET 的好处恰好相反：语法接近自然语言，窗体拖几个按钮就能出来，写错一行不会满屏报红。你想验证“这个服务器到底能不能连上”，十分钟就能有个能点击界面的程序。

还有一个很现实的原因：工业现场的存量代码里，VB 风格的东西极多。很多老师傅留下的脚本、表格里的宏、老上位机里的模块，都是这种写法。你以后去维护、去改，看得懂比写得漂亮更重要。入门阶段，先用一门能快速看到结果的语言建立信心，比一上来就纠结语言优劣划算得多。

再说回 OPC 本身：这类老标准的接口是围绕组件对象模型设计的，VB.NET 调这种组件，一句创建对象的语句就够，不用写一堆包装。这一点在入门阶段特别友好：代码短，你就更容易看清“哪一步出了错”。

2.3 这份例子跑通之后，你手里有什么

跑通一个最小例子，你得到的不是一段能用一辈子的代码，而是三样更值钱的东西。第一是一副骨架：连接服务器、建一个组、把点加进去、读一次、写一次、断开，这六步就是所有数据采集程序的雏形，后面加界面、加记录、加报警，都是往这副骨架上挂东西。

第二是一套判断故障的思路。连不上，先查那个注册名写没写对；读出来是零，先看质量码；界面卡死，先想是不是在界面线程里同步读设备。有了这套思路，以后再遇到类似问题，你不会干瞪眼。

第三是一点点信心。新手最怕的不是难，是“我连第一步都迈不出去”。当你亲眼看到文本框里跳出设备上真实的数字，那种“原来就这么回事”的感觉，比看十篇原理文章都管用。

3. 动手前先弄懂三件事：服务器、ProgID 和质量码

3.1 OPC 服务器、客户端、Item：三个角色一台戏

把 OPC 想成一个仓库。OPC 服务器是仓库管理员，他手上有全部货架的清单，也知道每样东西放在哪；你的 VB.NET 程序是来提货的客户；而 Item（项）就是货架编号。你要做的，是告诉管理员“我要三号货架上的东西”，他拿给你，顺便告诉你这件货是新到的还是放了三天。

这里有个新手最容易搞错的地方：ItemID 不是你程序里起的变量名，而是服务器自己定义的一串字符串，可能是“通道1.设备1.温度”，也可能是“Device1.Tag001”，长得完全没有规律。你必须从服务器的配置工具里原样抄过来，多一个空格都不行。第一次学的时候我照着截图手打了一个 ItemID，结果大小写错了一个字母，程序不报错，就是一直返回空值，我查了大概两个小时才发现问题。

中间还夹着一个概念叫“组”。组就是一批点的集合，组上有个刷新周期，单位是毫秒。你把十个点放进同一个组，服务器就按这个周期统一更新它们。为什么要多这一层？因为真实项目里点动辄几百个，一个一个去设定更新频率不现实，按组管理才管得过来。入门例子通常只建一个组、放一个点，但你要知道这层结构是为以后准备的。

3.2 那串 ProgID 和 32 位还是 64 位：连不上的头号嫌疑

代码里那句创建对象的语句，括号里填的字符串叫 ProgID，格式一般是“厂家.产品.版本”，比如你会在注册表里看到类似“某某服务器.数据访问.1”这样的东西。它是服务器程序安装时写进系统注册表的，你的程序拿这串名字去问系统：“这个组件在哪？”系统查到了，就把它启动起来给你用。

所以“连不上”的第一嫌疑，永远是这串名字。要么你抄错了，要么服务器根本没装好，要么装的是另一个版本。查的办法很简单，不用装任何工具，一行只读的命令就能列出本机注册过的东西：

# 只读注册表，列出本机注册过的、名字里带 OPC 的 ProgID # CLSID 子键是组件注册的标志，有它才说明这是个能创建的对象 Get-ChildItem 'Registry::HKEY_CLASSES_ROOT' | Where-Object { $_.PSChildName -match 'OPC' -and (Test-Path "$($_.PSPath)\CLSID") } | Select-Object -ExpandProperty PSChildName

这段命令做三件事：遍历系统里的文件类型和组件注册区，筛出名字里带 OPC 的项，再筛掉那些没有 CLSID 子键的普通文件类型，最后只把名字打印出来。它只读不写，不会改动系统任何配置。跑完你会拿到一个列表，把其中一个原样填进代码里的常量就行。

第二个嫌疑是位数。这类老组件有 32 位和 64 位两种，而你的项目默认可能是“任意平台”，在 64 位系统上跑起来就是 64 位进程。一个 64 位进程去创建 32 位组件，系统会告诉你“类没有注册”，你明明看到注册表里有，却怎么都连不上，非常容易让人以为这是玄学。解决办法不复杂：在项目属性里把目标平台明确改成 x86，然后重新编译。

提示：遇到“明明装了却创建不了对象”，先查 ProgID，再查位数，这两步能解决入门阶段八成的连接问题，别急着怀疑服务器坏了。

3.3 读到值不算成功：Quality 和时间戳才是真相

新手最容易犯的错，是眼睛只盯着那个数值。读到一个 25.0，就以为设备温度是 25 度。实际上服务器返回给你的东西有三样：值、质量、时间戳。后两个才是判断“这个数字能不能信”的依据。

质量码是几个固定数字：192 表示好（正常），64 表示不确定，0 表示坏。你读到 0 的时候，那个值可能是上一次通信正常时留下的残影，也可能是设备根本没回数据，服务器顺手填的默认值。时间戳则告诉你这个值是什么时候采到的，一个显示当前时间、实际却是半小时前的数据，在只看数值的界面上完全看不出来。

这个坑很隐蔽，因为程序不会报错，界面也照常刷新，你会觉得一切都好，直到某天发现记录的数据对不上现场。所以从第一个例子开始，就要养成习惯：日志里同时打印值、质量和时间戳。一开始觉得啰嗦，等哪天真出问题，这三样东西就是唯一能救你的线索。

4. 第一个例子：把“读一个点”从零跑起来

4.1 开跑前的四样东西

别急着打开代码，先把环境点清楚，缺一样都会卡在半路。第一，一台装了常用桌面系统的电脑，因为这类老标准的通信机制是系统自带的，不需要额外装什么运行环境。第二，VB.NET 的集成开发环境，装的时候记得勾选桌面开发相关的组件，不然新建项目的时候连窗体模板都找不到。

第三，一个能连上的 OPC 服务器。可以是装在本机的，也可以是局域网里别人已经配好的；如果只是想试试，本机装一个带模拟数据的服务器最省事，它自己会造几个会跳动的点给你读。第四，一个确定的 ItemID 和一个确定的 ProgID，这两样必须从服务器的配置界面里抄，不要凭感觉猜。四样凑齐，你才具备“跑通”的前提，否则后面每报一个错你都会怀疑人生。

4.2 建项目、摆控件、加引用

第一步，新建一个 Windows 窗体应用（VB.NET）项目，名字随便起，比如 OpcDemo。第二步，在项目属性里把目标平台改成 x86，这一步很多人会跳过，然后在连接的时候被“类未注册”拦住。

第三步，从工具箱往窗体上拖控件：四个按钮，分别改名为 btnConnect、btnRead、btnWrite、btnDisconnect，文本写成“连接”“读取”“写入”“断开”；一个文本框 txtValue，用来显示读到的值和输入要写的值；一个列表框 lstLog，用来打日志。第四步，双击每个按钮，让开发环境自动生成事件处理函数，接下来往里填代码就行。

这里不引用任何第三方组件库，用的是后期绑定的写法，好处是换服务器不用重新编译，坏处是编译期没有智能提示，写错方法名要到运行时才报错。入门阶段这个取舍是值得的：少一层依赖，就少一个出错的地方。

4.3 核心代码：连上、读一次、写一次、断开

先写声明和连接部分。注意常量那两行必须改成你自己环境里的值，这是整个例子唯一需要你动手改的地方。

' 窗体控件：btnConnect / btnRead / btnWrite / btnDisconnect，外加 txtValue 和 lstLog Imports Microsoft.VisualBasic ' CreateObject 在这个命名空间里 Public Class MainForm ' 用 Object 做后期绑定：不提前引用任何组件库，换服务器也不用重新编译 Private opcServer As Object = Nothing Private opcGroup As Object = Nothing Private opcItem As Object = Nothing ' 下面两行换成你自己环境里的真实值，抄错一个字符都连不上 Private Const SERVER_PROG_ID As String = "你的服务器ProgID.1" Private Const ITEM_ID As String = "通道1.设备1.温度" Private Sub btnConnect_Click(sender As Object, e As EventArgs) Handles btnConnect.Click Try ' 1) 按 ProgID 创建服务器对象，这一步只查本机注册表，不碰网络 opcServer = CreateObject(SERVER_PROG_ID) ' 2) 连本机；要连远程就把节点名作为参数传进去 opcServer.Connect() ' 3) 建一个组，名字随意，刷新周期单位是毫秒 opcGroup = opcServer.OPCGroups.Add("G1") opcGroup.UpdateRate = 1000 opcGroup.IsActive = True ' 4) 往组里加一个项，第二个参数是客户句柄，自己编号就行 opcItem = opcGroup.OPCItems.AddItem(ITEM_ID, 1) Log("连接成功，项已加入") Catch ex As Exception Log("连接失败：" & ex.Message) End Try End Sub

这段代码里，第一句是按名字把服务器进程拉起来，相当于敲门；第二句是正式握手；第三句建组，刷新周期设成 1000 毫秒，意思是这个组里的数据每秒更新一次，改小会更快但更吃资源；第四句才是真正要数据，把 ItemID 挂进组里，第二个参数是客户端自己给这个点编的号，随便给个数字即可，以后可以用它来找点。整个过程包在异常处理里，因为连接失败是常态，你需要看到错误信息，而不是让程序直接崩掉。

接着写读取、写入和断开。三个动作都不长，但每一句背后都有一个容易忽略的细节。

Private Sub btnRead_Click(sender As Object, e As EventArgs) Handles btnRead.Click Try Dim value As Object = Nothing Dim quality As Object = Nothing Dim stamp As Object = Nothing ' 第一个参数：1 = 直接找设备要（慢但最新），2 = 读服务器缓存（快但可能旧） opcItem.Read(1, value, quality, stamp) txtValue.Text = If(value Is Nothing, "(空值)", value.ToString()) Log($"值={value} 质量={quality} 时间={stamp}") Catch ex As Exception Log("读取失败：" & ex.Message) End Try End Sub Private Sub btnWrite_Click(sender As Object, e As EventArgs) Handles btnWrite.Click Try ' 只有可读写的点才写得进去，只读点会直接抛异常 opcItem.Write(CDbl(txtValue.Text)) Log("写入完成") Catch ex As Exception Log("写入失败：" & ex.Message) End Try End Sub Private Sub btnDisconnect_Click(sender As Object, e As EventArgs) Handles btnDisconnect.Click Try If opcServer IsNot Nothing Then opcServer.Disconnect() opcServer = Nothing Log("已断开") Catch ex As Exception Log("断开时出错：" & ex.Message) End Try End Sub Private Sub Log(msg As String) lstLog.Items.Add($"{Now:HH:mm:ss} {msg}") End Sub End Class

读取那句的第一个参数是数据来源，填 1 表示绕过缓存直接问设备，拿到的一定是最新值，但速度慢，设备没响应时会卡一下；填 2 表示读服务器自己维护的缓存，速度快，代价是可能拿到一两秒前的数据。入门阶段先用 1，看得清楚；等以后做界面刷新，再换成 2。后面三个参数是输出参数，值、质量、时间戳都会回填，所以必须先声明成 Nothing 再传进去。

写入那句要特别注意类型转换。文本框里拿到的是字符串，直接写进去服务器可能不认，例子用 CDbl 转成数值型。如果目标点是个布尔量或者整型，你就要改成对应的转换方式，写错类型会抛异常。断开那句做了个判空，防止你还没连接就点断开，程序直接报空引用。

最后补一个日志方法，把时间戳打在每行前面。别小看这一行，排查问题的时候，有没有时间戳决定了你是能定位问题，还是只能从头再试一遍。

4.4 怎么判断自己真的跑通了

跑通的标准不是“没报错”，而是三个信号同时出现。第一，点连接之后日志里出现“连接成功”，说明名字和位数都对。第二，点读取之后文本框里出现一个数字，而且这个数字在变，说明数据是真的从设备上来的，不是初始值。第三，日志里的质量那一栏显示的是 192 那个好值，时间戳是刚刚。

三个信号缺一个，都说明你只是“看起来跑通了”。比如值有但不变，可能是读的缓存而设备本身没在跑；值在变但质量不好，说明通信时断时续，可能是网络或者权限问题。这时候回到第三章那三条线索去对：名字对不对、位数对不对、质量好不好。顺序别乱，从最简单的查起。

注意：先在按钮上手动点几次，确认每一步都正常，再去想“怎么让它自动刷新”。手动都跑不通的时候加定时器，只会让错误信息刷满屏幕，反而看不清。

5. 新手避坑：五个最常翻车的现场

5.1 报“ActiveX 部件不能创建对象”

现象很直接：一点连接，弹窗告诉你某个部件创建不了，程序停在创建对象那一行。原因通常有三种：ProgID 抄错了；服务器根本没装或者装了一半；你的项目是 64 位而组件是 32 位。新手往往只想到第一种，改了半天名字发现还是不行，其实是位数的问题。

解决办法按顺序来：先用第三章那段只读命令把本机注册的名字列出来，复制粘贴，不要手打；然后到项目属性里把目标平台改成 x86 重新编译；两招都试过还不行，就把服务器程序单独打开，看它自己能不能跑起来。如果它自己都起不来，你的代码再对也没用。

5.2 本机能连，换台机器就连不上

现象是：在自己的电脑上一切正常，拷到现场那台机器上就连接失败，错误信息还特别含糊。原因是这类老标准跨机器访问时，走的是系统自带的分布式组件机制，涉及访问身份和权限，不是你在代码里加一行就能解决的。默认配置下，匿名访问基本会被拒。

解决办法有三条路：最简单的，把程序放到服务器所在的同一台机器上跑，直接绕开跨机问题；其次，让两边用同一个账号登录，减少身份不一致带来的麻烦；最后才是去动系统里的组件权限配置，这一步建议在有经验的人指导下做，改错了会影响别的程序。

5.3 值一直是 0，或者质量是坏值

现象是连接成功、读取也不报错，但那个数字永远是 0，或者日志里质量一栏显示 0。原因是 ItemID 拼错了、目标设备没在运行、这个点压根没配置采集。服务器不会因为你要的东西不存在就报错，它会老老实实回一个坏质量和默认值。

解决办法：回服务器的配置工具里，找到那个点，看它在线的时候数值有没有在动；把 ItemID 整段复制过来，别靠记忆；再检查一下这个点是不是被设成了只读或者没启用。入门时最好先挑一个明显在跳动的点来测试，比如计数器或者时钟，别用一个常年不变的设定值来判断。

5.4 点一下按钮界面就假死

现象是点读取之后窗口卡住，拖不动，过几秒才恢复，网络差的时候卡得更久。原因是你用了同步读取，而这句代码跑在界面线程上，界面线程被占住，窗口自然就没反应了。这不是程序坏了，是写法不适合。

解决办法：入门阶段先接受这个现象，别在按钮里连点；往下走一步，把读取放进定时器或者后台线程里，界面就不会被堵住；再进一步，改用组订阅的方式，让服务器主动把变化推给你，你只管接收。这三步是循序渐进的关系，别一上来就追求最复杂的那种。

5.5 轮询太快，服务器被拖垮

现象是把刷新周期从 1000 毫秒改成 100 毫秒之后，一开始看着挺爽，过一会儿服务器响应变慢，甚至别的程序也连不上了。原因是每个点每次读取都是一次实实在在的请求，几十个点乘以每秒十次，压力全压在服务器和设备通信上。

解决办法：先问自己真的需要多快，大多数温度、液位这类量，一秒一次完全够；把点分组，重要的快一点，不重要的慢一点；能用变化推送就别用死循环轮询。这一条在实验环境里体现不出来，到了现场就是事故，早一点建立这个意识没坏处。

6. 下一步学什么：从读一个点，到做一块能看的小面板

第一个例子跑通之后，最容易犯的错是马上想去学一堆新概念，结果把刚建立的信心又弄丢了。比较稳的走法只有三步，每一步都基于你已经跑通的那点东西。

第一步，把“点一次按钮读一次”改成“自动读”。加一个定时器，间隔设成 1000 毫秒，把读取逻辑挪进去，注意判断质量好不好再显示。这一步你会第一次体会到“数据是连续流进来的”，而不是你戳一下它才动一下。

第二步，把读到的数据存下来。别小看这个动作，它让你从“看数”变成“用数”：

' 只把质量好的数据写进文件，避免把坏值当成生产记录 If Convert.ToInt32(quality) = 192 Then Dim line As String = $"{Now:yyyy-MM-dd HH:mm:ss},{ITEM_ID},{value}" IO.File.AppendAllText("D:\opc-log.csv", line & Environment.NewLine) End If

这段代码做两件事：先判断质量码是不是 192，只有好值才落盘；然后拼一行“时间、点名、数值”追加到文件末尾。用追加而不是覆盖，是因为你要的是一天下来完整的过程，不是最后一秒的快照。跑一天，用表格软件打开这个文件，你就能画出曲线了。

第三步，才是扩点。把三个五个点放进同一个组，用列表框或者表格显示出来，这时候你会发现当初那个“组”的概念终于派上用场。再往后，想接远程、想跨平台、想摆脱系统权限的麻烦，就去了解新一代的那套标准，它把原来依赖系统组件的部分换成了通用协议，学习曲线更平缓。

最后说个我自己的教训。刚开始做这类程序的时候，我图快，读到值就直接显示，从来不看质量码，结果有一次现场设备断了半天，界面上数字依然漂亮地显示着，我一口咬定是对方网络问题，折腾一下午才发现是自己程序在骗自己。从那以后我每次写这类读取逻辑，都强制先把质量码和时间戳打出来，哪怕界面上不显示，日志里也一定要有。希望帮到你。

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