基于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读到的数据扔进内存队列，业务层从队列里取数据做判断。这样做的好处是，通信波动不会直接卡死界面，业务逻辑修改也碰不到通信代码。

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 0x0301，S7-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 Action<bool> 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 OperateResult<byte[]> ReadBytes(string address, ushort length) { // 内部加入连接状态判断和断线重连 if (!_plc.ConnectServer().IsSuccess) { ConnectionStatusChanged?.Invoke(false); return new OperateResult<byte[]>("连接已断开"); } 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通信跑通，把数据打通，再从最简单的单一工位做追溯验证，一步步扩展。工业现场最稀缺的不是技术新奇，是稳和可靠。一套能让产线工人愿意用、放心用的软件，比任何花哨的功能都重要。