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以太网直连、报文简单、易抓包调试、多客户端无地址语义靠文档约定点位中等、局域网稳定Modbus RTU硬件成本低、抗干扰好、老设备通吃速率低、需处理帧边界、一主多从轮询慢点位少、距离远、老机型厂商私有协议功能全、能读系统块文档难拿、版本耦合、无通用工具需要深度诊断时OPC UA语义化、自带类型和安全服务端要装、配置重、客户端库体积大多设备集成、上层 MES 对接我的判断标准是设备有网口且支持 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 头加 PDUMBAP 头 7 个字节前 2 字节是事务标识接着 2 字节协议标识固定 02 字节长度表示后面还有多少字节1 字节单元标识。这个长度字段就是解决粘包的关键先读 7 字节头解析出长度再按长度精确读剩余部分。切记不要读到多少算多少TCP 是字节流一次Receive可能只给你半个报文。private async Taskbyte[] 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·mraw1 对应满量程 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。参数经验取值影响采集周期20 ms越小越细但通信压力大滑动平均窗口5~8 点窗口大平滑好但峰值被削低通时间常数 RC30~50 ms大则平滑但滞后峰值保持判定连续上升后回落 3%防止噪声被误判为峰值这里有个必须讲清楚的原则滤波只用于显示和趋势判断判定用的原始值要单独留一份。因为滤波必然削峰如果拿滤波后的值去判扭矩是否超过上限会出现实际超了但程序说没超的情况这在质量追溯上是致命的。我的做法是双轨一路原始值存库一路滤波值给曲线和实时显示判定时对原始值做短窗口最大值比如取 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 ListSampleRow(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 编程软件里监视到的值对比确认地址映射正确。这一步绝不能省我见过太多地址错一位查了两天的案例。第二步做写入验证先写一个不影响安全的参数比如某个显示用的阈值确认能写进去且读回来一致再考虑写工艺参数。第三步才是完整流程跑一遍观察曲线形态是否符合工艺预期。验收我列了几个硬指标达不到就不算完验收项标准检查方法通信成功率连续 8 小时 99.5%统计面板计数断线恢复拔网线后 15 s 内自动恢复手动拔插测试采样节拍抖动P95 周期 30 ms记录时间戳差值内存占用8 小时增长 50 MB任务管理器观察曲线刷新1000 点批次不卡顿目视 帧率日志数据完整性点数与理论值偏差 1%与批次时长换算比对特别说一下内存这一项。.NET 程序内存缓慢上涨几乎是必然的多数是事件没解绑、定时器没释放、大对象进了 Gen2 没回收。判断是不是真泄漏的办法很简单跑 8 小时手动触发一次GC.Collect()再看内存有没有回落到接近初始值。如果回落了说明只是分配压力大不是泄漏如果不回落就要用内存分析工具去抓快照对比了。这个判断方法不严谨但足够用来决定要不要现在停下来排查。6. 常见问题与排查技巧实录6.1 通信类问题的定位顺序通信问题占了现场问题的一大半我总结了一个从外到内的排查顺序基本能覆盖九成情况。先看物理层网口灯亮不亮、网线是不是被压、交换机是不是有人拔了。再看网络层ping通不通、延迟多少、有没有丢包如果 ping 有规律地丢包多半是网线质量或电磁干扰问题。然后看端口层用端口探测确认 502 是否可达有些现场防火墙会挡。最后才看协议层抓包看请求发出去没有、从站回没回、回的异常码是什么。这个顺序的价值在于避免一上来就怀疑代码。我遇到过好几次代码翻来覆去改最后发现是交换机的一个端口坏了。先花两分钟排除外部因素比读一小时代码划算。现象可能原因处理方式偶发超时几秒一次PLC 扫描周期长于超时阈值超时从 1 s 放宽到 2~3 s全部值都偏移寄存器地址 0 基/1 基搞错整体减 1 验证浮点数离谱字序高低字反了切换字序配置试四种组合读单个值正常批量读报异常跨越了非法地址区拆分请求避开空洞地址连接建立后立刻被断开单元标识或从站号不匹配核对从站号试 1 和 255白天正常晚上异常车间某设备启停产生干扰检查屏蔽与接地错开时段验证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质量部门直接能用。追溯这块可以给每个工件打一个码和批次关联扫码就能查到当时的完整曲线和判定依据真出了问题能快速定位到是哪一批、什么参数、什么时间。最后分享一个小技巧如果现场经常反映曲线形状不对但说不出哪里不对可以做一个模板比对功能。挑一件确认合格的产品把它的曲线存成模板之后每件都和模板做归一化后的差值比较差值超过阈值就标黄提示。这个功能实现起来不复杂但对工艺人员非常友好因为他们看图的能力比看数字强得多。这套程序的骨架其实并不复杂难的是那些不起眼的细节地址偏移一位、浮点字序反了、滤波把峰值削掉了、日志没记原始报文导致查不出原因。这些坑我都踩过写出来就是希望后来的人少走一遍。真要做我建议的顺序是先把模拟器写出来把通信链路调通再上真机只读验证最后才做写入和完整业务。一步都不省看着慢其实是最快的路。