简介这是一份基于 C# 的电子秤重量读取示例工程面向需要对接串口称重设备的 .NET 开发者与物联网入门学习者重点解决串口通信、委托事件接收和重量数据解析等问题。压缩包共 21 个文件以 6 个 cs 源码为核心配有 3 个 exe 可执行文件、resources/resx 界面资源、csproj/sln 项目与解决方案文件整体约 38KB结构紧凑便于直接打开调试。已有 340 人学习下载说明其作为小型实战样例具有一定参考价值。读者可从中了解 SerialPort 参数配置、DataReceived 事件注册、按设备协议提取重量数值以及把读数更新到界面或保存到数据库时需注意的线程安全思路适合用作课程设计、设备联调或二次开发的基础模板。1. 秤在跳、数是错的问题多半不在协议层产线上新上一台称重工位扫码枪插上就能用轮到电子秤就卡住了C# 里 SerialPort 打开成功DataReceived 也在触发界面上的重量却一会儿 12.34、一会儿 12.3偶尔还蹦出个 1234操作工连按三次打印出来三条不一样的记录。多数人第一反应是协议没解析对抱着说明书啃校验和改两天还是抖——真正的原因往往更靠前串口参数和物理链路没对齐或者上位机压根没定义「什么算一个有效读数」。读取电子秤重量难点不是把字节变成数字而是把一条会抖、会粘包、会掉线的字节流变成业务敢拿去打印的稳定值。下面按我拆过的几套称重上位机从接线选型、帧解析、判稳滤波讲到现场排查做收银、配料、检重、仓储称重对接的 C# 开发者都能照着走。2. 接线与选型RS232、RS485、USB 三条路怎么选2.1 物理层先定再谈代码拿到一台秤第一件事不是写代码而是翻说明书最后一页看清它到底从哪个口出数。电子秤的输出形态就那么几类选错了后面全是无用功。我在现场见过最冤的一种工程师在 C# 里写了两天串口结果那台秤是键盘口输出插上去在 Excel 里直接打字根本没有串口这回事。所以先看接口再定方案。RS232 是最常见的形态点对点一根三芯线TX、RX、GND就能通。上位机这侧基本都得靠 USB 转串口转换器因为现在的工控机和笔记本很少带原生九针口。它的标称距离是十几米但实际现场五米以上、旁边再有个变频器或者大功率电机误码率就上来了。我一般会建议秤到机柜的线不要超过三米超过就换 RS485。RS485 是差分总线抗干扰强一台转换器挂多台秤是常规操作仓库、配料线上的多工位称重基本走这条。代价是半双工发指令和收数据不能同时来代码里要处理收发切换的时序而且每台秤要有一个总线地址轮询着读。RS485 还有个经典问题是终端电阻和共地长总线两端不接匹配电阻波形反射上来前面几台好好的最后一台老是校验错。第三类是 USB 直连或者键盘口HID。前者在系统里虚拟出一个串口用法和 RS232 一样只是端口号会随着插拔变化后者是把重量当键盘输入打到焦点窗口里好处是免驱免协议坏处是焦点一切换就丢数据而且拿不到原始帧做不了追溯。小工具、临时收银可以用产线上我不推荐。还有一类带网口或者无线模块的秤本质上就是把串口数据透传成 TCP 流C# 侧换成 Socket 收字节解析逻辑一行不用改。这种方案的好处是走网线可以拉很远坏处是断线重连要自己写而且现场 IP 冲突这种事一个项目能遇上一次就够记一辈子。接口形态典型距离拓扑C# 侧接入最常见的翻车点RS2323 至 15 米点对点SerialPort转换器电平不对、没共地、线太长受干扰RS485几十到几百米总线多机SerialPort 地址轮询终端电阻缺失、收发切换时序、共地USB 虚拟串口5 米内点对点SerialPort端口号漂移、热插拔后句柄失效键盘口 HID5 米内点对点键盘钩子或 RawInput焦点丢失、拿不到原始帧以太网透传受网络限制点对点或组网TcpClientIP 冲突、断线重连、心跳缺失选型的判断顺序我一般这么走先看秤有几个口再看工位到机柜的距离然后看是不是要多台并到一个界面最后看业务要不要追溯原始数据。要追溯就必须走串口或者网口键盘口直接排除。2.2 协议形态决定代码骨架物理层通了接下来要搞清楚秤是主动说话还是等你问。这两种形态写出来的代码结构完全不同混着写后期维护会非常痛苦。第一种是连续发送。秤上电之后按固定频率往串口吐帧常见的一秒十次上位机只管收和切帧。这种最省事缺点是数据量大空闲时也在刷日志一晚上能写几百兆。做连续发送的解析核心是一个带缓冲的状态机因为 DataReceived 给你的可能是半帧也可能是一帧半。第二种是指令应答。上位机发一条命令读净重、读毛重、去皮、清零秤回一帧。这种模式必须做请求串行化同一路串口上不能两个线程同时发命令否则回来的数据对不上是谁的。我的做法是给每一路秤配一个请求队列发出去之后等回包超时就重发重发三次判离线。这里有个坑去皮的命令有的秤要求先稳定再发不稳定直接忽略上位机这边就会一直等超时看起来像通信断了。第三种是寄存器式典型是 MODBUS RTU 那一套从站地址 功能码 寄存器地址 CRC16重量放在固定的保持寄存器里。这种协议的好处是有标准可循坏处是要背寄存器表而且不同厂家的寄存器地址规划完全不一样换一台秤就得改配置。我一般会把寄存器地址、数据类型16 位整数还是 32 位浮点、小数位做成一张配置文件代码里只认配置不写死。第四种是 ASCII 文本帧形如ST,GS,0012.34kg这样一行回车换行结尾。可读性最好抓串口一眼就能看懂调试期特别舒服。缺点是帧长不固定而且有的厂家会在数值前面补空格对齐用 Split 硬切会切出一堆空串。判断自己手上这台属于哪种最快的办法是打开串口助手什么都不发看有没有数据自己冒出来有就是连续发送没有就发一条说明书上的读指令试试回了就是指令应答。两条路都不通再回头查物理层。2.3 串口参数与第一段能跑的代码参数这块没什么玄学照着说明书抄抄完再用抓包验证。真正容易出错的是几个默认值之外的东西比如 DTR 和 RTS 要不要拉高、ReceivedBytesThreshold 设多少。有些转换器或者秤端的光耦隔离电路要求 DTR 有电平才肯往外发数据这时候你把波特率核对了八遍也没用一个字节都不会来。下面这段代码只干一件事把秤吐出来的原始字节按十六进制打到控制台。别急着解析先看清它到底在说什么这一步省下来后面会加倍还回去。using System; using System.IO.Ports; // 只做一件事把秤吐出来的原始字节按十六进制打出来先看清再解析 public sealed class RawSniffer : IDisposable { private readonly SerialPort _port new SerialPort(); public RawSniffer(string portName, int baudRate) { _port.PortName portName; _port.BaudRate baudRate; // 以说明书为准常见 9600 / 19200 / 38400 _port.DataBits 8; // 少数老秤是 7 位协议表里会写 _port.Parity Parity.None; _port.StopBits StopBits.One; _port.Handshake Handshake.None; // 称重场景几乎不用硬件流控 _port.ReadTimeout 500; _port.WriteTimeout 500; _port.DtrEnable true; // 部分转换器/秤端电路不拉高就不发数据 _port.RtsEnable true; _port.ReceivedBytesThreshold 1; // 设成帧长会漏数据原因见第 5 章 _port.DataReceived OnDataReceived; } public void Start() _port.Open(); private void OnDataReceived(object sender, SerialDataReceivedEventArgs e) { try { // 一次事件里的字节数不固定必须一次读干净不能只读固定长度 int available _port.BytesToRead; if (available 0) return; byte[] buffer new byte[available]; int read _port.Read(buffer, 0, available); Console.WriteLine(${DateTime.Now:HH:mm:ss.fff} - {BitConverter.ToString(buffer, 0, read)}); } catch (TimeoutException) { // 读超时不是故障丢掉这一批继续等 } catch (InvalidOperationException) { // 串口已被关闭直接退出回调 } } public void Dispose() { _port.DataReceived - OnDataReceived; // 先摘事件再关避免关闭过程中回调重入 if (_port.IsOpen) _port.Close(); _port.Dispose(); } }逻辑很直白构造时把参数定死Start 打开端口每次 DataReceived 触发就把当前可读字节全部读出来打一行十六进制。BytesToRead是内核缓冲区里的待读字节数它会随数据到达不断变化所以不能假设每次都是完整一帧。BitConverter.ToString输出形如02-31-2D-30-30-31-32-33-34-03的字符串帧头帧尾一眼能认出来。参数上要留意的就三个。ReceivedBytesThreshold必须设 1设大了会出现「第一批数据来了后面全静默」的现象因为凑不满阈值事件就不再触发。ReadTimeout给 500 毫秒够用太短会在低波特率下频繁超时。DtrEnable和RtsEnable按需拉高拉高没有副作用不拉高可能一个字节都收不到。提示DataReceived 跑在线程池线程上不是 UI 线程。在这回调里直接改控件属性轻则界面卡顿重则抛跨线程异常而且异常还在线程池里程序可能悄无声息地挂掉。3. 帧解析定长帧、ASCII 行、校验和的三套切法3.1 三类帧结构和对策串口给你的是字节流不是消息。所谓解析就是在流里找到帧边界把一段字节认定为一条完整读数。现场见的协议基本落在三类里对策各不相同。定长帧最好处理。帧头固定一个字节常见 0x02 STX帧长固定帧尾固定常见 0x03 ETX中间带一个校验字节。收到数据后找帧头凑够固定长度就校验校验过了就是一帧不过就把帧头丢掉往前挪一个字节重新找。这套逻辑用状态机写出来不超过五十行但能扛住绝大多数噪声。带长度字段的变长帧稍微麻烦一点。帧头后面跟一个长度字节先读到长度再按长度等后续字节。难点在于长度字段本身也可能被噪声污染读出一个 200 的长度缓冲区就一直等下去。所以必须配一个等待超时比如 500 毫秒没凑齐就整段丢弃重新同步。ASCII 行帧靠分隔符切一般是\r\n。这种最简单也最容易翻车因为串口给你的可能是半行ST,GS,0012.就来了这时候切出来的内容 parse 一定失败。做法是维护一个字符串缓冲每次追加后找\r\n找到才切找不到就留着等下一批。帧类型边界识别长度控制校验方式典型坑定长二进制帧固定帧头 固定帧尾常量异或、累加和帧头出现在数据区误判带长度字段帧帧头 长度字节动态CRC16长度字段被污染死等ASCII 行帧\r\n或\n不定部分带 BCC半行、空格填充MODBUS RTU从站地址 功能码按功能码CRC163.5 字符静默间隔判断3.2 缓冲区粘包、半包与超时重同步缓冲区这块是新手最容易写崩的地方。常见的错法是每次 DataReceived 都 new 一个 byte 数组然后直接对这个数组做解析结果一帧被拆成两半两半都解析失败数据就丢了。正确做法是有一个跨事件存活的累积缓冲每次把新字节追加进去然后循环尝试从缓冲区头部取帧取不出来就跳出循环等下一批。累积缓冲有两个必须加的保护。一个是长度上限比如 4096 字节超过就丢掉最老的数据。没有这个上限遇到一台只发帧头不发帧尾的坏秤内存会一路涨到进程被杀。另一个是时间上限超过 500 毫秒没有新字节进来说明缓冲区里躺着的是残缺帧或者纯噪声直接清空重新找同步。这两个保护不加现场跑一周必出问题。还有一个细节是同步位置。找到帧头之后如果校验不过不能清空整个缓冲区只能把帧头那一个字节丢掉从下一个字节重新找。因为帧头字节有可能就出现在数据区里整段清空会连带丢掉后面真正的帧。3.3 二进制解析器状态机加异或校验下面这个解析器按「STX 8 字节净荷 异或校验 ETX」的九字节定长帧写。你手上那台秤的字段位置大概率不一样要改的只有ParseBody里的位移和符号位判断骨架可以整套搬走。using System; using System.Collections.Generic; public struct WeightFrame { public decimal Value { get; set; } public bool IsStable { get; set; } public bool IsNet { get; set; } // true净重false毛重 public int Decimals { get; set; } public DateTime Timestamp { get; set; } } // 帧约定示例[0]0x02 [1]状态位 [2..5]大端整数 [6]小数位 [7]异或 [8]0x03 public sealed class ScaleFrameParser { private const byte Stx 0x02; private const byte Etx 0x03; private const int FrameLength 9; private const int MaxBuffer 4096; private readonly Listbyte _buffer new Listbyte(512); private DateTime _lastAppend DateTime.UtcNow; public void Append(byte[] data, int count) { for (int i 0; i count; i) _buffer.Add(data[i]); _lastAppend DateTime.UtcNow; // 只增不减的缓冲就是内存泄漏超上限先丢最老的 if (_buffer.Count MaxBuffer) _buffer.RemoveRange(0, _buffer.Count - MaxBuffer); } public bool TryDequeue(out WeightFrame frame) { frame default; // 半帧保护500ms 没有新字节说明前面残留的不是真帧清掉重新同步 if (_buffer.Count 0 (DateTime.UtcNow - _lastAppend).TotalMilliseconds 500) _buffer.Clear(); while (_buffer.Count FrameLength) { int start _buffer.IndexOf(Stx); if (start 0) { _buffer.Clear(); return false; } if (start 0) _buffer.RemoveRange(0, start); // 丢掉帧头前的噪声 if (_buffer.Count FrameLength) return false; // 还没收全等下一批 if (_buffer[FrameLength - 1] ! Etx) { _buffer.RemoveAt(0); continue; } byte xor 0; for (int i 1; i FrameLength - 2; i) xor ^ _buffer[i]; if (xor ! _buffer[FrameLength - 2]) { _buffer.RemoveAt(0); continue; } frame ParseBody(_buffer); _buffer.RemoveRange(0, FrameLength); return true; } return false; } private static WeightFrame ParseBody(Listbyte buf) { // 按你手上秤的协议表改这一段这里假设 [1] bit0稳定位 bit1净重位 byte status buf[1]; int raw (buf[2] 24) | (buf[3] 16) | (buf[4] 8) | buf[5]; int decimals buf[6]; return new WeightFrame { Value raw / (decimal)Math.Pow(10, decimals), IsStable (status 0x01) ! 0, IsNet (status 0x02) ! 0, Decimals decimals, Timestamp DateTime.Now }; } }关键参数三个。FrameLength是整帧长度含帧头帧尾写错一个字节整个解析就永远不成功。校验范围是从状态位到数据末字节不含帧头和校验位本身这个范围必须按协议表来多算一个字节就全错。MaxBuffer给 4096 足够一般一帧不超过几十字节这个值只是防泄漏不需要精确。位移那行要特别提一句如果协议里重量是 BCD 码就不能用移位拼整数得按半字节取(b 4) * 10 (b 0x0F)。BCD 和二进制搞混是现场最常见的「数值翻倍或者串位」的根源看到 12.34 变成 1234 或者 24.68先怀疑这个。3.4 ASCII 协议别用 Split 硬切ASCII 帧的处理思路完全不同核心是按行切分加正则提取。用Split(,)硬切的后果是数值前面补了空格切出来是空串转换成数字直接抛异常而这个异常在 DataReceived 的线程池线程里往往没人接程序就这么静默地少了一条记录。using System; using System.Globalization; using System.Text.RegularExpressions; // 形如 ST,GS,0012.34kg\r\n稳定位,毛净位,符号数值单位 private static readonly Regex AsciiFrame new Regex( ^(?stableST|US),(?modeGS|NT|TR),(?sign[-])(?num\d(?:\.\d)?)\s*(?unitkg|g|t|lb)\s*$, RegexOptions.Compiled); public static bool TryParseAscii(string line, out WeightFrame frame) { frame default; var m AsciiFrame.Match(line.Trim()); if (!m.Success) return false; decimal value decimal.Parse(m.Groups[num].Value, CultureInfo.InvariantCulture); if (m.Groups[sign].Value -) value -value; string numText m.Groups[num].Value; int dot numText.IndexOf(.); frame new WeightFrame { Value value, IsStable m.Groups[stable].Value ST, IsNet m.Groups[mode].Value NT, Decimals dot 0 ? 0 : numText.Length - dot - 1, Timestamp DateTime.Now }; return true; }正则里的ST/US、GS/NT/TR这些缩写各厂家不统一有的用S和U有的用0和1。正确做法是把说明书上的缩写表原样抄下来再改正则不要凭印象写。\s*放在数值和单位之间是必要的因为不少秤会在单位前补空格对齐。行切分部分配套写一个字符串缓冲每次收到字节先按编码转成字符串追加进去然后循环找\r\n找到就截取前面那一段交给TryParseAscii剩下的留着。转字符串时用Encoding.ASCII就够称重协议里不会有中文。要注意有的秤只发\n不发\r先在抓包里确认再决定分隔符。4. 判稳与落地从一条读数到一笔能打印的称重记录4.1 判稳为什么不能收到就打印秤上的稳定标志位看着很美好实际现场一半靠不住。有些低端秤这个位恒为 1等于没给有些秤要重量变化超过两个分度值才重新判稳放上去轻一点的物件它一直显示上一次的稳定值。所以上位机必须自己判一次稳不能把秤给的标志当圣旨。我的做法是滑动窗口维护最近 N 帧同时满足三个条件才算稳定。第一窗口内每一帧的秤端稳定位都为真。第二窗口内最大值减最小值不超过容差。第三窗口首尾时间差超过保持时长。三个条件都过取窗口平均值作为稳定值比取最后一帧更抗抖动能把半个分度值的来回跳抹平。参数怎么定取决于分度值。容差一般取两倍分度值比如分度值 0.01kg 的秤容差给 0.02kg这样称重时正常的机械振动不会被误判成不稳定。窗口帧数取 5配合一秒十帧的发送频率相当于 500 毫秒的观察期操作工放上东西一秒内出结果体感上是即时的。保持时长给 300 毫秒比窗口时长略短避免两个条件互相卡住。using System; using System.Collections.Generic; using System.Linq; public sealed class WeightStabilizer { private readonly QueueWeightFrame _window new QueueWeightFrame(); private readonly int _sampleCount; private readonly decimal _tolerance; private readonly TimeSpan _hold; public WeightStabilizer(int sampleCount 5, decimal tolerance 0.02m, int holdMs 300) { _sampleCount sampleCount; _tolerance tolerance; _hold TimeSpan.FromMilliseconds(holdMs); } public void Push(WeightFrame frame) { _window.Enqueue(frame); while (_window.Count _sampleCount) _window.Dequeue(); // 长时间没有新帧要清空否则拔线后旧窗口会“诈尸”出一个稳定值 if ((DateTime.Now - _window.Last().Timestamp).TotalMilliseconds 2000) _window.Clear(); } public bool TryGetStable(out decimal value) { value 0m; if (_window.Count _sampleCount) return false; if (_window.Any(f !f.IsStable)) return false; decimal min _window.Min(f f.Value); decimal max _window.Max(f f.Value); if (max - min _tolerance) return false; if (_window.Last().Timestamp - _window.First().Timestamp _hold) return false; value _window.Average(f f.Value); return true; } }那段超时清空是踩出来的。有一次现场拔了秤去清理上位机还弹了一次打印打出来的是拔线前的重量操作工以为秤坏了。加上两秒超时清空之后就再没出现过。4.2 单位与精度decimal 不是洁癖重量这种数值用 double 存是给自己埋雷。0.1 加 0.2 在 double 里不等于 0.3连续累加几十次之后打印出来的净重会多出个 0.0000000001业务方看到就来找你。C# 里处理重量统一用 decimal内部统一按千克存只在展示层换单位。换算表很简单克除以 1000吨乘以 1000磅乘以 0.45359237。麻烦的是取整。称重业务里有个隐含规则显示值必须是分度值的整数倍因为秤本身就是按分度值跳的。这时候用Math.Round的默认行为会出问题它默认是银行家舍入2.5 会舍成 2现场拿砝码一校就对不上。要显式指定MidpointRounding.AwayFromZero。// 内部统一按 kg 的 decimal 存只在展示层换单位 public static decimal ToKilogram(decimal value, string unit) unit switch { kg value, g value / 1000m, t value * 1000m, lb value * 0.45359237m, _ throw new ArgumentOutOfRangeException(nameof(unit), unit, 未识别的重量单位) }; // 按分度值取整别用默认的银行家舍入现场拿砝码一校就露馅 public static decimal RoundToDivision(decimal value, decimal division) Math.Round(value / division, MidpointRounding.AwayFromZero) * division p a hrefhttps://download.csdn.net/download/king6accp/10018961 stylecolor:#ec7500;font-size:14px; 本文还有配套的精品资源点击获取 /a img altmenu-r.4af5f7ec.gif srchttps://csdnimg.cn/release/wenkucmsfe/public/img/menu-r.4af5f7ec.gif stylewidth:16px;margin-left:4px;vertical-align:text-bottom;cursor:text; /p
简介这是一份基于 C# 的电子秤重量读取示例工程面向需要对接串口称重设备的 .NET 开发者与物联网入门学习者重点解决串口通信、委托事件接收和重量数据解析等问题。压缩包共 21 个文件以 6 个 cs 源码为核心配有 3 个 exe 可执行文件、resources/resx 界面资源、csproj/sln 项目与解决方案文件整体约 38KB结构紧凑便于直接打开调试。已有 340 人学习下载说明其作为小型实战样例具有一定参考价值。读者可从中了解 SerialPort 参数配置、DataReceived 事件注册、按设备协议提取重量数值以及把读数更新到界面或保存到数据库时需注意的线程安全思路适合用作课程设计、设备联调或二次开发的基础模板。1. 秤在跳、数是错的问题多半不在协议层产线上新上一台称重工位扫码枪插上就能用轮到电子秤就卡住了C# 里 SerialPort 打开成功DataReceived 也在触发界面上的重量却一会儿 12.34、一会儿 12.3偶尔还蹦出个 1234操作工连按三次打印出来三条不一样的记录。多数人第一反应是协议没解析对抱着说明书啃校验和改两天还是抖——真正的原因往往更靠前串口参数和物理链路没对齐或者上位机压根没定义「什么算一个有效读数」。读取电子秤重量难点不是把字节变成数字而是把一条会抖、会粘包、会掉线的字节流变成业务敢拿去打印的稳定值。下面按我拆过的几套称重上位机从接线选型、帧解析、判稳滤波讲到现场排查做收银、配料、检重、仓储称重对接的 C# 开发者都能照着走。2. 接线与选型RS232、RS485、USB 三条路怎么选2.1 物理层先定再谈代码拿到一台秤第一件事不是写代码而是翻说明书最后一页看清它到底从哪个口出数。电子秤的输出形态就那么几类选错了后面全是无用功。我在现场见过最冤的一种工程师在 C# 里写了两天串口结果那台秤是键盘口输出插上去在 Excel 里直接打字根本没有串口这回事。所以先看接口再定方案。RS232 是最常见的形态点对点一根三芯线TX、RX、GND就能通。上位机这侧基本都得靠 USB 转串口转换器因为现在的工控机和笔记本很少带原生九针口。它的标称距离是十几米但实际现场五米以上、旁边再有个变频器或者大功率电机误码率就上来了。我一般会建议秤到机柜的线不要超过三米超过就换 RS485。RS485 是差分总线抗干扰强一台转换器挂多台秤是常规操作仓库、配料线上的多工位称重基本走这条。代价是半双工发指令和收数据不能同时来代码里要处理收发切换的时序而且每台秤要有一个总线地址轮询着读。RS485 还有个经典问题是终端电阻和共地长总线两端不接匹配电阻波形反射上来前面几台好好的最后一台老是校验错。第三类是 USB 直连或者键盘口HID。前者在系统里虚拟出一个串口用法和 RS232 一样只是端口号会随着插拔变化后者是把重量当键盘输入打到焦点窗口里好处是免驱免协议坏处是焦点一切换就丢数据而且拿不到原始帧做不了追溯。小工具、临时收银可以用产线上我不推荐。还有一类带网口或者无线模块的秤本质上就是把串口数据透传成 TCP 流C# 侧换成 Socket 收字节解析逻辑一行不用改。这种方案的好处是走网线可以拉很远坏处是断线重连要自己写而且现场 IP 冲突这种事一个项目能遇上一次就够记一辈子。接口形态典型距离拓扑C# 侧接入最常见的翻车点RS2323 至 15 米点对点SerialPort转换器电平不对、没共地、线太长受干扰RS485几十到几百米总线多机SerialPort 地址轮询终端电阻缺失、收发切换时序、共地USB 虚拟串口5 米内点对点SerialPort端口号漂移、热插拔后句柄失效键盘口 HID5 米内点对点键盘钩子或 RawInput焦点丢失、拿不到原始帧以太网透传受网络限制点对点或组网TcpClientIP 冲突、断线重连、心跳缺失选型的判断顺序我一般这么走先看秤有几个口再看工位到机柜的距离然后看是不是要多台并到一个界面最后看业务要不要追溯原始数据。要追溯就必须走串口或者网口键盘口直接排除。2.2 协议形态决定代码骨架物理层通了接下来要搞清楚秤是主动说话还是等你问。这两种形态写出来的代码结构完全不同混着写后期维护会非常痛苦。第一种是连续发送。秤上电之后按固定频率往串口吐帧常见的一秒十次上位机只管收和切帧。这种最省事缺点是数据量大空闲时也在刷日志一晚上能写几百兆。做连续发送的解析核心是一个带缓冲的状态机因为 DataReceived 给你的可能是半帧也可能是一帧半。第二种是指令应答。上位机发一条命令读净重、读毛重、去皮、清零秤回一帧。这种模式必须做请求串行化同一路串口上不能两个线程同时发命令否则回来的数据对不上是谁的。我的做法是给每一路秤配一个请求队列发出去之后等回包超时就重发重发三次判离线。这里有个坑去皮的命令有的秤要求先稳定再发不稳定直接忽略上位机这边就会一直等超时看起来像通信断了。第三种是寄存器式典型是 MODBUS RTU 那一套从站地址 功能码 寄存器地址 CRC16重量放在固定的保持寄存器里。这种协议的好处是有标准可循坏处是要背寄存器表而且不同厂家的寄存器地址规划完全不一样换一台秤就得改配置。我一般会把寄存器地址、数据类型16 位整数还是 32 位浮点、小数位做成一张配置文件代码里只认配置不写死。第四种是 ASCII 文本帧形如ST,GS,0012.34kg这样一行回车换行结尾。可读性最好抓串口一眼就能看懂调试期特别舒服。缺点是帧长不固定而且有的厂家会在数值前面补空格对齐用 Split 硬切会切出一堆空串。判断自己手上这台属于哪种最快的办法是打开串口助手什么都不发看有没有数据自己冒出来有就是连续发送没有就发一条说明书上的读指令试试回了就是指令应答。两条路都不通再回头查物理层。2.3 串口参数与第一段能跑的代码参数这块没什么玄学照着说明书抄抄完再用抓包验证。真正容易出错的是几个默认值之外的东西比如 DTR 和 RTS 要不要拉高、ReceivedBytesThreshold 设多少。有些转换器或者秤端的光耦隔离电路要求 DTR 有电平才肯往外发数据这时候你把波特率核对了八遍也没用一个字节都不会来。下面这段代码只干一件事把秤吐出来的原始字节按十六进制打到控制台。别急着解析先看清它到底在说什么这一步省下来后面会加倍还回去。using System; using System.IO.Ports; // 只做一件事把秤吐出来的原始字节按十六进制打出来先看清再解析 public sealed class RawSniffer : IDisposable { private readonly SerialPort _port new SerialPort(); public RawSniffer(string portName, int baudRate) { _port.PortName portName; _port.BaudRate baudRate; // 以说明书为准常见 9600 / 19200 / 38400 _port.DataBits 8; // 少数老秤是 7 位协议表里会写 _port.Parity Parity.None; _port.StopBits StopBits.One; _port.Handshake Handshake.None; // 称重场景几乎不用硬件流控 _port.ReadTimeout 500; _port.WriteTimeout 500; _port.DtrEnable true; // 部分转换器/秤端电路不拉高就不发数据 _port.RtsEnable true; _port.ReceivedBytesThreshold 1; // 设成帧长会漏数据原因见第 5 章 _port.DataReceived OnDataReceived; } public void Start() _port.Open(); private void OnDataReceived(object sender, SerialDataReceivedEventArgs e) { try { // 一次事件里的字节数不固定必须一次读干净不能只读固定长度 int available _port.BytesToRead; if (available 0) return; byte[] buffer new byte[available]; int read _port.Read(buffer, 0, available); Console.WriteLine(${DateTime.Now:HH:mm:ss.fff} - {BitConverter.ToString(buffer, 0, read)}); } catch (TimeoutException) { // 读超时不是故障丢掉这一批继续等 } catch (InvalidOperationException) { // 串口已被关闭直接退出回调 } } public void Dispose() { _port.DataReceived - OnDataReceived; // 先摘事件再关避免关闭过程中回调重入 if (_port.IsOpen) _port.Close(); _port.Dispose(); } }逻辑很直白构造时把参数定死Start 打开端口每次 DataReceived 触发就把当前可读字节全部读出来打一行十六进制。BytesToRead是内核缓冲区里的待读字节数它会随数据到达不断变化所以不能假设每次都是完整一帧。BitConverter.ToString输出形如02-31-2D-30-30-31-32-33-34-03的字符串帧头帧尾一眼能认出来。参数上要留意的就三个。ReceivedBytesThreshold必须设 1设大了会出现「第一批数据来了后面全静默」的现象因为凑不满阈值事件就不再触发。ReadTimeout给 500 毫秒够用太短会在低波特率下频繁超时。DtrEnable和RtsEnable按需拉高拉高没有副作用不拉高可能一个字节都收不到。提示DataReceived 跑在线程池线程上不是 UI 线程。在这回调里直接改控件属性轻则界面卡顿重则抛跨线程异常而且异常还在线程池里程序可能悄无声息地挂掉。3. 帧解析定长帧、ASCII 行、校验和的三套切法3.1 三类帧结构和对策串口给你的是字节流不是消息。所谓解析就是在流里找到帧边界把一段字节认定为一条完整读数。现场见的协议基本落在三类里对策各不相同。定长帧最好处理。帧头固定一个字节常见 0x02 STX帧长固定帧尾固定常见 0x03 ETX中间带一个校验字节。收到数据后找帧头凑够固定长度就校验校验过了就是一帧不过就把帧头丢掉往前挪一个字节重新找。这套逻辑用状态机写出来不超过五十行但能扛住绝大多数噪声。带长度字段的变长帧稍微麻烦一点。帧头后面跟一个长度字节先读到长度再按长度等后续字节。难点在于长度字段本身也可能被噪声污染读出一个 200 的长度缓冲区就一直等下去。所以必须配一个等待超时比如 500 毫秒没凑齐就整段丢弃重新同步。ASCII 行帧靠分隔符切一般是\r\n。这种最简单也最容易翻车因为串口给你的可能是半行ST,GS,0012.就来了这时候切出来的内容 parse 一定失败。做法是维护一个字符串缓冲每次追加后找\r\n找到才切找不到就留着等下一批。帧类型边界识别长度控制校验方式典型坑定长二进制帧固定帧头 固定帧尾常量异或、累加和帧头出现在数据区误判带长度字段帧帧头 长度字节动态CRC16长度字段被污染死等ASCII 行帧\r\n或\n不定部分带 BCC半行、空格填充MODBUS RTU从站地址 功能码按功能码CRC163.5 字符静默间隔判断3.2 缓冲区粘包、半包与超时重同步缓冲区这块是新手最容易写崩的地方。常见的错法是每次 DataReceived 都 new 一个 byte 数组然后直接对这个数组做解析结果一帧被拆成两半两半都解析失败数据就丢了。正确做法是有一个跨事件存活的累积缓冲每次把新字节追加进去然后循环尝试从缓冲区头部取帧取不出来就跳出循环等下一批。累积缓冲有两个必须加的保护。一个是长度上限比如 4096 字节超过就丢掉最老的数据。没有这个上限遇到一台只发帧头不发帧尾的坏秤内存会一路涨到进程被杀。另一个是时间上限超过 500 毫秒没有新字节进来说明缓冲区里躺着的是残缺帧或者纯噪声直接清空重新找同步。这两个保护不加现场跑一周必出问题。还有一个细节是同步位置。找到帧头之后如果校验不过不能清空整个缓冲区只能把帧头那一个字节丢掉从下一个字节重新找。因为帧头字节有可能就出现在数据区里整段清空会连带丢掉后面真正的帧。3.3 二进制解析器状态机加异或校验下面这个解析器按「STX 8 字节净荷 异或校验 ETX」的九字节定长帧写。你手上那台秤的字段位置大概率不一样要改的只有ParseBody里的位移和符号位判断骨架可以整套搬走。using System; using System.Collections.Generic; public struct WeightFrame { public decimal Value { get; set; } public bool IsStable { get; set; } public bool IsNet { get; set; } // true净重false毛重 public int Decimals { get; set; } public DateTime Timestamp { get; set; } } // 帧约定示例[0]0x02 [1]状态位 [2..5]大端整数 [6]小数位 [7]异或 [8]0x03 public sealed class ScaleFrameParser { private const byte Stx 0x02; private const byte Etx 0x03; private const int FrameLength 9; private const int MaxBuffer 4096; private readonly Listbyte _buffer new Listbyte(512); private DateTime _lastAppend DateTime.UtcNow; public void Append(byte[] data, int count) { for (int i 0; i count; i) _buffer.Add(data[i]); _lastAppend DateTime.UtcNow; // 只增不减的缓冲就是内存泄漏超上限先丢最老的 if (_buffer.Count MaxBuffer) _buffer.RemoveRange(0, _buffer.Count - MaxBuffer); } public bool TryDequeue(out WeightFrame frame) { frame default; // 半帧保护500ms 没有新字节说明前面残留的不是真帧清掉重新同步 if (_buffer.Count 0 (DateTime.UtcNow - _lastAppend).TotalMilliseconds 500) _buffer.Clear(); while (_buffer.Count FrameLength) { int start _buffer.IndexOf(Stx); if (start 0) { _buffer.Clear(); return false; } if (start 0) _buffer.RemoveRange(0, start); // 丢掉帧头前的噪声 if (_buffer.Count FrameLength) return false; // 还没收全等下一批 if (_buffer[FrameLength - 1] ! Etx) { _buffer.RemoveAt(0); continue; } byte xor 0; for (int i 1; i FrameLength - 2; i) xor ^ _buffer[i]; if (xor ! _buffer[FrameLength - 2]) { _buffer.RemoveAt(0); continue; } frame ParseBody(_buffer); _buffer.RemoveRange(0, FrameLength); return true; } return false; } private static WeightFrame ParseBody(Listbyte buf) { // 按你手上秤的协议表改这一段这里假设 [1] bit0稳定位 bit1净重位 byte status buf[1]; int raw (buf[2] 24) | (buf[3] 16) | (buf[4] 8) | buf[5]; int decimals buf[6]; return new WeightFrame { Value raw / (decimal)Math.Pow(10, decimals), IsStable (status 0x01) ! 0, IsNet (status 0x02) ! 0, Decimals decimals, Timestamp DateTime.Now }; } }关键参数三个。FrameLength是整帧长度含帧头帧尾写错一个字节整个解析就永远不成功。校验范围是从状态位到数据末字节不含帧头和校验位本身这个范围必须按协议表来多算一个字节就全错。MaxBuffer给 4096 足够一般一帧不超过几十字节这个值只是防泄漏不需要精确。位移那行要特别提一句如果协议里重量是 BCD 码就不能用移位拼整数得按半字节取(b 4) * 10 (b 0x0F)。BCD 和二进制搞混是现场最常见的「数值翻倍或者串位」的根源看到 12.34 变成 1234 或者 24.68先怀疑这个。3.4 ASCII 协议别用 Split 硬切ASCII 帧的处理思路完全不同核心是按行切分加正则提取。用Split(,)硬切的后果是数值前面补了空格切出来是空串转换成数字直接抛异常而这个异常在 DataReceived 的线程池线程里往往没人接程序就这么静默地少了一条记录。using System; using System.Globalization; using System.Text.RegularExpressions; // 形如 ST,GS,0012.34kg\r\n稳定位,毛净位,符号数值单位 private static readonly Regex AsciiFrame new Regex( ^(?stableST|US),(?modeGS|NT|TR),(?sign[-])(?num\d(?:\.\d)?)\s*(?unitkg|g|t|lb)\s*$, RegexOptions.Compiled); public static bool TryParseAscii(string line, out WeightFrame frame) { frame default; var m AsciiFrame.Match(line.Trim()); if (!m.Success) return false; decimal value decimal.Parse(m.Groups[num].Value, CultureInfo.InvariantCulture); if (m.Groups[sign].Value -) value -value; string numText m.Groups[num].Value; int dot numText.IndexOf(.); frame new WeightFrame { Value value, IsStable m.Groups[stable].Value ST, IsNet m.Groups[mode].Value NT, Decimals dot 0 ? 0 : numText.Length - dot - 1, Timestamp DateTime.Now }; return true; }正则里的ST/US、GS/NT/TR这些缩写各厂家不统一有的用S和U有的用0和1。正确做法是把说明书上的缩写表原样抄下来再改正则不要凭印象写。\s*放在数值和单位之间是必要的因为不少秤会在单位前补空格对齐。行切分部分配套写一个字符串缓冲每次收到字节先按编码转成字符串追加进去然后循环找\r\n找到就截取前面那一段交给TryParseAscii剩下的留着。转字符串时用Encoding.ASCII就够称重协议里不会有中文。要注意有的秤只发\n不发\r先在抓包里确认再决定分隔符。4. 判稳与落地从一条读数到一笔能打印的称重记录4.1 判稳为什么不能收到就打印秤上的稳定标志位看着很美好实际现场一半靠不住。有些低端秤这个位恒为 1等于没给有些秤要重量变化超过两个分度值才重新判稳放上去轻一点的物件它一直显示上一次的稳定值。所以上位机必须自己判一次稳不能把秤给的标志当圣旨。我的做法是滑动窗口维护最近 N 帧同时满足三个条件才算稳定。第一窗口内每一帧的秤端稳定位都为真。第二窗口内最大值减最小值不超过容差。第三窗口首尾时间差超过保持时长。三个条件都过取窗口平均值作为稳定值比取最后一帧更抗抖动能把半个分度值的来回跳抹平。参数怎么定取决于分度值。容差一般取两倍分度值比如分度值 0.01kg 的秤容差给 0.02kg这样称重时正常的机械振动不会被误判成不稳定。窗口帧数取 5配合一秒十帧的发送频率相当于 500 毫秒的观察期操作工放上东西一秒内出结果体感上是即时的。保持时长给 300 毫秒比窗口时长略短避免两个条件互相卡住。using System; using System.Collections.Generic; using System.Linq; public sealed class WeightStabilizer { private readonly QueueWeightFrame _window new QueueWeightFrame(); private readonly int _sampleCount; private readonly decimal _tolerance; private readonly TimeSpan _hold; public WeightStabilizer(int sampleCount 5, decimal tolerance 0.02m, int holdMs 300) { _sampleCount sampleCount; _tolerance tolerance; _hold TimeSpan.FromMilliseconds(holdMs); } public void Push(WeightFrame frame) { _window.Enqueue(frame); while (_window.Count _sampleCount) _window.Dequeue(); // 长时间没有新帧要清空否则拔线后旧窗口会“诈尸”出一个稳定值 if ((DateTime.Now - _window.Last().Timestamp).TotalMilliseconds 2000) _window.Clear(); } public bool TryGetStable(out decimal value) { value 0m; if (_window.Count _sampleCount) return false; if (_window.Any(f !f.IsStable)) return false; decimal min _window.Min(f f.Value); decimal max _window.Max(f f.Value); if (max - min _tolerance) return false; if (_window.Last().Timestamp - _window.First().Timestamp _hold) return false; value _window.Average(f f.Value); return true; } }那段超时清空是踩出来的。有一次现场拔了秤去清理上位机还弹了一次打印打出来的是拔线前的重量操作工以为秤坏了。加上两秒超时清空之后就再没出现过。4.2 单位与精度decimal 不是洁癖重量这种数值用 double 存是给自己埋雷。0.1 加 0.2 在 double 里不等于 0.3连续累加几十次之后打印出来的净重会多出个 0.0000000001业务方看到就来找你。C# 里处理重量统一用 decimal内部统一按千克存只在展示层换单位。换算表很简单克除以 1000吨乘以 1000磅乘以 0.45359237。麻烦的是取整。称重业务里有个隐含规则显示值必须是分度值的整数倍因为秤本身就是按分度值跳的。这时候用Math.Round的默认行为会出问题它默认是银行家舍入2.5 会舍成 2现场拿砝码一校就对不上。要显式指定MidpointRounding.AwayFromZero。// 内部统一按 kg 的 decimal 存只在展示层换单位 public static decimal ToKilogram(decimal value, string unit) unit switch { kg value, g value / 1000m, t value * 1000m, lb value * 0.45359237m, _ throw new ArgumentOutOfRangeException(nameof(unit), unit, 未识别的重量单位) }; // 按分度值取整别用默认的银行家舍入现场拿砝码一校就露馅 public static decimal RoundToDivision(decimal value, decimal division) Math.Round(value / division, MidpointRounding.AwayFromZero) * division p a hrefhttps://download.csdn.net/download/king6accp/10018961 stylecolor:#ec7500;font-size:14px; 本文还有配套的精品资源点击获取 /a img altmenu-r.4af5f7ec.gif srchttps://csdnimg.cn/release/wenkucmsfe/public/img/menu-r.4af5f7ec.gif stylewidth:16px;margin-left:4px;vertical-align:text-bottom;cursor:text; /p
