简介这份资源面向使用 WinForm 开发串口称重采集功能的 .NET 开发者聚焦耀华 3190-A12E 电子秤通过 RS232 串口读取重量的实现。代码区分两种工作模式连续发送模式对应方案 2指令模式对应方案 1默认指令模式下可完成清零与读数操作并提示先用超级终端验证电子秤能否正常向电脑发送数据波特率 9600、其余参数默认即可其他品牌电子秤需参照说明书调整。压缩包共 41 个文件约 102KB以 cs 源码、resx 与 resources 资源文件、config 配置、txt 说明及编译产物为主构成可直接运行的完整 WinForm 工程。已有 2144 人学习下载适合需要快速打通串口通信与称重采集链路的开发者参考复用。1. 车间称重台前的那根串口线到底怎么把重量读进 WinForm去年帮一个做配料的小厂改称重工位操作员每天要把电子秤上的数字手抄进 Excel一天两百多笔抄错一次整批配方就废。他们的秤是耀华 3190-A12E背后一个 RS232 接口一根串口线连到工位机。需求说白了就一句话WinForm 窗体上实时显示重量点一下按钮把重量和批次号写进数据库。听起来像课后作业真上手才发现坑不少——串口参数对不上收不到数、收上来的是一串十六进制看不懂、UI 线程被阻塞直接假死。这篇就把这个「winform 读取串口电子秤重量」的完整落地过程拆开讲从 SerialPort 配置、耀华协议帧解析到界面刷新和二次开发扩展代码都能直接抄。适合手里有串口秤、想做个称重上位机的开发者新手照着能跑通熟手能直接拿去改。2. 技术选型与工程骨架WinForm SerialPort 为什么够用2.1 为什么不上第三方串口库这个场景的技术栈其实很朴素.NET Framework 4.x或 .NET 6 的 Windows 桌面运行时、WinForm、System.IO.Ports.SerialPort。有人会问要不要上什么串口通信框架我的血泪经验是——读取电子秤这种单向、低频每秒几帧到十几帧、帧长固定的场景SerialPort 自带的能力完全够多引一个库只是多一层要排查的黑匣子。SerialPort 的 DataReceived 事件在后台线程触发把字节读进缓冲区主线程只负责解析和刷 UI职责清晰。选 WinForm 而不是 WPF理由也很实际工位机配置低WinForm 启动快、控件少、部署就是一个 exe 加几个 dll现场维护的人看得懂。真要上 WPF 也不是不行但称重界面就几个 Label 和一个 DataGridView没必要。工程骨架我一般这么分ScaleReader/ ├── Forms/ │ └── MainForm.cs // 界面与事件绑定 ├── Core/ │ ├── ScalePort.cs // 串口封装打开/关闭/收字节 │ ├── FrameParser.cs // 协议解析字节流 - 重量 │ └── WeightRecord.cs // 数据模型 ├── Config/ │ └── scale.config.json // 串口参数、协议类型 └── Program.cs把串口封装和协议解析从窗体里拆出来是为了后面换秤型、换协议时不用动界面代码。这个拆分看着小题大做但等你接到第二台不同品牌的秤就懂了。2.2 串口参数怎么定波特率、数据位、校验位耀华 3190-A12E 这类计价秤的串口输出常见出厂配置是波特率 9600、8 位数据位、1 位停止位、无校验8-N-1连续发送模式。但注意不同批次、不同设置菜单里可能被改成 4800 或 19200校验位也可能被设成偶校验。所以参数不能写死必须做成可配置现场对不上就改配置重开而不是重新编译。// Core/ScalePort.cs public class ScalePort : IDisposable { private readonly SerialPort _port; public event Actionbyte[]? DataReceived; public ScalePort(string portName, int baudRate 9600, Parity parity Parity.None, int dataBits 8, StopBits stopBits StopBits.One) { _port new SerialPort(portName, baudRate, parity, dataBits, stopBits) { ReadTimeout 500, WriteTimeout 500, // 关键收到多少读多少不要等缓冲区满 ReceivedBytesThreshold 1 }; _port.DataReceived OnDataReceived; } private void OnDataReceived(object sender, SerialDataReceivedEventArgs e) { try { int n _port.BytesToRead; if (n 0) return; var buf new byte[n]; _port.Read(buf, 0, n); DataReceived?.Invoke(buf); // 抛给解析层别在这里做业务 } catch (Exception ex) { // 串口被拔、驱动异常都会走到这 Debug.WriteLine($串口读取异常: {ex.Message}); } } public void Open() _port.Open(); public void Close() { if (_port.IsOpen) _port.Close(); } public void Dispose() { _port?.Dispose(); } }逐段说下关键点。ReceivedBytesThreshold 1是让事件尽快触发默认值在某些情况下会攒一批才通知称重场景要的是实时。DataReceived里只做「读字节 抛事件」绝不做解析和 UI 更新因为它在后台线程直接碰控件会抛跨线程异常。ReadTimeout设 500ms 是防止读操作卡死虽然这里用的是BytesToRead判断但保留超时是习惯。异常捕获不能省现场工人拔线、换 USB 转串口都会让读操作抛异常不接住整个程序就崩。2.3 配置外置让现场能改参数串口名COM3 还是 COM5、波特率这些装到不同机器上都不一样。我一般用一个简单的 JSON 配置启动时读界面上再给个下拉框允许临时改。// Config/scale.config.json { portName: COM3, baudRate: 9600, parity: None, dataBits: 8, stopBits: One, protocol: YaoHua }读取用System.Text.Json或Newtonsoft.Json都行反序列化成一个ScaleConfig类。这里有个小技巧Parity、StopBits这些枚举配置里存字符串读的时候Enum.Parse比存数字可读性好得多现场维护的人改配置也不容易改错。协议类型也放配置里是为了后面接第二种秤时解析器能按类型分发而不是改代码。3. 协议解析核心把一串十六进制变成能看的重量3.1 耀华连续发送帧长什么样耀华 3190 系列在连续发送模式下常见是每帧固定若干字节帧头有标识中间是重量数值的 ASCII 或 BCD 编码末尾带校验。不同型号、不同输出格式设置下帧结构会有差异所以第一步永远是拿串口助手把原始字节抓下来看清楚再写解析。我一般让现场把秤调到连续发送用串口工具抓几十帧对比空秤、放 500g、放 2kg 三种状态帧里哪几位在变一眼就看出来了。假设抓到的帧是这种结构这是这类秤常见的形态具体以实际抓包为准帧头 0x02接着若干位重量数据ASCII 数字然后单位标识最后 0x03 结束。解析的核心就是「找帧头、取数据段、校验、转数值」。// Core/FrameParser.cs public class FrameParser { private readonly Listbyte _buffer new(); // 输入一段原始字节输出解析出的重量kg解析不出返回 null public decimal? Feed(byte[] chunk) { _buffer.AddRange(chunk); // 帧头 0x02帧尾 0x03中间是数据 int start _buffer.IndexOf(0x02); int end _buffer.IndexOf(0x03); if (start 0 || end 0 || end start) { // 数据不完整保留缓冲等下一批缓冲过长则丢弃防内存涨 if (_buffer.Count 256) _buffer.Clear(); return null; } // 取出完整帧移除已消费部分 var frame _buffer.GetRange(start, end - start 1).ToArray(); _buffer.RemoveRange(0, end 1); return ParseFrame(frame); } private decimal? ParseFrame(byte[] frame) { // 去掉帧头帧尾取中间 ASCII 数字 var payload frame.Skip(1).Take(frame.Length - 2).ToArray(); var text Encoding.ASCII.GetString(payload); // 只保留数字和小数点过滤单位字母、符号 var digits new string(text.Where(c char.IsDigit(c) || c .).ToArray()); if (decimal.TryParse(digits, out var value)) return value; return null; } }逻辑说明Feed方法设计成「喂多少处理多少」因为串口一次Read拿到的字节数不保证正好是一帧可能半帧也可能一帧半。用缓冲区累积每次找帧头帧尾凑齐一帧就解析并移除剩下的留着等下次。这是串口解析最稳的写法比「假设每次读到的就是一帧」可靠得多后者在高速或系统繁忙时必翻车。参数说明0x02/0x03是这类秤常见的 STX/ETX 帧界定符如果你的秤抓包发现是别的比如 0x3D 开头改这两个常量即可。ParseFrame里过滤非数字字符是因为帧里常混着单位kg/g和状态位直接decimal.TryParse会失败。如果你的秤输出的是 BCD 编码而非 ASCII那就要按位取半字节换算逻辑不同得先确认编码方式。3.2 校验位要不要算有些型号的帧末尾带校验和比如前面所有字节异或有些没有。抓包时如果发现最后一字节随数据变化且不符合数值规律大概率是校验。校验该算就算算不过就丢帧这是防止读到半帧错值的后悔药。异或校验的写法private bool CheckXor(byte[] frame) { // 假设最后一字节是校验前面所有字节异或 byte sum 0; for (int i 0; i frame.Length - 1; i) sum ^ frame[i]; return sum frame[^1]; }如果抓包确认没有校验位这段就别加加了反而把所有帧都判成错。判断依据只有一个抓包对比。3.3 把解析结果接到界面上解析出来的重量要显示到 Label还要处理「稳定值」的问题——秤在晃动时数值一直在跳业务上通常要等数值稳定几百毫秒才采信。我一般加一个简单的稳定判定连续 N 次解析结果差值小于阈值才认为稳定。// MainForm.cs 片段 private decimal? _lastStable; private int _stableCount; private void OnScaleData(byte[] chunk) { var weight _parser.Feed(chunk); if (weight is null) return; // 跨线程更新 UI BeginInvoke(new Action(() { lblWeight.Text weight.Value.ToString(0.000) kg; if (_lastStable.HasValue Math.Abs(weight.Value - _lastStable.Value) 0.002m) _stableCount; else _stableCount 0; _lastStable weight.Value; btnConfirm.Enabled _stableCount 5; // 稳定才允许确认 })); }BeginInvoke是 WinForm 跨线程更新控件的标准做法别用Invoke死等也别关掉跨线程检查CheckForIllegalCrossThreadCalls false图省事那是埋雷。稳定判定阈值 0.002kg 和次数 5 是经验值秤的精度和刷新率不同要调精度 1g 的秤阈值可以更小。4. 避坑与排查现场最容易翻车的五件事4.1 打开串口报「拒绝访问」现象_port.Open()抛UnauthorizedAccessException提示端口被占用。原因COM 口是独占资源串口助手没关、上一个进程没退干净、或者驱动虚拟出的口被别的软件占着。解决先确认串口助手已关闭任务管理器里看有没有残留进程必要时拔插 USB 转串口让系统重新枚举。代码里Open要包 try-catch失败给明确提示而不是崩掉。4.2 能打开但一个字节都收不到现象串口打开成功DataReceived从不触发。原因八成是参数不匹配——波特率、校验位和秤的设置不一致或者秤根本没设成连续发送模式。解决用串口助手用同样参数试助手能收到说明是代码问题收不到就是秤的设置或接线问题。RS232 还要注意 TX/RX 是否交叉、是否需要交叉线接线错了数据方向就是反的。4.3 收到的全是乱码或问号现象字节能收到转成字符串是乱码。原因编码假设错了秤发的可能是 BCD 或二进制而非 ASCII或者波特率偏差导致位错。解决先按十六进制看原始字节确认帧结构和编码方式再决定用 ASCII 还是按位解析。波特率偏差通常表现为偶发错帧而不是全乱。4.4 界面卡死、按钮点不动现象称重时窗体无响应。原因在DataReceived里直接操作控件或者解析逻辑太重阻塞了后台线程又或者用了Invoke同步等待。解决后台线程只读字节解析轻量化UI 更新一律BeginInvoke异步投递。解析里别做数据库写入这种耗时操作要写就丢到队列里由独立线程处理。4.5 数值偶尔跳一下又恢复现象重量显示偶尔出现一个明显错误的值。原因半帧被当成完整帧解析或者校验没做。解决确认缓冲区累积逻辑正确3.1 的写法就是为此有校验位的一定要校验校验不过丢帧。另外 USB 转串口在电磁干扰大的车间容易丢字节能上带隔离的转换器就上。5. 二次开发从「能读」到「能用在产线」5.1 换秤型时改哪里这套结构的好处是换秤只动FrameParser。新秤的帧结构不同就新写一个解析类实现同一个接口配置里protocol字段决定实例化哪个。我一般定义一个IFrameParser接口Feed(byte[])返回decimal?耀华一个实现别的品牌各一个实现窗体代码一行不改。这是当初拆层的回报。5.2 加数据落库和批次管理称重确认后要写库别在 UI 线程里同步写。用一个BlockingCollectionWeightRecord做生产者消费者UI 线程把记录丢进队列后台线程批量写数据库。批量写比逐条写快一个数量级产线高峰期不会卡。表结构至少要有批次号、重量、时间戳、操作员方便追溯。// 后台写库线程 private void DbWorker() { var batch new ListWeightRecord(); foreach (var rec in _queue.GetConsumingEnumerable()) { batch.Add(rec); if (batch.Count 20 || _queue.Count 0) { SaveBatch(batch); // 事务批量插入 batch.Clear(); } } }5.3 验证改造是否成功的三个动作改完别只看界面显示对了就完事。第一空秤归零、放标准砝码、取下看数值是否线性准确第二快速连续放取看稳定判定和按钮使能是否跟得上第三拔掉串口线再插回看程序是否自动恢复还是需要重启——现场拔线是常态能自动重连的版本才敢交付。我吃过一次亏交付当天工人拔了下串口程序直接白屏从那以后每次交付前都强制走一遍拔插测试重连逻辑也成了标配。希望这些能帮到你少走我踩过的那些弯路。本文还有配套的精品资源点击获取
