简介这是一套 C# 编写的 MES制造执行系统完整源代码项目按 Mes.Client 与 Mes.Server 两大部分组织供制造企业信息化开发人员、系统集成工程师及相关专业学生参考或二次开发该版本为 MES2.0 改版重点针对界面 UI、源码整理与功能做了升级。压缩包共 2000 个文件包含 520 个 C# 源码文件、1025 个 CSS 样式文件、415 个 JavaScript 脚本文件以及少量 DLL、配置文件、说明文档与项目文档整体大小约 35.87MB。内部结构采用分层模块化设计客户端分为模型层、服务引用、通用工具、界面层与单元测试可以分离业务逻辑与展示服务端提供服务宿主、数据操作对象与对外接口便于独立部署和维护。从预览中可看到订单、产品、工序调度、用户、合作伙伴、房间设计等业务数据操作类覆盖典型 MES 业务流程有助于理解数据流与业务逻辑当前已有 1552 人学习或下载适合需要完整项目源码参考的中高级 .NET 开发人员。 做车间MES这块也有几年了从最早的WinForm小工具一路做到现在的成套系统中间踩过的坑比踩过的产线地面还多。今天借这个项目跟大伙儿聊聊——一个用C#写的、典型C/S架构的MES系统代码分成Mes.Client和Mes.Server两大块。如果你正准备入职做MES、或者厂里要自研一套轻量级制造执行系统这篇东西应该能帮你少走不少弯路。先把这个系统的定位说清楚。MES制造执行系统干的事情就是接住ERP下发的生产计划再把计划拆成一张张工单派到产线然后盯着每一个工位、每一道工序、每一台设备把“实际干了什么、干得怎么样、用了多少料、花了多少时间”全部记录在案。这个标题里的Mes.Client就是工位上操作员每天面对的客户端程序Mes.Server则是部署在机房、处理所有业务逻辑和数据持久化的服务端。这套系统说白了要解决的就是车间里“计划归计划、干归干、账归账”互相脱节的经典老毛病。刚接触MES的人容易有个错觉觉得这玩意儿跟进销存差不多其实差别大了去了。MES一头要跟PLC、扫码枪、电子秤、甚至视觉检测设备打交道另一头要随时响应产线上的高频操作实时性、稳定性、易用性的要求比普通管理系统高出一个量级。下面我从架构选型到核心代码再到现场踩坑实录一层层拆开来讲。1. MES为什么首选C/S架构而不是B/S很多没下过车间的人会问都什么年代了怎么不做成网页版浏览器打开就能用不是更方便吗我直接说结论B/S在MES里有天生的短板不是技术上不能做而是车间现场这个场景不适合。1.1 车间现场对“实时交互”和“硬件对接”的硬性要求MES的客户端用法跟普通办公软件完全不一样。操作员不是坐在电脑前慢慢点鼠标而是站在产线边上一只手拿扫码枪另一只手可能还戴着手套。界面弹个窗、光标跳错位置、数据延迟半秒都会直接拖慢产线节拍。C/S架构下客户端和服务端之间是长连接数据交互走Socket或TCP毫秒级响应是标配。而且扫码枪、电子秤、打印机这些外设C#配合WinForm或WPF做本地驱动对接比网页版通过ActiveX或WebSocket中转靠谱太多。另外还有一条关键因素车间网络环境没那么理想交换机老旧、网线接触不良、偶尔断个几秒钟都是常态。B/S架构一断网页面直接白屏C/S客户端可以做本地缓存和断点续传网络恢复后自动补传数据。光这一条在真正的生产环境里就能救命。1.2 Mes.Client和Mes.Server的分工逻辑这项目的两个核心工程分工非常清晰。Mes.Client部署在产线工位电脑上负责三件事第一呈现工单信息、作业指导书、质检要求给操作员看第二采集操作员的报工数据、扫码数据、不合格品数据第三指挥本地硬件比如触发扫码枪、打印标签、控制信号灯。Mes.Server则部署在服务器上负责所有共享资源的统一管理工单调度与下发、工艺参数维护、人员权限认证、数据库读写、报表计算。客户端不直接碰数据库所有数据请求都先发给Server由Server校验后再落库。这样设计的好处是数据库连接数不会因为客户端增多而爆炸业务规则改动也只需更新服务端客户端分发的压力小很多。CLR层面的代码结构上一般还会把公共的实体类、消息协议、数据库访问基类抽成一个公共类库两个工程共同引用避免重复代码。做多了你会发现这个分层设计本质上是在参考传统三层架构只不过把“表现层”和“业务层”用两个独立进程拆开了。2. Mes.Client客户端产线上每天被“蹂躏”的界面客户端是整个系统里被吐槽最多的部分也是最能体现MES开发功力的地方。写办公软件的思路放到MES上做出来的东西操作员根本不愿意用。2.1 界面设计的核心不是美观是“防呆”车间里的操作员文化水平参差不齐有老师傅也有新员工而且大家普遍没耐心看说明书。MES界面设计的核心原则就俩字防呆。操作按钮必须大字号必须大重要信息用颜色区分——比如绿色代表正常红色代表异常黄色代表待处理。界面上能用一个按钮完成的操作绝不用两个。我见过一个做得非常到位的报工界面整个屏幕只有一个文本框、一个大按钮、一条产量进度条。操作员扫一下工单条码系统自动带出产品型号和工序再扫一下员工牌系统记录操作人每加工完一件扫一下流转卡产量进度条就跳一格。全程只需要扫三次码点零次鼠标。这种设计才是MES客户端该有的样子。2.2 扫码枪触发事件MES里最容易被写烂的环节扫码枪在MES里的地位相当于键盘鼠标在办公软件里的地位但很多人没意识到扫码枪的接入方式分两种处理逻辑完全不同。一种是键盘模拟模式HID模式扫码枪把条码内容像键盘打字一样“敲”进当前聚焦的输入框最后再自动敲一个回车。另一种是串口模式扫码枪通过COM口传输数据程序需要用SerialPort控件主动去读。多数便宜好用的扫码枪走的是第一种模式也正是这种模式最容易出问题——焦点不在输入框上时条码内容会“敲”到不知道哪里去。处理HID模式扫码枪的标准做法是在窗口上放一个专用的条码输入框让它始终保持聚焦。TextChanged事件里判断是否扫完了或者KeyDown事件里判断结尾的回车符。我习惯用回车符判定因为条码长度不固定靠长度判断容易出错private void txtBarcode_KeyDown(object sender, KeyEventArgs e) { if (e.KeyCode Keys.Enter) { string barcode txtBarcode.Text.Trim(); if (string.IsNullOrEmpty(barcode)) return; // 解析条码匹配工单号或序列号 ProcessBarcode(barcode); // 清空输入框准备下一次扫描 txtBarcode.Clear(); txtBarcode.Focus(); e.SuppressKeyPress true; } }这里有个细节很多人不知道如果输入法停在中文状态扫码扫进来的字母会被输入法截胡变成拼音或汉字条码自然就解析失败了。我踩过这个坑之后在客户端窗体激活事件里强制把输入法切到英文模式private void Form_Activated(object sender, EventArgs e) { InputLanguage.CurrentInputLanguage InputLanguage.FromCulture(new CultureInfo(en-US)); }这一行代码能省掉现场一半的“扫码扫不上”报障。2.3 客户端与服务端的通信协议设计Mes.Client和Mes.Server之间的通信是这个系统的命脉。项目里最常用的方案是Socket长连接自定义消息协议。消息格式我推荐这么设计消息头固定几个字节存命令字和长度消息体用JSON序列化。// 客户端发送报工请求 var message new { command WorkReport, data new { workOrder WO202406001, process OP20, operator 张三, quantity 1, result OK } }; string json JsonConvert.SerializeObject(message); byte[] body Encoding.UTF8.GetBytes(json); byte[] header new byte[8]; // 前4字节存命令字后4字节存包体长度大端序 // ...发送逻辑为什么用短连接轮询不行因为报工操作是高频的一条产线一天几千次报工如果用HTTP短连接轮询服务端要频繁建立和销毁连接数据库连接也跟着频繁开关性能损耗巨大。长连接维持在线一发一收还能顺便实现服务端向客户端主动推送消息——比如管理员在办公室改了一道工序客户端立刻弹提示不用等操作员刷新。3. Mes.Server服务端整个系统的大脑和数据中枢如果说客户端是手和脚Service端就是大脑。所有业务规则、数据校验、权限控制都在这一层完成。这一层设计得好不好直接决定了系统能支撑多少人同时在线、数据准不准、报表跑得快不快。3.1 服务端框架搭建与通信机制服务端的核心是一个Socket监听服务。启动时监听一个固定端口收到客户端连接请求后分配独立的会话线程做消息接收和响应。这里要特别提醒别用“一个连接一个线程”的土办法硬扛。连接少的时候没事产线规模一大几百个工位同时在线几百个线程来回切换CPU光花在线程调度上了。建议用异步Socket 线程池模型或者直接上TcpListener配合async/await模式代码写起来干净性能也好public async Task StartListeningAsync(int port) { _listener new TcpListener(IPAddress.Any, port); _listener.Start(); while (true) { TcpClient client await _listener.AcceptTcpClientAsync(); _ Task.Run(() HandleClientAsync(client)); } }接收消息后服务端先做身份校验再按命令字分发到不同的处理模块——工单模块、报工模块、质检模块、追溯模块。每个模块内部再调用业务逻辑层和数据访问层。为了后期维护方便命令分发用字典映射比用一堆switch-case优雅得多。3.2 核心业务模块拆解一个能真正跑起来的MES下面这几个模块缺一不可。工单管理是所有业务的源头。服务端从ERP或手工录入的方式接收生产计划拆分成工单每个工单包含产品编码、数量、交期、工艺路线。工艺路线是关键它决定了这个产品要经过哪几道工序每道工序对应的报工界面、质检方案、需要采集的参数都不一样。报工采集是最频繁的操作。操作员扫一次流转卡客户端发来报工请求服务端要校验当前工序是否匹配、数量是否合理、人员是否有权限校验通过写入生产记录表同时更新工单完工数量。这一块的数据表设计尤其重要建议至少拆成三张表报工主表、报工明细表、报工参数表。主表记录“谁在什么时候报了哪个工单的哪道工序”明细表记录“加工了什么产品、数量多少”参数表记录“当时的温度、压力、转速等工艺参数”。这样拆的好处是后续做质量追溯时能精确到某一批次产品在某个时间点的具体工艺参数。质量管理模块一般做成独立的质检流程。最常见的做法是首检、巡检、完工检三检制。首件加工完成后操作员通知质检员到现场检验合格后才能批量生产巡检是每隔固定时间抽检完工检是整批加工完后的最终判定。质检结果回写工单状态不合格的触发不合格品处理流程——返工、报废或者让步接收每一步都要留记录。3.3 数据库设计的几个关键点MES的数据量增长非常快。一条中型产线一天产生的报工记录、参数记录、操作日志轻松超过十万条。数据库设计的良心决定了三年后这个系统是继续流畅跑还是卡成PPT。主表设计上我建议所有业务表都带这几个字段工单号、工序号、操作员ID、设备编码、时间戳。这几个字段组合起来就是一条完整的生产履历。查询时按工单号和时间段建复合索引绩效统计和产能分析报表基本都能秒开。服务端还应该做一个操作日志表记录所有客户端的登录、登出、关键操作的完整履历。车间里出了质量事故要追责时日志表就是唯一的裁判能明确还原“谁在什么时间干了什么”。4. 从工单下达到质量追溯一整套完整的数据流讲完模块咱们把整套系统的数据流转从头到尾走一遍。理解了这个数据流你就理解了MES系统的全部核心。4.1 一场典型的产线作业流程计划员在服务端导入生产计划系统自动拆分成工单。工单下发到指定产线操作员打开Mes.Client扫一下工单条码客户端显示这个工单的全部信息——产品型号、计划数量、已完工数量、当前工序、工艺要求。操作员按下“开始生产”按钮客户端向服务端发送一个开工请求服务端把工单状态从“已下发”改为“生产中”同时记录开工时间。然后操作员开始逐件加工每完成一件扫流转卡报工一次。服务端收到报工消息校验通过后写入生产记录表更新工单完工数量并计算完成率——这些实时数据会被看板程序以图表形式投到车间的大屏幕上。一批活干完了操作员点击“报完工”服务端校验完工数量与计划数量是否一致如果合格率达标工单状态改为“已完成”信息回传到ERP系统。整个“计划→执行→反馈”闭环就完成了。4.2 质量数据怎么驱动不良品处理和工艺改善质检员在Mes.Client上打开质检界面扫描待检批次的条码系统显示该批次的生产履历——谁加工的、哪台设备、用的哪批原材料、当时的工艺参数。质检员录入抽检数据系统自动按判定规则出结论比如抽检5件、允许1件不合格这种AQL方案。判定为不合格批次的系统自动锁定该批次剩余库存防止流入下道工序。然后生成不合格品处理单指定处理方式。返工后要重新走质检流程报废的要从库存中扣除并记录损耗原因。这些数据攒起来以后就是工艺改善的金矿。比如某个工位的报工参数里温度偏高对应批次的合格率明显下降工艺工程师就能据此调整参数。4.3 看板数据实时展示的实现思路车间大屏上的生产看板本质上就是对服务端数据的实时汇总。客户端Socket长连接的好处在这里体现得最明显——服务端可以主动把汇总数据推送给看板程序WebSocket或者轮询做起来都更别扭。产量数据用原有的报工表做聚合按产线、按小时、按班组三个维度实时计算。设备状态这一块如果MES对接了设备数据比如PLC上报的开机、待机、故障状态看板上还能多一个OEE综合效率的展示。这块如果暂时没接设备也可以用人工报工的模式实现设备状态上报。5. 常见问题与排查技巧实录每个MES项目上线初期都会遇到一批共性问题的轮回。在这里把我遇到过的、以及身边同事遇到过的高频问题整理成速查表方便大家直接对号入座。问题现象可能原因排查思路与解决方法客户端提示“无法连接服务器”服务端没有启动、防火墙拦截、网络不通先ping服务器IP再telnet测试端口通不通检查服务端程序的监听端口是否被占用扫码枪偶尔扫不出来输入法停留在中文状态、焦点丢失窗体激活事件强制切英文输入法条码框始终保持Focus用KeyDown的回车符判断代替TextChanged高并发时报工消息积压服务端同步阻塞处理、线程池太小改为异步处理请求业务逻辑里避免同步I/O操作数据库连接用连接池建索引优化慢查询断网恢复后数据对不上客户端没有做本地缓存客户端增加本地SQLite或简单文件缓存断网时写入本地网络恢复后按时间戳补传看板数据延迟很大看板程序每次都查数据库看板改用服务端推送或者本地缓存聚合结果数据变更时增量更新不用每次都全量查询追溯某批次产品时查不到参数报工参数表没有写入记录检查客户端报工流程是否采集了参数数据服务端日志看报工请求是否被拒除了表里这些硬问题再分享一个蛮隐蔽的坑标签打印。MES里的流转卡、序列号标签、条码标签看着不起眼实际上最容易出乱子。标签格式需要跟车间现有的流程卡保持一致标签打印机驱动必须提前测试尤其是条码密度、纸张大小、打印浓度这些参数稍微不对扫码枪就认不出来。我见过好几个项目系统业务逻辑都跑通了硬是在打印标签的环节卡了一个礼拜。所以做MES别瞧不起打印这个“小事”提前试好绝对不亏。另外还有一点经验之谈MES最难的从来不是技术是业务梳理。技术上的Socket、数据库、WinForm都是成熟的套路真正费心的是跟车间主任、工艺工程师、操作班长反复确认每个流程节点的真实做法——很多流程在制度文件里和实际操作中根本是两回事。系统做出来要符合实际操作而不是符合制度文件这是MES能否落地的分水岭。如果你正准备自己动手写一套我的建议是不要一开始就求大求全从一条产线的报工和追溯需求做起跑通了再加质量管理、设备集成、看板展示。等客户端和服务端这套骨架立住了后续加功能也就是往框架里填肉的事。本文还有配套的精品资源点击获取 C#开发MES系统：C/S架构与车间信息化实战解析
简介这是一套 C# 编写的 MES制造执行系统完整源代码项目按 Mes.Client 与 Mes.Server 两大部分组织供制造企业信息化开发人员、系统集成工程师及相关专业学生参考或二次开发该版本为 MES2.0 改版重点针对界面 UI、源码整理与功能做了升级。压缩包共 2000 个文件包含 520 个 C# 源码文件、1025 个 CSS 样式文件、415 个 JavaScript 脚本文件以及少量 DLL、配置文件、说明文档与项目文档整体大小约 35.87MB。内部结构采用分层模块化设计客户端分为模型层、服务引用、通用工具、界面层与单元测试可以分离业务逻辑与展示服务端提供服务宿主、数据操作对象与对外接口便于独立部署和维护。从预览中可看到订单、产品、工序调度、用户、合作伙伴、房间设计等业务数据操作类覆盖典型 MES 业务流程有助于理解数据流与业务逻辑当前已有 1552 人学习或下载适合需要完整项目源码参考的中高级 .NET 开发人员。 做车间MES这块也有几年了从最早的WinForm小工具一路做到现在的成套系统中间踩过的坑比踩过的产线地面还多。今天借这个项目跟大伙儿聊聊——一个用C#写的、典型C/S架构的MES系统代码分成Mes.Client和Mes.Server两大块。如果你正准备入职做MES、或者厂里要自研一套轻量级制造执行系统这篇东西应该能帮你少走不少弯路。先把这个系统的定位说清楚。MES制造执行系统干的事情就是接住ERP下发的生产计划再把计划拆成一张张工单派到产线然后盯着每一个工位、每一道工序、每一台设备把“实际干了什么、干得怎么样、用了多少料、花了多少时间”全部记录在案。这个标题里的Mes.Client就是工位上操作员每天面对的客户端程序Mes.Server则是部署在机房、处理所有业务逻辑和数据持久化的服务端。这套系统说白了要解决的就是车间里“计划归计划、干归干、账归账”互相脱节的经典老毛病。刚接触MES的人容易有个错觉觉得这玩意儿跟进销存差不多其实差别大了去了。MES一头要跟PLC、扫码枪、电子秤、甚至视觉检测设备打交道另一头要随时响应产线上的高频操作实时性、稳定性、易用性的要求比普通管理系统高出一个量级。下面我从架构选型到核心代码再到现场踩坑实录一层层拆开来讲。1. MES为什么首选C/S架构而不是B/S很多没下过车间的人会问都什么年代了怎么不做成网页版浏览器打开就能用不是更方便吗我直接说结论B/S在MES里有天生的短板不是技术上不能做而是车间现场这个场景不适合。1.1 车间现场对“实时交互”和“硬件对接”的硬性要求MES的客户端用法跟普通办公软件完全不一样。操作员不是坐在电脑前慢慢点鼠标而是站在产线边上一只手拿扫码枪另一只手可能还戴着手套。界面弹个窗、光标跳错位置、数据延迟半秒都会直接拖慢产线节拍。C/S架构下客户端和服务端之间是长连接数据交互走Socket或TCP毫秒级响应是标配。而且扫码枪、电子秤、打印机这些外设C#配合WinForm或WPF做本地驱动对接比网页版通过ActiveX或WebSocket中转靠谱太多。另外还有一条关键因素车间网络环境没那么理想交换机老旧、网线接触不良、偶尔断个几秒钟都是常态。B/S架构一断网页面直接白屏C/S客户端可以做本地缓存和断点续传网络恢复后自动补传数据。光这一条在真正的生产环境里就能救命。1.2 Mes.Client和Mes.Server的分工逻辑这项目的两个核心工程分工非常清晰。Mes.Client部署在产线工位电脑上负责三件事第一呈现工单信息、作业指导书、质检要求给操作员看第二采集操作员的报工数据、扫码数据、不合格品数据第三指挥本地硬件比如触发扫码枪、打印标签、控制信号灯。Mes.Server则部署在服务器上负责所有共享资源的统一管理工单调度与下发、工艺参数维护、人员权限认证、数据库读写、报表计算。客户端不直接碰数据库所有数据请求都先发给Server由Server校验后再落库。这样设计的好处是数据库连接数不会因为客户端增多而爆炸业务规则改动也只需更新服务端客户端分发的压力小很多。CLR层面的代码结构上一般还会把公共的实体类、消息协议、数据库访问基类抽成一个公共类库两个工程共同引用避免重复代码。做多了你会发现这个分层设计本质上是在参考传统三层架构只不过把“表现层”和“业务层”用两个独立进程拆开了。2. Mes.Client客户端产线上每天被“蹂躏”的界面客户端是整个系统里被吐槽最多的部分也是最能体现MES开发功力的地方。写办公软件的思路放到MES上做出来的东西操作员根本不愿意用。2.1 界面设计的核心不是美观是“防呆”车间里的操作员文化水平参差不齐有老师傅也有新员工而且大家普遍没耐心看说明书。MES界面设计的核心原则就俩字防呆。操作按钮必须大字号必须大重要信息用颜色区分——比如绿色代表正常红色代表异常黄色代表待处理。界面上能用一个按钮完成的操作绝不用两个。我见过一个做得非常到位的报工界面整个屏幕只有一个文本框、一个大按钮、一条产量进度条。操作员扫一下工单条码系统自动带出产品型号和工序再扫一下员工牌系统记录操作人每加工完一件扫一下流转卡产量进度条就跳一格。全程只需要扫三次码点零次鼠标。这种设计才是MES客户端该有的样子。2.2 扫码枪触发事件MES里最容易被写烂的环节扫码枪在MES里的地位相当于键盘鼠标在办公软件里的地位但很多人没意识到扫码枪的接入方式分两种处理逻辑完全不同。一种是键盘模拟模式HID模式扫码枪把条码内容像键盘打字一样“敲”进当前聚焦的输入框最后再自动敲一个回车。另一种是串口模式扫码枪通过COM口传输数据程序需要用SerialPort控件主动去读。多数便宜好用的扫码枪走的是第一种模式也正是这种模式最容易出问题——焦点不在输入框上时条码内容会“敲”到不知道哪里去。处理HID模式扫码枪的标准做法是在窗口上放一个专用的条码输入框让它始终保持聚焦。TextChanged事件里判断是否扫完了或者KeyDown事件里判断结尾的回车符。我习惯用回车符判定因为条码长度不固定靠长度判断容易出错private void txtBarcode_KeyDown(object sender, KeyEventArgs e) { if (e.KeyCode Keys.Enter) { string barcode txtBarcode.Text.Trim(); if (string.IsNullOrEmpty(barcode)) return; // 解析条码匹配工单号或序列号 ProcessBarcode(barcode); // 清空输入框准备下一次扫描 txtBarcode.Clear(); txtBarcode.Focus(); e.SuppressKeyPress true; } }这里有个细节很多人不知道如果输入法停在中文状态扫码扫进来的字母会被输入法截胡变成拼音或汉字条码自然就解析失败了。我踩过这个坑之后在客户端窗体激活事件里强制把输入法切到英文模式private void Form_Activated(object sender, EventArgs e) { InputLanguage.CurrentInputLanguage InputLanguage.FromCulture(new CultureInfo(en-US)); }这一行代码能省掉现场一半的“扫码扫不上”报障。2.3 客户端与服务端的通信协议设计Mes.Client和Mes.Server之间的通信是这个系统的命脉。项目里最常用的方案是Socket长连接自定义消息协议。消息格式我推荐这么设计消息头固定几个字节存命令字和长度消息体用JSON序列化。// 客户端发送报工请求 var message new { command WorkReport, data new { workOrder WO202406001, process OP20, operator 张三, quantity 1, result OK } }; string json JsonConvert.SerializeObject(message); byte[] body Encoding.UTF8.GetBytes(json); byte[] header new byte[8]; // 前4字节存命令字后4字节存包体长度大端序 // ...发送逻辑为什么用短连接轮询不行因为报工操作是高频的一条产线一天几千次报工如果用HTTP短连接轮询服务端要频繁建立和销毁连接数据库连接也跟着频繁开关性能损耗巨大。长连接维持在线一发一收还能顺便实现服务端向客户端主动推送消息——比如管理员在办公室改了一道工序客户端立刻弹提示不用等操作员刷新。3. Mes.Server服务端整个系统的大脑和数据中枢如果说客户端是手和脚Service端就是大脑。所有业务规则、数据校验、权限控制都在这一层完成。这一层设计得好不好直接决定了系统能支撑多少人同时在线、数据准不准、报表跑得快不快。3.1 服务端框架搭建与通信机制服务端的核心是一个Socket监听服务。启动时监听一个固定端口收到客户端连接请求后分配独立的会话线程做消息接收和响应。这里要特别提醒别用“一个连接一个线程”的土办法硬扛。连接少的时候没事产线规模一大几百个工位同时在线几百个线程来回切换CPU光花在线程调度上了。建议用异步Socket 线程池模型或者直接上TcpListener配合async/await模式代码写起来干净性能也好public async Task StartListeningAsync(int port) { _listener new TcpListener(IPAddress.Any, port); _listener.Start(); while (true) { TcpClient client await _listener.AcceptTcpClientAsync(); _ Task.Run(() HandleClientAsync(client)); } }接收消息后服务端先做身份校验再按命令字分发到不同的处理模块——工单模块、报工模块、质检模块、追溯模块。每个模块内部再调用业务逻辑层和数据访问层。为了后期维护方便命令分发用字典映射比用一堆switch-case优雅得多。3.2 核心业务模块拆解一个能真正跑起来的MES下面这几个模块缺一不可。工单管理是所有业务的源头。服务端从ERP或手工录入的方式接收生产计划拆分成工单每个工单包含产品编码、数量、交期、工艺路线。工艺路线是关键它决定了这个产品要经过哪几道工序每道工序对应的报工界面、质检方案、需要采集的参数都不一样。报工采集是最频繁的操作。操作员扫一次流转卡客户端发来报工请求服务端要校验当前工序是否匹配、数量是否合理、人员是否有权限校验通过写入生产记录表同时更新工单完工数量。这一块的数据表设计尤其重要建议至少拆成三张表报工主表、报工明细表、报工参数表。主表记录“谁在什么时候报了哪个工单的哪道工序”明细表记录“加工了什么产品、数量多少”参数表记录“当时的温度、压力、转速等工艺参数”。这样拆的好处是后续做质量追溯时能精确到某一批次产品在某个时间点的具体工艺参数。质量管理模块一般做成独立的质检流程。最常见的做法是首检、巡检、完工检三检制。首件加工完成后操作员通知质检员到现场检验合格后才能批量生产巡检是每隔固定时间抽检完工检是整批加工完后的最终判定。质检结果回写工单状态不合格的触发不合格品处理流程——返工、报废或者让步接收每一步都要留记录。3.3 数据库设计的几个关键点MES的数据量增长非常快。一条中型产线一天产生的报工记录、参数记录、操作日志轻松超过十万条。数据库设计的良心决定了三年后这个系统是继续流畅跑还是卡成PPT。主表设计上我建议所有业务表都带这几个字段工单号、工序号、操作员ID、设备编码、时间戳。这几个字段组合起来就是一条完整的生产履历。查询时按工单号和时间段建复合索引绩效统计和产能分析报表基本都能秒开。服务端还应该做一个操作日志表记录所有客户端的登录、登出、关键操作的完整履历。车间里出了质量事故要追责时日志表就是唯一的裁判能明确还原“谁在什么时间干了什么”。4. 从工单下达到质量追溯一整套完整的数据流讲完模块咱们把整套系统的数据流转从头到尾走一遍。理解了这个数据流你就理解了MES系统的全部核心。4.1 一场典型的产线作业流程计划员在服务端导入生产计划系统自动拆分成工单。工单下发到指定产线操作员打开Mes.Client扫一下工单条码客户端显示这个工单的全部信息——产品型号、计划数量、已完工数量、当前工序、工艺要求。操作员按下“开始生产”按钮客户端向服务端发送一个开工请求服务端把工单状态从“已下发”改为“生产中”同时记录开工时间。然后操作员开始逐件加工每完成一件扫流转卡报工一次。服务端收到报工消息校验通过后写入生产记录表更新工单完工数量并计算完成率——这些实时数据会被看板程序以图表形式投到车间的大屏幕上。一批活干完了操作员点击“报完工”服务端校验完工数量与计划数量是否一致如果合格率达标工单状态改为“已完成”信息回传到ERP系统。整个“计划→执行→反馈”闭环就完成了。4.2 质量数据怎么驱动不良品处理和工艺改善质检员在Mes.Client上打开质检界面扫描待检批次的条码系统显示该批次的生产履历——谁加工的、哪台设备、用的哪批原材料、当时的工艺参数。质检员录入抽检数据系统自动按判定规则出结论比如抽检5件、允许1件不合格这种AQL方案。判定为不合格批次的系统自动锁定该批次剩余库存防止流入下道工序。然后生成不合格品处理单指定处理方式。返工后要重新走质检流程报废的要从库存中扣除并记录损耗原因。这些数据攒起来以后就是工艺改善的金矿。比如某个工位的报工参数里温度偏高对应批次的合格率明显下降工艺工程师就能据此调整参数。4.3 看板数据实时展示的实现思路车间大屏上的生产看板本质上就是对服务端数据的实时汇总。客户端Socket长连接的好处在这里体现得最明显——服务端可以主动把汇总数据推送给看板程序WebSocket或者轮询做起来都更别扭。产量数据用原有的报工表做聚合按产线、按小时、按班组三个维度实时计算。设备状态这一块如果MES对接了设备数据比如PLC上报的开机、待机、故障状态看板上还能多一个OEE综合效率的展示。这块如果暂时没接设备也可以用人工报工的模式实现设备状态上报。5. 常见问题与排查技巧实录每个MES项目上线初期都会遇到一批共性问题的轮回。在这里把我遇到过的、以及身边同事遇到过的高频问题整理成速查表方便大家直接对号入座。问题现象可能原因排查思路与解决方法客户端提示“无法连接服务器”服务端没有启动、防火墙拦截、网络不通先ping服务器IP再telnet测试端口通不通检查服务端程序的监听端口是否被占用扫码枪偶尔扫不出来输入法停留在中文状态、焦点丢失窗体激活事件强制切英文输入法条码框始终保持Focus用KeyDown的回车符判断代替TextChanged高并发时报工消息积压服务端同步阻塞处理、线程池太小改为异步处理请求业务逻辑里避免同步I/O操作数据库连接用连接池建索引优化慢查询断网恢复后数据对不上客户端没有做本地缓存客户端增加本地SQLite或简单文件缓存断网时写入本地网络恢复后按时间戳补传看板数据延迟很大看板程序每次都查数据库看板改用服务端推送或者本地缓存聚合结果数据变更时增量更新不用每次都全量查询追溯某批次产品时查不到参数报工参数表没有写入记录检查客户端报工流程是否采集了参数数据服务端日志看报工请求是否被拒除了表里这些硬问题再分享一个蛮隐蔽的坑标签打印。MES里的流转卡、序列号标签、条码标签看着不起眼实际上最容易出乱子。标签格式需要跟车间现有的流程卡保持一致标签打印机驱动必须提前测试尤其是条码密度、纸张大小、打印浓度这些参数稍微不对扫码枪就认不出来。我见过好几个项目系统业务逻辑都跑通了硬是在打印标签的环节卡了一个礼拜。所以做MES别瞧不起打印这个“小事”提前试好绝对不亏。另外还有一点经验之谈MES最难的从来不是技术是业务梳理。技术上的Socket、数据库、WinForm都是成熟的套路真正费心的是跟车间主任、工艺工程师、操作班长反复确认每个流程节点的真实做法——很多流程在制度文件里和实际操作中根本是两回事。系统做出来要符合实际操作而不是符合制度文件这是MES能否落地的分水岭。如果你正准备自己动手写一套我的建议是不要一开始就求大求全从一条产线的报工和追溯需求做起跑通了再加质量管理、设备集成、看板展示。等客户端和服务端这套骨架立住了后续加功能也就是往框架里填肉的事。本文还有配套的精品资源点击获取