车间里那几块LED屏很多厂装了半年就成摆设了。倒不是屏本身坏了而是它显示的数据没人维护、没人更新时间一长员工扫一眼知道个大概时间管理层想看真实产出还是得跑到电脑前翻Excel。我在上海做了几年工厂数字化落地接手过好几个MES系统对接LED电子看板的项目前期需求调研的时候听车间主任和计划员描述得最多的就是数据全是手工抄的等抄完再录入上午的产量下午才知道哪还有什么实时管控可言。这篇文章就是我自己的落地实操复盘范围覆盖从硬件选型、接口方案、数据表设计、刷新机制到联调验收的全流程还包括上线之后最容易踩的几个坑。适合正在做或者准备做车间数字化改造的制造企业IT、自动化工程师、项目实施方参考也适合MES厂商的交付团队拿来当对接手册看。1. 为什么车间LED看板一定要对接MES而不是继续让班长手动改数据1.1 车间现场的旧常态看板是“给别人看”的不是“给自己用”的我见过太多工厂的看板是这么运作的早上开班班长在白板上写上今天的计划产量然后每隔两小时让统计员去各工位抄一遍实际完工数回来再用记号笔更新看板。有的厂稍微先进点用Excel统计完再投到电视上但本质上还是人工链路。这个模式的毛病不是“累”而是“慢”和“失真”。数据从生产现场到看板中间至少隔了半小时到两小时一旦某个工位忘记上报或者统计员临时有事看板上的数字就和现场实际情况完全对不上。更要命的是管理层看到的是一个“过去时”的车间碰到异常根本没法快速决策——比如某条线已经停线十分钟了看板上还显示着停线前的产量这种看板装了跟没装区别不大。1.2 对接MES之后看板才是真正的“车间驾驶舱”MES系统本身在不停产生数据工单下达、工序报工、设备运行状态、质检结果、物料消耗这些数据是实时的。LED电子看板对接MES本质上是把MES的实时数据“投影”到车间物理空间里让现场所有人看到的信息和系统里的信息完全一致。对接后能解决几个核心问题实时产量透明化MES每接收一次报工看板数字就变一次不用等班长汇总异常信息及时触达设备故障、质量报警、缺料预警看板第一时间变色、闪烁员工和管理人员站在车间任何一个角落都能看到管理层与一线信息对齐老板在办公室看到的数字化报表和车间里工人抬头看到的数字来自同一个数据源没人能再“谎报军情”数据可追溯看板显示的数据背后都能查到对应的工单、工序、报工记录不再是无源之水。我之前跟客户聊的时候打过一个比方没对接MES的看板就像一块只显示“今天天气晴”的天气预报屏看着没毛病但你要出门该淋雨还是淋雨。对接之后的看板则像一个实时更新的地图导航路况堵了它会告诉你重新规划路线它也能及时反应。车间管理要的就是这种“即时反应”的能力而这一切的前提是数据链路必须打通。1.3 适合对接的典型场景根据我自己的项目经验以下几类场景对接价值最大机加工车间CNC、车铣刨磨设备多、节拍快、产量统计容易滞后电子装配线工位之间衔接紧密任何一个工位卡壳都会传导到整条线注塑/冲压车间设备状态直接影响产出OEE是核心指标汽配/零部件行业客户审核要求追溯性强看板是展示实力的窗口。2. 对接方案选型三种主流模式怎么选我到底该走哪条路LED看板和MES对接市面上没有“一个万能接口”的说法因为每个厂的控制卡、MES架构、网络环境都不一样。做方案选型时我一般从三个维度去衡量现有MES提供什么接口能力、车间网络稳定程度、现场有多少块屏。下面把三种主流模式拆开讲清楚。2.1 方案一MES直接连LED控制卡串口或网口直发这个思路最直接MES系统通过串口线RS232/RS485或者网线把要显示的数据直接发给LED屏的控制卡控制卡收到数据后渲染到屏上。优点就是链路短、延迟最低如果MES本身是定制开发的把发数据的逻辑直接集成到MES模块里数据从数据库到屏幕理论上只要几百毫秒。但缺点也很实际第一MES要跟每一块控制卡点对点连接屏多了之后MES端要维护一堆连接并发一高容易出问题第二LED控制卡的通信协议各家不一样直接用MES连会让MES和控制卡厂商深度耦合后面换LED屏品牌就要改MES代码第三工业现场环境复杂串口线长距离传输容易受干扰网线布线也得考虑车间环境。这个方案我只建议一种场景用全厂就一两块屏MES是自家开发的、想快速出效果且当前控制卡支持TCP/UDP直连协议。2.2 方案二中间数据库表做中转最稳妥的过渡方案这是很多MES厂商和集成商最喜欢用的方式也是我第一次做对接时的选择。逻辑是在MES数据库里新建一张“看板数据表”MES通过定时任务或者触发器把看板需要的数据写入这张表LED看板的管理软件再定时轮询这张表拿到数据后调用控制卡的SDK刷到屏上。优点非常明显开发量小MES那边只需要维护一段“写中间表”的逻辑看板端只要做“读中间表”的逻辑两边解耦各自改各自的不互相影响。对老系统改造也友好不需要MES开放底层API只需要数据库层面开一个只读或可写账号。缺点也是有的实时性取决于轮询频率通常要1秒到5秒轮询一次做不到毫秒级响应中间表会积累历史数据不清理的话会越堆越多如果MES数据库本身负载很大高频轮询还会增加数据库压力。这个方案我一般推荐给老MES系统、不方便大量改动、网络相对稳定、对实时性要求不是极致的场景。五块屏以内的项目用中间库能省掉很多麻烦。2.3 方案三接口网关 REST API / MQTT我目前最推荐的方案近两年我做的项目基本都走这个路线。逻辑是MES端把数据通过REST API或者MQTT消息推送给一个独立的“看板数据网关服务”网关再通过WebSocket或者MQTT把数据下发到各块LED屏对应的控制终端通常是安卓盒子或者带网关功能的控制卡。这个方案的优势在于彻底解耦。MES只负责把数据推送到网关至于数据要显示在哪块屏、用什么颜色什么布局全部由网关和看板端管理。新增显示屏只需要在网关注册一台设备完全不用改MES。MQTT的消息质量等级还能保证断网重连后的数据补偿实时性和可靠性都优于轮询模式。代价是前期开发量大一些需要团队有后端开发能力如果MES本身比较封闭还需要先确认能否开放推送接口。但长远看只要超过五块屏或者未来有扩屏计划这套方案投入产出比是最高的。2.4 选型对比速查表方案开发成本实时性扩展性耦合度适用场景MES直连控制卡低最高差高1-2块屏MES自主开发中间数据库表中中秒级中中5块屏内老系统改造预算有限接口网关REST/MQTT中高高毫秒级好低5块屏以上长期数字化规划3. 核心实施步骤全流程从硬件选型到联调验收方案定了之后最大的坑往往不在技术上而在实施节奏。下面这个流程是我走完多个项目后固化的照着做基本不会漏项。3.1 LED屏硬件选型与控制器确认先别急着写代码硬件不确认后面全白搭。看板屏选型时几个关键参数物理分辨率与观看距离室内车间一般选P2.5或P3P代表像素间距数字越小越清晰室外或大空间选P4-P6。观看距离越远像素间距可以越大但文字和数字的清晰度必须够用。亮度与可视角度车间光线复杂尽量避免反光亮度建议不低于1500cd/㎡可视角度要看屏安装位置。防护等级车间粉尘大、油污多LED模组至少要IP40以上正面最好有防护。然后是核心部件——LED控制卡控制器这是对接的关键。控制卡分同步卡和异步卡同步卡依赖电脑输出信号电脑关了屏就没了不适合做数据看板异步卡自带存储和嵌入式系统数据下发后可以脱机显示更适合接MES做数据看板。我推荐选异步卡并且要确认它的二次开发能力。现在主流控制卡品牌比如仰邦、灰度、励研、诺瓦等大多提供HTTP接口或者SDK你在电脑上写程序调用它的API就能动态刷新屏幕上指定区域的内容。如果控制卡只支持配套软件手动改字那对接工作会非常痛苦选型时必须避开。安装位置也要提前勘测屏的供电在哪里、网线能不能拉到屏上、无线覆盖好不好、现场有没有大功率设备产生电磁干扰。这些都影响后面网络的稳定性。3.2 看板数据字段设计与页面布局硬件到位后下一步是设计“屏幕上到底显示什么”。我常用的方法是拉着车间主任、计划员、产线班组长开一次需求会把大家关心的字段一条条列出来。基本都会包含这些核心项工单号当前正在执行的生产订单计划数量该工单排产总数完成数量当前累计报工数达成率完成数量 ÷ 计划数量 × 100%不良率不良数 ÷ 完工数 × 100%设备状态运行/待机/故障/维修当班产量本班次累计产出异常信息最近一条报警或者缺料提示。页面布局上我习惯分四个区域顶部放车间名称、日期时间、班次信息中部核心数据区放产量达成相关字段数字要大、要醒目左下角放设备状态矩阵或产线状态列表右下角滚动显示异常信息。颜色统一用红黄绿正常绿色、预警黄色、异常红色。3.3 MES侧数据接口开发要点如果是中间库方案核心工作就是设计“看板数据中间表”。下面给一个简化版的建表参考CREATE TABLE kanban_daily_output ( id bigint NOT NULL AUTO_INCREMENT, work_order varchar(32) NOT NULL COMMENT 工单号, product_code varchar(32) DEFAULT NULL COMMENT 产品编码, line_code varchar(16) NOT NULL COMMENT 产线编号, shift_code varchar(8) NOT NULL COMMENT 班次编号, plan_qty int NOT NULL COMMENT 计划数量, done_qty int NOT NULL COMMENT 完成数量, ng_qty int DEFAULT 0 COMMENT 不良数量, achieve_rate decimal(5,2) DEFAULT NULL COMMENT 达成率%, current_status tinyint DEFAULT 0 COMMENT 0运行 1待机 2故障 3维修, update_time datetime NOT NULL COMMENT 更新时间, PRIMARY KEY (id), KEY idx_line_shift (line_code,shift_code) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENTLED看板产量汇总表;MES侧的定时任务逻辑通常是这样每30秒或1分钟查一次MES的报工表、设备状态表按产线和班次聚合计算完成数量、不良数量更新中间表里的对应记录只保留每个产线每个班次一条最新数据。如果MES本身就是用Java Spring Boot开发的定时任务可以用Scheduled注解也可以用Quartz或者xxl-job。我一般建议用xxl-job方便统一监控任务执行情况和失败重试。注意定时任务里加一个“防重入”的逻辑防止上一次任务还没跑完新一轮又启动了导致数据错乱。如果走接口方案MES侧要提供一个REST接口比如GET /api/v1/kanban/line/{lineCode}返回JSON格式的看板数据{ lineCode: LINE-A, workOrder: WO20240518001, planQty: 500, doneQty: 327, ngQty: 3, achieveRate: 65.4, deviceStatus: RUNNING, updateTime: 2025-07-21 14:32:10 }接口要做好鉴权和限流因为看板服务轮询频率高如果接口本身很慢会拖垮MES主服务。我自己遇到过一个问题MES的接口没做超时设置看板服务卡在等待响应上结果把MES的Tomcat线程池占满了导致工位终端上操作卡顿。后来所有接口统一设置超时500ms超时就返回上一次的缓存数据问题才解决。这个细节大家一定要记住。3.4 看板渲染服务与刷新机制设计LED屏幕显示数据的方式我一般分两种第一种是后端渲染成图片再推给控制卡。看板服务把从数据库或接口拿到的数据用模板引擎比如Thymeleaf、Freemarker生成一张完整的页面再用浏览器内核比如无头Chromium截屏成PNG图片通过控制卡的HTTP接口把图片推上去。好处是美工效果好什么复杂布局都能画字体字号清晰坏处是性能开销大截一次图要几百毫秒到一两秒高频刷新不现实。第二种是控制卡直接显示文本/表格数据。异步控制卡一般支持XML或简单协议下发富文本内容看板程序直接把“工单号WOxxx完成327/500”这样的文本拼接好发给控制卡。好处是速度快、占用资源小坏处是排版能力有限精细的UI做不了。具体选哪种看你买的是哪类控制卡。但不管哪种方式刷新机制的设计通则是一致的产量、达成率这些核心数字3到5秒刷新一次就够了不要做1秒刷新成本和风险都高日期、时间、班次信息可以1秒刷新但这部分一般由控制卡本地时钟显示不需要经过MES异常状态触发可以做成“事件驱动”MES一推送异常消息立即刷新这块区域而不是等下一轮轮询。刷新逻辑里最容易忽视的是数据时序问题。我之前在项目里碰到过一种诡异现象看板上的数字一会儿跳多一会儿跳少。后来排查半天发现是看板程序的轮询任务和MES的定时任务在并发更新同一条中间表记录MES刚写入新数据看板程序的旧数据又回写了彼此覆盖。解决方式是在中间表加一个update_time字段并设置“小于当前时间才允许更新”的条件或者干脆让看板端只读、永远不回写只由MES单向写入。3.5 联调、试运行与验收标准开发完成后不要急着全厂上线先选一条产线做联调。联调阶段我通常按这个清单来check数据链路是否端到端打通MES任务→中间库/接口→看板服务→控制卡→屏幕显示刷新频率是否满足现场需要连续观察30分钟记录从MES数据变化到屏幕显示变化的延迟时间数据准确性核对随机抽5个工单将MES报表数据与看板显示数据比对数次误差必须为0异常场景测试模拟断网、断电、数据库重启、MES服务重启观察看板能否自动恢复并补齐数据显示效果确认站在车间实际使用位置看能否清晰辨识主数字是不是够大、颜色是否刺眼。试运行建议至少跑满一个完整班次8小时让一线班长每天反馈看板信息是否和现场实际吻合。验收时把试运行期间发现的Bug清单和修复结果作为附件明确加分项是异常恢复时间我的标准是任何异常发生后看板必须在5分钟内自动恢复正确显示。4. 上线后常见问题与排查手记附速查表上线不是终点运维才是大头。这里把我踩过的坑一条条列出来。4.1 看板数据不更新或刷新慢排查思路从数据链路的最末端往源头查看屏幕显示的更新时间戳是不是最新的如果不是说明看板服务或者控制卡这层有问题登录看板服务所在服务器查看看板程序日志确认是否还在正常轮询或接收消息查MES定时任务日志确认任务有没有正常执行有没有报SQL异常查中间表数据看update_time有没有在更新。最常见的四个原因MES定时任务挂了没人知道数据库连接池到了上限定时任务拿不到连接看板程序连MES接口超时后没有重试机制控制卡离线网线松动或者控制卡死机。我的建议是给看板服务做一个“心跳看护”看板程序每分钟往日志数据库写一条心跳记录运维用定时脚本检查心跳是否正常异常就告警到钉钉/企业微信群不用等到一线员工发现屏幕不动了再报修。4.2 显示乱码、花屏、残影乱码多半是字符编码不一致。MES数据库用的UTF-8中间表或者控制卡协议默认GBK中文字符就会出现乱码。解决方法是统一编码我的统一标准是MES侧如果控制不了就做转换看板服务在发给控制卡之前强制转成控制卡支持的编码格式。实操中可以在看板服务里加一个配置项按控制卡型号选编码别写死在代码里。花屏和残影一般是硬件问题屏幕供电电压不稳加稳压电源控制卡和屏之间的排线接触不良重新插拔并固定控制卡老化死机设置定期自动重启比如每天凌晨断电重启一次。4.3 车间网络抖动导致数据丢失车间里大功率设备启停容易造成电压波动Wi-Fi信号也经常被钢结构厂房屏蔽。网络抖动在工业现场几乎是常态所以看板系统必须设计成“能容忍断网”而不是一旦网络波动就白屏。具体做法看板服务本地缓存最近一次成功获取的数据断网时继续显示缓存内容并在屏幕上显示“网络中断数据非实时”使用MQTT QoS 1或2的消息机制网络恢复后自动补发断网期间的消息控制卡支持离线文件存储的优先把数据写到本地断网也能正常播放。4.4 常见问题速查表问题现象可能原因排查顺序解决方案屏幕数字长期不变MES定时任务未执行1.日志 2.任务调度平台 3.数据库重启任务加任务存活监控数字频繁跳变多端并发写中间表1.查中间表更新时间 2.查写库SQL改成单向写加时间戳条件中文乱码编码不一致1.中间表字符集 2.控制卡协议编码统一转换编码做配置项屏幕颜色异常控制卡信号线松动1.排线 2.供电插拔排线加固重启后不恢复看板服务未开机自启1.服务器服务状态注册系统服务设置开机自启数据总是慢几分钟定时任务周期太长1.任务配置 2.数据库压力调短周期优化SQL5. MES系统里的英文术语对接开发时你一定会遇到这个对接项目的开发过程中我发现一个很有意思的现象本来是MES领域的人和LED硬件领域的人碰头结果双方嘴里全是缩写。这边说“你去查一下WIP的oee”那边说“我调用SDK的API pull一下”沟通全靠猜。我顺手把跟本项目相关性最高的术语整理了一份。5.1 业务层术语看得懂业务才知道要传哪些数据MESManufacturing Execution System制造执行系统通俗讲就是“车间里的操作系统”管工单、管报工、管质量、管设备。EAPEquipment Automation Program设备自动化程序负责和生产线设备交互采集设备状态和加工数据。LED看板要显示“设备运行状态”经常要依赖EAP采集的数据。APSAdvanced Planning and Scheduling高级排程系统用来做生产计划的自动排布。看板上的“计划数量”往往来自APS的排程结果。WIPWork In Process在制品指车间里正在加工、还没完工的产品。看板上统计的“完成数量”对应的就是WIP逐步转为成品的进度。OEEOverall Equipment Effectiveness设备综合效率等于可用率×性能×良率。很多看板都会把OEE当大数字显示老板爱看。SPCStatistical Process Control统计过程控制用统计方法监控质量波动。质量看板常用。BOMBill of Materials物料清单一个成品需要哪些零部件。看板上显示产品编码时关联BOM。SFCShop Floor Control车间现场控制跟MES概念接近有些老外企业习惯用SFC表示车间的执行管理系统。5.2 技术层术语写代码时绕不开的名词APIApplication Programming Interface应用编程接口。前面说的REST接口就是API的一种。SDKSoftware Development Kit软件开发工具包控制卡厂商给的二次开发包里面通常包含动态库和示例代码。RESTRepresentational State Transfer一种接口风格用HTTP的GET/POST等动词操作资源是当前最常见的系统对接协议。MQTTMessage Queuing Telemetry Transport消息队列遥测传输专门为物联网场景设计的轻量消息协议适合车间实时数据推送。WebSocket支持服务端主动推送数据的全双工通信协议看板页面实时刷新常用。OEE/ERP/MES/SFC这些业务系统之间的集成经常会提到ETLExtract, Transform, Load也就是抽数据、清洗转换、装载入库中间库方案本质就是一种轻量ETL。HMIHuman Machine Interface人机交互界面车间里的触摸屏终端也叫HMI和LED看板是“同类不同命”HMI偏操作看板偏显示。这些术语在对接落地的沟通里非常高频。我自己的习惯是建立一张专用的名词对照表直接贴在项目群里规定所有人在写需求、写代码注释、写验收文档时必须用统一中文名英文缩写避免“产量”叫Yield还是Output都能吵半天。写在最后的几句实在话做LED看板对接MES这个事技术难度说实话不高市面上能做的集成商一大把。真正决定项目成败的是前期有没有把“谁看、看什么、看了之后干什么”这三件事聊透。有的厂只想着车间里挂几块大屏能满足客户参观和体系审核那这项目定位就是“面子工程”按面子工程去做就行。但如果管理层真的希望看板成为日常管理的一部分那数据源头、刷新时效、异常联动、运维责任这四个环节缺一不可。我个人的体会是项目推进过程中最容易被低估的是“数据责任归属”问题。MES数据谁维护、中间表谁清理、看板进程谁监控、屏幕坏了找谁修——这些问题如果在项目启动时没有明确到人后期一定会变成踢皮球。上线试运行一周后我会专门留半天给客户的IT、生产班组长做一次实操培训把日常检查和简单排障方法都过一遍培训完要他们签字确认。这一步看起来不起眼但能省掉未来一大半的售后电话。如果你正在规划类似的车间数字化升级我的建议是先不要急着买屏也不要急着让MES厂商承诺“万能接口”而是先把数据流程画出来从MES到屏幕的每一条线、每一个节点都落到纸面上再决定用中间库还是上网关。图清楚了后面的活就有条不紊。下一篇我打算展开写一下看板页面的UI布局细节包括字号多大才醒目、颜色怎么搭配不刺眼、异常闪烁怎么设计才不让人疲劳如果有兴趣可以继续关注。