基于C#的PLC工位追溯与报警提示系统开发实战解析

1. 项目背景与需求拆解搞制造业自动化的朋友应该都有体会产线上最怕的不是设备停机而是出了事查不清。我去年在某汽车零部件车间帮人做了一套基于C#的PLC工位间追溯与报警提示软件核心就是为了解决一台产品经过哪些工位、每个工位做了什么加工、出了异常时现场有没有人第一时间响应这三件事。先说现场背景。那条产线有六个工位从压装、铆接到检测、打标每个工位由独立的PLC控制。以前的信息流是断的PLC只管自己这个工位的动作产品在工位之间的流转状态没人记录一旦终端客户投诉这批货里有几个不良品厂里翻遍纸质记录也查不到具体是哪台设备、哪个时段、哪个批次做的。报警也同样原始就是设备自带的三色灯中控室根本不知道现场哪个工位停了更不知道停了多久。这套软件要解决的痛点很明确一是把散布在六台PLC里的生产数据串起来形成产品档案二是建立一套即时报警通知机制让异常从灯亮了没人管变成系统自动记录并循环提醒。文章后面全部围绕这两个核心展开顺便把我在开发过程中踩过的坑、掉过的头发一并复盘。1.1 核心需求梳理在动手写第一行代码之前我先花了两天时间蹲在产线旁边把需求白纸黑字列出来。这一步相当关键因为现场人员描述需求和真正需要的东西往往差了十万八千里。经过和工艺、设备、质量三个部门反复对齐这套软件最终锁定为六个功能点采集每台PLC的关键工位信号包括加工完成、检测结果、设备状态、报警代码建立产品ID与各工位加工记录的绑定关系实现全程追溯按产品ID、工单号、时间段等维度查询追溯档案实时监听PLC报警信号按优先级触发声光提示和界面弹窗记录报警发生时间、恢复时间、处理人、处理结果生产数据存入数据库为后续做报表统计留好接口这六个功能看起来不复杂但真正做起来牵扯到通信协议、数据库设计、UI交互、现场部署一堆细节。后文我会按模块逐个拆解。1.2 技术选型为什么是C#有人问过我工位追溯和报警提示这种活用组态软件比如WinCC、组态王不是更省事吗确实如果用组态软件画面和PLC点位绑定的开发周期可能只要一两周。但组态软件有两个天然短板第一追溯逻辑复杂时要写大量脚本尤其是产品ID和工位数据的关联、跨工位的数据拼接脚本写多了维护成本极高第二数据报表和外部系统对接能力弱后面想扩展MES接口、做移动端推送组态软件基本都得绕道。选用C#主要是看中三点和PLC通信的生态成熟西门子、三菱、Modbus TCP都有现成库可用WinForm/WPF做工业上位机界面开发效率高数据绑定、多线程、定时器这些用起来顺手数据库连接和业务逻辑编写灵活追溯查询这种重SQL场景非常合适. NET平台做工业软件还有一个隐性优势部署时可以用.NET Framework自带的运行时目标机器不一定联网不需要额外装一大堆依赖。这对车间里那台配置不高的工控机来说很友好。1.3 整体架构设计这套软件的架构我定位为单机部署、数据集中、逻辑分层。不搞花哨的微服务也不做跨机器的分布式部署因为现场就一台工控机一台数据库服务器六台PLC通过工业交换机组成一个小型局域网。逻辑上分四层层级职责关键技术点通信层与PLC交换数据读写点位S7协议、Modbus TCP业务层追溯逻辑、报警判定、数据落库多线程、队列、状态机数据层存储追溯记录和报警记录SQL Server数据库界面层实时监控、查询、报警展示WinForm控件、数据绑定通信层和业务层之间用数据订阅模式解耦通信层只管把从PLC读到的数据扔进内存队列业务层从队列里取数据做判断。这样做的好处是通信波动不会直接卡死界面业务逻辑修改也碰不到通信代码。2. 通信层让C#和PLC顺畅对话通信层是整个软件的地基这一层做不好后面所有的追溯和报警都是空中楼阁。先说结论通信层最难的不是连上PLC读到数据而是长时间稳定运行不出错。2.1 协议选型与连接方式现场六台PLC全部支持标准以太网通信所以方案很直接统一走以太网协议不碰串口。这一选择省掉了大量串口通信的兼容性麻烦比如波特率不一致、线缆干扰、地址冲突等等。协议层面我主要用了两种西门子S7协议用于S7-1200/1500系列PLC读取DB块和M区数据Modbus TCP用于部分老型号PLC和远程IO模块选型时我做过一个对比测试S7协议通过底层库直连读取100个字节的响应时间在10毫秒左右Modbus TCP稍慢大约15~20毫秒。对于工位追溯这种秒级或毫秒级的场景两者都完全够用不需要纠结性能差异。有一点要注意S7协议有TSAP连接参数不同型号PLC的TSAP不同连接前必须确认。S7-1200通常用TSAP 0x0301S7-1500用0x0101。我第一次配置时把1200的TSAP套到1500上结果连接超时报错排查了半天才反应过来是型号差异。2.2 通信库的封装C#连西门子PLC常用方案是直接调用S7.Net或者HslCommunication这类开源库。我最终选了HslCommunication原因是它对不同品牌PLC的协议封装更统一API风格一致文档也相对完整。但注意直接用第三方库不是拿来就完事一定要在它外面再包一层自己的通信服务类。我的封装思路如下每台PLC对应一个通信实例统一管理连接状态提供ReadData/WriteData方法内部处理重试和异常通信状态变化时触发事件通知界面层更新连接指示灯所有PLC连接参数IP、端口、机架号、槽号放在配置文件里方便现场改public class PlcChannel : IDisposable { private HslCommunication.Profinet.Siemens.SiemensS7Net _plc; private readonly PlcConfig _config; public event Actionbool ConnectionStatusChanged; public PlcChannel(PlcConfig config) { _config config; _plc new HslCommunication.Profinet.Siemens.SiemensS7Net( HslCommunication.Profinet.Siemens.SiemensPLCS.S1200, config.IpAddress); _plc.SetPersistConnection(true); // 保持长连接 } public bool Connect() { var result _plc.ConnectServer(); ConnectionStatusChanged?.Invoke(result.IsSuccess); return result.IsSuccess; } public OperateResultbyte[] ReadBytes(string address, ushort length) { // 内部加入连接状态判断和断线重连 if (!_plc.ConnectServer().IsSuccess) { ConnectionStatusChanged?.Invoke(false); return new OperateResultbyte[](连接已断开); } return _plc.Read(address, length); } }封装的核心逻辑是把异常消化在内部。因为工控机上跑的软件没人盯着控制台输出任何未处理的异常都可能导致程序崩溃到时候产线直接断数据后果很严重。2.3 数据采集策略与性能优化采集策略我踩过一个典型的坑最初图省事用一个高频率的定时器每秒轮询六台PLC的所有点位结果CPU占用率飙到40%而且频繁通信导致PLC本身扫描周期都受影响。后来改成分层采集策略快变量2秒采样设备运行状态、报警信号、急停状态慢变量10秒采样产量计数、设备温度、节拍时间事件变量触发式加工完成信号、检测结果变化每个工位的关键信号用标签表管理把PLC地址、数据类型、采样周期、业务含义全部映射起来。标签表单独建一个类管理代码里不做硬编码这样PLC点位调整时只需要改配置文件。public class TagItem { public string TagName { get; set; } // 标签名如工位1_加工完成 public string PlcAddress { get; set; } // PLC地址如DB1.DBX10.0 public string DataType { get; set; } // bool / int / real public int SampleCycle { get; set; } // 采样周期秒 public string StationId { get; set; } // 所属工位 }多线程采集要注意一个细节不同PLC的读取操作必须放在独立线程里不能让一台PLC的通信超时拖慢其他PLC。我用了一个简单的线程池每台PLC一个采集线程线程之间通过BlockingCollection对接。还有一个实用技巧连续读取同一DB块内的多个连续地址效率远高于逐点读取。比如工位1的10个信号都在DB1的前20个字节里那就一次性读取20个字节再按偏移量解析比发10次请求快得多对PLC的扫描周期影响也小。2.4 断线重连与心跳机制车间环境里网线被叉车压断、交换机掉电、PLC固件重启这些事我都遇到过。没有断线重连机制通信层一旦断开就永远回不来整个追溯系统形同虚设。实现上我做了三层防护心跳检测每5秒发送一个读取请求连续3次失败判定为断线自动重连断线后按指数退避策略重连间隔从5秒逐步增加到60秒成功连接后恢复5秒数据缓存断线期间采集到的关键事件先写入内存队列恢复后补录数据库数据缓存这个设计要特别说明一下。追溯数据讲究连续性如果通信中断期间产品还在继续过站这些过站记录就丢了事后没法补。所以我在业务层放了一个待补录队列断线期间产生的加工完成事件先缓存恢复后按时间戳插入数据库。当然如果断线时间特别长比如半小时以上队列会占用大量内存我设置了队列长度上限超过上限就丢弃最早的数据并记录一条日志毕竟追溯数据也不能无限堆积。3. 追溯模块串起工位间的数据流追溯是整个软件的灵魂。报警提示只是告诉现场现在出了问题而追溯要回答的是这批产品从哪来、经过了什么、谁加工的、结果如何。3.1 追溯数据模型设计我设计追溯模型时参考了汽车行业常用的批次追溯思路但针对机加工产线做了适配。核心概念只有三个产品唯一标识、工位加工记录、装配物料绑定。产品唯一标识用的是条码/二维码。产品进入产线第一个工位时扫码枪把条码读进来PLC通过IO信号通知上位机新产品已到位上位机把当前产品ID记入内存中的在制队列后续每个工位完成加工时都往这条产品记录里追加一条工位加工记录。数据模型的关键在于主数据表明细表的两层结构产品主表记录产品ID、条码、型号、工单号、上线时间、下线时间工位明细表记录每个工位的加工时间、加工参数、检测结果、操作设备物料绑定表记录关键物料如螺栓、密封圈的批次号与产品的绑定关系-- 产品主表 CREATE TABLE ProductTrace ( Id INT IDENTITY PRIMARY KEY, ProductSn NVARCHAR(50) NOT NULL, ModelCode NVARCHAR(20) NOT NULL, WorkOrder NVARCHAR(30), StartTime DATETIME, EndTime DATETIME, FinalResult TINYINT DEFAULT 0 ); -- 工位明细表 CREATE TABLE StationRecord ( Id INT IDENTITY PRIMARY KEY, ProductId INT NOT NULL, StationCode NVARCHAR(10) NOT NULL, ProcessTime DATETIME DEFAULT GETDATE(), ResultCode TINYINT, KeyParams NVARCHAR(200) );工位明细表里的KeyParams字段我用JSON格式存工位的关键参数快照比如压装力、扭矩值、检测尺寸。这样好处是表结构不需要跟着工艺参数变化来回改查询时用什么参数一目了然。缺点是无法对这些JSON内的字段做高效SQL聚合但这套系统主要用于单件追溯查询不涉及大批量统计分析所以完全够用。3.2 产品身份绑定逻辑产品身份绑定是整个追溯系统最容易出错的地方。现场经常出现的情况是产品还没到位扫码枪就扫了或者产品已经过了工位1但工位1的加工完成信号还没触发。我的处理思路是信号驱动超时兜底。每个工位的PLC程序里都定义一个工位完成通过信号只有当产品确实完成加工并流到下一工位时才置位。上位机监听到这个信号的上升沿从0变1才记录该工位的加工记录。这是最可靠的方式因为信号本身来自PLC的传感器逻辑代表物理世界的真实动作。但光靠信号还不够还要有兜底机制。有些工位设备老旧传感器偶尔失灵信号可能不触发或者重复触发。所以我加了一个超时强制完成策略新产品上线后如果在设定时间内比如5分钟仍没有收到加工完成信号系统会产生一条工位超时的异常记录并弹出报警提示让人工确认。还有一点容易忽略条码重复。扫码枪可能连续扫到同一个条码两次导致一个产品ID被重复写入。我在主表上对ProductSn字段加了唯一索引同时前端扫码逻辑里做了防抖——同一产品ID在10秒内不允许重复上线。3.3 追溯查询界面实现追溯查询界面的核心要求是快。操作员输入一个条码1秒内必须看到结果否则人家就会觉得系统不好用转而走回纸质记录的老路。界面布局上我分成三个区域顶部查询条件区支持条码、工单号、时间段三种查询方式左侧产品主信息展示包括条码、型号、工单、上下线时间、最终判定结果右侧工位明细列表按时间顺序显示每个工位的加工记录工位明细列表是查询界面的核心我用DataGridView展示每条记录包含工位号、工序名称、加工时间、结果状态、关键参数。结果状态用颜色区分绿色表示合格红色表示异常。这一块看似简单但要做得好用有几个细节双击某条工位记录弹出该工位的详细参数快照点击产品主信息中的物料绑定列表可以看到关键物料的批次号查询结果支持导出CSV方便质量部门拿去做统计分析private void BtnQuery_Click(object sender, EventArgs e) { string sn txtProductSn.Text.Trim(); if (string.IsNullOrEmpty(sn)) { MessageBox.Show(请输入产品条码); return; } var product _dbService.GetProductBySn(sn); if (product null) { lblResult.Text 未找到该产品的追溯记录; return; } BindProductInfo(product); BindStationRecords(product.Id); }查询性能优化上我建了一个复合索引ProductSn Id并按Id倒序排列数据返回。数据量在十万级时单条查询响应时间基本在200毫秒以内现场体验完全没问题。3.4 跨工位数据拼接产线是流水线式的产品经过工位1、工位2、工位3……每个工位的数据是独立采集的。追溯的关键操作就是把这些独立的数据按产品ID拼起来。拼接逻辑有些隐蔽的坑。比如产品在工位2和工位3之间被人工干预拿走过再放回来时工位2的完成信号可能没触发或触发混乱。我在设计时用产品在制队列工位顺序校验来兜底每台产品在制队列中维护当前应到的工位序号如果工位上报的加工记录序号和预期不符系统判定为跳序异常并报警同时把产品状态标记为待人工确认。这个设计初期被现场抱怨报警太多后来发现确实抓到了几个真正的漏工序问题质量部门反而要求保留。这类防呆逻辑做上位机软件时一定要主动加生产现场的意外状况永远比你想的多。4. 报警提示模块让异常第一时间可见追溯解决的是事后查报警解决的是事前知。一套好的报警系统要做到两层效果现场操作员能在5秒内发现异常中控室或管理人员能在1分钟内接收到异常通知。4.1 报警等级与分类设计报警不能一刀切不同等级的异常需要不同的响应方式。我把报警分为三个等级等级类型响应要求示例一级设备安全类立即停机排查急停触发、安全门打开、电机过载二级质量异常类当前产品隔离处理检测尺寸超差、压装力不足三级生产提示类记录并提醒工位超时、物料接近用完三级报警的分类不是拍脑袋定的而是和现场生产主管、设备工程师一起花了一下午逐个梳理报警点位后定下来的。梳理过程中还发现很多PLC报警代码的含义和现场描述不一致最后统一整理成了一份报警字典表存在数据库里报警代码直接映射成中文描述比PLC里的数字代码直观太多了。4.2 实时报警检测逻辑报警检测本质上是一个状态变化监听器PLC里的报警位从0变1系统就认为报警发生从1变0就认为报警恢复。但直接监听位变化会造成很多误报。PLC上电瞬间或通信中断恢复时所有点位都会被读成初始值这时候报警位经常是1系统就会误报一堆假报警。我在检测逻辑里加了通信稳定窗通信恢复正常后先等待3秒确保点位状态稳定再开始监听报警变化。报警检测和去重的核心代码如下private void CheckAlarm(TagItem alarmTag) { bool rawValue ReadBool(alarmTag.PlcAddress); bool lastValue _lastAlarmStates.GetValueOrDefault(alarmTag.TagName, false); if (rawValue !lastValue) { // 上升沿报警触发 var alarm new AlarmRecord() { AlarmCode alarmTag.TagName, StationId alarmTag.StationId, StartTime DateTime.Now, Level alarmTag.AlarmLevel }; _alarmQueue.Enqueue(alarm); FireAlarmNotification(alarm); // 触发界面弹窗与声音 } else if (!rawValue lastValue) { // 下降沿报警恢复 UpdateAlarmEndTime(alarmTag.TagName, DateTime.Now); } _lastAlarmStates[alarmTag.TagName] rawValue; }注意报警恢复时间的记录同样重要。管理层最关心的是报警持续了多久因为停机时间直接关联产能损失。所以每条报警记录都必须有开始时间和结束时间两段时间之差就是报警持续时间。有的报警恢复信号可能因为通信抖动丢失我同样用超时兜底机制——如果报警持续超过4小时还没恢复信号系统自动标记为可疑持续报警并再次提醒管理员确认现场状态。4.3 报警提示的呈现方式报警提示不能只靠弹窗弹窗是最弱的一种提醒方式——操作员可能正背对着电脑。我做了三通道提醒界面通道主界面顶部固定显示报警横幅红色闪烁显示最新一级报警声音通道不同等级报警播放不同的蜂鸣声一级报警声音最急促记录通道报警记录实时写入数据库中控室可以通过局域网页面查看声音提示这里有个细节Windows系统自带的MessageBeep声音太轻车间环境噪音大根本听不见。我自己折腾了一段播放WAV音频的代码提前录制了几种不同节奏的报警音。后来发现车间工人都被磨出条件反射了一听到急促的蜂鸣就知道有工位出问题了。报警弹窗我控制得比较谨慎只对一级报警弹模态窗口因为模态窗口会阻塞界面操作如果现场频繁弹窗操作员会被烦死最后直接关掉软件。二级报警用非模态的浮动条展示三级报警只做列表记录。4.4 报警历史与处理闭环报警不能只响不闭。我做了报警工单流程每条报警记录默认状态是待处理操作员处理完现场问题后在系统里选择确认填写处理结果和故障原因状态变为已处理。如果4小时内还没确认系统自动把报警升级为超时未处理并向班组长界面显著置顶展示。这一套流程实施后现场报警反馈率和处理及时率提升非常明显班组长每天早上第一件事就是看昨天的报警处理情况不用再去车间翻纸。报警历史查询界面按日期、工位、等级筛选还能统计每个工位的报警次数排名顺带优化了设备的针对性维护计划。5. 实战中的坑与排查技巧这部分是我最想分享的。所有顺利的规划都差不多但坑各有各的踩法。这套系统从开发到稳定运行前后花了大概一个半月其中有三分之一时间在跟各种莫名其妙的现场问题较劲。5.1 通信超时与数据丢包处理开发阶段一切正常一到现场接上真正的PLC通信超时频繁出现。排查了一圈发现是交换机端口配置问题。现场网络交换机的某些端口开启了风暴抑制导致PLC广播报文被丢弃而S7协议在建立连接前有一个广播握手过程被丢包后就表现成超时。解决方案有两步一是把工业交换机的风暴抑制功能对该网段关闭或调高阈值二是在软件层面对首次连接做特殊重试——失败后间隔2秒、5秒、10秒递增重试最多重试5次。加了这个重试逻辑后通信成功率从90%直接拉到了接近100%。数据丢包则是另一个问题。Modbus TCP偶尔出现读回的字节串错位我排查后发现是PLC侧程序里把两个连续的写入指令间隔设得太短导致上位机的连续读取和PLC的写入撞车。处理办法是读操作全部加互斥锁同一时刻只能有一个线程在通信总线上进行读取彻底避免指令交错。5.2 UI卡顿与刷新机制WinForm界面卡顿十有八九是把耗时操作放在了UI线程。我最初做报警列表刷新时直接在数据到达事件里调用了dataGridView.Rows.Add结果数据一多界面就假死。改进方案是老生常谈但真的管用所有PLC数据到达、数据库读写都不准碰UI控件通过Control.BeginInvoke把界面更新操作切回UI线程。报警列表更新采用定时批量刷新策略数据先存内存队列每500毫秒批量刷新一次界面而不是来一条刷一条。还有个隐藏很深的坑DataGridView的自动调整列宽功能。当初觉得让列宽自动适应内容很省事结果数据量大时每次都触发尺寸计算CPU占用飙升。改成固定列宽模式后问题消失。所以工业上位机UI优化第一原则就是别让控件做超出必要的工作。5.3 数据一致性问题追溯数据的一致性核心在数据库并发。多线程同时采集六台PLC的数据写数据库时如果发生死锁会导致部分工位记录丢失。我在数据访问层做了统一的事务管理所有写入操作都走同一个数据库上下文写入前先检查该产品ID是否已存在工位记录不存在才插入。同时把写入操作串行化——用一个专门的写入线程队列所有数据先入队由这个单线程统一执行数据库写入。这是这套系统里我最满意的一个设计带来的好处是写入顺序严格按时间戳不会出现工位2的记录先于工位1记录的问题并发冲突彻底消失。代价是写入吞吐量受限但对这个场景来说完全不是瓶颈。关键要理解这里为什么串行化反而是最优解追溯数据本身强关联、强有序没必要用并发写入换一点吞吐排好序比跑得快重要得多。5.4 现场部署注意事项部署环境比开发环境复杂得多。我在现场遇到过几类问题工控机系统时间不准。PLC日志和数据库记录对时间一致性要求极高如果工控机时间每天都偏几分钟追溯时间线就乱了。解决办法是部署时打开Windows时间同步并手工校时。杀毒软件拦截。车间工控机装的杀毒软件会把通信库误报为风险程序。部署时要把程序所在目录加入白名单。断电异常。车间偶尔闪断工控机直接断电数据库可能损坏。我用了两个策略数据库文件放在D盘数据目录并设置自动备份程序启动时先备份数据库文件再打开连接异常时能快速恢复。部署时还有一件小事值得说给工控机设置一个固定的IP并且和PLC的IP规划在同一个网段。现场换工控机时如果IP变了所有PLC连接配置、防火墙规则、数据库连接串全要跟着改提前固定IP能省很多事。5.5 报警误报与漏报的平衡艺术报警系统最难的是在误报和漏报之间找平衡。报警阈值设得太敏感天天响假警报操作员就麻了设得太迟钝真出问题又发现不了。举一个具体例子工位3的压装检测信号PLC里输出的是一个模拟量需要在软件里转成质量判定。最初我参考设备手册设置了固定阈值结果冬天车间温度低压装力整体偏低阈值没变导致大量正常产品被判成压装不足产线整条停摆。后来我把固定阈值改成动态基准容差区间每天开机后自动采集前20件合格产品的压装力数据取平均值再以这个均值为中心上下浮动某个百分比作为判定区间。这样环境温度、设备磨损、物料批次变化带来的基准漂移都能自动适应。这套动态阈值上线后误报率降低了大半。所以报警设计一定要理解现场数据的波动规律不能只读手册、不读数据。6. 这套系统的扩展方向与个人体会软件上线稳定运行之后我并没有停在能用这个阶段。后面一个月又陆续做了几个方向的扩展也总结了不少自己的体会。6.1 从单机追溯走向多线协同最初这套系统只针对一条产线。由于数据库结构和接口设计从一开始就留了车间编码和产线编码字段后来其他两条产线要接入时只需要在标签表和配置表里增加产线维度即可。界面层增加了一个产线切换下拉框数据自动按产线过滤。这个扩展过程比预想顺利原因是当初设计表结构时我没有偷懒每个关键表的业务主键都包含产线/工位维度而不是简单用自增ID做唯一逻辑。6.2 从报警提示走向Andon管理报警模块后来演变成了一个轻量的Andon安灯系统。除了原有的声光提示我加了一个车间看板页面通过一块液晶电视显示每台设备的实时状态绿色运行、黄色待料、红色故障。这个页面用只读权限的数据库连接即使主程序卡死也不会影响看板显示。车间主任反馈看板上线后管理效率明显提升站在办公室就能看到整个车间的脉搏。这个看板页面最有价值的是停机时长排名列每次班前会讨论的都是这台设备昨天怎么又停了40分钟设备部门出勤维修的主动性比以前强了很多。6.3 数据接口与MES的对接预留虽然当前厂里还没有成熟的MES系统但我在软件里预留了标准的数据访问接口一个只读视图提供给外部系统查询产品追溯记录一个Web API接口供第三方系统按产品条码获取追溯JSON数据。这两个接口都是只读的不会影响主系统的正常运行。我的个人体会是做工业上位机软件克制比激进重要。用户提出一百个需求你先挑核心的十个做剩下的先预留接口。不要一上来就搞大而全的平台也不要过早引入复杂的架构能把产品追溯报警通知这两件事做到稳定可靠就已经解决工厂80%的痛点。6.4 最后分享两个小技巧写这套系统的过程中有两个小技巧虽然不起眼但实际帮助非常大值得单独说。第一个是PLC点位映射表的自动校验工具。现场PLC程序经常被设备工程师修改改完之后地址可能变了。我在系统里做了一个点位健康检查功能启动时自动读取所有配置的点位地址对比预设的类型和范围发现异常直接列出清单。这个小功能救了我好几次因为现场工程师改完PLC程序很多时候不会主动告诉你。第二个是日志分级。我把软件日志分成Debug、Info、Warn、Error四级Debug日志记录每个PLC点位的原始值变化默认关闭。现场出问题时通过配置文件打开Debug日志配合数据库里的追溯记录基本能定位90%的问题。平时运行时只开Info和Error日志文件不会无限膨胀。如果你也准备做类似的工位追溯或报警软件我建议你先不要纠结用什么框架、什么数据库先把PLC通信跑通把数据打通再从最简单的单一工位做追溯验证一步步扩展。工业现场最稀缺的不是技术新奇是稳和可靠。一套能让产线工人愿意用、放心用的软件比任何花哨的功能都重要。