简介这是一套面向C#开发者和设备管理从业者的企业级设备信息化管理系统源码。系统覆盖资产管理、设备维修保养、备件管理、文件管理与可视化仪表盘等核心模块展示了C#与.NET框架在实际业务中的完整应用尤其适合希望掌握企业级分层架构、数据库交互和复杂业务逻辑的初中级开发者研究学习。资源包共497个文件以243个cs源码文件为主体配合resources资源文件、resx界面资源、vb脚本、png/ico图标、dll库及exe可执行程序等压缩包整体约293MB结构清晰可逐模块拆解阅读。目前已有698人学习下载。虽然项目删除了csproj工程文件导致无法直接编译运行但源码本身保留了完整的业务逻辑和界面设计思路读者可从中学习模块化设计、异常处理、数据验证以及设备全生命周期管理的实现方式是一份贴近实际场景的C#进阶参考资料。1. 一套 C# 设备信息化管理系统源码拿到手先别急着解压早上八点维修主管老张打开 Excel 想统计上个月故障发现点检表停在两周前备件出库单是纸质昨晚三号机停机四十分钟消息还在班长微信里。设备信息化管理系统要解决的正是这种断层把设备台账、点检保养、维修工单、备件库存和运行状态统一到一个可查的界面通常用 WinForm 做桌面端、SQL Server 或 SQLite 存数据、Modbus/HTTP 从 PLC 采状态。适合工厂设备部、上位机开发者和想从 Excel 台账升级的 IT 工程师。拿到源码不要急着编译先盘一遍结构再决定改哪里。2. 拆解C#解决方案结构从WinForm界面到DAL数据访问层一个合格的设备信息化管理系统源码至少会包含四个工程UI 层负责人机交互BLL 层处理业务规则DAL 层封装数据库操作Models 层承载数据实体。有些还会拆出 Common 放日志和工具函数Host 或 Service 做数据采集。下面这张表列了各层在设备管理场景里的具体职责工程名职责设备管理中高频出现的类UI (WinForm/WPF)窗体、控件、页面跳转、校验输入MainForm.cs, DeviceEditForm.cs, PointCheckForm.csBLL业务规则、权限守卫、状态流转DeviceManager.cs, PlanService.csDAL读写数据库、事务、缓存DeviceRepository.cs, SqlHelper.csModels表和视图的实体映射Device.cs, PointCheckRecord.csCommon日志、配置、加密、通信帮助LogHelper.cs, ModbusClient.cs这个划分不是装饰。实际调试中如果我在 DeviceEditForm.cs 里直接写 SqlConnection三个月后加了设备字段改起来就是全局替换而按上面分层改的是模型和仓储UI 只绑数据。C# 在设备信息化里的优势也在这强类型语言Models 字段改错编译期就报错不像脚本等到运行期才崩。2.1 先认清 C# 在设备信息化里的三个优势第一是 WinForm 成熟。设备科电脑配置普遍不高运维多是 IT 兼着WPF 学习成本高WinForm 一个 Form DataGridView 就能跑起来。热词里常搜的 “c# winform主题实现的方法”大多是为了让界面不再像工具箱常见做法是封装一个 BaseForm 统一设 BackColor 和 Font而不是引用重量级 UI 框架。第二是通信生态。设备数据采集绕不开串口、以太网、Modbus、S7 协议。C# 的 SerialPort、System.IO.Pipelines、NModbus4 都有现成库写一个 Modbus TCP 客户端半小时以内。第三是部署简单。.NET Framework 目标机器大多自带或装一个运行时即可用 InstallShield 或 ClickOnce 打包成 MSI 就能给维修班用。2.2 打开解决方案前必须检查的配置项拿到源码先看 .sln 文件引用了哪些项目再看项目文件里的 TargetFrameworkVersion。设备管理系统常驻 Windows绝大多数用 .NET Framework 4.7.2 或 4.8不要一上来就升级到 .NET 6。热词里就有 “c#不再支持netframework 4.0”是的老代码如果锁 4.0NuGet 能还原的包已经很少我一般建议先升到 4.7.2。下面是一个典型的 DAL 项目文件片段Project SdkMicrosoft.NET.Sdk PropertyGroup TargetFrameworknet472/TargetFramework OutputTypeLibrary/OutputType RootNamespaceDeviceSystem.DAL/RootNamespace AssemblyNameDeviceSystem.DAL/AssemblyName /PropertyGroup ItemGroup PackageReference IncludeDapper Version2.0.123 / PackageReference IncludeNModbus4 Version2.1.0 / /ItemGroup /Project这里 TargetFramework 是 net472表示 .NET Framework 4.7.2Dapper 是轻量 ORM适合设备数据这种主要是单表读写和中等复杂统计查询的场景NModbus4 用于后面从 PLC 读温度、频率等参数。注意如果你在 VS2019 打开源码SDK 风格项目可以直接还原包如果是旧式 csproj需要确保 packages.config 存在。配置项另外一处是 App.config / web.config。设备管理系统桌面端几乎都有连接字符串connectionStrings add nameDeviceDB connectionStringData Source127.0.0.1;Initial CatalogDeviceInfo;User Idsa;Password****;MultipleActiveResultSetsTrue providerNameSystem.Data.SqlClient / /connectionStringsData Source 指向数据库实例本地开发用 .\SQLEXPRESS生产用独立数据库服务器MultipleActiveResultSets 打开后DataGridView 绑定和后台线程查询共用同一连接时更方便。这个配置至少要确认三点数据库能不能 ping 通账号密码有没有过期实例名是否匹配。否则后面编译通过也连不上库。2.3 依赖安装和两次编译的注意事项打开 sln 后第一件事是右键解决方案还原 NuGet 包。设备类项目依赖 Dapper、SqlSugar、NModbus4、Newtonsoft.Json、EPPlus导出 Excel这一类。还原报错时八成是目标框架太低或 NuGet 源没配好。用国内镜像源把 nuget.org 和 api.nuget.org 都加上防止 timeout。编译第一次通常会有几个警告引用了不存在的程序集、XAML 资源没找到、或者第三方控件授权。别急着搜索先看错误列表里是不是同一个 DLL 缺失。常见是 System.Data.SQLite 的 Interop 目录必须随 exe 一起发布x64/x86 没配对会一直报 BadImageFormatException。编译通过后先跑不要直接部署。看启动日志里有没有连接数据库失败、初始化表失败、串口被占用。设备管理系统和普通软件不同它要写日志、写设备表每台机器上要保留配置。源码包里的 install.bat 如果存在读一遍里面通常包含创建数据库、复制 Interop.dll、注册计划任务三件事。3. 用C#落地设备台账、点检与Modbus数据采集的代码骨架设备信息化的核心不在界面多好看而在于三个代码骨架台账建模、计划调度、数据采集。下面这张表先把模块和对应技术点对齐后面逐个展开。模块核心实体C# 技术点设备台账DeviceDataGridView BindingList点检保养PointCheckPlanSystem.Threading.Timer / Quartz.NET数据采集DeviceRuntimeSerialPort / ModbusClient维修工单RepairOrder枚举状态机3.1 设备台账模型怎么设计才算“信息化”很多源码把 Device 类只写成编号、名称、规格那是资产登记不是信息化。信息化要求设备能关联点检计划、备件供应商、运行参数。下面这个模型是一个可用的基线public class Device { public int Id { get; set; } public string DeviceCode { get; set; } // 设备编号全局唯一 public string DeviceName { get; set; } // 设备名称 public string Location { get; set; } // 安装位置 public int DeviceTypeId { get; set; } // 类型外键 public DateTime InstallDate { get; set; } // 安装日期 public DateTime? LastMaintainDate { get; set; } // 上次保养时间可空 public int MaintenanceCycleDays { get; set; } // 保养周期天 public int Status { get; set; } // 0-停机 1-运行 2-维修 public decimal MaxTemp { get; set; } // 报警阈值 }这段模型把设备字段和业务参数放在一起Status 用一个 int 枚举方便从 PLC 读到告警时直接赋值MaxTemp 这类阈值放在设备行再合适不过否则报警逻辑每次都要去配置表查慢且乱。注意 LastMaintainDate 用了 DateTime?空值表示该设备从来没有过保养记录统计“超期未保养”时直接用 IS NULL 或 DATEDIFF 判断比默认值 1900-01-01 干净得多。3.2 点检与保养计划C#的Timer还是调度库点检计划本质是“每天定时触发一批任务”。最常见的错误是在每个窗体里 new Timer 然后去查数据库窗口一关定时器跟着死掉。正确做法是让后台任务脱离窗体存在。我一般会用一个 Windows 服务或单独的计划任务来运行点检生成器。如果只想改造现有源码用 System.Threading.Timer 也比 WinForm Timer 可靠因为后者依赖 UI 线程锁屏后可能被调整。下面是一个最小调度示例public class PointCheckScheduler { private readonly Timer _timer; private readonly int _intervalMinutes 30; public PointCheckScheduler() { _timer new Timer(CheckPointPlan, null, TimeSpan.Zero, TimeSpan.FromMinutes(_intervalMinutes)); } private void CheckPointPlan(object state) { // 查询所有今天需要生成点检单的设备 var repo new PointCheckRepository(); var dueList repo.GetDueDevices(DateTime.Today); foreach (var device in dueList) { var record new PointCheckRecord { DeviceId device.Id, PlanDate DateTime.Today, Status 0 // 待检 }; repo.Insert(record); } } }注意这里 Timer 的回调在 ThreadPool 上执行不能在里面直接操作 WinForm 控件需要 Invoke。GetDueDevices 的数据层 SQL 大致是DATEDIFF(day, ISNULL(d.LastMaintainDate, d.InstallDate), GETDATE()) d.MaintenanceCycleDays这样新装设备也能在第一个周期后进入点检列表。intervalMinutes 取 30 分钟可以容忍程序重启后最多半小时补生成点检单。热词里 “c# 延时 效率” 常问的就是 Timer 精度和线程占用这里用线程池定时器不占 UI 线程点检生成量再大也不会让界面卡死。3.3 从PLC读状态C#上位机连Modbus的最小示例设备信息系统如果只录入数据那叫台账不叫信息化。真正的信息化离不开数据采集。C# 上位机最常见的接入协议是 Modbus TCP现场是西门子 PLC 时再用 S7.Net 读 DB 块。下面用 NModbus4 读一个温度寄存器的代码可以抄using Modbus.Device; public class ModbusReader { private TcpClient _tcp; public bool Connect(string ip, int port) { _tcp new TcpClient(); _tcp.Connect(ip, port); // PLC 或 Modbus 网关的 IP return _tcp.Connected; } public ushort ReadTemperature(byte slaveId, ushort startAddress) { var master ModbusIpMaster.CreateIp(_tcp); // 读单个保持寄存器返回 16 位无符号数值 ushort[] values master.ReadHoldingRegisters(slaveId, startAddress, 1); return values[0]; } }参数要点slaveId 是 PLC 通信模块上配置的从站号通常为 1startAddress 以 0 为起点如果触摸屏上写的是 40001转换成 startAddress 0。ReadHoldingRegisters 读的是 Modbus 4 区温度变送器如果挂在输入寄存器要改用 ReadInputRegisters。注意每次读操作后不要马上 CloseTcpClient 复用在产线轮询里能省一半以上握手时间。轮询频率不要快于 100ms否则 PLC 容易拒连。西门子 1200 的思路完全一样换成 S7.Net 的 Plc.Read 之后返回 Object再自行转 ushort 或 float。4. C#设备信息系统的数据库表设计与三个高频统计查询设备系统能不能在维修科真正用起来全看查询方不方便。台账百来条数据时内存也够但点检记录一天几千条Excel 就卡死了。下面给出 SQL Server 下三张核心表的 DDLSQLite 移植也很简单把 INT 改成 INTEGER、NVARCHAR 改成 TEXT 即可。先放一张表说明三张表在业务上的定位表名业务定位主要关联键生命周期Device设备主数据DeviceCode 唯一一次录入持续维护PointCheckRecord点检执行流水DeviceId PlanDate每天新增RepairOrder维修停机流水DeviceId StartedAt故障或预防性记录4.1 设备主数据、点检记录和维修工单怎么建先说 Device 表CREATE TABLE dbo.Device ( DeviceId INT IDENTITY(1,1) PRIMARY KEY, DeviceCode NVARCHAR(50) NOT NULL, DeviceName NVARCHAR(100) NOT NULL, Location NVARCHAR(100) NULL, DeviceTypeId INT NOT NULL, InstallDate DATE NOT NULL, LastMaintainDate DATE NULL, MaintenanceCycleDays INT NOT NULL DEFAULT 90, Status TINYINT NOT NULL DEFAULT 1 ); CREATE UNIQUE INDEX UX_Device_DeviceCode ON dbo.Device(DeviceCode);DeviceId 是自增主键业务上只用 DeviceCode 作为人工可读编号比如 IM-2024-001必须唯一MaintenanceCycleDays 默认 90代表设备保养周期点检计划生成器拿它去算到期日Status 用 TINYINT0 停机、1 运行、2 维修比字符串省空间且 C# 转枚举方便。Location 不需要建索引作为筛选条件使用频率低。然后是每天都在涨的点检记录表CREATE TABLE dbo.PointCheckRecord ( Id BIGINT IDENTITY(1,1) PRIMARY KEY, DeviceId INT NOT NULL REFERENCES dbo.Device(DeviceId), PlanDate DATE NOT NULL, ActualTime DATETIME2(0) NULL, Result TINYINT NOT NULL DEFAULT 0, -- 0待检 1正常 2异常 Remark NVARCHAR(200) NULL ); CREATE INDEX IX_PCR_Device_Plan ON dbo.PointCheckRecord(DeviceId, PlanDate);这里的联合索引 DeviceId PlanDate 是统计的命脉。漏检率的查询条件通常是WHERE DeviceId ? AND PlanDate ? AND PlanDate ?这个索引能直接命中如果后期要统计所有设备某天的漏检PlanDate 在索引第二列不高效可以再加一个单独 PlanDate 索引数据量过了 50 万再考虑。维修工单表CREATE TABLE dbo.RepairOrder ( OrderNo NVARCHAR(32) NOT NULL PRIMARY KEY, DeviceId INT NOT NULL REFERENCES dbo.Device(DeviceId), StartedAt DATETIME2(0) NOT NULL, FinishedAt DATETIME2(0) NULL, TotalDownMinutes INT NOT NULL DEFAULT 0, RepairType TINYINT NOT NULL, -- 1故障 2预防性 Engineer NVARCHAR(20) NULL ); CREATE INDEX IX_RO_Device ON dbo.RepairOrder(DeviceId, StartedAt);TotalDownMinutes 是停机分钟数由维修人员在界面录入“开始时间、结束时间”后自动计算。统计时可用的字段是 RepairType 1 的故障单这样才能把故障停机时间和计划性维护分开算。FinishedAt 为空就代表设备当前正在维修大屏上的红绿灯状态就是从它推的。4.2 月度可用率与设备故障数的SQL写法有了这三张表设备主管最关心的月度故障数、停机时长、可用率可以一条查询出来DECLARE MonthStart DATE 2025-01-01; DECLARE TotalMinutes DECIMAL(18,2) 31 * 24 * 60; SELECT d.DeviceName, COUNT(ro.OrderNo) AS FaultCount, ISNULL(SUM(ro.TotalDownMinutes), 0) AS DownMinutes, ROUND(100.0 * (1 - ISNULL(SUM(ro.TotalDownMinutes), 0) / TotalMinutes), 2) AS AvailabilityRate FROM dbo.Device d LEFT JOIN dbo.RepairOrder ro ON d.DeviceId ro.DeviceId AND ro.RepairType 1 AND ro.StartedAt MonthStart AND ro.StartedAt DATEADD(month, 1, MonthStart) GROUP BY d.DeviceName ORDER BY DownMinutes DESC;MonthStart 是月初日期统计区间使用半开区间 月初 AND 下月月初避免漏掉月末当天 23:59 的工单。AvailabilityRate 用 1 - 停机分钟 / 总分钟是设备可用率的口径。LEFT JOIN 保留了所有设备没有维修单的设备会显示 0 停机、可用率 100%界面里注意用 Status 字段把停用设备过滤掉。点检漏检率是另一个高频指标它能反映点检计划有没有真正执行SELECT d.DeviceName, COUNT(*) AS TotalPlan, SUM(CASE WHEN pc.ActualTime IS NULL THEN 1 ELSE 0 END) AS MissingCount, ROUND(100.0 * SUM(CASE WHEN pc.ActualTime IS NULL THEN 1 ELSE 0 END) / COUNT(*), 1) AS MissingRate FROM dbo.PointCheckRecord pc JOIN dbo.Device d ON pc.DeviceId d.DeviceId WHERE pc.PlanDate 2025-01-01 AND pc.PlanDate 2025-02-01 GROUP BY d.DeviceName HAVING SUM(CASE WHEN pc.ActualTime IS NULL THEN 1 ELSE 0 END) 0 ORDER BY MissingCount DESC;HAVING 过滤掉没有漏检的设备维修班只需要关注漏检率不为 0 的机器。CASE 聚合在几万行上很快但如果 PlanDate 没索引每月初查询会把全表扫一遍数据量上来以后必须给 PlanDate 单独建索引。4.3 为设备状态大屏准备一个视图大屏一般不直接查原始表而是查询视图。下面这个视图用来生成每台设备当前是否在修CREATE VIEW v_DeviceRunningStatus AS SELECT d.DeviceId, d.DeviceName, CASE WHEN EXISTS ( SELECT 1 FROM dbo.RepairOrder ro WHERE ro.DeviceId d.DeviceId AND ro.FinishedAt IS NULL ) THEN 0 ELSE 1 END AS IsRunning FROM dbo.Device d;视图逻辑简单只要存在未完成的维修工单就认为设备不是运行状态。这样做的好处是状态不依赖任何服务端定时刷新每次查询都是实时坏处是界面每秒钟刷新一次会带来数据库压力常见做法是 C# 端每 30 秒查一次缓存到内存。统计查询的最终结果要打印签字时我一般用 iText7 将 DataTable 输出到 PDF用 ColumnText 把文本固定到点检表的矩形框里和这条视图数据的字段一一对应。5. 让C#设备管理系统跑起来的编译部署5个坑与验证技巧设备系统源码大多是 Windows 环境编译坑集中在路径、框架、依赖和调度这几点。我按遇到顺序列一下。坑现象解法解压路径过长编译时找不到文件或报CS错误解压到 D:\Dev\ 这类短路径框架版本不一致NuGet还原失败统一 TargetFramework 4.7.2数据库连接串写死换机器就连不上统一读 App.configInterop.DLL缺失BadImageFormatExceptionx64/x86文件夹随exe发布定时跟随窗体关窗后点检不生成注册计划任务或Windows服务主要说验证。上了这么多表结构和统计逻辑最后不造数据验证不敢交给维修班。下面这段 SQL 给 1 号设备生成 365 天未执行的点检记录DECLARE i INT 0; DECLARE d DATE DATEADD(day, -365, GETDATE()); WHILE i 365 BEGIN INSERT INTO PointCheckRecord(DeviceId, PlanDate, ActualTime, Result) VALUES(1, d, NULL, 0); SET d DATEADD(day, 1, d); SET i i 1; END循环 365 次生成待检记录然后跑漏检率 SQL结果应当是 100%。接着在系统里手动执行一次点检提交更新 ActualTime 和 Result再跑同一句 SQL漏检率会从 100% 降到 364/365 约 99.7%说明设备和点检记录链路是通的。设备信息化管理系统上线前我习惯用上面这组脚本把报表数字和 Excel 对平再让维修班签字这一步省掉后面一半的抱怨。本文还有配套的精品资源点击获取
C#设备信息化管理系统源码实战：从架构设计到数据采集
简介这是一套面向C#开发者和设备管理从业者的企业级设备信息化管理系统源码。系统覆盖资产管理、设备维修保养、备件管理、文件管理与可视化仪表盘等核心模块展示了C#与.NET框架在实际业务中的完整应用尤其适合希望掌握企业级分层架构、数据库交互和复杂业务逻辑的初中级开发者研究学习。资源包共497个文件以243个cs源码文件为主体配合resources资源文件、resx界面资源、vb脚本、png/ico图标、dll库及exe可执行程序等压缩包整体约293MB结构清晰可逐模块拆解阅读。目前已有698人学习下载。虽然项目删除了csproj工程文件导致无法直接编译运行但源码本身保留了完整的业务逻辑和界面设计思路读者可从中学习模块化设计、异常处理、数据验证以及设备全生命周期管理的实现方式是一份贴近实际场景的C#进阶参考资料。1. 一套 C# 设备信息化管理系统源码拿到手先别急着解压早上八点维修主管老张打开 Excel 想统计上个月故障发现点检表停在两周前备件出库单是纸质昨晚三号机停机四十分钟消息还在班长微信里。设备信息化管理系统要解决的正是这种断层把设备台账、点检保养、维修工单、备件库存和运行状态统一到一个可查的界面通常用 WinForm 做桌面端、SQL Server 或 SQLite 存数据、Modbus/HTTP 从 PLC 采状态。适合工厂设备部、上位机开发者和想从 Excel 台账升级的 IT 工程师。拿到源码不要急着编译先盘一遍结构再决定改哪里。2. 拆解C#解决方案结构从WinForm界面到DAL数据访问层一个合格的设备信息化管理系统源码至少会包含四个工程UI 层负责人机交互BLL 层处理业务规则DAL 层封装数据库操作Models 层承载数据实体。有些还会拆出 Common 放日志和工具函数Host 或 Service 做数据采集。下面这张表列了各层在设备管理场景里的具体职责工程名职责设备管理中高频出现的类UI (WinForm/WPF)窗体、控件、页面跳转、校验输入MainForm.cs, DeviceEditForm.cs, PointCheckForm.csBLL业务规则、权限守卫、状态流转DeviceManager.cs, PlanService.csDAL读写数据库、事务、缓存DeviceRepository.cs, SqlHelper.csModels表和视图的实体映射Device.cs, PointCheckRecord.csCommon日志、配置、加密、通信帮助LogHelper.cs, ModbusClient.cs这个划分不是装饰。实际调试中如果我在 DeviceEditForm.cs 里直接写 SqlConnection三个月后加了设备字段改起来就是全局替换而按上面分层改的是模型和仓储UI 只绑数据。C# 在设备信息化里的优势也在这强类型语言Models 字段改错编译期就报错不像脚本等到运行期才崩。2.1 先认清 C# 在设备信息化里的三个优势第一是 WinForm 成熟。设备科电脑配置普遍不高运维多是 IT 兼着WPF 学习成本高WinForm 一个 Form DataGridView 就能跑起来。热词里常搜的 “c# winform主题实现的方法”大多是为了让界面不再像工具箱常见做法是封装一个 BaseForm 统一设 BackColor 和 Font而不是引用重量级 UI 框架。第二是通信生态。设备数据采集绕不开串口、以太网、Modbus、S7 协议。C# 的 SerialPort、System.IO.Pipelines、NModbus4 都有现成库写一个 Modbus TCP 客户端半小时以内。第三是部署简单。.NET Framework 目标机器大多自带或装一个运行时即可用 InstallShield 或 ClickOnce 打包成 MSI 就能给维修班用。2.2 打开解决方案前必须检查的配置项拿到源码先看 .sln 文件引用了哪些项目再看项目文件里的 TargetFrameworkVersion。设备管理系统常驻 Windows绝大多数用 .NET Framework 4.7.2 或 4.8不要一上来就升级到 .NET 6。热词里就有 “c#不再支持netframework 4.0”是的老代码如果锁 4.0NuGet 能还原的包已经很少我一般建议先升到 4.7.2。下面是一个典型的 DAL 项目文件片段Project SdkMicrosoft.NET.Sdk PropertyGroup TargetFrameworknet472/TargetFramework OutputTypeLibrary/OutputType RootNamespaceDeviceSystem.DAL/RootNamespace AssemblyNameDeviceSystem.DAL/AssemblyName /PropertyGroup ItemGroup PackageReference IncludeDapper Version2.0.123 / PackageReference IncludeNModbus4 Version2.1.0 / /ItemGroup /Project这里 TargetFramework 是 net472表示 .NET Framework 4.7.2Dapper 是轻量 ORM适合设备数据这种主要是单表读写和中等复杂统计查询的场景NModbus4 用于后面从 PLC 读温度、频率等参数。注意如果你在 VS2019 打开源码SDK 风格项目可以直接还原包如果是旧式 csproj需要确保 packages.config 存在。配置项另外一处是 App.config / web.config。设备管理系统桌面端几乎都有连接字符串connectionStrings add nameDeviceDB connectionStringData Source127.0.0.1;Initial CatalogDeviceInfo;User Idsa;Password****;MultipleActiveResultSetsTrue providerNameSystem.Data.SqlClient / /connectionStringsData Source 指向数据库实例本地开发用 .\SQLEXPRESS生产用独立数据库服务器MultipleActiveResultSets 打开后DataGridView 绑定和后台线程查询共用同一连接时更方便。这个配置至少要确认三点数据库能不能 ping 通账号密码有没有过期实例名是否匹配。否则后面编译通过也连不上库。2.3 依赖安装和两次编译的注意事项打开 sln 后第一件事是右键解决方案还原 NuGet 包。设备类项目依赖 Dapper、SqlSugar、NModbus4、Newtonsoft.Json、EPPlus导出 Excel这一类。还原报错时八成是目标框架太低或 NuGet 源没配好。用国内镜像源把 nuget.org 和 api.nuget.org 都加上防止 timeout。编译第一次通常会有几个警告引用了不存在的程序集、XAML 资源没找到、或者第三方控件授权。别急着搜索先看错误列表里是不是同一个 DLL 缺失。常见是 System.Data.SQLite 的 Interop 目录必须随 exe 一起发布x64/x86 没配对会一直报 BadImageFormatException。编译通过后先跑不要直接部署。看启动日志里有没有连接数据库失败、初始化表失败、串口被占用。设备管理系统和普通软件不同它要写日志、写设备表每台机器上要保留配置。源码包里的 install.bat 如果存在读一遍里面通常包含创建数据库、复制 Interop.dll、注册计划任务三件事。3. 用C#落地设备台账、点检与Modbus数据采集的代码骨架设备信息化的核心不在界面多好看而在于三个代码骨架台账建模、计划调度、数据采集。下面这张表先把模块和对应技术点对齐后面逐个展开。模块核心实体C# 技术点设备台账DeviceDataGridView BindingList点检保养PointCheckPlanSystem.Threading.Timer / Quartz.NET数据采集DeviceRuntimeSerialPort / ModbusClient维修工单RepairOrder枚举状态机3.1 设备台账模型怎么设计才算“信息化”很多源码把 Device 类只写成编号、名称、规格那是资产登记不是信息化。信息化要求设备能关联点检计划、备件供应商、运行参数。下面这个模型是一个可用的基线public class Device { public int Id { get; set; } public string DeviceCode { get; set; } // 设备编号全局唯一 public string DeviceName { get; set; } // 设备名称 public string Location { get; set; } // 安装位置 public int DeviceTypeId { get; set; } // 类型外键 public DateTime InstallDate { get; set; } // 安装日期 public DateTime? LastMaintainDate { get; set; } // 上次保养时间可空 public int MaintenanceCycleDays { get; set; } // 保养周期天 public int Status { get; set; } // 0-停机 1-运行 2-维修 public decimal MaxTemp { get; set; } // 报警阈值 }这段模型把设备字段和业务参数放在一起Status 用一个 int 枚举方便从 PLC 读到告警时直接赋值MaxTemp 这类阈值放在设备行再合适不过否则报警逻辑每次都要去配置表查慢且乱。注意 LastMaintainDate 用了 DateTime?空值表示该设备从来没有过保养记录统计“超期未保养”时直接用 IS NULL 或 DATEDIFF 判断比默认值 1900-01-01 干净得多。3.2 点检与保养计划C#的Timer还是调度库点检计划本质是“每天定时触发一批任务”。最常见的错误是在每个窗体里 new Timer 然后去查数据库窗口一关定时器跟着死掉。正确做法是让后台任务脱离窗体存在。我一般会用一个 Windows 服务或单独的计划任务来运行点检生成器。如果只想改造现有源码用 System.Threading.Timer 也比 WinForm Timer 可靠因为后者依赖 UI 线程锁屏后可能被调整。下面是一个最小调度示例public class PointCheckScheduler { private readonly Timer _timer; private readonly int _intervalMinutes 30; public PointCheckScheduler() { _timer new Timer(CheckPointPlan, null, TimeSpan.Zero, TimeSpan.FromMinutes(_intervalMinutes)); } private void CheckPointPlan(object state) { // 查询所有今天需要生成点检单的设备 var repo new PointCheckRepository(); var dueList repo.GetDueDevices(DateTime.Today); foreach (var device in dueList) { var record new PointCheckRecord { DeviceId device.Id, PlanDate DateTime.Today, Status 0 // 待检 }; repo.Insert(record); } } }注意这里 Timer 的回调在 ThreadPool 上执行不能在里面直接操作 WinForm 控件需要 Invoke。GetDueDevices 的数据层 SQL 大致是DATEDIFF(day, ISNULL(d.LastMaintainDate, d.InstallDate), GETDATE()) d.MaintenanceCycleDays这样新装设备也能在第一个周期后进入点检列表。intervalMinutes 取 30 分钟可以容忍程序重启后最多半小时补生成点检单。热词里 “c# 延时 效率” 常问的就是 Timer 精度和线程占用这里用线程池定时器不占 UI 线程点检生成量再大也不会让界面卡死。3.3 从PLC读状态C#上位机连Modbus的最小示例设备信息系统如果只录入数据那叫台账不叫信息化。真正的信息化离不开数据采集。C# 上位机最常见的接入协议是 Modbus TCP现场是西门子 PLC 时再用 S7.Net 读 DB 块。下面用 NModbus4 读一个温度寄存器的代码可以抄using Modbus.Device; public class ModbusReader { private TcpClient _tcp; public bool Connect(string ip, int port) { _tcp new TcpClient(); _tcp.Connect(ip, port); // PLC 或 Modbus 网关的 IP return _tcp.Connected; } public ushort ReadTemperature(byte slaveId, ushort startAddress) { var master ModbusIpMaster.CreateIp(_tcp); // 读单个保持寄存器返回 16 位无符号数值 ushort[] values master.ReadHoldingRegisters(slaveId, startAddress, 1); return values[0]; } }参数要点slaveId 是 PLC 通信模块上配置的从站号通常为 1startAddress 以 0 为起点如果触摸屏上写的是 40001转换成 startAddress 0。ReadHoldingRegisters 读的是 Modbus 4 区温度变送器如果挂在输入寄存器要改用 ReadInputRegisters。注意每次读操作后不要马上 CloseTcpClient 复用在产线轮询里能省一半以上握手时间。轮询频率不要快于 100ms否则 PLC 容易拒连。西门子 1200 的思路完全一样换成 S7.Net 的 Plc.Read 之后返回 Object再自行转 ushort 或 float。4. C#设备信息系统的数据库表设计与三个高频统计查询设备系统能不能在维修科真正用起来全看查询方不方便。台账百来条数据时内存也够但点检记录一天几千条Excel 就卡死了。下面给出 SQL Server 下三张核心表的 DDLSQLite 移植也很简单把 INT 改成 INTEGER、NVARCHAR 改成 TEXT 即可。先放一张表说明三张表在业务上的定位表名业务定位主要关联键生命周期Device设备主数据DeviceCode 唯一一次录入持续维护PointCheckRecord点检执行流水DeviceId PlanDate每天新增RepairOrder维修停机流水DeviceId StartedAt故障或预防性记录4.1 设备主数据、点检记录和维修工单怎么建先说 Device 表CREATE TABLE dbo.Device ( DeviceId INT IDENTITY(1,1) PRIMARY KEY, DeviceCode NVARCHAR(50) NOT NULL, DeviceName NVARCHAR(100) NOT NULL, Location NVARCHAR(100) NULL, DeviceTypeId INT NOT NULL, InstallDate DATE NOT NULL, LastMaintainDate DATE NULL, MaintenanceCycleDays INT NOT NULL DEFAULT 90, Status TINYINT NOT NULL DEFAULT 1 ); CREATE UNIQUE INDEX UX_Device_DeviceCode ON dbo.Device(DeviceCode);DeviceId 是自增主键业务上只用 DeviceCode 作为人工可读编号比如 IM-2024-001必须唯一MaintenanceCycleDays 默认 90代表设备保养周期点检计划生成器拿它去算到期日Status 用 TINYINT0 停机、1 运行、2 维修比字符串省空间且 C# 转枚举方便。Location 不需要建索引作为筛选条件使用频率低。然后是每天都在涨的点检记录表CREATE TABLE dbo.PointCheckRecord ( Id BIGINT IDENTITY(1,1) PRIMARY KEY, DeviceId INT NOT NULL REFERENCES dbo.Device(DeviceId), PlanDate DATE NOT NULL, ActualTime DATETIME2(0) NULL, Result TINYINT NOT NULL DEFAULT 0, -- 0待检 1正常 2异常 Remark NVARCHAR(200) NULL ); CREATE INDEX IX_PCR_Device_Plan ON dbo.PointCheckRecord(DeviceId, PlanDate);这里的联合索引 DeviceId PlanDate 是统计的命脉。漏检率的查询条件通常是WHERE DeviceId ? AND PlanDate ? AND PlanDate ?这个索引能直接命中如果后期要统计所有设备某天的漏检PlanDate 在索引第二列不高效可以再加一个单独 PlanDate 索引数据量过了 50 万再考虑。维修工单表CREATE TABLE dbo.RepairOrder ( OrderNo NVARCHAR(32) NOT NULL PRIMARY KEY, DeviceId INT NOT NULL REFERENCES dbo.Device(DeviceId), StartedAt DATETIME2(0) NOT NULL, FinishedAt DATETIME2(0) NULL, TotalDownMinutes INT NOT NULL DEFAULT 0, RepairType TINYINT NOT NULL, -- 1故障 2预防性 Engineer NVARCHAR(20) NULL ); CREATE INDEX IX_RO_Device ON dbo.RepairOrder(DeviceId, StartedAt);TotalDownMinutes 是停机分钟数由维修人员在界面录入“开始时间、结束时间”后自动计算。统计时可用的字段是 RepairType 1 的故障单这样才能把故障停机时间和计划性维护分开算。FinishedAt 为空就代表设备当前正在维修大屏上的红绿灯状态就是从它推的。4.2 月度可用率与设备故障数的SQL写法有了这三张表设备主管最关心的月度故障数、停机时长、可用率可以一条查询出来DECLARE MonthStart DATE 2025-01-01; DECLARE TotalMinutes DECIMAL(18,2) 31 * 24 * 60; SELECT d.DeviceName, COUNT(ro.OrderNo) AS FaultCount, ISNULL(SUM(ro.TotalDownMinutes), 0) AS DownMinutes, ROUND(100.0 * (1 - ISNULL(SUM(ro.TotalDownMinutes), 0) / TotalMinutes), 2) AS AvailabilityRate FROM dbo.Device d LEFT JOIN dbo.RepairOrder ro ON d.DeviceId ro.DeviceId AND ro.RepairType 1 AND ro.StartedAt MonthStart AND ro.StartedAt DATEADD(month, 1, MonthStart) GROUP BY d.DeviceName ORDER BY DownMinutes DESC;MonthStart 是月初日期统计区间使用半开区间 月初 AND 下月月初避免漏掉月末当天 23:59 的工单。AvailabilityRate 用 1 - 停机分钟 / 总分钟是设备可用率的口径。LEFT JOIN 保留了所有设备没有维修单的设备会显示 0 停机、可用率 100%界面里注意用 Status 字段把停用设备过滤掉。点检漏检率是另一个高频指标它能反映点检计划有没有真正执行SELECT d.DeviceName, COUNT(*) AS TotalPlan, SUM(CASE WHEN pc.ActualTime IS NULL THEN 1 ELSE 0 END) AS MissingCount, ROUND(100.0 * SUM(CASE WHEN pc.ActualTime IS NULL THEN 1 ELSE 0 END) / COUNT(*), 1) AS MissingRate FROM dbo.PointCheckRecord pc JOIN dbo.Device d ON pc.DeviceId d.DeviceId WHERE pc.PlanDate 2025-01-01 AND pc.PlanDate 2025-02-01 GROUP BY d.DeviceName HAVING SUM(CASE WHEN pc.ActualTime IS NULL THEN 1 ELSE 0 END) 0 ORDER BY MissingCount DESC;HAVING 过滤掉没有漏检的设备维修班只需要关注漏检率不为 0 的机器。CASE 聚合在几万行上很快但如果 PlanDate 没索引每月初查询会把全表扫一遍数据量上来以后必须给 PlanDate 单独建索引。4.3 为设备状态大屏准备一个视图大屏一般不直接查原始表而是查询视图。下面这个视图用来生成每台设备当前是否在修CREATE VIEW v_DeviceRunningStatus AS SELECT d.DeviceId, d.DeviceName, CASE WHEN EXISTS ( SELECT 1 FROM dbo.RepairOrder ro WHERE ro.DeviceId d.DeviceId AND ro.FinishedAt IS NULL ) THEN 0 ELSE 1 END AS IsRunning FROM dbo.Device d;视图逻辑简单只要存在未完成的维修工单就认为设备不是运行状态。这样做的好处是状态不依赖任何服务端定时刷新每次查询都是实时坏处是界面每秒钟刷新一次会带来数据库压力常见做法是 C# 端每 30 秒查一次缓存到内存。统计查询的最终结果要打印签字时我一般用 iText7 将 DataTable 输出到 PDF用 ColumnText 把文本固定到点检表的矩形框里和这条视图数据的字段一一对应。5. 让C#设备管理系统跑起来的编译部署5个坑与验证技巧设备系统源码大多是 Windows 环境编译坑集中在路径、框架、依赖和调度这几点。我按遇到顺序列一下。坑现象解法解压路径过长编译时找不到文件或报CS错误解压到 D:\Dev\ 这类短路径框架版本不一致NuGet还原失败统一 TargetFramework 4.7.2数据库连接串写死换机器就连不上统一读 App.configInterop.DLL缺失BadImageFormatExceptionx64/x86文件夹随exe发布定时跟随窗体关窗后点检不生成注册计划任务或Windows服务主要说验证。上了这么多表结构和统计逻辑最后不造数据验证不敢交给维修班。下面这段 SQL 给 1 号设备生成 365 天未执行的点检记录DECLARE i INT 0; DECLARE d DATE DATEADD(day, -365, GETDATE()); WHILE i 365 BEGIN INSERT INTO PointCheckRecord(DeviceId, PlanDate, ActualTime, Result) VALUES(1, d, NULL, 0); SET d DATEADD(day, 1, d); SET i i 1; END循环 365 次生成待检记录然后跑漏检率 SQL结果应当是 100%。接着在系统里手动执行一次点检提交更新 ActualTime 和 Result再跑同一句 SQL漏检率会从 100% 降到 364/365 约 99.7%说明设备和点检记录链路是通的。设备信息化管理系统上线前我习惯用上面这组脚本把报表数字和 Excel 对平再让维修班签字这一步省掉后面一半的抱怨。本文还有配套的精品资源点击获取
