C#上位机液压压机压装监控：Modbus TCP实时采集与曲线落库

压机压装这个工序，外行看热闹，内行看曲线。同一套模具、同一批工件，压装力到没到位、扭矩有没有突然抬头、保压那几秒有没有掉压，全都藏在一条几百毫秒到几十秒的曲线里。设备自带的触摸屏通常只给你一个当前值和几个报警灯，真要追溯"这一件为什么判不合格"，往往查无实据。WCS-HY 这套 C# 上位机就是在这个背景下做出来的：它跑在工控机或办公电脑上，通过实时通信把液压压机的压力、位移、速度、扭矩等信号持续读上来，做实时显示、曲线记录、阈值报警与数据留存，顺便把工艺参数下发下去。这篇文章面向做过一点 C#、但没怎么碰过工业现场通信的开发者，也面向天天跟压机打交道、想自己搞一套监控的工艺和设备人员。我会把选型理由、通信细节、扭矩数据的换算与滤波、落库与绘图、联调验收和踩过的坑一次讲透，代码能直接抄，参数给的是常见工况下的经验值，你按自己设备手册微调即可。

1. 整体架构与选型思路拆解

1.1 为什么这套活儿适合用 C# 上位机来做

工业上位机可选的路线不少：组态软件拖控件、LabVIEW 画框图、Python 快速搭、C# 自己写。WCS-HY 这个项目最后落在 C#，不是因为语言崇拜，而是几个现实约束凑到一起的结果。第一是交付形态，现场需要的是一个能双击运行、能装在企业办公电脑上、能导出 Excel 给质量部门看的桌面程序，WinForm 或 WPF 天然合适，打包成单文件或带运行时安装包都不费劲。第二是通信与并发的处理成本，串口、TCP、定时采集、后台落库这些事在 .NET 里有成熟的原生支持，SerialPort、Socket、Task、Channel、ConcurrentQueue拿来就用，不需要额外折腾运行时。第三是调试体验，现场改一行代码、附加进程、打个断点看寄存器原始值，这套流程比很多图形化环境直接得多。

更关键的一点是"人"的因素。设备科往往有一两个会 C# 的同事，程序交付后需要能自己加个字段、改个阈值、调个曲线颜色，C# 的可读性和社区资料密度在这件事上有优势。我见过用组态软件做的同类项目，第一版两周上线很爽，第二年要加一个"按班次统计扭矩峰值"的需求，改起来比重写还难受。所以这里的选型逻辑不是"哪个技术最强"，而是"三年后谁来维护、维护成本多高"。这个判断在做任何上位机项目时都值得先问一遍。

至于界面框架，WinForm 和 WPF 我都用过。数据点少、页面简单、要快，WinForm 足够；要做高刷新率曲线、要好看、要适配不同分辨率，WPF 的渲染分离更省心。WCS-HY 属于中等复杂度，用 WinForm 加第三方图表库是性价比最高的组合，本文的代码以 WinForm 为背景，WPF 只需把控件替换掉，逻辑层一模一样。

1.2 分层拆解：通信、采集、业务、界面各管一摊

新手最容易写出来的结构是"一个 Form 里塞两千行"：按钮点击里开线程读数据，读到就直接改控件，落库也顺手写在同一个方法里。这种写法在 demo 阶段跑得挺欢，一旦现场网络抖一下、界面卡一下，问题就纠缠在一起分不清是谁的锅。WCS-HY 采用的分层很朴素，但每一层都有明确的职责边界。

这条边界一旦立住，后面所有问题都能定位：数值不动，看采集层有没有新数据；有新数据但界面不刷新，看展示层的刷新节流；界面正常但数据库没记录，看持久层的队列积压。分层不是为了"架构好看"，是为了出问题时你能在五分钟内缩小范围。现场排障最贵的是时间，不是代码量。

1.3 "实时"到底指哪个时间尺度

"实时通信"这个词特别容易被误解。有人以为要毫秒级硬实时，其实压机监控根本不需要，也做不到——Windows 不是实时操作系统，普通网卡和交换机也没有确定性调度。WCS-HY 里我把实时拆成三个尺度，各自定指标，反而清楚得多。

第一个尺度是通信往返，指一次请求到响应的耗时，正常在 5~50 ms 之间，具体取决于 PLC 扫描周期和网络状况。这个尺度上的目标是"稳定"而不是"极快"，抖动控制比平均值更重要。第二个尺度是采集节拍，也就是上位机多久取一次数。压装过程通常在 300 ms 到 30 s 之间，扭矩的上升沿可能只有几十毫秒，采样周期定在 20 ms 意味着一次 5 秒的压制能采到 250 个点，足够画出形状，也足够抓到峰值。第三个尺度是界面与落库刷新，界面 100~200 ms 刷一次眼睛就完全够用，落库可以攒 200 ms 到 1 s 批量写。把这三个尺度分开定指标，就不会犯"为了界面流畅去提高采样率"或者"为了采样率把界面刷爆"这类低级错误。

我一般会在程序里内置一个统计面板，实时显示最近 100 次通信的成功率、平均耗时、P95 耗时和当前队列积压深度。这个面板在联调阶段是救命的东西，上线后也建议保留，藏在"诊断"页里就行。

2. 通信链路搭建与协议细节

2.1 通信方式选型：三种常见路线怎么挑

工业现场能选的通信方式不外乎几类：Modbus TCP、串口 Modbus RTU、厂商私有协议、OPC UA。WCS-HY 用的是 Modbus TCP，理由很实在。

我的判断标准是：设备有网口且支持 Modbus TCP，就优先走网口，因为调试成本最低——拿个抓包工具就能看到报文，谁在什么时候发了什么一目了然。只有老设备只有 485 口时才退到 RTU，这时候就必须认真处理帧边界问题。私有协议除非甲方明确要求读系统诊断块，否则不碰，因为一旦固件升级，你的解析代码就可能全废。

还有一条经验：能用批量读就别单点读。Modbus 一次可以读连续的一段保持寄存器，把扭矩、压力、位移、状态字排在同一段地址里，一次请求全部拿回，比发四个请求快得多也稳得多。这里唯一的约束是寄存器必须连续，所以项目启动时我会先跟电控确认"能不能把这些量排到一段连续地址"，这个沟通成本远低于后期优化通信。

2.2 连接状态机与断线重连

现场网络不是机房网络。交换机被人踢掉电源、网线被叉车压断、PLC 临时重启，这些都发生过。如果程序是"连不上就弹框退出"，那基本没法用。WCS-HY 的做法是把连接做成一个显式状态机，状态变化驱动行为，而不是散落在各处的 try-catch。

状态定义很简单：Disconnected（未连接）、Connecting（连接中）、Online（正常）、Degraded（连着但错误率高）、Reconnecting（重连等待）。规则是：连续 3 次请求超时或异常，从Online落到Degraded并开始计数；再失败 2 次直接断开进入Reconnecting，按 1 s、2 s、5 s、10 s 的退避序列重试，封顶 10 s 不再拉长。退避的意义在于避免雪崩——断线瞬间如果每秒重试十次，PLC 那边的连接资源可能被占满，反而谁都连不上。

public enum LinkState { Disconnected, Connecting, Online, Degraded, Reconnecting } private readonly int[] _backoffMs = { 1000, 2000, 5000, 10000 }; private int _failCount; private int _backoffIndex; private async Task RunAsync(CancellationToken ct) { while (!ct.IsCancellationRequested) { try { State = LinkState.Connecting; await _client.ConnectAsync(_ip, _port, 2000, ct); State = LinkState.Online; _failCount = 0; _backoffIndex = 0; while (!ct.IsCancellationRequested) { var ok = await PollOnceAsync(ct); if (ok) { _failCount = 0; if (State == LinkState.Degraded) State = LinkState.Online; } else { _failCount++; if (_failCount >= 3) State = LinkState.Degraded; if (_failCount >= 5) break; // 跳出内层，走重连 } await Task.Delay(_pollIntervalMs, ct); } } catch (OperationCanceledException) { break; } catch (Exception ex) { Log.Warn($"链路异常：{ex.Message}"); } finally { _client.Close(); } State = LinkState.Reconnecting; var wait = _backoffMs[Math.Min(_backoffIndex++, _backoffMs.Length - 1)]; await Task.Delay(wait, ct); } }

这段代码里有个细节值得说：PollOnceAsync返回 false 而不是抛异常，异常在更外层统一处理。原因是"超时"和"连接被重置"在业务上是同一种失败，但在代码里表现完全不同，如果每个调用点都去 catch，代码会迅速失控。统一收敛成布尔返回值，日志里保留异常详情，逻辑就干净了。

2.3 报文收发：粘包、超时与异常码

Modbus TCP 的报文结构是 MBAP 头加 PDU，MBAP 头 7 个字节，前 2 字节是事务标识，接着 2 字节协议标识（固定 0），2 字节长度（表示后面还有多少字节），1 字节单元标识。这个长度字段就是解决粘包的关键：先读 7 字节头，解析出长度，再按长度精确读剩余部分。切记不要"读到多少算多少"，TCP 是字节流，一次Receive可能只给你半个报文。

private async Task<byte[]> ReadFrameAsync(Socket sock, CancellationToken ct) { var head = await ReadExactAsync(sock, 7, ct); // MBAP 头 int len = (head[4] << 8) | head[5]; // 剩余字节数（含单元标识） var body = await ReadExactAsync(sock, len - 1, ct); // 单元标识已在头里 var frame = new byte[7 + body.Length]; Buffer.BlockCopy(head, 0, frame, 0, 7); Buffer.BlockCopy(body, 0, frame, 7, body.Length); return frame; }

串口 RTU 就没这么友好了，它没有长度字段，靠 3.5 个字符时间的静默间隔判断帧结束。实际项目里我不用这种"等静默"的方式，而是靠固定请求长度加超时：发出去之后启动一个 200 ms 的定时器，收满预期字节数就立即解析，超时就丢弃缓冲区。这样即使有半帧残留也不会污染下一次请求。

异常码也必须处理。Modbus 的响应如果最高位是 1，说明是异常响应，后面跟一个异常码：01 非法功能、02 非法数据地址、03 非法数据值、04 从站故障。现场最常遇到的是 02——地址算错了。这里有个经典坑：设备手册上写"40001 对应扭矩"，但报文里的地址要减 1 变成 0，因为协议里是 0 基址而手册是 1 基址。我第一次接这类设备时在这上面耗了整整一个下午，所有值都是错的，最后发现整体偏移了一位。所以要养成习惯：先读一个已知值的寄存器验证地址映射，再往下做。

3. 扭矩与压力数据的处理链路

3.1 从模拟量到工程量：标定与量程换算

压机上的扭矩信号通常来自扭矩传感器，经变送器输出 4~20 mA 进 PLC 的模拟量输入模块，PLC 内部再换算成一个整数码值。上位机拿到的就是这个码值，必须自己再换算成牛顿米。这一步做错，后面所有曲线和判定都是错的，所以我把它当成整个项目的地基。

常见模拟量模块把 4~20 mA 映射成 5530~27648（不同模块的数值不同，以手册为准），其中 0 mA 附近会有一个负向溢出区，用来判断断线。换算用两点线性：

// 两点标定：raw0 对应 0 N·m，raw1 对应满量程 rangeNm public double RawToTorque(int raw) { if (raw < _rawMin) return double.NaN; // 断线或溢出，返回无效 double ratio = (raw - _raw0) / (double)(_raw1 - _raw0); return ratio * _rangeNm; }

_raw0和_raw1不该是拍脑袋填的，要做实际标定。流程是：压机空载，记下此时的码值作为零点_raw0；然后用标准扭矩仪或者挂标准砝码的杠杆，加载到一个已知扭矩值，记下码值作为_raw1。两点定一条直线，中间的线性度由传感器保证。如果现场条件不允许加载，退而求其次用变送器的标称量程算，但一定要在程序里留一个"标定"按钮，让设备科以后能自己校。

还有一个高频陷阱：32 位浮点数的字序。有些 PLC 把 float 拆成两个 16 位寄存器，高位在前还是低位在前，各家不同，甚至同一家的不同型号也不同。表现就是读出来的值荒谬得离谱，比如 1.2 变成 8.6e-41 这种。解决办法不是猜，是做个"字序切换"的下拉框，四种组合（AB、BA、ABCD、CDAB）都试一遍，哪个出来正常值就用哪个，然后写进配置。这个功能看着丑，但能省掉半天扯皮。

3.2 采样节拍与滤波：抖动是常态，别跟它较劲

扭矩信号天生就抖。液压系统的脉动、压装瞬间的冲击、变频器的干扰、甚至信号线与动力线并行敷设，都会在原始值上叠加几十个码值的噪声。直接拿原始值画曲线，看起来像心电图，工艺人员根本不认。所以滤波不是可选项，是必做项。

WCS-HY 里我用的是两级：先做滑动平均压高频噪声，再做一阶低通平滑，最后对峰值单独做保持。滑动平均窗口取 5~8 个点，窗口太大延迟就明显，压装过程只有几百毫秒，延迟 100 ms 意味着峰值会被削平，这是不可接受的。一阶低通的公式是y = a*x + (1-a)*y，其中a = dt / (RC + dt)，我一般让 RC 取 30~50 ms，换算下来 a 大约 0.3~0.5。

这里有个必须讲清楚的原则：滤波只用于显示和趋势判断，判定用的原始值要单独留一份。因为滤波必然削峰，如果拿滤波后的值去判"扭矩是否超过上限"，会出现实际超了但程序说没超的情况，这在质量追溯上是致命的。我的做法是双轨：一路原始值存库，一路滤波值给曲线和实时显示，判定时对原始值做短窗口最大值（比如取 5 个原始点的最大值）而不是平均。这个细节写出来不起眼，但它决定了你的报警可不可信。

3.3 峰值、保压均值与工艺判定

压装工艺的判定通常不只一个数。以常见的一段压装为例，至少要看四个特征：峰值扭矩（整个过程中最大扭矩）、保压段均值（保压开始到结束的平均扭矩）、上升斜率（从接触工件到峰值的平均增速）、位移-扭矩关系（同一位置扭矩是否异常偏高，往往意味着工件尺寸超差或异物）。这四个特征构成了一个判定向量，比单看峰值可靠得多。

实现上我会定义一个工艺状态机，用位移或压力的突变来划分阶段：压下前是Idle，检测到压力超过接触阈值进入Pressing，位移到达设定值进入Holding，保压时间到进入Release，压力回落到阈值以下进入Done。每个阶段只负责收集本阶段的统计量，阶段切换时把结果打包成一个批次对象。状态机的好处是任何一个阶段出问题都能单独定位，而不是面对一条混沌的曲线猜。

public void OnSample(double torque, double pos, double press, long ts) { switch (_phase) { case Phase.Idle: if (press > _contactPress) { _phase = Phase.Pressing; _batch.StartTs = ts; } break; case Phase.Pressing: _batch.PeakTorque = Math.Max(_batch.PeakTorque, torque); if (pos >= _targetPos) { _phase = Phase.Holding; _holdAcc.Clear(); } break; case Phase.Holding: _holdAcc.Add(torque); if (ts - _holdStartTs > _holdMs) { _batch.HoldAvg = _holdAcc.Average(); _phase = Phase.Release; } break; case Phase.Release: if (press < _contactPress * 0.5) { _phase = Phase.Done; _batch.Judge = Judge(_batch); // 纯函数，方便单测 } break; } }

Judge写成纯函数是我坚持的一点。它只接收一个批次对象，返回合格/不合格加原因码，不碰任何界面和数据库。这样我可以在办公室用一串历史数据跑回归测试，把判定逻辑改到满意再上现场。现场调判定规则是最容易出事的时候，有单测兜底心里踏实得多。

4. 数据落库与曲线绘制的工程化处理

4.1 高频数据的内存缓冲与批量写入

先算个量。采集周期 20 ms，一次压装 10 s，就是 500 个点；如果同时存扭矩、压力、位移、速度四个量，一次 2000 个值。一天 2000 次压装，就是 400 万个值。这个量级用逐条 INSERT 写 SQLite 肯定卡，尤其是在采集线程里写，一次事务 5 ms，一天下来光写库就吃掉不少时间，还容易和采集抢资源。

做法是三级缓冲：采集线程只把数据塞进ConcurrentQueue，立刻返回；一个专门的后台写线程每 200 ms 把队列里的东西批量取出来，一个事务插完，然后清空；队列长度超过阈值（比如 5 万条）就触发告警并降级——只存特征值不存曲线点。这个降级策略很重要，宁可丢曲线也不能让内存爆掉导致程序崩溃，因为特征值才是质量追溯的核心。

private async Task WriterLoopAsync(CancellationToken ct) { var buffer = new List<SampleRow>(4096); while (!ct.IsCancellationRequested) { buffer.Clear(); while (buffer.Count < 4096 && _queue.TryDequeue(out var row)) buffer.Add(row); if (buffer.Count == 0) { await Task.Delay(200, ct); continue; } using var tran = _conn.BeginTransaction(); using var cmd = _conn.CreateCommand(); cmd.Transaction = tran; cmd.CommandText = "INSERT INTO sample(batch_id,ts,torque,press,pos,speed) VALUES(?,?,?,?,?,?)"; var p1 = cmd.Parameters.Add("@b"); var p2 = cmd.Parameters.Add("@t"); // ... 其余参数省略，重点是复用参数对象，不要每次 new foreach (var r in buffer) { p1.Value = r.BatchId; p2.Value = r.Ts; /* ... */ cmd.ExecuteNonQuery(); } tran.Commit(); await Task.Delay(200, ct); } }

这里有个容易被忽略的性能点：SqliteCommand和参数对象要复用，不要在循环里反复 new。我实测过一个版本，光这一项优化就让 10 万条写入从 40 s 降到 6 s 左右。另外索引不要建太多，sample表上batch_id一个索引足够，时间范围查询靠批次表关联，别在采样表上再建时间索引，否则写入会明显变慢。

4.2 曲线绘制的降采样与刷新节流

曲线卡顿是上位机最常见的投诉。原因通常两个：一是数据点太多，二是刷新太频繁。1000 个点画一张图完全没问题，10 万个点就必然卡。但一次压装只有几百个点，卡的原因往往是"把历史所有批次都画在同一张图上"。

解决办法分两层。第一层是只画当前批次加最近若干批次，历史曲线要按需加载，不要一次性全查。第二层是降采样，当点数超过控件宽度像素数的两三倍时，用按像素分桶取最小最大值的方式抽稀。这种方法保留了曲线的包络形状，视觉上和原始曲线几乎没区别，但点数从十万级降到千级，帧率立刻回来。

刷新节流也一样。采样线程每 20 ms 产生一个点，但界面没必要每 20 ms 重绘一次。我用一个 100 ms 的Timer或者System.Timers.Timer触发刷新，每次只把新增的点追加进去，然后让图表库做增量刷新，而不是清空重画。

private void RefreshTimer_Tick(object sender, EventArgs e) { var pending = Interlocked.Exchange(ref _pendingPoints, null); if (pending == null) return; // 批量追加，避免逐点触发重绘 _series.Points.AddRange(pending); if (_series.Points.Count > 3000) TrimByBucket(_series, 3000); _plotView.InvalidatePlot(true); // 只重绘数据，不重绘全部布局 }

InvalidatePlot(true)这个参数很关键，很多图表库有类似开关，控制是否重新计算坐标轴范围。每次全量刷新坐标轴是卡顿的主要来源之一。另外注意跨线程：所有对控件的操作必须回到 UI 线程，用Invoke或者SynchronizationContext.Post，不要在采集线程里直接改控件，那样轻则界面异常，重则直接崩。

5. 实操过程记录：从空工程到能跑

5.1 环境准备与工程骨架

开发环境用 .NET 6 或 .NET 8 的 WinForm 项目都行，后者在新机器上更省事。工程结构我习惯这样切：WcsHy.Comm（通信与协议）、WcsHy.Core（采集、换算、状态机）、WcsHy.Storage（库与导出）、WcsHy.UI（界面）、WcsHy.Simulator（模拟从站）。模拟器这个项目一定要建，后面会讲为什么它是整个项目最值钱的部分之一。

依赖尽量少。日志用 NLog 或 Serilog，数据库用 SQLite 的托管驱动，图表用 OxyPlot 或 ScottPlot 这类开源库，配置用 JSON 文件加一个简单的强类型映射。不要一上来引入依赖注入框架和 ORM，这个规模的项目用不上，反而增加新人理解成本。配置里至少要放这些项：IP、端口、从站号、寄存器地址映射表、采集周期、滤波参数、量程与标定点、判定阈值、数据库路径。把这些从代码里挪到配置，现场改参数就不用重新编译，这个便利性在调试期价值极高。

数据库表设计我建议至少三张：batch（批次主表，存起止时间、峰值、保压均值、判定结果、原因码）、sample（曲线采样点，按批次关联）、alarm（报警流水，存时间、类型、级别、处理状态）。批次主表是查询入口，采样表是大数据表，两者分开可以让"查最近 20 批次的结论"这种高频操作非常快，不用扫采样表。

5.2 关键环节：先做模拟从站，再上真机

这是我最想强调的一条经验。没有模拟器的时候，开发完全依赖现场设备：设备在跑生产，你不敢随便发写命令；设备停机了，你又没法测；网络断了，你连报错都复现不了。整个开发节奏被设备绑架。

模拟器做的事很朴素：起一个 TCP 服务端，监听 502 端口，收到 Modbus 请求就按地址表返回数据，数据用一条正弦加噪声的曲线模拟压装过程。写起来大概两三百行，但它的价值在于：你可以在办公室里把断线重连、异常码、超时、粘包这些场景全部人为制造一遍。比如让模拟器随机延迟 500 ms 返回，看你的超时逻辑对不对；让它在第 100 个请求后主动断开，看重连状态机跳不跳；让它返回一个异常码 02，看你有没有正确处理。

// 模拟器片段：收到请求后随机延迟，模拟真实工业网络的抖动 private async Task HandleClientAsync(TcpClient client) { using var stream = client.GetStream(); var buf = new byte[512]; while (true) { int n = await stream.ReadAsync(buf, 0, buf.Length); if (n <= 0) break; if (_random.Next(100) < 5) // 5% 概率超时不回 { await Task.Delay(_timeoutMs); continue; } var resp = BuildResponse(buf, n, _simulatedValues); await Task.Delay(_random.Next(2, 30)); // 模拟 2~30ms 网络与PLC延迟 await stream.WriteAsync(resp, 0, resp.Length); } }

有了这个，联调阶段就变成了"先在模拟器上跑通，再去现场只对接真实地址"。现场的时间通常很宝贵，设备停一次成本不低，把能提前做的事提前做完，是对现场人员最基本的尊重。

5.3 上机联调与验收清单

真机联调我一般按固定顺序走，不跳步。第一步只读不写，把每个需要的寄存器单独读一遍，和 PLC 编程软件里监视到的值对比，确认地址映射正确。这一步绝不能省，我见过太多"地址错一位，查了两天"的案例。第二步做写入验证，先写一个不影响安全的参数（比如某个显示用的阈值），确认能写进去且读回来一致，再考虑写工艺参数。第三步才是完整流程跑一遍，观察曲线形态是否符合工艺预期。

验收我列了几个硬指标，达不到就不算完：

特别说一下内存这一项。.NET 程序内存缓慢上涨几乎是必然的，多数是事件没解绑、定时器没释放、大对象进了 Gen2 没回收。判断是不是真泄漏的办法很简单：跑 8 小时，手动触发一次GC.Collect()，再看内存有没有回落到接近初始值。如果回落了，说明只是分配压力大，不是泄漏；如果不回落，就要用内存分析工具去抓快照对比了。这个判断方法不严谨，但足够用来决定"要不要现在停下来排查"。

6. 常见问题与排查技巧实录

6.1 通信类问题的定位顺序

通信问题占了现场问题的一大半，我总结了一个从外到内的排查顺序，基本能覆盖九成情况。先看物理层：网口灯亮不亮、网线是不是被压、交换机是不是有人拔了。再看网络层：ping通不通、延迟多少、有没有丢包，如果 ping 有规律地丢包，多半是网线质量或电磁干扰问题。然后看端口层：用端口探测确认 502 是否可达，有些现场防火墙会挡。最后才看协议层：抓包看请求发出去没有、从站回没回、回的异常码是什么。

这个顺序的价值在于避免"一上来就怀疑代码"。我遇到过好几次，代码翻来覆去改，最后发现是交换机的一个端口坏了。先花两分钟排除外部因素，比读一小时代码划算。

6.2 扭矩数据异常的三类原因

扭矩值跳动、漂移、跳变，是工艺人员最常提的问题。我把原因分成三类，对应三个方向。

第一类是信号链问题。信号线与动力线并行、屏蔽层两端接地形成地环流、变频器输出线没有屏蔽，都会让原始值带上几十个码值的噪声。处理方式是屏蔽层单端接地、信号线走独立线槽、必要时加隔离模块。这类问题的特征是"噪声幅度和某台设备的启停强相关"，观察一下就能确认。

第二类是机械与液压问题。液压油温变化会让压力波动，油液有气会让压力爬升不线性，压头与导轨间隙大也会让扭矩出现周期性波动。这类问题的特征是"噪声有规律、频率和机械动作对应"，这时候改程序没用，得让设备科去查机械和油路。

第三类是程序和参数问题。滤波参数设得太激进导致响应滞后、标定点填错导致整体偏差、采样周期不稳导致时间轴失真。这类问题的特征是"偏差是系统性的、可重复的"。我一般让现场先录一段原始数据回传，在办公室用同一段数据跑一遍程序，看结果能不能复现。能复现就是程序问题，不能复现就是现场信号问题，一下子就把范围劈开了。

6.3 界面卡顿与内存增长的实操处理

界面卡顿的处理路径很固定。先确认卡的是"绘图"还是"整个 UI 线程"。判断方法是在卡的时候点一下别的按钮，如果按钮也没反应，说明 UI 线程被占了，多半是采集或计算跑在了 UI 线程上；如果按钮有反应只是图不刷新，那就是绘图本身太重。前者要挪线程，后者要降采样加节流。

还有一个隐蔽的坑：Timer的Tick里如果做了耗时操作（比如查数据库、写文件、算大数组），事件会排队堆积。表现是程序越跑越卡，重启就好。解决方法是 Tick 里只做最短的事，把重活丢给Task.Run或者后台队列。

内存方面，最常见的三个来源是：事件订阅只加不减（尤其是静态事件，会把整个窗体的引用留住）、IDisposable对象忘了释放、以及大数组被闭包捕获。第二个最好查，把创建SerialPort、Socket、Bitmap的地方全搜一遍，看有没有using或者Dispose。第一个稍微难查，我的习惯是窗体关闭时显式解绑所有事件，宁可多写几行，也别指望 GC 帮你收拾。

提示：曲线控件里保存的历史点是最容易被忽略的内存大户。如果程序允许"一直往图上加点"，跑一天下来点数是几十万，内存和渲染都会崩。务必给每组曲线设一个点数上限，超过就按桶抽稀或直接丢弃最早的批次。

6.4 几条踩出来的经验

第一条，永远不要在采集线程里做任何可能阻塞的事。写日志、写数据库、弹框、改控件，这些都算。日志要用异步的、库要用队列的、界面要投递的。采集线程一旦卡住，采样节拍就乱了，后面所有基于时间的判断都不可信。

第二条，时间戳统一在采集侧打，不要在落库侧打。这两个时间能差几百毫秒，曲线的时间轴就对不上了。我用的是Stopwatch做高精度差值、DateTime.Now做绝对时间，两者结合，避免系统时间被调整时曲线跳变。

第三条，参数下发一定要有回读确认。写完寄存器立刻读回来比对，不一致就报警。我见过一次写参数没确认的情况，操作员以为写进去了，实际因为越界被 PLC 拒绝，结果压了一批不合格品。这个成本远高于多写两行读回代码。

第四条，给程序留一个"只读模式"。调试初期、设备检修期、或者客户还没验收的时候，只读模式能保证程序绝对不对设备产生任何影响，心里有底，客户也放心。

第五条，日志要能还原现场。原始报文、关键判断的输入输出、状态机的每次切换，都要带时间戳记下来。出问题的时候，一份好日志能顶半天现场蹲守。日志级别做成可配置，默认 Info，现场排障时开到 Debug，把原始报文也记下来，排完再关掉，避免日志文件把硬盘塞满。

7. 这套东西后续还能怎么延展

做完基础版本，能延展的方向其实挺多，而且都不需要推倒重来，因为分层立住了之后，加功能就是往里插模块。

一个是多机联网。现在是一台压机一套上位机，如果车间有十几台，可以加一个轻量的数据汇聚服务，各上位机把批次特征值上报，用一个简单的 HTTP 接口或者数据库共享就行。这样班组长在办公室就能看到所有设备的当日完成量、不合格率和报警分布。注意别把曲线点也往上送，那数据量太大，只传特征值和统计量就够了。

另一个是工艺参数配方管理。同一台压机要换不同工件，对应的压力、位移、保压时间、扭矩上下限都不一样。做成配方表，加一个下拉框选择，切换时自动下发并回读确认，能省掉大量手动改参数的出错机会。配方表放在数据库里，支持导入导出，工艺科自己就能维护。

再一个是趋势预警。单件合格不代表设备状态好，比如保压均值在慢慢往上飘，可能意味着密封件老化。把每天的均值、峰值做趋势统计，设个缓慢变化的阈值，提前预警比事后维修划算得多。这类统计不需要复杂的算法，滑动窗口加阈值比较就够了。

还有报表与追溯。把批次表按班次汇总，导出 Excel 或生成 PDF，质量部门直接能用。追溯这块可以给每个工件打一个码，和批次关联，扫码就能查到当时的完整曲线和判定依据，真出了问题能快速定位到是哪一批、什么参数、什么时间。

最后分享一个小技巧：如果现场经常反映"曲线形状不对但说不出哪里不对"，可以做一个模板比对功能。挑一件确认合格的产品，把它的曲线存成模板，之后每件都和模板做归一化后的差值比较，差值超过阈值就标黄提示。这个功能实现起来不复杂，但对工艺人员非常友好，因为他们看图的能力比看数字强得多。

这套程序的骨架其实并不复杂，难的是那些不起眼的细节：地址偏移一位、浮点字序反了、滤波把峰值削掉了、日志没记原始报文导致查不出原因。这些坑我都踩过，写出来就是希望后来的人少走一遍。真要做，我建议的顺序是：先把模拟器写出来，把通信链路调通，再上真机只读验证，最后才做写入和完整业务。一步都不省，看着慢，其实是最快的路。