★ FEATURED ARTICLE 简介这是一套面向电子测量及自动化测试开发者的C#电阻测试软件源代码围绕日置电阻测试仪实现电阻自动测量与数据交互适用于实验室、科研或产线质检等需要精确测阻的场景。资源共165个文件包含30个C#核心源码、3个可直接运行的exe程序以及配置文件、资源文件、界面图标等工程辅助材料整个压缩包仅1.07MB轻量却覆盖完整工程结构可看到串口/网口连接、SCPI标准指令收发、量程切换、数据解析、结果存储与WinForms界面绑定等关键实现。目前已有393人学习浏览。通过学习源码能够掌握C#与日置测试仪的通信协议设计、异步读取与错误处理技巧还能基于现有框架快速扩展批量测试、实时曲线、异常报警等功能对理解仪器自动化控制很有帮助。源码模块划分清楚适合有一定C#基础、希望入门仪器控制与上位机开发的人群参考。1. XCS 电阻测试软件源代码先搞清这套 C# 上位机在拆什么做产线测试的老工程师应该都有这种经历手里一台日置电阻测试仪精度高、稳定性好但每次测量都得人工按键读数、手写记录批量测几百个电阻时效率低到让人怀疑人生。XCS 电阻测试软件源代码就是解决这个问题的——它是一套用 C# 写的上位机程序通过 RS-232 串口和日置电阻测试仪通信发 SCPI 命令读取阻值、判定合格、保存记录。我拆完这套源码的第一感受是它把「测量硬件 上位机逻辑 数据管理」串成了一条完整的自动化链路非常适合刚接手产线自动化改造的工程师、做电子测量毕设的学生以及想从零搭一套仪表上位机框架的 C# 开发者。有一点你打开源码包就会注意到里面有一堆.csproj.ResolveAssemblyReference.cache、.GenerateResource.Cache之类的文件别慌这些是 Visual Studio 编译时留下的中间缓存不是核心代码。真正值钱的是那几个.cs文件、app.config和工程文件——只要搞懂它们的组织方式你就能把任何一台带 SCPI 指令集的测试仪接进自己的程序里。2. 从 SerialPort 到 SCPIC# 与日置电阻测试仪的通信链路2.1 串口参数先对齐9600、8N1 和换行符C# 与日置电阻测试仪通信的第一步不是写代码而是把串口参数对齐。日置的电阻测试仪默认串口参数一般是 9600 波特率、8 个数据位、无校验位、1 个停止位也就是常说的 8N1。这个参数在设备背面铭牌或操作手册里能查到不同型号可能支持更高的波特率但默认值基本不会变。我一般会在连接界面下拉框里把常用波特率都列出来默认选中 9600防止现场设备被上一个工程师改过参数。using System.IO.Ports; SerialPort _port new SerialPort(); _port.PortName COM3; // 实际端口以设备管理器为准 _port.BaudRate 9600; // 日置默认波特率可改 _port.DataBits 8; // 数据位 8 _port.Parity Parity.None; // 无校验位 _port.StopBits StopBits.One; // 停止位 1 _port.Handshake Handshake.None; // 通常无流控 _port.ReadTimeout 2000; // 读超时 2 秒 _port.WriteTimeout 2000; // 写超时 2 秒 _port.Open();这段代码里有几个参数值得展开说。ReadTimeout和WriteTimeout设成 2 秒是经验值——太短的话设备响应稍慢就会抛超时异常太长的话批量测试时卡住一个命令会拖慢整条产线。Handshake设为 None 是因为日置电阻测试仪一般不用硬件流控除非你接的是某些需要 RTS/CTS 的老旧设备。打开串口后建议先用_port.DiscardInBuffer()清空接收缓冲区把设备上电时可能发来的乱码丢弃否则第一次读数据就可能读到脏数据。如果设备是 USB 接口别以为就走 USB 协议——日置很多型号的 USB 口在驱动装好后会枚举成一个虚拟串口设备管理器里显示为COM4、COM7之类的编号代码里照样用 SerialPort 操作。以太网接口的型号则要换思路用System.Net.Sockets.TcpClient连设备的 5025 端口或者说明书里指定的端口。判断用哪种方式最简单的方法是看设备管理器里有没有出现 COM 口没有 COM 口再考虑走网口。2.2 SCPI 命令封装*IDN? 与 :MEAS:RES?通信链路建起来之后第二步是封装 SCPI 命令。SCPIStandard Commands for Programmable Instruments是测试仪器通用的命令集日置电阻测试仪基本都支持。最常用的两条命令*IDN?用于查询设备标识MEAS:RES?或:MEAS:RES?用于读取当前电阻值。注意命令最后的问号不能丢这是查询命令的标志。public string SendCommand(string cmd) { // 清空接收缓冲区避免读到上一次的残留数据 _port.DiscardInBuffer(); // 写入命令SCPI 命令要求以换行符结尾 _port.Write(cmd \n); // 等待设备响应简单起见用 Thread.Sleep 也可 string response _port.ReadExisting(); if (string.IsNullOrEmpty(response)) { response _port.ReadLine(); // 阻塞读到换行符 } return response.Trim(); }这段代码有一个关键细节_port.Write(cmd \n)末尾的换行符。SCPI 标准规定命令以换行符\n结束但日置部分型号对\r\n更友好具体以设备手册为准。我踩过这个坑——命令发出去设备完全不响应后来用串口助手抓包才发现换行符不对。ReadLine()会阻塞到收到换行符为止所以必须设ReadTimeout否则设备不响应时程序会一直卡住。Trim()是去掉设备返回数据首尾的空白字符和换行这一步不能省。封装时我一般会把命令做成常量或枚举而不是散落在代码各处public static class ScpiCommands { public const string Identify *IDN?; public const string MeasureResistance :MEAS:RES?; public const string SetRangeAuto :SENS:RES:RANG:AUTO ON; public const string SetRange :SENS:RES:RANG {0}; }这样做的好处是后续要换设备型号时只需要改这个静态类里的命令字符串。日置不同型号的 SCPI 命令虽然大体一致但量程设置、触发方式等细节可能有差异。常见做法是在SetRange里传具体量程比如SetRange(1000)表示设到 1kΩ 档但要注意有些型号支持自动量程有些型号必须手动指定。读电阻值的完整流程通常是先发SetRangeAuto或手动设量程再发MeasureResistance最后解析返回值。2.3 数据解析科学计数法与浮点位日置电阻测试仪返回的电阻值格式一般是科学计数法字符串比如1.2345E04表示 12345 欧姆。直接double.Parse会出问题——如果系统区域设置为中文某些 .NET 版本下double.Parse(1.2345E04)会抛FormatException因为它期望小数点符号是本地化的。这就是很多人觉得串口读数「玄学」的原因同样的代码在中文 Windows 上跑得好好的换一台机器就崩。using System.Globalization; public static bool TryParseResistance(string raw, out double value) { value 0; if (string.IsNullOrWhiteSpace(raw)) return false; // 去掉返回结果里的空格、换行、可能的单位后缀 raw raw.Trim().TrimEnd(Ω, k, M); // 必须用 InvariantCulture 解析科学计数法 return double.TryParse(raw, NumberStyles.Float | NumberStyles.AllowExponent, CultureInfo.InvariantCulture, out value); }关键点是CultureInfo.InvariantCulture——强制用小数点作为千分位和小数符号不随系统区域设置变化。NumberStyles.AllowExponent是必须加的否则E04这种指数部分不会被识别。有些设备返回的数据里还带单位字符比如kΩ、MΩ这里用TrimEnd把尾部单位去掉。但在去掉之前要先确认设备配置——如果设备配置为不返回单位只返回纯数值就不需要这一步。我一般建议在设备端把输出格式设为纯数值减少解析分支。解析还有一个边界情况要处理设备可能返回9.9000E37或类似的值表示量程溢出或开路。这种值在业务逻辑里应当视为无效测量而不是当成真实电阻值存进数据库。判断方法是设一个合理的物理上限比如被测电阻不可能超过 100MΩ超过就标记为「溢出」。这个检查要放在解析之后、判定逻辑之前。3. 源码骨架拆解UI、控制层与业务逻辑层怎么咬合3.1 界面层WinForms 还是 WPF 的选择XCS 这套源码的 UI 部分走的 WinForms 路线按钮、文本框、下拉框、DataGridView 都是经典控件布局。我的看法是这种测量软件用 WinForms 是合理选择——开发效率高、控件成熟、部署简单代码里也容易一眼看出哪个按钮绑定了哪个事件。WPF 的好处是界面更现代、数据绑定更灵活但学习成本和改造成本都更高。对于产线测试工具这种重逻辑、轻界面的场景WinForms 完全够用而且对新手更友好。界面层有一个绕不开的问题跨线程访问控件。串口数据是后台线程收的但更新界面必须在 UI 线程。很多初学者直接在事件回调里写textBox1.Text result;跑起来时不时报InvalidOperationException: 线程间操作无效。正确做法是用Control.BeginInvoke或者SynchronizationContext把更新操作切回 UI 线程。private void OnDataReceived(string result) { if (this.InvokeRequired) { // 跨线程时把操作封送到 UI 线程 this.BeginInvoke(new Actionstring(OnDataReceived), result); return; } txtResistance.Text result; txtResistance.BackColor IsSpecOk(_lastValue) ? Color.Green : Color.Red; }InvokeRequired判断当前线程是否为控件所属线程是则直接更新否则用BeginInvoke异步切换。用BeginInvoke而不是Invoke是为了避免 UI 线程卡住时后台线程被阻塞等待导致串口缓冲区溢出。界面上给测试结果上色是个很实用的习惯——绿色合格、红色超差产线操作员不用看数字就知道产品行不行。需要提示的是频繁写 DataGridView 也会卡 UI批量测试时可以先攒一批数据再批量刷新而不是来一条刷一条。3.2 控制层把按钮事件和串口读写解耦源码里值得学习的结构是控制层的解耦方式。连接按钮、读值按钮、量程选择下拉框各自处理自己的交互逻辑但真正干活的都调同一个通信管理类。这样做的好处是后续你要把串口换成网口或者从日置换成其他品牌设备只需要改通信管理类的内部实现按钮事件几乎不用动。public class CommManager { private SerialPort _port; private readonly object _lock new object(); public bool Connect(string portName, int baudRate) { lock (_lock) { _port new SerialPort(portName, baudRate, Parity.None, 8, StopBits.One); _port.ReadTimeout 2000; _port.WriteTimeout 2000; _port.Open(); return _port.IsOpen; } } public string Query(string scpiCommand) { lock (_lock) { _port.DiscardInBuffer(); _port.Write(scpiCommand \n); return _port.ReadLine().Trim(); } } public void Close() { lock (_lock) { if (_port ! null _port.IsOpen) _port.Close(); } } }lock (_lock)这行是关键——多个按钮事件或定时器同时调用Query时串口同一时刻只能有一个写操作否则命令会互相穿插设备返回的数据就乱了。这是上位机开发里最容易被忽略的并发问题UI 线程、定时器线程、后台采集线程同时碰串口不加锁轻则数据错乱重则直接异常崩溃。Query方法把「发命令 读响应」封装成一个原子操作业务层不需要关心串口细节。控制层里还要处理设备连接状态。我见过很多源码只在按钮点击时判断_port.IsOpen其实不够——设备可能在测试中途被拔掉或者串口被其他程序占用。更好的做法是让Query里捕捉InvalidOperationException和TimeoutException返回特定错误码由界面层统一弹窗提示。这套源码里如果没做这个兜底你接手后第一件事就应该补上。3.3 业务逻辑层合格判定与超时重试业务逻辑层的核心是「拿到的数据怎么用」。电阻测试软件最基本的业务是上下限判定——根据产品规格设一个最小值和一个最大值测量值落在区间内判合格否则判不合格。这段逻辑看似简单但要注意边界值处理规格是 100Ω 到 110Ω那么 100.0 到底算合格还是不合格不同工厂标准可能不一样我一般把边界设为含等号并在配置界面上加一个「边界是否包含」的选项。public class TestResult { public string SerialNumber { get; set; } public double Resistance { get; set; } public bool IsPass { get; set; } public DateTime TestTime { get; set; } } public static bool IsWithinSpec(double resistance, double low, double high) { // 先排除无效测量值 if (double.IsNaN(resistance) || resistance 0) return false; // 上下限包含边界等于规格值视为合格 return resistance low resistance high; }这里有一个容易翻车的地方设备返回的电阻值理论上是正数但如果测量端悬空或接触不良返回值可能是异常大数或负数。resistance 0的判断能挡掉一部分脏数据但更稳妥的做法是在上一条解析函数里就把溢出值和无效值标记为NaN业务层统一处理。超时重试也是业务逻辑层该管的事——产线上探针接触不良是常态第一次读不到值直接判不合格会误杀良品常见做法是自动重试 3 次。实际生产中我一般会把超时重试写成策略模式但小工具不必搞那么复杂一个for循环里加Thread.Sleep(200)就够用了。需要提醒的是重试间隙的Sleep时间不能太短否则设备还没准备好你又发命令等于没重试。200 毫秒是我反复调出来的经验值——日置仪表的测量周期一般在几十毫秒到几百毫秒之间200 毫秒能让设备完成一次完整的测量循环。4. 把数据落库与导出测试记录的可靠性设计4.1 SQLite 还是 CSV看你要什么电阻测试数据不存下来的话整个自动化就是白搭。常见做法有两种CSV 文件和 SQLite 数据库。CSV 的优势是零依赖、直接用 Excel 打开、方便产线组长当天拷走缺点是数据量大了之后查询、筛选、按批次统计都是噩梦。SQLite 的优势是支持 SQL 查询、数据完整性好、并发写入不容易坏缺点是要带System.Data.SQLite.dll或Microsoft.Data.Sqlite.dll进发布目录。我的习惯是如果只是单机自用、一天几百条数据CSV 就够如果要溯源、按工单查历史、做统计分析直接 SQLite。源码包里大概率是二者选其一或者两个都支持。不管哪一种数据记录里至少要包含这些字段测试时间、被测物编号或批次号、电阻测量值、判定结果、操作员、设备型号。操作员这个字段经常被忽略但产线上出了问题要追溯是谁测的没有这个字段就说不清楚。4.2 落库代码SQLite 插入测试记录用 SQLite 时要注意建表语句里的字段类型和索引。测试时间建议用TEXT存 ISO 格式字符串而不是DATETIME——省去不同 SQLite 版本对日期类型处理的差异。批次号建一个普通索引因为按批次查询是最常见的操作。using Microsoft.Data.Sqlite; private static readonly string ConnStr Data Sourcetest_records.db; public static void InsertRecord(TestResult r) { using var conn new SqliteConnection(ConnStr); conn.Open(); string sql INSERT INTO resistance_log (test_time, serial_no, resistance, is_pass, operator_name) VALUES (time, sn, res, pass, op); using var cmd new SqliteCommand(sql, conn); cmd.Parameters.AddWithValue(time, r.TestTime.ToString(yyyy-MM-dd HH:mm:ss)); cmd.Parameters.AddWithValue(sn, r.SerialNumber); cmd.Parameters.AddWithValue(res, r.Resistance); cmd.Parameters.AddWithValue(pass, r.IsPass ? 1 : 0); cmd.Parameters.AddWithValue(op, Environment.UserName); cmd.ExecuteNonQuery(); }这段代码里using var是 C# 8 的语法作用等价于using (var conn ...) { }作用域结束后自动释放资源省心不少。参数化写入是必须的——虽然这是本地单机工具不联网、没有外部输入攻击面但被测物编号如果是人工输入的里面有特殊字符时直接拼接 SQL 会报错甚至走偏。Environment.UserName用来记录当前 Windows 登录用户名当操作员标识胜在零配置。要注意的是AddWithValue在某些 SQLite 驱动下会把r.Resistance推断成REAL类型如果你的建表语句里resistance列是TEXT写入时会出问题所以建表时类型要和写入值严格对应。建表语句和库初始化一般在程序启动时执行一次。核心是幂等——重复执行不报错用IF NOT EXISTS修饰。产线上程序可能被反复拷贝到不同机器每台机器首次运行都能自动建库是最好的体验。4.3 写 CSV 的坑编码与追加如果不想引外部依赖CSV 方案也够用。但写 CSV 有两条血泪经验要记住。第一编码必须用 UTF-8 with BOM否则 Excel 打开中文会乱码——这是 .NET 里File.WriteAllText默认就是 UTF-8 无 BOM 导致的高频翻车现场。第二每次测试都追加写入不要一次性把整个 DataTable 重写进文件否则程序中途异常会把之前几百条数据全丢。public static void AppendCsv(TestResult r, string filePath) { bool fileExists File.Exists(filePath); var line string.Join(,, r.TestTime.ToString(yyyy-MM-dd HH:mm:ss), r.SerialNumber, r.Resistance.ToString(F4, CultureInfo.InvariantCulture), r.IsPass ? PASS : FAIL); // UTF8Encoding(true) 表示带 BOMExcel 打开不乱码 if (!fileExists) { string header 测试时间,编号,电阻值(Ω),判定\n; File.WriteAllText(filePath, header, new UTF8Encoding(true)); } File.AppendAllText(filePath, line \n, new UTF8Encoding(false)); }UTF8Encoding(true)带 BOM 用于首次创建文件时写表头后续追加内容时用UTF8Encoding(false)不带 BOM避免每条记录前面都多一个 BOM 头导致 Excel 解析混乱。电阻值用ToString(F4, CultureInfo.InvariantCulture)指定 4 位小数并且强制用点号做小数点——中文系统下直接ToString()可能输出逗号CSV 的逗号是分隔符数据里有逗号就炸了。另一个细节是文件路径产线电脑的用户目录可能包含中文用户名路径拼接时要避免写死路径。我一般把 CSV 放在程序目录下的logs文件夹按日期命名文件比如resistance_20240315.csv一天一个文件方便归档。5. 踩坑与排查串口、协议与缓存文件的血泪经验5.1 串口打不开或一打开就报占用现象点击连接按钮程序抛UnauthorizedAccessException提示串口被占用或者明明设备管理器里有 COM 口但代码里Open()就是失败。原因最常见是被其他程序占用了串口——比如日置自带的官方软件、串口调试助手、甚至上一个没关干净的测试程序。另一个常见原因是设备管理器里看到的 COM 口号与程序写死的不一致USB 转串口的 COM 号在换 USB 口后会变。解决代码里不要写死COM3连接前用SerialPort.GetPortNames()枚举当前所有可用串口填到下拉框里让用户选。同时启动时检查端口是否已被占用占用时弹窗提示具体是哪个进程。排查占用的方法先关掉所有可能碰串口的软件再试不行就重新插拔 USB让系统重新枚举 COM 号再不行用设备管理器把端口从 COM 号改成空闲的号码。5.2 能连上但发送命令无响应现象串口能打开*IDN?发出去程序一直等到超时读不到任何返回。原因换行符不对是最常见的原因。SCPI 标准是\n但有些设备固件只认\r\n发\n时设备认为命令不完整不执行。其次是波特率不匹配——设备实际被改成了 19200界面还按 9600 发设备收到的是乱码自然不响应。第三个原因是 USB 转串口芯片驱动有问题数据只是单向通。解决先把_port.Write的内容改成cmd \r\n重试。这一步不行的就用串口调试助手手工连一下——这招能区分「程序问题」和「设备问题」调试助手能收到返回就说明是程序通信细节不对收不到就查设备设置。我在现场排查这类问题从来都是先上调试助手比看代码快得多。5.3 返回值解析偶尔失败或拿到 NaN现象设备明明显示有读数但程序解析出来的值是 0、NaN 或者明显的错值。有时连续测几十个都没问题偶尔蹦出来一个诡异数据把整批统计带偏。原因设备响应速度不稳定。日置在触发测量后需要稳定的测量时间命令刚发完就立刻去读读到的是上一次的残留数据或者空串。另一个原因是量程不匹配——电阻远大于当前量程设备返回溢出标志而不是有效数值。解决读值前先发*OPC?操作完成查询或加固定延时强制等设备就绪。延时取 200 到 500 毫秒比较稳妥太短没意义太长降低效率。解析层对返回值做白名单校验必须能被TryParseResistance成功解析且数值在合理物理范围内否则丢弃重测。重试逻辑放到循环里连续 3 次异常再判失败避免偶发抖动直接灭掉一个良品。5.4 源码包里那堆 cache 文件看不懂也别删现象打开源码包看到一堆.csproj.ResolveAssemblyReference.cache、.GenerateResource.Cache、DesignTimeResolveAssemblyReferencesInput.cache、.vshost.exe.config之类的文件有些人会误以为是病毒或者无关垃圾直接删掉结果工程文件打不开。原因这些是 Visual Studio 在编译和设计期自动生成的缓存和临时文件不是项目必需的源代码资源。.csproj配套的AssemblyReference.cache帮助 IDE 缓存程序集引用关系加速后续编译GenerateResource.Cache是资源文件生成的中间产物。它们有或没有都不影响程序编译结果——VS 下次编译会重新生成。解决正确做法是不提交进源代码管理。用 Git 做源代码管理时.gitignore里加上编译输出目录bin/、obj/、*.cache、*.vshost.exe*这样提交仓库时就不会被这些文件污染。如果你拿到的是一个压缩包直接解压后忽略这些文件就行不要手动删除——万一某个 VS 版本对缓存有依赖删了可能出现设计器打不开的怪问题。真正要关注的是.cs源码文件、.csproj工程文件、app.config或App.config配置文件。5.5 编译通过但发布后运行闪退现象开发机上跑得好好的拷到产线电脑上双击 exe 界面一闪就没了什么提示都没有。原因最常见的是 .NET Framework 版本不对。用 VS 2022 建的 WinForms 项目默认可能选 .NET 6 或 .NET 7产线电脑没装对应 Runtime 自然跑不起来稍微老一点的机器连 .NET Framework 4.5 都可能缺。另一个常见原因是配置文件里写的数据库路径或日志路径在目标机器上不存在程序启动时直接异常。解决发布时选「目标运行时」自包含self-contained模式把 .NET Runtime 一起打包产线电脑零依赖直接跑。或者建项目时就选 .NET Framework 4.6.1 这种老版本里覆盖率高的目标。发布后先在「干净的」虚拟机或另一台没装过开发工具的电脑上试跑一遍。程序里所有文件路径都用Path.Combine(AppDomain.CurrentDomain.BaseDirectory, ...)拼不要用相对路径依赖当前工作目录。5.6 防反编译与 DLL 合并现象发布出来的 exe 用dnSpy或ILSpy一拖就开源码逻辑、数据库连接字符串、SCPI 命令表全部裸奔。原因C# 编译出来的 IL 是托管代码任何 IL 反编译工具都能还原成可读性很高的源码。这不是 bug是这门语言的天性。解决对商业交付场景至少做两层处理。第一层用混淆器比如 Obfuscar把类名、方法名、字符串常量打乱提高逆向门槛第二层用Costura.Fody把依赖的 DLL 合并进主 exe减少发布文件数量。但注意防反编译只能提高门槛不能完全阻止——真正敏感的东西比如数据库密码应该放到配置文件里加密存储而不是写在代码里。这套 XCS 源码如果只是自用学习和内部工具防反编译倒不是优先事项把日志和异常处理做好比防破解更实际。6. 进阶与验证日志埋点、防反编译与一条自检命令前面五章把源码拆得差不多了这一章讲两个能直接提升交付质量的技巧。第一个是给程序加一个最小化的日志系统。串口通信是典型的黑匣子——设备不响应、数据解析失败、超时重试这些问题在用户界面上只表现为一个小红叉用户不知道发生了什么、发生在哪一步。我的习惯是用一个静态 Logger 类把所有串口命令、原始返回、解析结果、异常信息按时间戳写进log_yyyyMMdd.txt。public static class Logger { public static void Info(string msg) { File.AppendAllText( $log_{DateTime.Now:yyyyMMdd}.txt, ${DateTime.Now:HH:mm:ss.fff} [INFO] {msg}\n); } public static void Error(string msg, Exception ex null) { File.AppendAllText( $log_{DateTime.Now:yyyyMMdd}.txt, ${DateTime.Now:HH:mm:ss.fff} [ERROR] {msg} {ex?.ToString()}\n); } }日志级别分 Info 和 Error 就够了不搞多级日志框架。关键动作打点连接成功打一条、发 SCPI 命令打一条、收到原始数据打一条、解析失败打一条。产线出问题时把日志文件收回来一看就能定位是通信问题、解析问题还是设备端问题。日志文件要做大小控制一天一个文件基本不会超大如果测试频率极高就按小时分文件。第二个技巧是程序启动时自动做一次设备自检。正常流程程序启动后自动向设备发送*IDN?查询然后校验返回字符串里是否包含期望的设备型号关键字。比如日置 RM3545 返回的标识字符串里含有RM3545匹配失败就弹窗提示「未检测到日置电阻测试仪或型号不匹配」而不是让用户等到点测试按钮时才发现设备没连上。public bool SelfCheck() { try { string idn _comm.Query(ScpiCommands.Identify); Logger.Info($SelfCheck IDN response: {idn}); return !string.IsNullOrEmpty(idn) idn.Contains(HIOKI); } catch (Exception ex) { Logger.Error(SelfCheck failed, ex); return false; } }这段自检代码的巧妙之处在于它验证了整条通信链路串口参数对不对、换行符对不对、设备是否在线、SCPI 握手是否正常——链路上哪一个环节有问题*IDN?都会失败。启动自检通过后再刷新 UI 界面的连接状态图标给操作员一个明确的「系统就绪」信号比把连接逻辑散落在各个按钮事件里健壮得多。如果你拿到这套 XCS 源码后只改一件事我建议先加这个自检。我接手过的每一套测量上位机启动自检都是第一个动刀的地方——它看起来只是多了一次查询实际上把通信问题在测试开始前就暴露了而不是在测到第三个产品时突然卡死。从那以后我每次写仪表类上位机都强制把自检 日志放在第一优先级实现哪怕是临时凑数的小工具也不例外。希望帮到你。本文还有配套的精品资源点击获取
阅读完成 · 觉得有帮助？
