基于C#的PLC工位级追溯与报警系统设计与实现

PLC工位间追溯与报警提示这类需求在国内制造业工厂里出现频率非常高。尤其是多工位、流水线式的组装或加工产线一旦出现质量异常最怕的就是查不到批次、定位不了工位、找不到责任人。我这次做的这套基于C#的上位机软件核心就是解决两个问题一是让每个工位的生产数据能串成一条完整的追溯链二是在关键质量节点出现异常时能够现场报警并留存记录。整个项目从需求梳理到落地部署大概花了三周时间前前后后也踩了不少坑这里把完整的设计思路、实现方式和排障经验整理出来给准备做类似项目的朋友一个参考。1. 项目全貌与核心需求拆解1.1 为什么需要工位级追溯先说个场景。一条组装线有八个工位分别是上料、点胶、压装、焊接、检测、打标、包装、码垛。每台产品依次流过这些工位任何一个环节出了问题如果只是靠纸质流转卡或者操作工的记忆排查起来非常痛苦。今天客户投诉某个批次的产品装配不良你得知道是哪个工位、哪台设备、哪个操作时段、哪一批物料做的甚至要知道当时设备的关键参数比如压装压力、焊接温度是多少。没有系统化的追溯这些信息要么根本找不到要么查起来耗时几天。所以说工位级追溯的核心价值在于质量问题的快速定位和反向追溯。它不只是记录一个产品序列号而是把“产品工位设备参数物料批次操作时间操作人员”这六类信息绑定在一条链路里。有了这条链路正查从物料追到成品和反查从成品追到物料都能在几秒钟内完成。再往深一层讲追溯做得好不好直接影响工厂能不能通过一些体系审核。很多客户验厂的时候对追溯链的完整性是有硬性要求的。哪怕内部管理没那么严格一旦出了客诉追溯数据就是你跟客户沟通的底牌。1.2 为什么选C#配PLC这套组合市面上做追溯系统的方案其实不少有直接用MES的有用组态软件二次开发的也有纯粹手工Excel记录的。但针对中小型产线、设备已经用PLC控制、预算有限、需求又比较个性化的场景我个人觉得C#上位机是最顺手的选择。组态软件比如组态王、力控、WinCC这类做画面和基本报警确实快但追溯逻辑一旦复杂起来脚本写起来非常别扭数据库操作也受限而且授权费用不低。MES系统功能齐全但对一条只有八个工位的产线来说部署成本偏重灵活度也不够。相比之下C#写上位机有几个实打实的优势与PLC通讯的生态非常成熟无论是西门子、三菱、欧姆龙还是Modbus协议都能找到成熟的通讯库走TCP/IP或串口都行操作SQL Server或SQLite非常顺手LinQ、EF框架都能用复杂的追溯查询也就是几条语句的事界面开发效率高WinForm或WPF都能快速做出接地气的操作界面工人培训成本低部署简单一台工控机装好.NET环境就能跑不需要额外装一堆运行时组件。这套组合的本质是PLC负责设备控制和信号采集C#上位机负责数据记录、逻辑判断和人机交互。两者各司其职分工非常清晰。1.3 需求范围这是我交付的功能清单开始写代码之前我跟产线负责人反复对了需求最终确认的交付范围是多工位数据采集每个工位通过PLC上报产品序列号、工位状态、关键工艺参数压力、温度、扭矩等、判定结果OK/NG追溯记录存储所有数据按产品序列号组织形成完整的生产档案支持按序列号、时间范围、工位编号、判定结果等多条件查询异常报警提示当某工位连续出现多个NG、关键参数超差、或者设备通信中断时软件界面弹窗报警同时驱动声光报警器并在数据库写入报警记录数据导出支持将查询结果导出成Excel报表方便质量部门做分析用户权限操作工、班组长、管理员三个角色对应不同的操作权限。这个需求范围不算大但“麻雀虽小五脏俱全”从数据采集、业务逻辑到界面交互、报表导出都有涉及。对我来说它是验证整套技术栈的好项目对工厂来说它是实实在在能用的工具。2. 系统架构与关键技术选型2.1 整体架构上位机、PLC、数据库组成的三角结构整个系统的物理架构很清晰三层结构底层是若干台PLC分布在各个工位负责采集传感器数据、执行控制逻辑、与上位机通讯中间层是上位机软件跑在工控机上通过以太网或串口与所有PLC连接轮询读取数据、写入指令、显示界面、触发报警顶层是数据库上位机把采集到的数据持久化存储后期通过查询界面检索。有人可能会问为什么不把数据采集逻辑放到独立的后台服务里界面单独做这样架构更“正规”。但考虑到现场的实际情况项目周期短、数据量不大、使用人数就几个单机版上位机直接集成采集和展示完全够用。如果以后要接MES或者多台工控机并发访问数据库再来拆分服务也不迟。数据库我选的是SQL Server Express。其实SQLite更轻量但这套系统后续可能要跟前端的看板系统对接SQL Server在语法兼容性和并发处理上更有优势而且Express版本免费对小项目足够友好。2.2 方案对比为什么不用组态软件和MES这里多聊一句方案选型。很多朋友纠结于用什么工具我觉得核心要看三点数据复杂度、项目预算、实施周期。如果只是简单的设备监控、几个报警灯、几块仪表盘组态软件确实最省事拖拽几下就能跑。但一旦涉及多工位间数据联动、复杂追溯查询、跟第三方系统对接组态软件就力不从心了你会发现自己一直在跟它的脚本引擎较劲而不是在解决业务问题。MES则属于另一个量级。它自带排产、质量管理、设备管理一大堆模块在大型工厂是刚需。但对于一条产线的追溯需求来说MES的实施周期通常按季度算成本按几十万算如果不是集团层面要统一上系统为了一个追溯功能去上MES是不划算的。C#在这两者中间提供了一个很好的“中间路线”开发周期短我这个项目从零到上线大概两周多、成本低没有授权费、灵活度高想加什么功能直接写。当然前提是你得愿意自己维护代码。2.3 PLC通讯协议选型走TCP/IP还是串口这是整个项目里最开始就要拍板的事。通讯协议取决于现场PLC的型号和网络条件。这次项目现场用的是西门子支持Profinet以太网通讯。我用的是S7协议基于TCP/IP通过以太网交换机把各工位PLC和上位机组成一个局域网。S7协议的好处是稳定、抗干扰能力强而且不需要在PLC侧做额外配置只要给PLC设置好IP地址和机架号就行。如果现场用的是三菱常见就是走MC协议也是基于TCP/IP通讯格式略有不同如果用的是一些国产PLC或者老设备可能就要走Modbus TCP甚至Modbus RTU串口。这里有个关键建议通讯协议的选型一定要在项目实施前跟电气工程师确认清楚最好把PLC型号、固件版本、IP地址规划表都要到手。我见过太多项目因为协议选错或者IP地址冲突导致通讯调试阶段反复返工。对于老设备只有串口的情况也不是不能做用RS485总线把所有设备挂一条线路上上位机通过串口服务器转成TCP/IP或者直接用USB转串口联机管理。但串口通讯的弊端是速率低、轮询周期长如果工位数多实时性会打折扣。能用以太网的尽量用以太网。3. 追溯逻辑的设计与实现3.1 数据结构用两张表搞定核心追溯链追溯系统的核心是数据模型。我最终设计了多张表其中最关键的是产品记录表ProductRecord和工位记录表StationRecord。产品记录表以“产品序列号SerialNumber”为主键记录产品从上线到成品的关键信息产品型号、当前工位、当前状态在制/完成/报废、创建时间、完成时间。这张表相当于产品的“身份证”。工位记录表更细每条记录对应一个产品在一个工位上的一次加工主键ID、产品序列号、工位编号、操作工账号、设备参数压装压力、焊接温度、扭矩值、判定结果、加工时间。一张表就能完整记录产品流经每个工位的状态变化。查询逻辑很简单输入一个总装好的成品的序列号先到ProductRecord找到这个产品然后根据序列号去StationRecord把所有工位记录全部捞出来就能还原出整个生产过程反过来如果想查某批物料用到了哪些产品上就得再建一张物料批次绑定表记录上料工位扫描的物料批次号和产品序列号之间的绑定关系。这个模型能不能支撑更复杂的场景比如工艺参数有几十个、需要拍照留档、需要关联设备维修记录其实都能扩展加字段、加表就行。核心思想就是以产品序列号为主线索把一切跟这个产品有关的信息都关联起来。3.2 序列号规则追溯链的主线不能乱追溯系统最怕的就是序列号重复或断号。我这次用的规则是“年月日流水号”的组合比如240512001代表24年5月12日第1台产品。这个规则基本能保证唯一性而且从序列号本身就能看出生产日期方便日常沟通。但这里有个细节序列号通常是PLC扫码枪读到的或者人工用扫码枪录入再传给上位机。如果产品本身没有一物一码的条件就得在生产开始时由上位机生成序列号并下发给PLC。这个流程在项目里属于“首次上料登记”是整个追溯链路的第一环。序列号规则建议在项目初期就定死一旦产品下线序列号一般不允许更改。中途如果发现序列号打错应该是“作废旧序列号创建新档案”而不是直接改原记录。3.3 多工位数据流转从单点采集到全链路关联单工位数据采集是最简单的读PLC数据块、解析、存储。真正的复杂度在于多工位之间的数据协同。比如产品在1号工位上料生成序列号A流到2号工位时PLC先读取产品本身携带的序列号通常由RFID或条码识别上位机判断这个序列号在数据库里是否存在、当前状态是否为“允许进入本工位”校验通过后才记录2号工位的加工数据。这本质上是一个状态机。产品在每个工位都有相应的前置状态和置后状态状态不对就不能往下走。状态机如果设计得好能避免大量脏数据重复过站同一个序列号在同工位记录两次可以拦截跳站跨过某个工位直接进入后面工位可以告警反流产品倒退到前面工位可以被识别。我实现的时候在每个工位的记录写入前都会查一次该产品在ProductRecord里的当前工位编码跟本工位的编码对比不匹配就直接拒绝写入并报警。3.4 报警机制用双通道确保异常不被忽略报警是这个项目里很受重视的功能。现场环境嘈杂操作工不一定时刻盯着屏幕所以单纯界面弹窗远远不够。我做的报警分成了三个层级界面告警在主界面顶部弹出一条红色醒目提示同时工位状态图标变成红色闪烁声音报警通过上位机声卡播放报警音同时通过PLC的一路DO点驱动现场的声光报警器记录留痕报警信息写入报警记录表包括报警工位、报警类型、产品序列号、报警时间、确认人、确认时间。这里最关键的体会是报警必须可确认、可追溯。如果只响不停工位停线了也没人知道是谁处理的责任无法闭环。所以我在报警弹窗上做了“确认”按钮操作工必须点击确认并输入工号这条报警才算关闭。如果超过设定时间没人确认软件会把报警级别升级通过短信或企业微信接口通知班组长。报警规则我做了三类配置一是连续NG数量阈值比如某工位连续3台NG就报警停线二是参数超差比如压装压力超过设定上下限三是通讯中断上位机连续几次读不到某台PLC的数据。4. 界面设计与数据可视化呈现4.1 主界面布局让车间工人一看就懂界面设计方面我遵循一个原则面向车间操作工的界面降低理解成本远比追求美观重要。整个主界面分四个区域顶部是产线总览条八个工位从左到右排列每个工位用小方块表示状态用颜色区分绿色表示运行正常、黄色表示待机、红色表示报警、灰色表示离线中间是当前产品信息区实时显示当前正在生产的产品的序列号、当前工位、关键参数和判定结果下方是报警信息栏列出当前未确认的报警记录右侧是操作按钮区包含查询、报表导出、系统设置等入口。每个工位方块点击进去能看到该工位的详细参数趋势图比如近两个小时的压装压力曲线。这对于设备工程师快速判断压力是否有漂移趋势非常有用。4.2 追溯查询界面支持按多条件组合检索查询界面做成了类Excel风格支持按序列号、时间范围、工位编号、判定结果等条件组合筛选。搜索结果以表格形式展示点击某一行可以展开该产品在所有工位的详细信息。这个界面的受众是质量工程师所以他们更关注的是能不能快速筛选、快速导出。我把查询结果默认按时间倒序排列同时提供聚合统计功能比如选中一批记录自动统计各工位的NG率、各操作工的报工数量。这样质量部门做周报的时候不需要再用原始Excel手动拉数据。4.3 报表导出一键生成日报与追溯报告导出功能看似简单其实也值得说。我直接调用第三方库把DataTable导出为Excel文件导出内容区分两种类型追溯报告某产品全工位详细信息用于客诉分析或质量追溯生产日报某时间段内所有工位的产量、良率、NG明细、报警汇总用于班组长日报。日报里还包含图表生成接口可以把良率趋势可视化。我发现实际使用中导出Excel比在线看数据更刚需因为工厂领导层的汇报习惯还是以文档为主这个功能必须做得稳。后期如果要对接还可以扩展成自动定时发送邮箱。5. 我踩过的坑通讯、并发与数据一致性5.1 PLC通讯偶尔断线加了心跳重连机制项目第一次联调时通讯还算顺利但运行半天后偶发一次“上位机读不到PLC数据”的情况界面显示离线等一会儿又自己恢复了。排查下来发现是PLC在长时间无通讯请求时会自动断开连接上位机没有感知到就一直卡在阻塞状态。解决方式是两层一是开辟独立通讯线程不对是设定通讯超时时间任何一次读写请求超过500毫秒未返回立即断开当前连接并重连二是做心跳检测即使没有业务数据请求每隔2秒主动发一次读请求确认连接是否存活如果连续3次失败则判定离线并报警。这个机制加上后后续运行一直很稳定。这里提醒一下重连时PLC需要短暂的重新握手时间不要频繁重连建议失败后等待1秒再重试避免影响设备正常通讯。5.2 多线程写库导致SQLite死锁队列化写操作第一版程序我在每个工位的数据接收事件里直接开线程写数据库结果跑了一个多小时就出现了“database is locked”的异常。原因非常典型SQLite在并发写入场景下会锁库多个线程同时写必然冲突。解决思路也不复杂引入一个写入队列所有数据先Post到队列里由一个专门的写库线程串行处理。虽然牺牲了一点实时性但换来了绝对的稳定。对于追溯系统这种场景数据实时性要求没那么高只要在几秒内落库就能接受。后来我把这个设计延续到了所有数据写入中比如报警记录、操作日志全部走队列。这个改动对系统的长期稳定运行非常关键。5.3 追溯时数据对不上先查工位时钟同步联调过程中出现过一次诡异问题某台产品在2号工位的记录时间比在1号工位还早。排查了一圈发现是工控机和PLC的系统时间没有同步PLC记录的时间戳比工控机慢了十几分钟。从那以后我在系统启动时会把工控机的时间同步给所有PLC并且在每条记录落库时统一使用上位机接收时刻而不是PLC返回的本地时刻。数据发生的时间以数据库时间戳为准PLC时间只作为辅助参考。这样时间线永远是准确的。5.4 UI卡顿假死采样数据量超预期追溯数据如果每500毫秒刷新一次数据量增长很快而且界面渲染会拖慢整个应用。第一版UI直接绑定数据源实时刷新结果发现操作卡顿明显。优化方案是界面定时器改为每2秒刷新一次而且只增量加载变化的数据同时把历史数据显示区域做成分页加载默认只显示最新200条。必要时点击加载更多。经过这番优化界面流畅度有了很大提升CPU占用也正常了。6. 现场部署与后期优化建议6.1 部署注意点工控机配置、网络规划与数据备份现场部署有几个容易被忽略的要点。首先是工控机的配置最低要求是双网卡一路接PLC局域网一路接办公网两个网络物理隔离避免PLC网络受广播风暴影响。如果条件不允许至少要在防火墙上做端口限制。其次是UPS电源。上位机如果突然断电数据库极容易损坏至少配一台在线式UPS。我这次就遇到过现场断电导致SQL Server数据库文件损坏的尴尬情况恢复花了不少时间。数据备份计划也需要提前规划。SQL Server Agent可以设置每日凌晨自动备份保留最近30天。备份文件建议通过网络自动拷贝到办公网的共享文件夹这样即使工控机硬盘损坏数据也不会丢。这套习惯建议所有做上位机项目的朋友养成。6.2 扩展方向对接MES、移动端看板和智能分析这个项目上线运行稳定后后续的扩展空间还很大。我简单列几个方向对接MES当前系统是独立运行的如果工厂后续上MES可以通过Web API把追溯数据推送上去统一管理移动端看板现场管理者希望能用手机随时看产量和异常可以开发一个简单的移动网页从数据库只读数据实现轻量看板智能分析结合历史追溯数据做参数趋势分析、工艺参数推荐、故障预测从“事后追溯”向“事前预警”转变这是最值得投入的方向。以我个人的经验来说这种规模的追溯项目最关键的是前期把数据模型和通讯方案定好这两件事做扎实了后面的开发自然就顺了。中间踩过的通讯断线、并发写库、时间同步这些坑其实都是这个领域里的“必修课”写出来供大家参考希望后来者能少走点弯路。