简介：本资源是一套基于C#开发的汽车衡称重与无人值守地磅过磅系统完整源码，面向工业自动化软件开发者、智能物流系统集成工程师及智能制造领域技术学习者，解决传统地磅人工干预多、效率低、易出错等痛点，适用于物流园区、矿山、电厂、建材厂等需高频次、高精度、全流程自动称重的场景。压缩包共219个文件，总大小72.31MB，涵盖88个C#核心逻辑文件（如WeighRecordModel.cs、MainViewModel.WeighMode.cs）、31个XAML界面文件支撑现代化UI交互、49个DLL实现硬件驱动（含CHCNetSDK.cs、VzClientSDK.cs等视频与设备接入模块）、27个PNG图标资源及5个XML配置文件保障灵活部署。已有401人学习下载，提供可直接编译运行的Visual Studio解决方案（含.sln与.csproj），完整覆盖车牌识别联动、红绿灯道闸控制、监控视频集成、称重数据持久化与权限管理等关键模块，代码结构清晰、命名规范、注释充分，便于二次开发与系统扩展。 去年做过一个地磅项目，现场调试阶段印象最深的一件事，是凌晨两点被客户电话叫起来。一辆运煤车停在厂门口的汽车衡上，磅房没人，司机找不到过磅员，后面的货车从厂内排到了国道上。客户在电话里说得很直白：“如果这套系统能做到没人值守，就不会出这种事。”
这句话其实点破了汽车衡称重软件的核心价值。用C#做一套无人值守地磅过磅软件，表面上看是把仪表读数读出来显示在屏幕上，但真正要解决的是“车来了怎么自动称”“称完怎么自动放行”“高峰期怎么不排队”“作弊怎么防”“数据怎么追溯”这一整条业务闭环。这篇文章我从源码设计角度做一次完整拆解，覆盖串口仪表通讯、道闸控制、车牌识别、状态机设计、防作弊策略、数据存储和现场部署，适合准备入行上位机开发、或者正在接称重项目的C#工程师参考。
1. 传统过磅的痛点与无人值守的业务闭环
1.1 传统过磅流程里藏着多少效率黑洞
干过称重行业的人都知道，传统的地磅过磅流程大概是这样的：司机把车开到磅前、下车、跑到磅房找过磅员、递纸质单据、等过磅员核对信息、操作电脑、等重量稳定、手工记录或打印磅单、然后才能开走。整个过程算下来，效率高点的一辆车也要一分多钟，遇到交接班、换单据、系统卡顿，三到五分钟一辆车也很正常。
更麻烦的是人为因素。过磅员每天坐在磅房里重复同样的操作，高峰期几百辆车过磅，难免看错车号、录错重量、打错磅单。纸质磅单一旦丢失或者字迹模糊，后期对账就是一场灾难。车队高峰期、夜班时段、节假日，磅房三班倒的人力成本也跑不掉。
还有一类问题更致命：作弊。地磅行业的作弊手法五花八门，后面我会单独开一章细说。这里想强调的是，传统“人盯秤”模式对作弊的防范完全依赖过磅员的责任心，一旦内外勾结，秤就是个摆设。
1.2 无人值守后的理想流程，每一步都有软件介入
无人值守地磅软件要做的，就是把上面那些依赖人力的环节替换成“硬件感知+软件决策”。一套典型的流程是这样的：
- 车辆驶入车道，车牌识别相机自动抓拍车牌，道闸前的地感线圈或红外对射检测到车辆。
- 道闸自动抬杆放行，车开上汽车衡。
- 上磅之后，红外光栅检测车辆是否完全进入称台区域，防止半轮压磅。
- 软件持续读取仪表重量数据，做稳定判断，重量稳定后自动锁定当前数值。
- 系统抓拍车辆正面、尾部、驾驶室等多角度照片，绑定当前重量、车号、时间。
- 防作弊逻辑检查通过后，数据自动写入数据库，生成过磅流水号。
- 出口道闸抬杆，车辆下磅，系统回到空闲状态等待下一辆车。
整套流程里，每个环节都需要软件参与决策：什么时候抬杆、什么时候读重量、什么时候锁数据、什么时候放行、异常了怎么处理。所以无人值守地磅软件本质上是一个业务控制系统，代码的复杂度不在UI，而在业务逻辑和硬件的协同。
2. 设备接入层实战：串口仪表、道闸与车牌相机
2.1 汽车衡仪表串口协议解析与C#实现
地磅的核心数据源是称重仪表，常见的品牌有托利多、柯力、耀华这些。绝大多数仪表都带RS232或RS485串口，数据模式一般有连续发送和应答式两种。连续发送就是仪表按固定频率往外吐数据，应答式是上位机发指令、仪表回一帧数据。开发之前第一件事是搞清楚仪的通信协议，尤其是数据帧格式。
以典型的ASCII协议为例，一帧数据可能长这样：
STX,1,1, 00012.345,kg,D,CS通常包含帧头、仪表地址、通道号、重量值、单位、状态位和校验码。C#里接收串口数据，很多人习惯直接在DataReceived事件里逐字节处理，但高频数据流下很容易出粘包和半包问题，更好的做法是先把字节流扔进一个线程安全的队列：
private ConcurrentQueue<byte[]> _receiveQueue = new ConcurrentQueue<byte[]>(); private void serialPort_DataReceived(object sender, SerialDataReceivedEventArgs e) { int bytesToRead = serialPort.BytesToRead; byte[] buffer = new byte[bytesToRead]; serialPort.Read(buffer, 0, bytesToRead); _receiveQueue.Enqueue(buffer); }然后在独立的解析线程里不断取出数据、拼接缓冲区、按帧头和帧尾切出完整帧：
private void ParsingLoop() { while (_isRunning) { if (_receiveQueue.TryDequeue(out byte[] data)) { _parsingBuffer.AddRange(data); while (TryExtractFrame(_parsingBuffer, out byte[] frame)) { ProcessFrame(frame); } } Thread.Sleep(10); } }TryExtractFrame做的事情就是查找帧头位置、判断长度是否足够、校验校验码。校验码一般是异或或累加和，不过这一步不能省，工业现场电磁干扰多，串口线上偶尔会收到被污染的帧，没有校验直接解析重量，会出现几百公斤的跳变。
仪表的连接方式也值得多说一句。工控机通常用RS232直连仪表，如果仪表只有RS485，需要加一个RS232转RS485的转换器。现场布线长了之后，串口线成为最脆弱的一环，屏蔽层、接地、走线位置都会影响数据稳定性。所以在软件里保留“读取超时”和“连续多帧数据异常”的自动告警，是一个成熟系统必须有的能力。
2.2 道闸与红绿灯控制：Modbus TCP还是IO继电器
道闸和红绿灯的控制方式，在无人值守地磅项目里常见的有三种：继电器控制卡直连、PLC通过Modbus控制、以及一体化工控机搭配IO模块。
继电器控制卡最简单，通过USB或PCI插卡输出电平信号控制道闸升降，但受限于供电和抗干扰能力，复杂的道闸互锁逻辑很难做。我个人更推荐用PLC，哪怕是小型PLC，原因很简单：地磅现场对设备的稳定性要求极高，PLC内部有独立的控制逻辑，软件崩溃的时候道闸还能按安全逻辑处理，不会出现“电脑死机、道闸卡在半空”的问题。
PLC的通讯方式最通用的是Modbus TCP，C#里可以直接用NModbus库操作线圈：
using (var client = new TcpClient("192.168.1.20", 502)) { var master = ModbusIpMaster.CreateIp(client); // 道闸抬杆：写线圈地址0，值为true master.WriteSingleCoil(0, true); // 红灯亮：写线圈地址1，值为true master.WriteSingleCoil(1, true); // 绿灯亮：写线圈地址2，值为false master.WriteSingleCoil(2, false); }这里要注意PLC的线圈地址和实际硬件的接线对应关系，必须提前画好点位表。开发时建议把所有点位封装成一个DeviceController类，上层业务逻辑只调用OpenBarrier()、CloseBarrier()、SetRedLight(bool)这类方法，不直接暴露Modbus寄存器地址，后期改点位只需要改这个类。
2.3 车牌识别相机接入与AForge参数控制
车牌识别有两种主流方案：一种是用市面上一体化的车牌识别相机，海康、大华都有，相机内部跑车牌识别算法，通过SDK或HTTP回调直接输出车牌号；另一种是普通网络摄像头加PC端OCR识别，工业项目里很多是先用方案一的相机完成车牌识别，再用普通摄像头做全景抓拍。
如果你是用AForge.NET库来控制摄像头，VideoCaptureDevice是核心类，可以枚举设备、启动视频流、抓取帧：
private VideoCaptureDevice _captureDevice; public void InitCamera() { var devices = new FilterInfoCollection(FilterCategory.VideoInputDevice); _captureDevice = new VideoCaptureDevice(devices[0].MonikerString); _captureDevice.NewFrame += OnNewFrame; _captureDevice.Start(); } private void OnNewFrame(object sender, NewFrameEventArgs eventArgs) { Bitmap frame = (Bitmap)eventArgs.Frame.Clone(); // 在这里做车牌识别或全景抓拍 }AForge里还有一个容易被忽略的功能，就是设置摄像头的视频属性和控制属性。用VideoCaptureDevice.SetCameraProperty可以调节亮度、对比度、曝光、增益等参数。白天逆光、夜晚低照度、雨天反光，都需要动态调整这些属性，否则车牌识别率会断崖式下降：
// 夜间补光模式下提高增益、降低曝光 _captureDevice.SetCameraProperty(CameraControlProperty.Exposure, -6, CameraControlFlags.Manual); _captureDevice.SetCameraProperty(CameraControlProperty.Gain, 12, CameraControlFlags.Manual);如果你使用的是Halcon做车牌OCR，初始化阶段需要注意GPU设备的加载问题。有个常见坑是相机或GPU驱动环境没配置好，调用QueryAvailableDLDevices("runtime", "gpu", out hv_DLDeviceHandle)直接报错。遇到这种情况，建议先强制用CPU模式把整个识别流程跑通，确认算法和参数没问题之后，再切回GPU加速，排查起来会快很多。
3. 过磅主流程的状态机设计与稳定判断
3.1 为什么要用状态机管理过磅流程
过磅流程看起来简单，实际写业务逻辑的时候，很多人会习惯用flag和if-else堆：判断车来了没有、判断重量稳了没有、判断道闸抬了没有。几个状态还能凑合，一旦加上超时、异常、防作弊检测，if-else很快就会变成一团乱麻。
状态机的价值在于，把业务流程拆成一个个明确的状态，每个状态只做它该做的事，由事件触发状态转移。我常用的过磅状态是这样定义的：
public enum WeighState { Idle, // 空闲，等待车辆 VehicleArrived, // 车辆上磅已检测到 PlateRecognized, // 车牌识别完成 Weighing, // 正在称重，等待稳定 DataLocked, // 重量锁定，保存数据 WaitingExit, // 等待道闸放行 Complete // 完成，复位到空闲 }每个状态转移必须满足转移条件，比如从Weighing到DataLocked的条件是“重量稳定且红外光栅正常”，从DataLocked到WaitingExit的条件是“数据库写入成功且抓拍完成”。状态机跑起来之后，整个流程在日志里一目了然，出问题的时候直接看状态卡在哪一环节，比翻一行行if-else日志高效得多。
3.2 重量稳定判断：不能拿来一帧就存
重量稳定判断是整个过磅软件里最核心、也最容易被做简单的逻辑。很多早期版本直接把串口收到的第一帧重量存进数据库，结果车还没停稳，读数还在飘，存进去的重量和实际结算重量差几十公斤甚至上百公斤，客户自然找上门。
比较靠谱的做法是取滑动窗口内连续几帧重量做比较。比如每秒收到10帧数据，我一般取最近5帧，如果这5帧的最大值与最小值之差小于设定阈值（比如5公斤），就认为重量稳定：
private bool IsWeightStable(IEnumerable<double> recentWeights, double threshold = 5, int windowSize = 5) { var window = recentWeights.TakeLast(windowSize).ToList(); if (window.Count < windowSize) return false; var max = window.Max(); var min = window.Min(); return (max - min) <= threshold; }还可以在窗口比较之前做一次滤波，比如滑动平均或者中值滤波，避免个别干扰帧导致误判。注意这里的阈值要根据地磅量程和车辆类型来调，轻车稳定性好，重车晃动时间长，阈值设得太小会导致锁定时间过长。
3.3 超时、复位与异常流程处理
无人值守地磅没有人在现场干预，所以软件必须自带异常恢复能力。常见场景包括：
- 车辆上磅后车牌识别失败：等待几秒后重新识别，连续失败则触发现场声光报警，并上传异常事件。
- 重量长时间不稳定：很可能车辆在磅上装卸货，或者有人员走动干扰，软件要设置超时时间，比如30秒仍不稳定就自动复位，等待车辆重新停稳。
- 道闸抬杆后车辆没有及时下磅：检测出秤台重量没有归零，软件输出提示并保持道闸状态锁定。
- 数据写入数据库失败：不能直接放行，必须留在当前状态重试或报警。
这些异常逻辑都需要在状态机的每次循环里检查。以超时为例，每个状态可以维护一个进入时间，循环检测当前时间与进入时间的差值，超过预设阈值就做超时处理。这也是我推荐把流程控制放在独立线程而不是UI线程里的原因——UI线程卡一下，称重流程还能继续跑，现场不会停摆。
4. 防作弊设计：从物理检测到数据防篡改
4.1 称重行业的作弊手法与物理防范
防作弊是无人值守地磅软件区别于普通称重软件的标志性功能。称重行业里常见的作弊手段大概有这几类：
- 不完全上磅：车辆只有一部分轮胎压在汽车衡上，人为“压边”减轻重量。
- 垫磅顶磅：在磅台下垫钢板、砖头，或者用液压顶顶起称台，让重量被分担掉。
- 遥控干扰：用无线遥控器干扰仪表或传感器的模拟信号，这是最激进的手段。
- 换车牌换卡：车辆身份和实际运单不匹配，内外勾结。
- 数据篡改：直接修改数据库或者磅单记录的重量。
针对这些手段，物理层和软件层要配合防范：
- 红外光栅对射：安装在地磅两侧，车辆任何一个轮胎没有完全进入称台，光栅就会遮挡，软件判定为非法称重。
- 重量异常监测：记录车辆上磅到稳定整个过程的重量曲线，如果出现跳变、骤减，系统自动标记为可疑。
- 多传感器数据比对：有些地磅支持按传感器分组读数，可以检测出垫磅、顶磅导致的偏载异常。
- 仪表加密和铅封：防止脉冲被替换。
4.2 数据层防篡改与审计设计
物理层面的防范解决了“怎么称”的问题，数据层面还要解决“称完怎么改不了”的问题。
我最在意的设计是过磅记录的不可篡改性。每条过磅记录生成一个唯一的流水号，格式比如20250613-0001，规则可以加日期、班次、序号。重要的字段（毛重、皮重、净重、车号、时间、红外状态、抓拍图片路径）在保存之后，业务代码里不允许提供“修改”的入口。如果因为特殊情况确实需要改单，必须走单独的“冲正”流程，保留原单记录并追加一条冲正记录，而不是把原记录更新掉。
审计日志也要单独建表，任何操作员登录、改单、校准、退出，全都写进审计表，且这个表不允许UPDAT和DELETE，只有INSERT权限。真出了纠纷，这套设计能证明系统是可信的，而不是靠解释“应该是某某人改的”。
每次过磅的抓拍图片也非常重要，建议按流水号命名存放在独立目录，比如D:\WeighImages\20250613\0001_front.jpg，并且把图片路径写进数据库记录。这样后期查询每一笔过磅记录都能调出当时的实拍画面，作为一手证据。
5. 数据存储与通讯：单机到联网的架构演进
5.1 本机SQLite还是服务器MySQL
无人值守地磅软件的部署环境差别很大。一个搅拌站或矿山，可能只有一台工控机在磅房里，没有稳定的网络。这种情况我首选SQLite，零配置、单文件、随开随用，非常契合工控机场景。
如果项目有局域网，并且需要和ERP、MES、或者集团调度系统对接，那就应该用MySQL或SQL Server。地磅数据量不算大，一天几千条过磅记录对数据库完全没压力，真正需要考虑的是断网续传和并发。
一个折中方案是：本机用SQLite做实时写入，同时把过磅记录同步到服务器MySQL，网络恢复后自动补传。这个方案在现场实用性很强，断电断网都不影响过磅，数据也不会丢。
5.2 过磅记录的事务一致性与并发处理
过磅流程里，数据写入不是一个简单的INSERT。一次过磅完成，需要同时写入：过磅主记录、抓拍图片路径记录、可能还有物流单关联记录。这几个操作必须放在一个事务里，要么全成，要么全不成。否则就会出现“重量存了、图片路径丢了”这种脏数据。
using (var conn = new SQLiteConnection(_connectionString)) { conn.Open(); using (var tx = conn.BeginTransaction()) { try { InsertWeighRecord(conn, tx, record); InsertImageRecord(conn, tx, imageRecord); tx.Commit(); } catch { tx.Rollback(); throw; } } }并发方面，串口解析线程、UI线程、网络推送线程都在访问数据，实体类的字段不能用普通List直接操作。我用ConcurrentQueue<T>来解耦生产者和消费者，重量帧从串口事件进队列，解析线程消费，UI线程通过事件订阅拿到更新后的重量显示。这样即使某一瞬间数据量大，也不会出现跨线程访问异常。
5.3 实时推送与报表：C# SignalR和定时任务
称重数据不只是显示在磅房的软件界面上，它还要实时推送到大厅显示屏、调度室、甚至集团总部。C#里做实时推送，SignalR是最顺手的一套方案。磅房工控机作为SignalR客户端，后端中心服务器作为Hub，重量变化时客户端实时推送，调度室网页端的大屏数据就能跟着刷新。
var connection = new HubConnectionBuilder() .WithUrl("http://localhost:5000/weighHub") .Build(); await connection.StartAsync(); await connection.InvokeAsync("SendWeighData", record);定时任务用得最多的场景有两个：一是当天过磅数据的定时汇总统计，凌晨生成前一天的日报表；二是历史数据的定期归档和清理。C#里可以直接用System.Threading.Timer，也可以用Quartz.NET做更复杂的调度，看项目规模选。
6. 从开发环境到工控机：现场部署的十个坑
6.1 通讯线的坑：串口丢包与RS232转USB
开发时用笔记本连仪表做测试，跑得好好的，到现场换上工控机就丢包、乱码。排查下来，大部分都是因为现场用了一个劣质RS232转USB线。笔记本自带的串口或者PCI多串口卡通常很稳，但那种十几块的转USB线在工业环境下就是灾难。
我的建议是：预算充足的话直接上PCI多串口卡，或者用质量好一点的工业级串口服务器。另外现场串口线的长度尽量控制在15米以内，走线避开变频器、电机这些强干扰源。软件侧也保留一个“连续接收失败自动恢复”的逻辑，超过几秒没有合法帧时，自动关闭串口重新打开，能解决不少偶发问题。
6.2 断电、重启与自动恢复
工控机在磅房是7x24小时跑，现场经常因为施工、检修断电。如果断电瞬间正好在写数据库，重启后可能遇到数据库文件损坏。应对措施有几层：
- 使用UPS不间断电源，至少保证工控机正常关机。
- 软件开机自启动，加入Windows计划任务或启动文件夹，掉电恢复后不需要人去点。
- 启动时自动检测上次运行状态，如果发现非正常退出，自动进入数据校验和恢复流程。
SQLite有一个比较实用的配置，就是开启WAL日志模式，写入崩溃恢复能力比默认的delete模式要强不少：
var connectionString = "Data Source=weigh.db;Version=3;Journal Mode=WAL;";6.3 抓拍图片与日志：磁盘空间是隐形杀手
一辆车过磅要抓拍多张图片，一天几百辆车就是上千张图片，一张按2MB算，一年下来几十GB。如果不做清理，磁盘满了之后抓拍失败、数据库写入失败，整个系统就瘫了。
我在项目里一般加一个定时清理任务，图片按日期归档，超过设定天数（比如90天）自动删除或压缩，流水记录里的图片路径跟着失效但记录本身不删。软件日志也按天滚动，保留最近30天即可，避免单个日志文件无限膨胀。
6.4 环境因素：补光、防雷与温度
设备稳定性的隐患往往在环境。车牌识别相机在夜间的补光灯角度如果没调好，车灯直射造成车牌反光，识别率会直线下降。现场摄像头尽量选带光敏传感器的，配合AForge调节曝光参数，能缓解不少逆光问题。
地磅现场的雷雨天气也是一大挑战，称重仪表、摄像头、道闸的通讯线缆如果没做好防雷和接地，一场雷雨就能打掉一块串口板。这部分在项目规划阶段就要重视，后期加装成本很高。
工控机还要注意散热和防尘。磅房夏天温度高，冬天如果没暖气，设备启动也可能出问题。选工控机时最好选无风扇宽温型号，哪怕贵一点也值得。
最后再分享一点我在这个行当里的体会。无人值守地磅软件的技术栈并不深，串口通讯、Modbus、状态机、数据库这些，任何一个C#开发者花时间都能学会。但真正让系统好用、稳定、让人放心，靠的是对现场的理解——磅房的灰尘、夜班的司机、偶发的雷雨、断掉的网络，这些才是开发中真正要面对的难题。如果你正在做类似的称重项目，或者准备接一套地磅软件的开发，希望这篇文章能让你少走一些弯路。有关状态机设计、串口协议解析的细节问题，欢迎交流，我可以把每个模块的完整实现思路再展开讲讲。
本文还有配套的精品资源，点击获取
