尧图网页设计 
简介基于 DevExpress v23.1 的固定式扫码系统 C# 源码面向需要开发工业扫码、条码采集及工位看板类应用的中高级 C# 工程师。资源在基础串口通信上做了完整封装内置 SerialPortUitls 工具类以事件回调方式实时接收扫码数据并完善了扫描报警和数据库查询功能适合直接迁移到生产项目或作为读码工位集成方案的起点。压缩包共 572 个文件约 120.67MB主体包括 170 个 dll 运行依赖、28 个 cs 源码文件、107 个 xml 配置与注释以及 resx 资源、png 图标、sql 数据库脚本和 VS 解决方案文件目录组织清晰可快速定位串口处理、报警逻辑和查询模块。目前已有 175 人浏览学习可重点参考其串口封装思路、报警联动设计以及 DevExpress 界面集成方式结合源码中的事件驱动接收模式与数据查询示例能大幅缩短固定式扫码系统的搭建与调试周期。1. 固定式扫码系统配上 DevExpress v23.1先看清这套 C# 源码到底解决什么问题DevExpress v23.1 固定式扫码系统 C# 源码拆开说就是一套桌面端上位机程序固定安装的扫码枪把条码收进来C# 负责读串口、解析、展示、落库DevExpress v23.1 负责把界面做得专业、把大数据量网格带起来。这类系统在产线质检、来料登记、工装模具出入库这类场景里很常见扫码枪架在工位上工件过来扫一下电脑屏幕上立刻能看到这个条码有没有扫到、是不是重码、已经扫了多少。它本质上是典型的 C# 上位机项目只是用了 DevExpress 这套商业控件看起来比纯 WinForms 原生控件精致不少。这个标题能承载的需求其实很直接要么你刚接到一个“给我的产线装一套扫码记录系统”的需求要么你手头正好有一套类似源码要接手改造。你需要的是把“界面、串口、数据库”这三大块打通而不是把 DevExpress 的每个控件都学会。这也引出一个反直觉的结论整条产线的稳定性往往不在扫码枪识别率上而在上位机软件怎么处理“扫码枪偶尔不出数据、偶尔出重复数据”这种边界情况。界面做得再漂亮队列和日志写不清楚现场照样翻车。适合人群很明确上位机工程师、准备接手扫码系统源码的维护者、想快速搭一套验证原型的产品负责人。2. 固定式扫码系统的整体框架先定硬件触发方式再谈 DevExpress 界面拿到“DevExpress v23.1 固定式扫码系统 C# 源码”这个标题时先别急着翻界面代码。固定式扫码系统是一套“硬件触发 上位机软件”的组合体常见做法是读码器固定安装工件经过时由光电感应器触发读码或者由上位机通过串口发一条命令让读码器扫描一次。这两种方式对应的设备参数和代码写法完全不一样先把这个定下来后面选控件、写界面、定数据库结构才不会返工。2.1 固定式扫码枪的选型与触发方式光眼、命令触发还是连续扫描做产线集成时我一般优先选带 IO 触发口的工业读码器比如常见的康耐视、基恩士或者国内的海康、大华等品牌它们都有串口和 IO 输出。一体机自带镜头和处理器分体机则把读码头和控制盒分开安装更灵活。选型的核心指标不是像素和分辨率而是“能不能稳定触发”。固定式扫码系统最容易翻车的地方就在这里读码器硬件本身扫得很快但上位机和它之间的“握手方式”一旦选错后面所有稳定性都无从谈起。三种触发方式的区别我用一张表说清楚触发方式触发来源适用场景数据特点光眼 / IO 触发光电传感器检测到位信号流水线自动扫描数据规范漏扫由硬件保证命令触发上位机串口发指令扫一次回一次人工工位、半自动设备上位机完全可控可加超时确认连续自动扫描读码器内部定时循环料堆盘点、传送带调试实现最简单但重码多必须过滤光眼触发是产线环境里最稳妥的方案光电传感器看到工件到位给读码器一个硬触发信号读码器扫完通过串口把条码发上来。这个链路里上位机只关心“收到没收到”不用操心触发时机。但光眼触发要拉 IO 信号线不是所有项目都能快速实施尤其改造老产线时工位布局可能根本不给你装传感器的位置。命令触发是软件工程师最容易先写通的一种方式因为不依赖额外硬件接线上位机发一条指令读码器扫一次简单直接。如果业务场景是“人来扫一枪”我更建议用命令触发配上超时提示。比如操作工把工件放到工位点一下“扫码”按钮上位机发触发指令读码器开始扫描3 秒内没扫到就语音报警。这种交互逻辑在光眼触发下反而不容易实现因为你不知道工件什么时候到位。连续自动扫描只适合测试台和料堆盘点正式产线不建议用因为它会产生大量重复扫码记录你不得不在软件里做重码过滤而过滤逻辑又会产生新的漏判风险。在这个章节就要定下一个代码层面的约定把触发方式抽象成一个接口上层界面只依赖接口不依赖具体触发实现。常见做法是定义ITrigger下面有IOTrigger和CommandTrigger两个实现。今天接的是串口读码器明天换 TCP 读码器或者换触发方式只改实现类不碰界面代码。固定式扫码系统的源码一旦剥离开硬件细节可维护性就上去了一大截。2.2 C# 工程分层让 DevExpress 控件只干界面的活别掺通信和数据库拿到一套 DevExpress 源码我第一件事就是看目录结构这是判断工程质量最直观的方式。很多下载来的“扫码系统源码”把串口代码直接写在Form_Load里全局变量到处飞接手的人连从哪里开始读都找不到。我一般会把工程按四层拆开每一层只干一件事。ScannerService负责串口或 TCP 的读写、协议解析对外只抛一个BarcodeScanned事件ScanBuffer是一个线程安全的条码队列把扫码枪的异步输入和界面的定时刷新解耦MainForm这层只做展示所有 DevExpress v23.1 控件都集中在这里不直接接触串口对象DataStore负责数据落库屏蔽 SQLite 的细节。这四层核心数据流是串口数据进队列UI 定时器取队列刷新网格后台线程把队列数据批量写库。这里有一个常见误区需要点出来有人觉得 DevExpress 是整套源码的核心拿到工程先研究 RibbonPage 怎么配置、GridView 的行样式怎么写。但对固定式扫码系统来说DevExpress 解决的是“给人看”的问题解决不了“数据没丢”的问题。真正决定现场口碑的是通信层和存储层。源码里有 DevExpress 工程并不稀奇真正值得看的是串口那几行是否做了异常处理、队列有没有边界控制、数据库有没有重复约束。实践顺序也很固定。第一步打开串口并绑定DataReceived事件第二步在事件里把收到的完整条码入队第三步 UI 定时器把队列里的条码刷新到网格第四步后台提交线程按批次写库。这个链路里最关键的其实是第二步到第三步之间的队列设计以及第三步到第四步之间的批量提交策略。后面两章会分别展开讲界面刷新和数据落库。收到一套“DevExpress v23.1 固定式扫码系统 C# 源码”先看三个文件就够了.sln工程结构App.config里的串口参数和数据库连接串以及ScannerService.cs或者最原始的那个Form1.cs。如果串口逻辑散落在各个窗体里那这套源码即使界面再漂亮改造价值也有限如果通信逻辑集中在独立类里那这就是一套可以拿来落地的底子。这也是判断“标题里的源码值不值得深入研究”最快的方式。3. 用 DevExpress v23.1 搭扫码结果主界面GridControl、Ribbon 与状态灯的活怎么分固定式扫码系统的界面不需要花哨但需要高效。操作工在产线边上站着眼睛扫一眼屏幕要立刻知道“刚才这个条码扫上了没有、有没有重码、今天一共扫了多少”。DevExpress v23.1 在这种场景下的价值主要体现在 GridControl 的性能和 Ribbon 的工具栏组织方式上。原生 DataGridView 在几千条数据时全量刷新会闪烁GridView 的缓存绘制机制会好很多列宽、冻结列、格式条件这些功能也省事。3.1 控件组合GridControl、Ribbon 与状态灯的活怎么分我常用的主界面布局分成三个区域。顶部是 RibbonControl放“开始扫码”“停止扫码”“导出 Excel”“参数设置”这些操作中间是 GridControl用来显示扫码明细记录每条数据包含条码、扫描时间、工位号、触发类型、重码状态底部或右侧用 PanelControl 加上 LabelControl 做状态统计显示已经扫了多少条、其中多少重码、当前通信是否正常。RibbonControl 在 DevExpress v23.1 里是默认的工具栏方案比传统 ToolStrip 在视觉上更接近现代软件但要注意别把功能堆太多。固定式扫码系统的操作工通常只需要一两个主按钮“开始扫码”和“停止扫码”放得足够大其他参数设置收进二级页面就好。我见过界面做得非常漂亮的扫码系统结果操作工找不到“开始”按钮在哪那种界面再漂亮也是失败的。GridControl 是这套系统的绝对主角。显示扫码记录时我用 GridView 而不是 TileView。TileView 的卡片式布局在展示“最近几条”时很直观但记录条数一多卡片渲染的开销明显更高产线连续扫一天几千上万条记录全部渲染成卡片性能会很难看。我的做法是主力表格用 GridView需要看最近扫码状态时用 DevExpress 的另一个视图或直接用 GridView 的顶部几个固定行展示。状态灯区域看起来简单其实很考验细节。我会在 PanelControl 里放三个 LabelControl 分别显示“今日总数”“重码数”“通信状态”然后用定时器每 500 毫秒刷新一次。通信状态这一项最容易忽略也最重要——串口掉了操作工不会立刻发现等发现时可能已经漏了几十件。状态灯用绿色代表正常红色代表串口断开或读码器异常这个信息比统计数字更先被操作工的余光捕捉到。3.2 扫码结果实时刷新与行状态着色GridControl 的事件与数据流代码固定式扫码系统有个特点条码是异步到达的扫码枪可能在任意时刻抛出一条数据。很多新手喜欢在串口DataReceived事件里直接gridView1.AddNewRow()产线一忙界面整个卡住。解决思路是所有通信线程只做一件事把数据放进ConcurrentQueueUI 线程用定时器批量取。这样串口接收线程永远不阻塞UI 的刷新节奏完全由程序控制。串口接收的核心代码是这样一段// 串口接收不解析、不刷屏只入队 private readonly ConcurrentQueuestring _barcodeQueue new ConcurrentQueuestring(); private readonly StringBuilder _buffer new StringBuilder(); private void SerialPort_DataReceived(object sender, SerialDataReceivedEventArgs e) { var port (SerialPort)sender; _buffer.Append(port.ReadExisting()); // 以回车换行作为一条完整条码的结束标志 if (_buffer.ToString().EndsWith(\r\n)) { string rawCode _buffer.ToString().Trim(); _buffer.Clear(); if (!string.IsNullOrEmpty(rawCode)) { _barcodeQueue.Enqueue(rawCode); } } }这里用ReadExisting()而不是ReadLine()原因是现场串口数据不一定每次都把结束符完整送到ReadLine()会一直等待一旦结束符丢失就卡死在那里ReadExisting()只读当前缓冲区里已有的字符配合StringBuilder做拼包反而更稳。Trim()是为了去掉条码前后可能混进来的空格、回车、换行和读码器附加的 ASCII 控制字符。ConcurrentQueue是线程安全的接收线程只入队速度最快也不会和 UI 线程产生锁竞争。UI 侧用System.Windows.Forms.Timer做定时刷新我习惯把Interval设为 500 毫秒。这个参数很讲究太快了定时器频繁访问队列和处理界面CPU 白白浪费太慢了扫码枪扫完到屏幕显示有明显的延迟操作工会觉得系统反应迟钝。500 毫秒对大多数产线场景都是合适的折中值。定时器事件里的逻辑是把队列里攒下的新条码一次性拿出来逐条加进网格数据源// UI 定时器每 500ms 批量刷新一次网格 private void uiTimer_Tick(object sender, EventArgs e) { var newItems new ListScanRecord(); while (_barcodeQueue.TryDequeue(out string code)) { newItems.Add(new ScanRecord { Barcode code, ScanTime DateTime.Now, IsDuplicated CheckDuplicated(code) }); } if (newItems.Count 0) return; records.AddRange(newItems); // records 是 BindingListScanRecord gridControl1.RefreshDataSource(); UpdateStatistics(); }数据源我用BindingListScanRecord而不是直接给 GridControl 赋ListT。原因在于BindingListT支持增量通知Add之后 GridView 能自动感知并刷新新行不会重置整个数据源ListT每次重新赋值DataSourceGridView 的列配置、排序状态、格式条件都会被冲掉。CheckDuplicated是查一个HashSetstring或者查当天数据库记录前者快后者更严谨看业务对重复判定的要求有多高。行状态着色是固定式扫码系统界面里最实用的功能之一重码标黄异常条码标红正常扫码不标色。操作工不用读内容一眼扫过去就知道哪条有问题。DevExpress 的 GridView 提供了RowCellStyle事件在行绘制前修改外观// 给重码行标黄给解析失败的行标红 private void gridView1_RowCellStyle(object sender, RowCellStyleEventArgs e) { if (e.Column.FieldName ! Barcode) return; var record gridView1.GetRow(e.RowHandle) as ScanRecord; if (record null) return; if (record.IsDuplicated) { e.Appearance.BackColor Color.FromArgb(255, 224, 178); } else if (record.IsError) { e.Appearance.BackColor Color.FromArgb(255, 192, 192); } }RowCellStyle是行绘制阶段的回调不是每加一条数据就全表重新绘制所以性能开销很小。要注意GetRow返回的是数据对象必须先判空再访问属性否则网格正在滚动或刷新时可能拿到空行导致空引用异常。这条代码里IsDuplicated和IsError都是ScanRecord上的布尔属性在构造函数里根据业务规则算好界面层不做重码判断保持职责单一。网格布局还有个容易被忽略的小点列宽和列顺序应当允许操作工调整但调整结果要保存下来不然每次重启程序都恢复默认。这个问题的典型表现和排查方式我会在第五章专门写这里只提醒一句GridControl 的列配置、筛选条件、排序状态都可以通过SaveLayoutToXml持久化到本地文件这是 v23.1 里很成熟的功能不用自己写注册表。4. 把扫码数据安全落进 SQLite连接串参数、批量事务与防丢策略固定式扫码系统的数据层经常被当成“附带功能”觉得不就是存条码吗随便写个数据库就行。实际操作中不是这么回事。扫码数据是高频追加数据产线一天几千条是常态峰值时可能几秒内连续来几十条而且这些数据还要被报表、看板、追溯系统反复读取。如果存储层设计得不好界面操作会被文件锁卡住数据还可能因为断电丢在内存里。这一章我把数据层的选型理由和写入策略展开讲。4.1 为什么固定式扫码系统的数据层优先选 SQLite 而不是 SQL Server固定式扫码上位机的部署环境多半是产线工控机大多数时候不会有人专门维护数据库服务。这条约束基本决定了选型方向一台机器、一个软件、单一写者数据量一天几千条到一两万条SQLite 恰好落在它的舒适区里。相比 SQL Server Express它免安装、免配置、单文件相比 Access它在并发读取和崩溃恢复上要可靠得多。下面这张对比表是我给现场实施团队讲选型时常用的一张表方案部署成本并发写能力崩溃恢复适合场景SQLite零随程序附带单写多读够用WAL 模式恢复可靠单机上位机、产线记录SQL Server Express需要安装服务配置较繁强强有 IT 团队的联网生产线Access Jet零但脆弱弱差文件易损坏原型或数据量极小的场景固定式扫码系统的数据模型是“单写多读”一个上位机进程负责写入扫码记录另外可能有统计界面、看板程序在同时读取同一个数据库文件。SQLite 的锁策略支持一个写连接和多个读连接并行前提是数据库要开启 WAL 模式。WAL 的全称是 Write-Ahead Logging它把新的写入追加到独立的.db-wal文件里写事务不再直接阻塞读操作读操作也不会阻塞写操作。这个模式对扫码系统这种“一边写入、一边查询统计”的场景非常合适。SQLite 也不是万能的。如果现场有两台电脑同时往同一个数据库文件里写比如两台扫码工位共用一台文件服务器的共享目录那 SQLite 的锁竞争会让双方都频繁报“database is locked”。遇到这种需求正确做法是后端换 SQL Server 或者 MySQL而不是在 SQLite 上加重试。固定式扫码系统多数是单机部署所以 SQLite 是我默认的推荐方案。连接串的写法也直接影响稳定性。我用的是Microsoft.Data.Sqlite连接串如下// SQLite 连接串与打开后的 PRAGMA 设置 string connStr Data Sourcescanlog.db;CacheShared;; using var conn new SqliteConnection(connStr); conn.Open(); using var pragmaCmd conn.CreateCommand(); pragmaCmd.CommandText PRAGMA journal_modeWAL; PRAGMA synchronousNORMAL; PRAGMA busy_timeout5000;; pragmaCmd.ExecuteNonQuery();这里说明几个参数的实际作用。journal_modeWAL解决读写互相阻塞的问题代价是目录里多出-wal和-shm两个文件程序退出时如果已经正常提交WAL 文件会自动合并回主数据库不要手动删它。synchronousNORMAL在 WAL 模式下已经能保证不丢已提交的数据比FULL快很多如果现场对数据安全有极端要求可以改成FULL但写入延迟会明显增加。busy_timeout5000是等待锁的时间单位是毫秒它让多个连接竞争同一文件时不会立刻报错而是等待对方事务结束这对同时开一个统计界面的场景很关键。4.2 扫码频率高时的写入策略缓冲队列、批量事务与防重复入库上位机软件接收扫码数据是事件驱动的数据到达的时间和频率完全不可控。如果每次收到一条条码就 INSERT 一条SQLite 的文件锁会被反复打开关闭事务提交也是一次一次地写磁盘写入慢不说频繁的锁操作还会拖累同一时刻的查询界面。常见做法是在内存里加一层缓冲队列攒够一定条数或一定时间再统一提交。我用一个后台提交线程专门负责这件事。主程序把扫码记录放进ConcurrentQueueScanRecord提交线程定时检查达到批量条件后取出一批数据在同一个事务里插入。事务的意义在于一批记录要么全部写入成功要么全部回滚中间不会出现写了一半的情况而且一个事务整体只需要做一次文件同步比逐条插入快得多。批量插入的核心代码如下// 批量写库同事务插入多条记录单次提交 private void FlushBatch(ListScanRecord batch) { using var conn new SqliteConnection(_connString); conn.Open(); using var tx conn.BeginTransaction(); var cmd conn.CreateCommand(); cmd.Transaction tx; cmd.CommandText INSERT INTO scan_log (barcode, scan_time, line, station, trigger_type) VALUES ($barcode, $scan_time, $line, $station, $trigger_type);; foreach (var item in batch) { cmd.Parameters.Clear(); cmd.Parameters.AddWithValue($barcode, item.Barcode); cmd.Parameters.AddWithValue($scan_time, item.ScanTime.ToString(yyyy-MM-dd HH:mm:ss.fff)); cmd.Parameters.AddWithValue($line, item.Line); cmd.Parameters.AddWithValue($station, item.Station); cmd.Parameters.AddWithValue($trigger_type, item.TriggerType); cmd.ExecuteNonQuery(); } tx.Commit(); }这里有个细节值得多说一句SQLite 的命名参数用$开头这是 SQLite 自己的参数风格和 C# 的字符串插值没有任何关系。cmd.Parameters.Clear()非常必要因为同一个SqliteCommand在执行多条插入时参数集合不会自动清空不清空会导致上一次的参数值残留到下一次执行里。ExecuteNonQuery每调用一次就执行一条插入语句但因为整个批次被包在同一个事务里SQLite 只在Commit()时才真正做一次文件同步所以性能损失可控。批量大小的设置也有讲究。我一般定两个条件批量达到 100 条或者距离上一次提交超过 2 秒满足任一条件就触发提交。太小了比如每 10 条就提交一次事务优势体现不出来文件锁还是被频繁占用太大了比如攒 1000 条才提交一旦程序崩溃或断电内存里未提交的数据会全部丢失。100 条和 2 秒这个组合在大多数产线场景下能在“数据安全”和“写入性能”之间找到平衡点。如果工位一天只有几百条数据可以把批量调小到 50 条同时把时间条件改为 5 秒降低空提交的频率。防重复入库是固定式扫码系统的另一道必修课。生产现场的同一个条码可能被多次扫到原因可能是工件回流、操作工重复触发也可能是读码器连续自动扫描。业务上要区分“重扫”和“一码多扫”重扫意味着上一次扫描结果作废一码多扫则要决定要不要记录第二次。我的做法是在scan_log表上对barcode字段建普通索引再配合HashSet做近期内容去重如果业务要求数据库层面绝对不重复就建UNIQUE约束并用INSERT OR IGNORE写入让 SQLite 自己过滤掉重复条码。注意INSERT OR IGNORE会静默忽略冲突记录如果你需要知道“哪些条码是重复的”就不能只依赖它还需要在应用层先做一次判定把重复标记写进业务字段。5. 固定式扫码系统在 v23.1 下的 5 个踩坑记录与排查思路这一章写的都是我在现场和接手源码时真实见过的坑。大部分问题不在 DevExpress 控件本身而是“串口 UI 数据库”三个模块接缝处的典型失误。每一条我都按“现象 → 原因 → 解决”的顺序来写方便你排查时直接对照。5.1 扫码枪连接正常但上位机就是收不到数据现象扫码枪在厂家自带的调试软件里能正常扫出条码串口线、USB 转串口驱动也没问题但 C# 程序打开串口后怎么扫都没有数据。原因基本逃不出三处一是串口参数对不上波特率、数据位、停止位、校验位任何一个和读码器实际设置不一致收到的都是乱码或者完全无响应二是触发方式不匹配读码器设置成光眼触发但光眼线没接或者没有物体通过三是程序用ReadLine()等结束符而读码器的输出格式里没有回车换行导致数据一直停在串口缓冲区里。排查顺序我一般这样走先用串口调试工具把波特率调成和读码器设置一致手动触发一次扫描看裸数据是否正常返回。如果裸串口有数据而程序收不到重点查触发方式和结束符如果裸串口也没数据重点查串口参数和读码器设置。程序侧临时把ReadLine()换成ReadExisting()并加上超时提示往往能立刻定位问题。5.2 扫码越多界面越卡CPU 一路飙升现象手动扫一两下没感觉产线一开工界面半小时后开始明显卡顿任务管理器里 CPU 占用率居高不下。原因最常见的只有两个一个是串口DataReceived事件里直接调了 UI 控件比如gridView1.AddNewRow()扫码频率一高UI 线程被大量跨线程调用淹没另一个是网格数据无限增长扫码记录攒了几万行GridView 全表重绘的开销越来越大。解决办法分两段。接收侧按第三章的方式改造成队列模式串口线程只入队UI 侧用定时器批量刷新。如果已经是队列模式但还是卡就要检查网格行数是不是失控了常见做法是只保留当天的扫码记录或者做成翻页视图以及用gridView1.BeginUpdate()包住批量插入操作插入完成后再EndUpdate()避免每一行都触发一次重绘。DevExpress 的 GridControl 在几千行内性能完全没问题如果上万行就开始卡先怀疑是不是开启了RowAutoHeight或者AllowHtmlDraw这类高开销选项。5.3 条码内容多了几个字符或者中文变成乱码现象原条码是ABC-123-456程序里显示成ABC-123-456后面带一个方框或者多一个换行带中文的条码显示成???或乱码。原因同样是两处一是条码数据本身携带了规定的结束符比如回车\r和换行\n程序入库前没清洗二是SerialPort的Encoding属性设置不对读码器输出的是 GB2312程序按 UTF-8 解码中文自然变成问号。解决时一个动作是入队前统一做Trim()去掉条码首尾的空白和控制字符另一个动作是按读码器说明书把SerialPort.Encoding设置为Encoding.Default或具体的 GBK 编码。这里要特别提醒一点如果读码器输出的条码中间本身包含空格不能用单纯Replace( , )的方式清洗否则会把有效内容破坏掉正确做法是只去掉首尾控制字符和结束符。5.4 GridControl 的布局每次重启都恢复默认操作工反复重新调列现象操作工把列宽调好、把拖动顺序调整好甚至设置了筛选条件第二天上班启动程序全部恢复成原始状态。原因GridView 的布局默认只停留在内存里没有持久化到磁盘。DevExpress v23.1 没有自动保存布局的开关需要开发者在代码里主动调用保存和恢复接口。解决方式很直接。窗体关闭时调用SaveLayoutToXml把列顺序、列宽、筛选条件、排序状态保存到一个 XML 文件窗体加载时先判断文件存在再调用RestoreLayoutFromXml恢复。相关代码是下面这样// 保存网格布局到本地 XML string layoutPath Path.Combine(AppContext.BaseDirectory, gridLayout.xml); private void MainForm_FormClosing(object sender, FormClosingEventArgs e) { gridView1.SaveLayoutToXml(layoutPath); } private void MainForm_Load(object sender, EventArgs e) { if (File.Exists(layoutPath)) { gridView1.RestoreLayoutFromXml(layoutPath); } }注意一点布局文件的兼容性通常只在同一 DevExpress 主版本内保证比如 v23.1 保存的布局文件在 v23.2 里可以尝试恢复但不保证完全兼容升级控件版本后最好让用户重新保存一次布局。如果工程里同时存在多个 GridView每个视图都要单独指定一个布局文件路径避免互相覆盖。5.5 源码换到另一台电脑编译报错“DevExpress”命名空间不存在现象源码在一台电脑上编译运行正常Git 拉到另一台电脑打开工程后所有 DevExpress 相关引用全部飘红报“命名空间不存在”或“类型或命名空间名称 DevExpress 未找到”。原因DevExpress 控件程序集的安装路径和版本在不同机器上不一致。工程文件里如果引用的是带版本号的程序集比如DevExpress.XtraGrid.v23.1.dll并且 HintPath 写的是原来那台机器上的安装目录新机器上目录不一样引用自然解析不到。v23.1 是版本绑定很严格的一套控件混用 22.2 和 23.1 的程序集也会出现类似问题。解决时先确认新机器安装的 DevExpress 版本然后把工程里所有 DevExpress 引用的 HintPath 改成新机器实际路径或者统一改成相对路径比如把所有需要的 DLL 复制到工程下的libs/目录引用路径都指向..\libs\DevExpress.XtraGrid.v23.1.dll。这样换机器、换目录都不会丢引用。如果项目里引用的是 NuGet 包方式则先执行nuget restore再重新生成如果代码逻辑没问题但引用一直飘红把bin和obj目录清掉重新编译能解决大部分“明明路径没错还是找不到”的玄学问题。提示源码工程里最容易出问题的不是业务代码而是 DevExpress 程序集的引用路径被写死到某台机器的 GAC 或安装目录里。你拿到源码后先检查.csproj里的 HintPath 是否包含绝对路径这条信息能直接判断这套源码的工程化水平。6. 让固定式扫码系统的数据更可信三个低成本改进技巧6.1 断线重连比报错提示更实际产线现场的 USB 转串口经常因为供电不稳或接口松动掉线。程序如果只是弹一个“串口断开”的提示框并停止工作操作工根本不会处理。我一般会加一个后台重连定时器检测到串口断开后每隔两秒尝试重新打开一次期间新扫到的数据先进入队列缓存串口恢复后继续写库。这个改动不大但对稳定性的提升立竿见影。6.2 日志字段别只存“条码 时间”最容易低估的是上下文字段的价值。scan_log表里的字段如果只有barcode和scan_time出问题时只能证明系统扫过这个条码但没法证明这个条码是在哪个工位、由哪台设备、用什么触发方式扫的。给表加上line、station、trigger_type这几个字段成本极低追溯问题时却少走很多弯路。上一章的INSERT语句里已经体现了这几个字段实际建表时把它们做成非空字段录入逻辑从一开始就补全。6.3 “扫码成功”和“扫描已确认”是两个状态固定式扫码系统里最常见的业务漏洞是把扫码当成一次性动作扫到了就等于入库了入库了就等于投料完成了。实际上产线可能因为条码贴歪、重码、错扫导致记录不准确。常见做法是给记录增加一个confirm_status字段0 待确认1 已确认2 重扫。操作工在界面上看到条码后确认状态才从待确认变成已确认重扫时不删除原记录而是新增一条状态为重扫的记录保留完整现场。这样每一条数据都有据可查。我在这类系统上吃过一次亏早期做的一套系统里扫码完成直接当成投料完成没有状态机也没有上下文日志。后来产线反馈有漏投料但系统里所有条码都显示已经扫过根本追查不出是哪个工位、哪台设备出了问题。把状态和上下文字段补上之后才真正把扫码系统做成了闭环。如果你要接手一套 DevExpress 固定式扫码系统源码我最诚恳的建议是先别急着跑界面把串口、队列、落库这一条链路画清楚链路通了再谈界面好不好看。希望帮到你。本文还有配套的精品资源点击获取 DevExpress v23.1固定式扫码系统C#源码实战解析
简介基于 DevExpress v23.1 的固定式扫码系统 C# 源码面向需要开发工业扫码、条码采集及工位看板类应用的中高级 C# 工程师。资源在基础串口通信上做了完整封装内置 SerialPortUitls 工具类以事件回调方式实时接收扫码数据并完善了扫描报警和数据库查询功能适合直接迁移到生产项目或作为读码工位集成方案的起点。压缩包共 572 个文件约 120.67MB主体包括 170 个 dll 运行依赖、28 个 cs 源码文件、107 个 xml 配置与注释以及 resx 资源、png 图标、sql 数据库脚本和 VS 解决方案文件目录组织清晰可快速定位串口处理、报警逻辑和查询模块。目前已有 175 人浏览学习可重点参考其串口封装思路、报警联动设计以及 DevExpress 界面集成方式结合源码中的事件驱动接收模式与数据查询示例能大幅缩短固定式扫码系统的搭建与调试周期。1. 固定式扫码系统配上 DevExpress v23.1先看清这套 C# 源码到底解决什么问题DevExpress v23.1 固定式扫码系统 C# 源码拆开说就是一套桌面端上位机程序固定安装的扫码枪把条码收进来C# 负责读串口、解析、展示、落库DevExpress v23.1 负责把界面做得专业、把大数据量网格带起来。这类系统在产线质检、来料登记、工装模具出入库这类场景里很常见扫码枪架在工位上工件过来扫一下电脑屏幕上立刻能看到这个条码有没有扫到、是不是重码、已经扫了多少。它本质上是典型的 C# 上位机项目只是用了 DevExpress 这套商业控件看起来比纯 WinForms 原生控件精致不少。这个标题能承载的需求其实很直接要么你刚接到一个“给我的产线装一套扫码记录系统”的需求要么你手头正好有一套类似源码要接手改造。你需要的是把“界面、串口、数据库”这三大块打通而不是把 DevExpress 的每个控件都学会。这也引出一个反直觉的结论整条产线的稳定性往往不在扫码枪识别率上而在上位机软件怎么处理“扫码枪偶尔不出数据、偶尔出重复数据”这种边界情况。界面做得再漂亮队列和日志写不清楚现场照样翻车。适合人群很明确上位机工程师、准备接手扫码系统源码的维护者、想快速搭一套验证原型的产品负责人。2. 固定式扫码系统的整体框架先定硬件触发方式再谈 DevExpress 界面拿到“DevExpress v23.1 固定式扫码系统 C# 源码”这个标题时先别急着翻界面代码。固定式扫码系统是一套“硬件触发 上位机软件”的组合体常见做法是读码器固定安装工件经过时由光电感应器触发读码或者由上位机通过串口发一条命令让读码器扫描一次。这两种方式对应的设备参数和代码写法完全不一样先把这个定下来后面选控件、写界面、定数据库结构才不会返工。2.1 固定式扫码枪的选型与触发方式光眼、命令触发还是连续扫描做产线集成时我一般优先选带 IO 触发口的工业读码器比如常见的康耐视、基恩士或者国内的海康、大华等品牌它们都有串口和 IO 输出。一体机自带镜头和处理器分体机则把读码头和控制盒分开安装更灵活。选型的核心指标不是像素和分辨率而是“能不能稳定触发”。固定式扫码系统最容易翻车的地方就在这里读码器硬件本身扫得很快但上位机和它之间的“握手方式”一旦选错后面所有稳定性都无从谈起。三种触发方式的区别我用一张表说清楚触发方式触发来源适用场景数据特点光眼 / IO 触发光电传感器检测到位信号流水线自动扫描数据规范漏扫由硬件保证命令触发上位机串口发指令扫一次回一次人工工位、半自动设备上位机完全可控可加超时确认连续自动扫描读码器内部定时循环料堆盘点、传送带调试实现最简单但重码多必须过滤光眼触发是产线环境里最稳妥的方案光电传感器看到工件到位给读码器一个硬触发信号读码器扫完通过串口把条码发上来。这个链路里上位机只关心“收到没收到”不用操心触发时机。但光眼触发要拉 IO 信号线不是所有项目都能快速实施尤其改造老产线时工位布局可能根本不给你装传感器的位置。命令触发是软件工程师最容易先写通的一种方式因为不依赖额外硬件接线上位机发一条指令读码器扫一次简单直接。如果业务场景是“人来扫一枪”我更建议用命令触发配上超时提示。比如操作工把工件放到工位点一下“扫码”按钮上位机发触发指令读码器开始扫描3 秒内没扫到就语音报警。这种交互逻辑在光眼触发下反而不容易实现因为你不知道工件什么时候到位。连续自动扫描只适合测试台和料堆盘点正式产线不建议用因为它会产生大量重复扫码记录你不得不在软件里做重码过滤而过滤逻辑又会产生新的漏判风险。在这个章节就要定下一个代码层面的约定把触发方式抽象成一个接口上层界面只依赖接口不依赖具体触发实现。常见做法是定义ITrigger下面有IOTrigger和CommandTrigger两个实现。今天接的是串口读码器明天换 TCP 读码器或者换触发方式只改实现类不碰界面代码。固定式扫码系统的源码一旦剥离开硬件细节可维护性就上去了一大截。2.2 C# 工程分层让 DevExpress 控件只干界面的活别掺通信和数据库拿到一套 DevExpress 源码我第一件事就是看目录结构这是判断工程质量最直观的方式。很多下载来的“扫码系统源码”把串口代码直接写在Form_Load里全局变量到处飞接手的人连从哪里开始读都找不到。我一般会把工程按四层拆开每一层只干一件事。ScannerService负责串口或 TCP 的读写、协议解析对外只抛一个BarcodeScanned事件ScanBuffer是一个线程安全的条码队列把扫码枪的异步输入和界面的定时刷新解耦MainForm这层只做展示所有 DevExpress v23.1 控件都集中在这里不直接接触串口对象DataStore负责数据落库屏蔽 SQLite 的细节。这四层核心数据流是串口数据进队列UI 定时器取队列刷新网格后台线程把队列数据批量写库。这里有一个常见误区需要点出来有人觉得 DevExpress 是整套源码的核心拿到工程先研究 RibbonPage 怎么配置、GridView 的行样式怎么写。但对固定式扫码系统来说DevExpress 解决的是“给人看”的问题解决不了“数据没丢”的问题。真正决定现场口碑的是通信层和存储层。源码里有 DevExpress 工程并不稀奇真正值得看的是串口那几行是否做了异常处理、队列有没有边界控制、数据库有没有重复约束。实践顺序也很固定。第一步打开串口并绑定DataReceived事件第二步在事件里把收到的完整条码入队第三步 UI 定时器把队列里的条码刷新到网格第四步后台提交线程按批次写库。这个链路里最关键的其实是第二步到第三步之间的队列设计以及第三步到第四步之间的批量提交策略。后面两章会分别展开讲界面刷新和数据落库。收到一套“DevExpress v23.1 固定式扫码系统 C# 源码”先看三个文件就够了.sln工程结构App.config里的串口参数和数据库连接串以及ScannerService.cs或者最原始的那个Form1.cs。如果串口逻辑散落在各个窗体里那这套源码即使界面再漂亮改造价值也有限如果通信逻辑集中在独立类里那这就是一套可以拿来落地的底子。这也是判断“标题里的源码值不值得深入研究”最快的方式。3. 用 DevExpress v23.1 搭扫码结果主界面GridControl、Ribbon 与状态灯的活怎么分固定式扫码系统的界面不需要花哨但需要高效。操作工在产线边上站着眼睛扫一眼屏幕要立刻知道“刚才这个条码扫上了没有、有没有重码、今天一共扫了多少”。DevExpress v23.1 在这种场景下的价值主要体现在 GridControl 的性能和 Ribbon 的工具栏组织方式上。原生 DataGridView 在几千条数据时全量刷新会闪烁GridView 的缓存绘制机制会好很多列宽、冻结列、格式条件这些功能也省事。3.1 控件组合GridControl、Ribbon 与状态灯的活怎么分我常用的主界面布局分成三个区域。顶部是 RibbonControl放“开始扫码”“停止扫码”“导出 Excel”“参数设置”这些操作中间是 GridControl用来显示扫码明细记录每条数据包含条码、扫描时间、工位号、触发类型、重码状态底部或右侧用 PanelControl 加上 LabelControl 做状态统计显示已经扫了多少条、其中多少重码、当前通信是否正常。RibbonControl 在 DevExpress v23.1 里是默认的工具栏方案比传统 ToolStrip 在视觉上更接近现代软件但要注意别把功能堆太多。固定式扫码系统的操作工通常只需要一两个主按钮“开始扫码”和“停止扫码”放得足够大其他参数设置收进二级页面就好。我见过界面做得非常漂亮的扫码系统结果操作工找不到“开始”按钮在哪那种界面再漂亮也是失败的。GridControl 是这套系统的绝对主角。显示扫码记录时我用 GridView 而不是 TileView。TileView 的卡片式布局在展示“最近几条”时很直观但记录条数一多卡片渲染的开销明显更高产线连续扫一天几千上万条记录全部渲染成卡片性能会很难看。我的做法是主力表格用 GridView需要看最近扫码状态时用 DevExpress 的另一个视图或直接用 GridView 的顶部几个固定行展示。状态灯区域看起来简单其实很考验细节。我会在 PanelControl 里放三个 LabelControl 分别显示“今日总数”“重码数”“通信状态”然后用定时器每 500 毫秒刷新一次。通信状态这一项最容易忽略也最重要——串口掉了操作工不会立刻发现等发现时可能已经漏了几十件。状态灯用绿色代表正常红色代表串口断开或读码器异常这个信息比统计数字更先被操作工的余光捕捉到。3.2 扫码结果实时刷新与行状态着色GridControl 的事件与数据流代码固定式扫码系统有个特点条码是异步到达的扫码枪可能在任意时刻抛出一条数据。很多新手喜欢在串口DataReceived事件里直接gridView1.AddNewRow()产线一忙界面整个卡住。解决思路是所有通信线程只做一件事把数据放进ConcurrentQueueUI 线程用定时器批量取。这样串口接收线程永远不阻塞UI 的刷新节奏完全由程序控制。串口接收的核心代码是这样一段// 串口接收不解析、不刷屏只入队 private readonly ConcurrentQueuestring _barcodeQueue new ConcurrentQueuestring(); private readonly StringBuilder _buffer new StringBuilder(); private void SerialPort_DataReceived(object sender, SerialDataReceivedEventArgs e) { var port (SerialPort)sender; _buffer.Append(port.ReadExisting()); // 以回车换行作为一条完整条码的结束标志 if (_buffer.ToString().EndsWith(\r\n)) { string rawCode _buffer.ToString().Trim(); _buffer.Clear(); if (!string.IsNullOrEmpty(rawCode)) { _barcodeQueue.Enqueue(rawCode); } } }这里用ReadExisting()而不是ReadLine()原因是现场串口数据不一定每次都把结束符完整送到ReadLine()会一直等待一旦结束符丢失就卡死在那里ReadExisting()只读当前缓冲区里已有的字符配合StringBuilder做拼包反而更稳。Trim()是为了去掉条码前后可能混进来的空格、回车、换行和读码器附加的 ASCII 控制字符。ConcurrentQueue是线程安全的接收线程只入队速度最快也不会和 UI 线程产生锁竞争。UI 侧用System.Windows.Forms.Timer做定时刷新我习惯把Interval设为 500 毫秒。这个参数很讲究太快了定时器频繁访问队列和处理界面CPU 白白浪费太慢了扫码枪扫完到屏幕显示有明显的延迟操作工会觉得系统反应迟钝。500 毫秒对大多数产线场景都是合适的折中值。定时器事件里的逻辑是把队列里攒下的新条码一次性拿出来逐条加进网格数据源// UI 定时器每 500ms 批量刷新一次网格 private void uiTimer_Tick(object sender, EventArgs e) { var newItems new ListScanRecord(); while (_barcodeQueue.TryDequeue(out string code)) { newItems.Add(new ScanRecord { Barcode code, ScanTime DateTime.Now, IsDuplicated CheckDuplicated(code) }); } if (newItems.Count 0) return; records.AddRange(newItems); // records 是 BindingListScanRecord gridControl1.RefreshDataSource(); UpdateStatistics(); }数据源我用BindingListScanRecord而不是直接给 GridControl 赋ListT。原因在于BindingListT支持增量通知Add之后 GridView 能自动感知并刷新新行不会重置整个数据源ListT每次重新赋值DataSourceGridView 的列配置、排序状态、格式条件都会被冲掉。CheckDuplicated是查一个HashSetstring或者查当天数据库记录前者快后者更严谨看业务对重复判定的要求有多高。行状态着色是固定式扫码系统界面里最实用的功能之一重码标黄异常条码标红正常扫码不标色。操作工不用读内容一眼扫过去就知道哪条有问题。DevExpress 的 GridView 提供了RowCellStyle事件在行绘制前修改外观// 给重码行标黄给解析失败的行标红 private void gridView1_RowCellStyle(object sender, RowCellStyleEventArgs e) { if (e.Column.FieldName ! Barcode) return; var record gridView1.GetRow(e.RowHandle) as ScanRecord; if (record null) return; if (record.IsDuplicated) { e.Appearance.BackColor Color.FromArgb(255, 224, 178); } else if (record.IsError) { e.Appearance.BackColor Color.FromArgb(255, 192, 192); } }RowCellStyle是行绘制阶段的回调不是每加一条数据就全表重新绘制所以性能开销很小。要注意GetRow返回的是数据对象必须先判空再访问属性否则网格正在滚动或刷新时可能拿到空行导致空引用异常。这条代码里IsDuplicated和IsError都是ScanRecord上的布尔属性在构造函数里根据业务规则算好界面层不做重码判断保持职责单一。网格布局还有个容易被忽略的小点列宽和列顺序应当允许操作工调整但调整结果要保存下来不然每次重启程序都恢复默认。这个问题的典型表现和排查方式我会在第五章专门写这里只提醒一句GridControl 的列配置、筛选条件、排序状态都可以通过SaveLayoutToXml持久化到本地文件这是 v23.1 里很成熟的功能不用自己写注册表。4. 把扫码数据安全落进 SQLite连接串参数、批量事务与防丢策略固定式扫码系统的数据层经常被当成“附带功能”觉得不就是存条码吗随便写个数据库就行。实际操作中不是这么回事。扫码数据是高频追加数据产线一天几千条是常态峰值时可能几秒内连续来几十条而且这些数据还要被报表、看板、追溯系统反复读取。如果存储层设计得不好界面操作会被文件锁卡住数据还可能因为断电丢在内存里。这一章我把数据层的选型理由和写入策略展开讲。4.1 为什么固定式扫码系统的数据层优先选 SQLite 而不是 SQL Server固定式扫码上位机的部署环境多半是产线工控机大多数时候不会有人专门维护数据库服务。这条约束基本决定了选型方向一台机器、一个软件、单一写者数据量一天几千条到一两万条SQLite 恰好落在它的舒适区里。相比 SQL Server Express它免安装、免配置、单文件相比 Access它在并发读取和崩溃恢复上要可靠得多。下面这张对比表是我给现场实施团队讲选型时常用的一张表方案部署成本并发写能力崩溃恢复适合场景SQLite零随程序附带单写多读够用WAL 模式恢复可靠单机上位机、产线记录SQL Server Express需要安装服务配置较繁强强有 IT 团队的联网生产线Access Jet零但脆弱弱差文件易损坏原型或数据量极小的场景固定式扫码系统的数据模型是“单写多读”一个上位机进程负责写入扫码记录另外可能有统计界面、看板程序在同时读取同一个数据库文件。SQLite 的锁策略支持一个写连接和多个读连接并行前提是数据库要开启 WAL 模式。WAL 的全称是 Write-Ahead Logging它把新的写入追加到独立的.db-wal文件里写事务不再直接阻塞读操作读操作也不会阻塞写操作。这个模式对扫码系统这种“一边写入、一边查询统计”的场景非常合适。SQLite 也不是万能的。如果现场有两台电脑同时往同一个数据库文件里写比如两台扫码工位共用一台文件服务器的共享目录那 SQLite 的锁竞争会让双方都频繁报“database is locked”。遇到这种需求正确做法是后端换 SQL Server 或者 MySQL而不是在 SQLite 上加重试。固定式扫码系统多数是单机部署所以 SQLite 是我默认的推荐方案。连接串的写法也直接影响稳定性。我用的是Microsoft.Data.Sqlite连接串如下// SQLite 连接串与打开后的 PRAGMA 设置 string connStr Data Sourcescanlog.db;CacheShared;; using var conn new SqliteConnection(connStr); conn.Open(); using var pragmaCmd conn.CreateCommand(); pragmaCmd.CommandText PRAGMA journal_modeWAL; PRAGMA synchronousNORMAL; PRAGMA busy_timeout5000;; pragmaCmd.ExecuteNonQuery();这里说明几个参数的实际作用。journal_modeWAL解决读写互相阻塞的问题代价是目录里多出-wal和-shm两个文件程序退出时如果已经正常提交WAL 文件会自动合并回主数据库不要手动删它。synchronousNORMAL在 WAL 模式下已经能保证不丢已提交的数据比FULL快很多如果现场对数据安全有极端要求可以改成FULL但写入延迟会明显增加。busy_timeout5000是等待锁的时间单位是毫秒它让多个连接竞争同一文件时不会立刻报错而是等待对方事务结束这对同时开一个统计界面的场景很关键。4.2 扫码频率高时的写入策略缓冲队列、批量事务与防重复入库上位机软件接收扫码数据是事件驱动的数据到达的时间和频率完全不可控。如果每次收到一条条码就 INSERT 一条SQLite 的文件锁会被反复打开关闭事务提交也是一次一次地写磁盘写入慢不说频繁的锁操作还会拖累同一时刻的查询界面。常见做法是在内存里加一层缓冲队列攒够一定条数或一定时间再统一提交。我用一个后台提交线程专门负责这件事。主程序把扫码记录放进ConcurrentQueueScanRecord提交线程定时检查达到批量条件后取出一批数据在同一个事务里插入。事务的意义在于一批记录要么全部写入成功要么全部回滚中间不会出现写了一半的情况而且一个事务整体只需要做一次文件同步比逐条插入快得多。批量插入的核心代码如下// 批量写库同事务插入多条记录单次提交 private void FlushBatch(ListScanRecord batch) { using var conn new SqliteConnection(_connString); conn.Open(); using var tx conn.BeginTransaction(); var cmd conn.CreateCommand(); cmd.Transaction tx; cmd.CommandText INSERT INTO scan_log (barcode, scan_time, line, station, trigger_type) VALUES ($barcode, $scan_time, $line, $station, $trigger_type);; foreach (var item in batch) { cmd.Parameters.Clear(); cmd.Parameters.AddWithValue($barcode, item.Barcode); cmd.Parameters.AddWithValue($scan_time, item.ScanTime.ToString(yyyy-MM-dd HH:mm:ss.fff)); cmd.Parameters.AddWithValue($line, item.Line); cmd.Parameters.AddWithValue($station, item.Station); cmd.Parameters.AddWithValue($trigger_type, item.TriggerType); cmd.ExecuteNonQuery(); } tx.Commit(); }这里有个细节值得多说一句SQLite 的命名参数用$开头这是 SQLite 自己的参数风格和 C# 的字符串插值没有任何关系。cmd.Parameters.Clear()非常必要因为同一个SqliteCommand在执行多条插入时参数集合不会自动清空不清空会导致上一次的参数值残留到下一次执行里。ExecuteNonQuery每调用一次就执行一条插入语句但因为整个批次被包在同一个事务里SQLite 只在Commit()时才真正做一次文件同步所以性能损失可控。批量大小的设置也有讲究。我一般定两个条件批量达到 100 条或者距离上一次提交超过 2 秒满足任一条件就触发提交。太小了比如每 10 条就提交一次事务优势体现不出来文件锁还是被频繁占用太大了比如攒 1000 条才提交一旦程序崩溃或断电内存里未提交的数据会全部丢失。100 条和 2 秒这个组合在大多数产线场景下能在“数据安全”和“写入性能”之间找到平衡点。如果工位一天只有几百条数据可以把批量调小到 50 条同时把时间条件改为 5 秒降低空提交的频率。防重复入库是固定式扫码系统的另一道必修课。生产现场的同一个条码可能被多次扫到原因可能是工件回流、操作工重复触发也可能是读码器连续自动扫描。业务上要区分“重扫”和“一码多扫”重扫意味着上一次扫描结果作废一码多扫则要决定要不要记录第二次。我的做法是在scan_log表上对barcode字段建普通索引再配合HashSet做近期内容去重如果业务要求数据库层面绝对不重复就建UNIQUE约束并用INSERT OR IGNORE写入让 SQLite 自己过滤掉重复条码。注意INSERT OR IGNORE会静默忽略冲突记录如果你需要知道“哪些条码是重复的”就不能只依赖它还需要在应用层先做一次判定把重复标记写进业务字段。5. 固定式扫码系统在 v23.1 下的 5 个踩坑记录与排查思路这一章写的都是我在现场和接手源码时真实见过的坑。大部分问题不在 DevExpress 控件本身而是“串口 UI 数据库”三个模块接缝处的典型失误。每一条我都按“现象 → 原因 → 解决”的顺序来写方便你排查时直接对照。5.1 扫码枪连接正常但上位机就是收不到数据现象扫码枪在厂家自带的调试软件里能正常扫出条码串口线、USB 转串口驱动也没问题但 C# 程序打开串口后怎么扫都没有数据。原因基本逃不出三处一是串口参数对不上波特率、数据位、停止位、校验位任何一个和读码器实际设置不一致收到的都是乱码或者完全无响应二是触发方式不匹配读码器设置成光眼触发但光眼线没接或者没有物体通过三是程序用ReadLine()等结束符而读码器的输出格式里没有回车换行导致数据一直停在串口缓冲区里。排查顺序我一般这样走先用串口调试工具把波特率调成和读码器设置一致手动触发一次扫描看裸数据是否正常返回。如果裸串口有数据而程序收不到重点查触发方式和结束符如果裸串口也没数据重点查串口参数和读码器设置。程序侧临时把ReadLine()换成ReadExisting()并加上超时提示往往能立刻定位问题。5.2 扫码越多界面越卡CPU 一路飙升现象手动扫一两下没感觉产线一开工界面半小时后开始明显卡顿任务管理器里 CPU 占用率居高不下。原因最常见的只有两个一个是串口DataReceived事件里直接调了 UI 控件比如gridView1.AddNewRow()扫码频率一高UI 线程被大量跨线程调用淹没另一个是网格数据无限增长扫码记录攒了几万行GridView 全表重绘的开销越来越大。解决办法分两段。接收侧按第三章的方式改造成队列模式串口线程只入队UI 侧用定时器批量刷新。如果已经是队列模式但还是卡就要检查网格行数是不是失控了常见做法是只保留当天的扫码记录或者做成翻页视图以及用gridView1.BeginUpdate()包住批量插入操作插入完成后再EndUpdate()避免每一行都触发一次重绘。DevExpress 的 GridControl 在几千行内性能完全没问题如果上万行就开始卡先怀疑是不是开启了RowAutoHeight或者AllowHtmlDraw这类高开销选项。5.3 条码内容多了几个字符或者中文变成乱码现象原条码是ABC-123-456程序里显示成ABC-123-456后面带一个方框或者多一个换行带中文的条码显示成???或乱码。原因同样是两处一是条码数据本身携带了规定的结束符比如回车\r和换行\n程序入库前没清洗二是SerialPort的Encoding属性设置不对读码器输出的是 GB2312程序按 UTF-8 解码中文自然变成问号。解决时一个动作是入队前统一做Trim()去掉条码首尾的空白和控制字符另一个动作是按读码器说明书把SerialPort.Encoding设置为Encoding.Default或具体的 GBK 编码。这里要特别提醒一点如果读码器输出的条码中间本身包含空格不能用单纯Replace( , )的方式清洗否则会把有效内容破坏掉正确做法是只去掉首尾控制字符和结束符。5.4 GridControl 的布局每次重启都恢复默认操作工反复重新调列现象操作工把列宽调好、把拖动顺序调整好甚至设置了筛选条件第二天上班启动程序全部恢复成原始状态。原因GridView 的布局默认只停留在内存里没有持久化到磁盘。DevExpress v23.1 没有自动保存布局的开关需要开发者在代码里主动调用保存和恢复接口。解决方式很直接。窗体关闭时调用SaveLayoutToXml把列顺序、列宽、筛选条件、排序状态保存到一个 XML 文件窗体加载时先判断文件存在再调用RestoreLayoutFromXml恢复。相关代码是下面这样// 保存网格布局到本地 XML string layoutPath Path.Combine(AppContext.BaseDirectory, gridLayout.xml); private void MainForm_FormClosing(object sender, FormClosingEventArgs e) { gridView1.SaveLayoutToXml(layoutPath); } private void MainForm_Load(object sender, EventArgs e) { if (File.Exists(layoutPath)) { gridView1.RestoreLayoutFromXml(layoutPath); } }注意一点布局文件的兼容性通常只在同一 DevExpress 主版本内保证比如 v23.1 保存的布局文件在 v23.2 里可以尝试恢复但不保证完全兼容升级控件版本后最好让用户重新保存一次布局。如果工程里同时存在多个 GridView每个视图都要单独指定一个布局文件路径避免互相覆盖。5.5 源码换到另一台电脑编译报错“DevExpress”命名空间不存在现象源码在一台电脑上编译运行正常Git 拉到另一台电脑打开工程后所有 DevExpress 相关引用全部飘红报“命名空间不存在”或“类型或命名空间名称 DevExpress 未找到”。原因DevExpress 控件程序集的安装路径和版本在不同机器上不一致。工程文件里如果引用的是带版本号的程序集比如DevExpress.XtraGrid.v23.1.dll并且 HintPath 写的是原来那台机器上的安装目录新机器上目录不一样引用自然解析不到。v23.1 是版本绑定很严格的一套控件混用 22.2 和 23.1 的程序集也会出现类似问题。解决时先确认新机器安装的 DevExpress 版本然后把工程里所有 DevExpress 引用的 HintPath 改成新机器实际路径或者统一改成相对路径比如把所有需要的 DLL 复制到工程下的libs/目录引用路径都指向..\libs\DevExpress.XtraGrid.v23.1.dll。这样换机器、换目录都不会丢引用。如果项目里引用的是 NuGet 包方式则先执行nuget restore再重新生成如果代码逻辑没问题但引用一直飘红把bin和obj目录清掉重新编译能解决大部分“明明路径没错还是找不到”的玄学问题。提示源码工程里最容易出问题的不是业务代码而是 DevExpress 程序集的引用路径被写死到某台机器的 GAC 或安装目录里。你拿到源码后先检查.csproj里的 HintPath 是否包含绝对路径这条信息能直接判断这套源码的工程化水平。6. 让固定式扫码系统的数据更可信三个低成本改进技巧6.1 断线重连比报错提示更实际产线现场的 USB 转串口经常因为供电不稳或接口松动掉线。程序如果只是弹一个“串口断开”的提示框并停止工作操作工根本不会处理。我一般会加一个后台重连定时器检测到串口断开后每隔两秒尝试重新打开一次期间新扫到的数据先进入队列缓存串口恢复后继续写库。这个改动不大但对稳定性的提升立竿见影。6.2 日志字段别只存“条码 时间”最容易低估的是上下文字段的价值。scan_log表里的字段如果只有barcode和scan_time出问题时只能证明系统扫过这个条码但没法证明这个条码是在哪个工位、由哪台设备、用什么触发方式扫的。给表加上line、station、trigger_type这几个字段成本极低追溯问题时却少走很多弯路。上一章的INSERT语句里已经体现了这几个字段实际建表时把它们做成非空字段录入逻辑从一开始就补全。6.3 “扫码成功”和“扫描已确认”是两个状态固定式扫码系统里最常见的业务漏洞是把扫码当成一次性动作扫到了就等于入库了入库了就等于投料完成了。实际上产线可能因为条码贴歪、重码、错扫导致记录不准确。常见做法是给记录增加一个confirm_status字段0 待确认1 已确认2 重扫。操作工在界面上看到条码后确认状态才从待确认变成已确认重扫时不删除原记录而是新增一条状态为重扫的记录保留完整现场。这样每一条数据都有据可查。我在这类系统上吃过一次亏早期做的一套系统里扫码完成直接当成投料完成没有状态机也没有上下文日志。后来产线反馈有漏投料但系统里所有条码都显示已经扫过根本追查不出是哪个工位、哪台设备出了问题。把状态和上下文字段补上之后才真正把扫码系统做成了闭环。如果你要接手一套 DevExpress 固定式扫码系统源码我最诚恳的建议是先别急着跑界面把串口、队列、落库这一条链路画清楚链路通了再谈界面好不好看。希望帮到你。本文还有配套的精品资源点击获取