倍福TcHmi上位机性能优化：异步子线程ADS通信防卡顿方案

近年来做倍福上位机开发的工程师，十有八九会撞上一个坎：TcHmi里一调用ADS通信，界面就卡死。有的项目数据量小，卡顿不明显；一旦碰上几十上百个变量实时刷新，鼠标直接变成“转圈圈”，操作按钮点了半天没反应，现场调试的血压比程序里的数据还高。这篇文章就是把我自己折腾了几个月、踩了无数坑之后沉淀下来的方案——在倍福TcHmi上位机里，用异步子线程调用ADS通信，把PLC数据稳定地推送到Web UI界面，并保证界面丝滑不卡顿、数据实时不丢失。

这篇文章适合正在维护或开发倍福TwinCAT上位机的工程师、刚接手TcHmi项目的开发人员，以及准备做设备上位机选型的技术管理者。我会把架构思路、核心代码、坑点教训、排查手段全部摊开来讲，代码可以直接抄回去改，省掉你一个月的试错时间。

1. 为什么TcHmi里直接调ADS会卡死界面？先说病根

很多人第一次接触TcHmi，以为它跟传统的WinForm/WPF上位机一个套路：界面上放个按钮，点击事件里写一段读取PLC数据的代码，等数据回来了再刷新控件。这个思路在WinForm时代没问题，但TcHmi的骨子里是Web技术——它的UI线程跑的是浏览器引擎的JavaScript，ADS通信却是跑在本地服务端的.NET进程里，两者之间隔着一层系统通信的墙。

我先用大白话拆一下整个过程。你在TcHmi里写了一个TypeScript函数，函数里调用ADS客户端去读PLC的一个变量：

// 错误示例：直接在UI逻辑里同步读ADS（必卡死） const result = TcHmi.ADS.readSymbol('MAIN.nAxisSpeed'); TcHmi.Controls.get('displaySpeed').setText(result);

这段代码的问题在于：TcHmi的UI运行在浏览器沙箱中，JavaScript执行环境是单线程的，按F12打开控制台能看到，执行到ADS读取那行时，页面会进入“阻塞等待”状态。ADS通信要跟本地服务端的端口握手、打包请求、等待PLC响应、解包返回，这整套流程少说几十毫秒，多则几百毫秒。界面上的动画、按钮点击、输入框刷新全部被这个同步调用卡住。

还有个电源层的问题是，TcHmi前端JavaScript根本不能直接发ADS报文。TcHmi对外暴露的TC3 ADS功能是异步回调风格的，而且必须经过服务端中转。新手往往把TcHmi当成一个普通上位机框架来用，写了大量同步逻辑，结果自然是一卡一顿、交互稀烂。

1.1 架构本质：其实你面对的是两个进程、三种角色

认清楚角色分工，问题就好解了。整个系统其实是这样的：

真正能直接跟PLC上的ADS端口建立连接的是TcHmi服务端进程（也就是运行TcHmi运行时的那台机器的Windows服务）。前端JavaScript只是通过TC3.1协议与服务端进行通信，间接发起ADS请求。所以，如果你在前端绑定了一个“同步读取”的函数，本质上就是在让服务端帮你去跑一次往返通信，这中间的耗时被前端无限放大。

1.2 为什么“异步”这个关键词是唯一正解

知道了卡顿根因，解决思路就清晰了：UI线程绝对不能被任何ADS通信阻塞。要么你让ADS调用在服务端异步执行，要么你在前端异步回调里处理结果，要么两者结合。而“异步子线程”这个做法，指的是在TcHmi服务端扩展中创建单独的线程或使用异步任务，让ADS的收发不干扰主线程，前台UI只管订阅结果、刷新展示。

你别小看这一步架构转换。一旦你从“同步调用、等结果”切换成“异步推送、订阅变化”，整个系统就从“你去PLC要数据”变成了“PLC数据变化了告诉你”，UI的实时性、流畅度、代码的可维护性完全不是一个量级。

2. 整体设计：前后端分离，服务端做ADS异步访问，前端做事件订阅

我最终落地的方案可以概括为三句话：前端只负责展示和交互，服务端负责ADS通信，两者通过TcHmi的扩展机制进行消息传递。下面把整个架构拆开讲。

2.1 TcHmi扩展是什么，为什么这条路最稳

TcHmi允许开发者写自己的服务端扩展（TcHmiExtension），扩展是.NET库，挂在TcHmi服务端进程里。前端可以通过内置的TcHmi.Extensions访问扩展暴露的接口。这样一个机制天然适合做ADS通信：

• 扩展运行在服务端进程中，跟ADS端口之间没有浏览器沙箱的隔离，网络IO、线程控制、数据缓存都非常自由；
• 前端通过异步消息调用扩展的功能，调用本身不阻塞，结果通过回调返回；
• 扩展可以自己管理线程和任务，比如单独开一个后台线程轮询PLC数据，再推给前端。

这比前端直连ADS的方案好在哪呢？最直观的一点：前端JS代码完全不需要关心ADS协议细节，也不用处理超时、重连、报文拆包这些问题。所有底层脏活累活都丢给服务端扩展，前端拿到的永远是整洁的数据对象。

2.2 数据流怎么走：从PLC变量到UI控件总共四跳

我画一张数据流向表给你看，每个环节的职责清清楚楚：

你在前端看到的效果就是：PLC里一个轴的实际速度变了，UI上的数字几乎同步刷新，而鼠标拖拽、按钮点击、页面切换全部不受影响。实际测试下来，在一个典型的双轴运动控制项目里，每秒上百次数据更新，页面帧率稳定在60FPS。

2.3 组件选型和技术栈清单

正式开工前，先把工具列表交底，避免你拿着旧版本折腾半天：

• 倍福 TwinCAT 3（我这边是3.1.4024版本，构建环境用的VS2019）；
• TcHmi 1.12版本以上（旧版本的事件机制和扩展接口有差异，后面代码建议基于1.12+）；
• Visual Studio 2019/2022，用来编译服务端扩展的C#工程；
• TwinCAT ADS库（TwinCAT.Ads，NuGet包版本4.4.0以上即可）；
• 前端调试建议直接用浏览器F12控制台，TcHmi自带了不少诊断输出。

这套组合的好处是，所有组件都是倍福官方生态内的，不用额外引第三方库，后续升级维护不容易踩雷。

3. 服务端扩展实现：ADS异步读取与子线程管理，逐行讲透

这个环节是整个方案的灵魂，也是代码量最大的部分。我会把关键代码片段拆开讲，你可以直接抄。

3.1 创建TcHmi扩展工程

在Visual Studio中新建类库项目，添加以下NuGet包引用：

• TwinCAT.Ads（负责ADS通信）
• TcHmiSrv（TcHmi服务端框架）

设置项目输出路径到TcHmi的扩展目录，然后在PackageDefinitions目录里配置清单文件，把NAME、VERSION、DEPENDENCIES填对。这个环节里的坑点主要是：清单文件里的名称必须跟项目程序集名称完全一致，否则TcHmi加载扩展时会静默失败，前端调用Extension接口报“未找到”，而服务端日志里又没任何错误。

3.2 服务端扩展的核心类设计

先看主体结构：

public class AdsExt : ITcHmiExtension { private AdsClient _adsClient; private readonly object _lockObj = new object(); private CancellationTokenSource _cts; private Task _pollingTask; private uint _lastErrorCode; // TcHmi框架依赖注入的构造 public AdsExt(TcHmiSrvHost host, string extensionName) { Host = host; ExtensionName = extensionName; } public TcHmiSrvHost Host { get; } public string ExtensionName { get; } public void Initialize() { _adsClient = new AdsClient(); _adsClient.Connect("192.168.0.1", 851); // 连接PLC的ADS端口 _cts = new CancellationTokenSource(); _pollingTask = Task.Run(() => PollingLoop(_cts.Token)); } public void Dispose() { _cts?.Cancel(); _pollingTask?.Wait(2000); _adsClient?.Dispose(); } }

重点解释两个地方：

Init和Dispose是TcHmi服务端在启停扩展时自动调用的。在Init里我做了两件事：连接ADS端口、启动轮询任务。轮询任务就是一个典型的异步子线程——后台持续跑，不占用UI线程。在Dispose里做清理，取消任务并释放ADS连接。如果你在多个页面间切换或者服务端重启，这里的生命周期处理一定要严谨，不然会出现“扩展已释放但线程还在跑”的内存泄漏。

线程锁_lockObj用在哪？如果多个前端消息同时触发扩展的方法，比如两个页面都在请求读取同一个变量，ADS客户端会同时被调用。ADS客户端本身不是线程安全的，我给它加锁，保证任何时刻只有一个线程在发送请求。这一行锁可以避免绝大多数“偶发性的ADS端口异常断开”问题。

3.3 轮询子线程：数据的生产者

后台轮询是整个数据流的起点。我的实现方式是每10毫秒读一次关键变量组，用异步方式防止阻塞：

private async Task PollingLoop(CancellationToken token) { uint[] symbols = new uint[] { 0x1000, 0x1001, 0x1002 }; // 关键变量句柄列表 while (!token.IsCancellationRequested) { try { Dictionary<string, object> values = new Dictionary<string, object>(); lock (_lockObj) { foreach (uint symbol in symbols) { object value = ReadAdsValue(symbol); values["Sym" + symbol.ToString("X")] = value; } } // 把读取到的数据广播到前端 Host.RaiseExtensionEvent(ExtensionName, "DataUpdated", values); } catch (Exception ex) { // 单次异常不打断轮询，只打日志 Host.WriteLog(TcHmiLogLevel.Error, $"Poll loop error: {ex.Message}"); } await Task.Delay(10, token); // 10ms周期 } }

这里有一个细节值得你后面调试时关注：轮询周期怎么定？如果PLC的循环周期是5ms，你轮询周期设10ms会造成部分数据更新丢失；如果PLC周期是50ms，你轮询周期设10ms则大部分时间是空转。我的建议是先看PLC任务周期，然后IPC通信的频率大约取任务周期的两倍，既不会丢数据，也不浪费CPU。对于大多数运动控制场景，10到20ms足够。

读具体值的函数：

private object ReadAdsValue(uint symbolHandle) { // 根据句柄读取变量值，返回object // 这里用ReadAny还是需要根据变量类型来区分 // 为了性能，用缓存句柄的方式避免每次都去解析符号名 }

注意：我在初始化阶段一次性拿到了符号句柄，轮询循环里直接按句柄读取，不再去解析符号名。如果每次读都走ReadSymbol去查名字，性能会差很多。这个优化在变量多的时候差异特别明显——实测300个变量轮询，用句柄比用名字快好几倍。

3.4 服务端暴露给前端的方法

前端需要能主动请求扩展执行一些操作，比如“启动轮询”、“暂停轮询”、“读取某个指定变量”。这些方法通过TcHmi扩展机制暴露。

[Obsolete("Keep for backward compatibility")] protected void RemoveObsoleteImplementation() { // 保留占位，实际开发时可以用Flux/Json接口 } public void MyMethod(string methodName, object parameters) { // 具体实现 }

这里要说明的是，TcHmi前端调用扩展方法时，走的是CallExtensionMethod通用接口。你需要在扩展类上暴露一个统一入口，根据参数里的methodName分发到不同的内部方法：

public void HandleMessage(string methodName, object parameters, TcHmiExtensionAsyncMsg asyncMsg) { switch (methodName) { case "StartPolling": StartPolling(); break; case "StopPolling": StopPolling(); break; case "ReadVariable": string name = (string)parameters; var value = ReadSingleVariable(name); // 回调结果给前端 asyncMsg.Result = value; break; } }

调用路径为：前端JS写TcHmi.Extensions.CallExtensionMethod("AdsExt", "ReadVariable", { name: "MAIN.nAxisPos" }, callback)。为了让前端能拿回结果，我统一把方法的执行结果挂到asyncMsg.Result上，TcHmi框架会自动把结果回传给前端回调函数。这个环节特别容易踩坑的是：在服务端方法里不能直接依赖前端传入的对象状态，你永远要假设前端可能传null、空对象或者类型不对的参数，服务端要做健壮性校验，否则一个脏数据就能把扩展进程打崩。

3.5 数据推送到UI的两种路径

既然做了异步架构，前端UI的更新就不能再用“前端主动去拿”的方式。我封装了两种推送路径，分别适用不同场景：

路径A：服务端主动广播（事件推送）

轮询循环里每次读到数据，就调用Host.RaiseExtensionEvent把整个数据包推送到前端。前端在TcHmi初始化时注册事件监听：

TcHmi.EventProvider.registerExtensionEvent('AdsExt', 'DataUpdated', (sender, args) => { const data = args.data; // 更新多个控件 TcHmi.Controls.get('displaySpeed').setText(data['Sym1000']); TcHmi.Controls.get('displayPos').setText(data['Sym1001']); });

这条路径适合需要实时刷新的场景，比如轴速度、电流、温度、位置曲线这类动态变化的数值。用这种事件推送的方式，前端不会发出任何ADS请求，服务端每10ms往浏览器推一次数据，浏览器都能轻松接住。

路径B：前端主动查询（异步请求）

某些操作型场景，比如“点击按钮读取当前配方的某个参数”，前端每次触发的时候需要一次明确的结果返回。我用的方式是：

async function readOneVariableAsync(name: string): Promise<number> { return new Promise<number>((resolve, reject) => { TcHmi.Extensions.CallExtensionMethod('AdsExt', 'ReadVariable', { name }, (result) => { resolve(result as number); }, (error) => { reject(error); }); }); }

因为CallExtensionMethod本身是异步回调式，所以前端根本不会卡UI。我把这个函数封装成Promise，再配合await语法，写代码的体验几乎同步，但底层全是异步的。这个封装手法建议你尽早用上，后面所有需要“一次性读取”的地方都用它，代码整洁度会高一个档次。

3.6 变量类型映射的处理细节

不要忽视ADS数据类型的映射问题。PLC侧的INT、DINT、REAL、STRING、BOOL、数组、结构体，到了C#侧是不同对象。实际开发中我总结了一套映射关系，方便你对照：

有一个我踩过的大坑：PLC侧的STRING在ADS里是固定长度数组，尾部可能有大量的空白字符。如果你直接用读取结果去比较，比如判断“配方名是否等于abc”，大概率永远不相等。处理方式是在服务端把字符串Trim掉空白再推给前端。这个细节我建议写进项目的公共函数里，让所有字符串统一走这个净化流程。

4. 前端UI异步刷新：控件绑定与事件注册的完整实现

服务端解决了“数据怎么来”的问题，前端还得解决“数据怎么展示”的问题。TcHmi的UI刷新机制有几个特殊性，我给你拆开讲。

4.1 前端框架初始化与事件注册时机

很多人在页面加载时就急着注册事件监听，结果发现没反应。原因在于：TcHmi的页面加载顺序是：TcHmi框架实例Ready事件 → 控件初始化完成事件 → 用户事件监听。如果你在框架还没Ready时就注册Extension事件，事件机制可能还没完成绑定，后面的广播自然接收不到。

我的建议是把注册代码放在TcHmi框架就绪回调里：

TcHmi.addEventListener('Ready', () => { // 注册扩展数据推送事件 TcHmi.EventProvider.registerExtensionEvent('AdsExt', 'DataUpdated', onDataUpdated); // 注册按钮点击等交互事件 TcHmi.Controls.get('btnReadPos').addEventListener('click', onClickReadPos); });

还有一个我常做的操作：页面关闭（切换View）时移除事件监听，避免内存泄漏和重复触发。TcHmi的页面路由不会主动帮你清理事件，重复注册会导致同一个数据包刷新控件两次，界面上数字闪烁变快，典型特征就是“数据更新变快了一倍”，其实是监听了两遍。

4.2 数据更新频率与控件的“节流”处理

这里想讲一个经验丰富的老开发才会注意的问题：后端推数据的频率往往是固定的，但前端渲染性能不是无限的。当每秒推送数据量超过30~60次时，即便UI线程不阻塞，浏览器渲染阶段也可能出现掉帧。

解决手段是做“节流”。我在前端数据处理逻辑里加了一个时间窗口：

let lastRenderTime = 0; const RENDER_INTERVAL_MS = 50; // 每50ms最多刷新一次 function onDataUpdated(sender, args) { const now = Date.now(); if (now - lastRenderTime < RENDER_INTERVAL_MS) { pendingData = args.data; // 缓存最新数据 return; } lastRenderTime = now; renderData(args.data); }

这样即使后端每秒推送100次，前端最多每50ms重绘一次，既保证了视觉上的实时性，又大大降低了UI开销。对曲线、柱状图这类控件来说，这个策略尤为重要，否则你会看到图表控件CPU占用率飙到100%。

4.3 数值格式化与显示经验

ADS传过来的原始数值，直接往控件里塞往往是灾难。我举个例子：PLC返回的轴位置是一个double类型的绝对位置编码器原始值，比如123456.789，你直接setText，界面上显示一长串小数，既难看又影响操作人员读数。

我的格式化方案是：

function formatAxesValue(rawValue: number, decimals: number = 2, unit: string = ''): string { return `${rawValue.toFixed(decimals)}${unit}`; }

如果是角度、温度这类带单位的量，我会维护一个变量映射表，在UI层统一格式化。同时，负数的处理、零值消除抖动（比如死区范围内显示为0），都建议在前端做一个统一的数据清洗层。这个清洗层通常是普通函数，不引入额外依赖，代码维护起来也直观。

4.4 按钮交互与异步调用的配合写法

操作型按钮在异步架构下有一个需要注意的体验细节：用户点了按钮之后，如果ADS读取需要几秒钟，界面不能没有反馈。我推荐的做法是，在点击事件里先禁用按钮并显示“正在读取...”状态，等异步回调完成后再恢复：

async function onClickReadPos() { const btn = TcHmi.Controls.get('btnReadPos'); btn.setEnabled(false); btn.setText('读取中...'); try { const pos = await readOneVariableAsync('MAIN.nAxisPos'); TcHmi.Controls.get('displayPos').setText(formatAxesValue(pos)); } catch (err) { console.error('读取失败', err); TcHmi.Controls.get('displayStatus').setText('读取失败'); } finally { btn.setEnabled(true); btn.setText('读取位置'); } }

这段代码用到了前面的Promise封装。注意try...finally保证按钮一定恢复，不然一旦ADS超时，按钮就永远是灰色的，现场操作人员会误认为程序已经死了。真实项目里这个场景出现过好多次，都是这种细节没有处理好。

5. 常见问题与排查技巧实录：踩过的坑都给你列出来了

实话讲，架构再好，实操中总有千奇百怪的问题。我把自己和同事们在实际项目中遇到的典型问题、定位方法和解决手段整理成了一张速查表。你照着这个表排查，大概率能少走很多冤枉路。

5.1 典型问题速查表

5.2 打开日志诊断的正确方式

排查TcHmi问题时，首先要确认日志环境。TcHmi服务端的管理视图里有诊断日志，能输出扩展加载、错误、警告这些信息。我在扩展里特意加了两类日志：

• 信息日志：扩展启动、停止、连接PLC成功、重连事件；
• 错误日志：ADS异常、读取超时、消息解析失败、轮询循环异常。

排查时先看错误日志有没有周期性规律。比如：如果错误日志每隔几秒报一次ADS Error 1797，基本可以判断是超时或者变量句柄失效；如果报ADS Error 715，往往是PLC程序处于运行态但数据区未就绪。这类的错误码都有对应的官方文档说明，建议你收藏一份。

5.3 一定要加的健壮性手段

开发到后期，我逐渐给自己立了几条规矩，每条都是从教训里提炼出来的：

第一，所有ADS调用必须包围try/catch，而且单次失败不能拖垮整个轮询线程。如果循环里某一次读取异常就直接抛出，线程就可能退出，后续所有数据推送全部停止，而且没有任何日志提示。这个bug最可怕的地方在于：它不报错、不崩溃，只是静默地停止推送，前端看起来就像“数据不动了”，排查起来非常费劲。

第二，重连机制不能省。PLC的ADS服务有时会因为控制器重启、程序下载、路由变化而临时中断。我的扩展在每次ADS异常后都会尝试重连，重连间隔从1秒开始指数退避，重连成功后自动恢复轮询。这个设计让整个系统几乎不会出现“需重启上位机才能恢复”的尴尬状况。

第三，前端异步请求必须设置超时。如果你不加超时，ADS调用一旦卡住，前端的Promise就会一直挂着，回调永远不触发，按钮永远处于“读取中...”状态。我给每次CallExtensionMethod调用外面包了一层超时控制，超时后直接走错误分支。这样用户至少能知道“读取超时”，而不是傻等。

5.4 一个典型的实战修复实录

说个实际案例。某项目在调试时发现：UI刷新曲线图时，只要鼠标在界面上快速移动，图表就明显卡顿，CPU占用到了70%。我第一反应是前端渲染性能问题，但后来抓日志发现，扩展每10ms往前端推的数据包里，包含了5个字符串参数，每个字符串都有几十个字符。前端每次刷新都要做字符串拼接、DOM更新，再加上鼠标移动事件重绘，浏览器彻底扛不住了。

解决方案是：减小数据包的体积——把字符串参数改成了枚举整数，前端再做一次映射翻译成文本；同时把轮询周期从10ms放宽到20ms；再加上节流。CPU占用直接从70%降到15%，曲线依然流畅。这个案例告诉你，异步架构确实解决了“UI卡死”，但数据频率、数据包大小、渲染策略这三个维度的平衡，仍然需要你持续优化。

6. 写在最后的一些体会

说实话，这套方案我前前后后迭代了三轮，从最初的前端直连ADS、到服务端同步调用、最后落成现在的异步扩展架构。回头看，最值钱的经验其实不是某段代码，而是对**“数据生产、数据搬运、数据展示”三层的清晰划分**。ADS通信和数据采集在服务端子线程里安静地跑，前端只管订阅和展示，两边各司其职，系统才真正稳定下来。

最后再分享一个小技巧：调试的时候，可以在TcHmi前端控制台里输入TcHmi.Extensions查看扩展是否加载完成，然后手动调用一下：

TcHmi.Extensions.CallExtensionMethod('AdsExt', 'ReadVariable', { name: 'MAIN.nAxisPos' }, (result) => console.log('result:', result), (err) => console.error('err:', err) );

这一步能帮你快速确认“扩展通不通、ADS通不通、数据通不通”，把问题范围第一次就缩小到具体环节。我每次去现场调试都依赖这条命令，能省掉大量盲目翻日志的时间。希望这篇内容能帮你把这个卡点顺利趟过去，有别的更好的思路欢迎一起探讨。