前阵子在上海松江帮一家汽配工厂做数字化改造老板上来就说想把 MES 系统的生产数据直接怼到车间那几块 LED 电子看板上省得每天让班长手抄产量、再跑去办公室更新表格。这个需求听起来很简单但真落地的时候坑不少——从控制卡选型、网络规划到数据接口协议每一步都有讲究。这篇我就把这套从零到上线的完整过程捋一遍把我踩过的坑和验证过的做法都写出来给正在做 MES 和 LED 看板对接的兄弟们一个可以直接抄的作业。这套方案适用于工厂已经有 MES 系统或者至少有计划上 MES、车间有或准备装 LED 电子显示屏、想自动展示实时工单进度、设备状态、产量达成率、异常报警等信息的场景。不论你是工厂的信息化工程师、MES 乙方实施顾问还是设备科负责看板维护的同事这篇内容都值得收藏。1. 项目背景与整体改造思路1.1 为什么车间看板非得和 MES 打通先说个场景。很多工厂早期都买过那种配套的 LED 看板U 盘插上去更新一次内容或者用厂商自带的软件手动改。这种模式在单班、品种少、节奏慢的小车间勉强能用但一旦上了 MES问题立刻暴露计划员在系统里排了今天的 20 个工单产线做完一个就得换下一个看板上的数据如果还要人工去改基本上就是摆设。我接手这个项目的时候车间里总共有 7 块 LED 屏分布在 4 条产线上。原来每块屏旁边配一台工控机靠人工在 Excel 里填数据再播放产线班组长每天至少花 40 分钟在更新看板内容上。老板的诉求很简单MES 里的工单号、计划数、完成数、不良数、当前良率、设备状态实时反映到看板上不用人管。这里要明白一个本质LED 看板对接 MES本质上不是两个软件联调而是打通一条从业务数据库到显示终端的实时数据链路。MES 管的是数据逻辑LED 屏管的是视觉呈现中间需要的是数据抽取、格式转换、下发显示这三个环节。只要这条链路稳了具体用哪种技术方案反而没那么重要。1.2 方案选型先定协议再定硬件在动手之前我花了整整两天时间做方案选型核心纠结三个问题第一LED 屏的控制卡支持什么接口协议。市面上主流控制卡主要分两类一类是老式的串口卡走 RS232/RS485传输距离短、要拉线另一类是现在的网口异步卡通过网线和局域网通信厂家一般提供 SDK 或者基于 HTTP 的自定义协议部分还支持 Modbus TCP。这个项目里 7 块屏都是近两年装的全部是网口异步卡这就给后续对接省了很多事。第二MES 系统能开放什么数据访问方式。厂里用的 MES 是某国产厂商的标准化产品后台是 SQL Server 数据库。厂商给了两种对接途径一是开放只读视图允许外部系统直接查数据库中的生产实时表二是提供 WebAPI 接口通过 HTTP 请求获取 JSON 数据。在实操中我建议优先问乙方要视图因为查询数据库的灵活度高想算什么口径自己写 SQL 就行不用等对方排期改接口。第三看板显示方案是走 PC 播放还是走控制卡本身渲染。这个选择最关键。市面上有两种常见做法一种是用一台迷你主机/工控机跑专用播放软件从 MES 拉数据再以图文形式投到 LED 屏上本质上是电脑当显示器另一种是控制卡直接支持文本/表格协议把数据推送过去后由控制卡本身完成排版渲染不需要电脑。前者显示效果好、能展示复杂图表但多了一套电脑硬件要维护后者稳定性更高、断点少适合显示实时数字、状态颜色块这种简单内容。我最终选了控制卡直接渲染为主、PC 播放为辅的混合方案4 块只显示产量和状态的大屏走控制卡协议3 块需要展示详细工单信息有表格、有进度条的屏走 PC 播放软件。这样既控制了硬件成本又保证了复杂画面的显示质量。2. 硬件准备LED 屏和控制卡你必须搞懂的底层逻辑2.1 控制卡的类型决定了你对接的难度很多搞软件的人第一次碰 LED 屏以为难点在屏本身其实错了。LED 屏就是一个显示终端真正决定你能否对接、怎么对接的是装在屏里面那张小小的控制卡。我建议先搞清楚你的屏用的是哪类卡。以最常见的异步控制卡为例它内部有存储和处理器能脱离电脑独立工作。你要做的就是把内容下发到卡上卡自己循环播放。异步卡按接口分又有串口卡和网口卡现在基本都网口了走 TCP/IP 协议。网口异步卡一般会配套一个节目制作软件你手工操作时是通过这个软件把内容传到卡里做对接时就要看这个软件或者厂家的 SDK 是否支持远程控制命令。常见品牌比如卡莱特、灵星雨、仰邦、诺瓦这些大厂基本都提供动态更新数据的接口只是调用方式各有差别。另外还有一个容易忽略的硬件——控制卡的型号和固件版本。同一品牌不同型号的卡支持的协议可能完全不同。我在现场就吃过亏供应商说这 7 块屏都是 同一款控制卡结果有两块是老库存固件版本老旧不支持 HTTP 动态数据接口后来只能先升级固件再对接。所以动工前一定要把所有屏拆开拍一下控制卡型号叫供应商确认支持列表避免做到一半发现卡脖子。2.2 网络规划别把所有屏塞进同一个摄像头那种局域网LED 看板对接 MES第一步是先把 7 块屏连到工厂局域网。听起来简单但实际做的时候有几个细节值得注意IP 地址规划。我建议给每块屏分配固定 IP不要用 DHCP 自动获取。因为控制卡软件在重连、下发内容时需要一个稳定的目标地址如果 IP 经常变调试起来会非常痛苦。我们当时规划了一个独立网段例如 192.168.20.10 到 192.168.20.16专门给 LED 屏用顺便在做防火墙策略时也好区分。带宽与隔离。屏的节目内容里如果带全彩图片、动画或者视频对带宽是有要求的。好在我们是文本数字为主占用极小。但要注意控制卡和 MES 数据库服务器之间如果有防火墙一定提前把端口放通。比如某些品牌卡的 SDK 用 9000 端口做数据下发另一些用 80 端口的 HTTP API这些都要在方案阶段就测试通道是否通。网线质量和交换机端口。车间环境粉尘大、电磁干扰严重超五类网线能用但建议上超六类屏蔽线尤其是走线靠近变频器、电机的地方。另外如果交换机端口支持 PoE 供电可以顺便给某些小尺寸控制卡供电少一根电源线也少一个故障点。2.3 供电与布线车间施工不能只图省事布线这块我单独拿出来说是因为它直接影响后面维护的幸福感。LED 屏的电源适配器一般放在屏体附近的防雨箱或者配电箱里要确保供电稳定建议每一路都加空开单独控制。施工时最容易犯的两个错误一是强弱电同管走线导致信号干扰严重屏幕出现花屏、乱码二是把控制卡放在密闭不透风的箱体里夏天车间温度高控制卡死机频繁。我后来让电工把所有信号线和电源线分管敷设控制卡箱体侧面加装了通风孔板这才彻底解决问题。这里分享一个我常用的经验值单块室内 P3 全彩屏约 3 平米功率大概在 200W-300W单色/双色文本屏功率更低约 50W-100W。7 块屏总功率不超过 1.5kW单独拉一路 220V 完全没问题但一定要算好线径2.5 平方毫米的铜线起步别用 1.5 的。2.4 控制卡参数设置与初始联调硬件接好电、连上网以后第一件事不是写代码而是把控制卡本身调试到能正常显示。用厂家软件打开之后依次做这几件事设置屏参包括屏宽、屏高像素点、扫描方式、颜色类型。这个参数不对屏幕显示就会错位或者直接花掉。一般屏体背面或者供应商给的资料里会有屏参表。设置网络参数给控制卡设置固定 IP、子网掩码、网关。如果跨网段访问 MES 数据库必须设对网关否则只在本网段内通信是通的跨网段就哑了。测试基本节目先添加一个最简单的文本节目比如测试 123看看显示颜色、位置、字号是否正常。这一步能验证屏体和控制卡工作正常后面 Debug 协议时就不用怀疑硬件了。确认动态数据接口可用用厂家软件的手动测试功能或 HTTP 工具尝试往控制卡推一条数据看屏幕是否刷新。例如仰邦的网口卡一般支持发送指定区域文本的指令你自己拼个 TCP 包发过去能看到屏幕变化就说明协议通道没问题。注意不同品牌的动态数据刷新机制不太一样。有的是发一条显示一条有的是先定义数据源再定时拉取。前者适合做实时推送后者适合做定时轮询。我建议优先选择支持按地址动态修改指定节目区域文本的卡这样对接最灵活。3. 软件对接三种主流通用方案的选型与实践3.1 方案一直连数据库 定时读表适合只读展示如果你的 MES 允许外部访问数据库而且看板只展示实时数据比如当前产量、良率、达成率那最快捷的路径就是直连数据库。我在这个项目里的做法是让 MES 乙方开放了几个只读视图视图结构是按照产线维度汇总的实时快照例如v_Production_Line_Realtime 字段LineCode, CurrentOrderNo, PlannedQty, CompletedQty, DefectQty, ProductRate, Status, UpdateTime对接程序我这里用的是 C# 写的一个 Windows 服务也可以换成 Python、Node.js每隔 10 秒执行一次SELECT * FROM v_Production_Line_Realtime把结果格式化后通过控制卡 SDK 推送到对应屏幕的指定区域。这个方案的优缺点非常分明优点实现简单SQL 人人都能写调试方便数据口径完全由 MES 侧来控制不会出现两边数据对不上的问题。缺点不是所有 MES 都允许开放数据库连接部分厂商出于安全考虑只给 API并且频繁查询数据库会占用连接资源查询频率不要太高。关于查询频率我自己的经验值是 10-15 秒一次。小于 5 秒基本上属于浪费因为 LED 屏上数字的变化对于现场的人来说并不需要毫秒级响应而且车间工人长时间盯着一块每 2 秒就跳一次的屏幕反而会疲劳。10 秒刷新既能保证数据及时性又不会给数据库增加太大压力。3.2 方案二调用 MES 的 WebAPI适合标准接口对接如果你们的 MES 有成熟的 API 接口比如用 RESTful 风格暴露了/api/production/line/{lineCode}/realtime这样的端点那对接方式会更干净。在代码层面你需要做的核心事情很简单写一个定时任务调用 HTTP 接口拿到 JSON 或 XML 数据解析之后映射到 LED 控制卡的显示字段。但实际操作时有两个坑一是高频轮询 API 会不会被限流。有些 MES 的 API 是有访问频率限制的之前我在别家就碰到过写了个后台服务每 3 秒请求一次结果跑了半小时 IP 被封了。所以对接前一定要和 MES 方确认限流策略保守起见轮询间隔保持 10 秒以上如果确实需要更高刷新率可以让 MES 那边单独开一个 Whitelist。二是 API 的认证 token 过期问题。很多系统用 JWT 或 OAuth2 做认证你的对接服务要处理好 token 刷新机制否则半夜 token 过期第二天早上看板就全变成无数据状态。我建议写一个启动时认证 定时刷新 token 失败告警的健壮逻辑不要等到用户自己发现看板没数据了才去重启服务。我用 Python 写了个 60 行左右的小脚本核心逻辑大致是import requests import time import json from led_sdk import send_text_frame # 假想的控制卡SDK token None def get_token(): global token resp requests.post(http://mes-api.company.com/auth, json{user: led, password: xxx}) token resp.json()[access_token] def fetch_line_data(line_code): headers {Authorization: fBearer {token}} resp requests.get(fhttp://mes-api.company.com/api/production/line/{line_code}/realtime, headersheaders, timeout5) return resp.json() def render_to_led(line_code, data): # 按控制卡的协议拼装文本帧推送到指定屏幕区域 frame f工单:{data[work_order]} 计划:{data[plan_qty]} 完成:{data[done_qty]} 良率:{data[yield_rate]} send_text_frame(line_code, frame) if __name__ __main__: get_token() while True: try: for code in [A01, A02, A03]: data fetch_line_data(code) render_to_led(code, data) time.sleep(10) except Exception as e: print([ERROR], e) time.sleep(30)脚本结构很简单但真正到了工程化落地还要加日志、告警、看门狗自动拉起这些后面在第四章统一说。3.3 方案三中间文件 消息队列适合跨部门协作与异构系统第三种方案我平时用得不多但在某些特殊场景下特别好用。比如 MES 系统是外购的数据库 IP 不开放给现场设备网段API 又因为商务问题迟迟协调不下来再比如车间里有不同品牌的 LED 屏有的支持协议 A、有的支持协议 B没有一个统一的对接入口。这时可以在中间的隔离区放一台采集服务器通过 MES 侧导出的文本文件Excel、CSV、TXT或者 MQTT 消息来中转数据。用文件的方式做最简单但不够实时一般适合每小时或者每班次刷新的看板比如显示今日各班次产量对比、月度达成率这种偏统计类的数据。实现上就是写个程序监控指定共享文件夹发现新文件就解析再分发到各 LED 屏。用 MQTT 消息做实时性高且架构清晰。MES 侧作为 Publisher 把生产事件推送到 Broker看板网关程序作为 Subscriber 订阅主题后自动更新 LED 屏。这个方案的优点是解耦彻底——MES 不需要知道 LED 屏的协议LED 屏也不需要理解 MES 的业务数据结构中间通过 topic 隔离。缺点是要额外部署一套 MQTT Broker对没有运维团队的工厂来说会增加一点维护成本。在方案选型时我习惯做一个对比表这样客户看着也清晰维度数据库直连WebAPI 对接中间文件/MQTT实时性高秒级高秒级文件分钟级MQTT秒级对接难度低中中高对 MES 影响需开放只读权限需开发/确认接口需 MES 侧推送/导出稳定性依赖 DB 连接稳定依赖 token 与限流策略文件依赖共享目录MQTT 依赖 Broker适用场景现场大屏实时产量多系统标准对接跨部门数据共享、多品牌屏混用3.4 协议再封装屏蔽底层差异方便以后扩展我特别想强调一点不管选了哪种对接方案写代码时最好把数据采集和LED 屏下发分成两层。数据采集层负责对接 MES下发层负责对接不同品牌的 LED 屏中间用统一的数据对象衔接。这样做的价值在项目后期会体现得特别明显。比如只做了一期对接二期老板突然说我们要在办公区再装一块拼接屏用另一个牌子的控制卡。如果你的代码里每个地方都直接调用某个品牌 SDK那就要全局改但如果你做了抽象把不同品牌的控制卡都封装成一个接口比如class LedScreen: def update_region(self, region_id: str, content: str, color: str): pass class BrandA_Screen(LedScreen): # 实现具体协议A pass class BrandB_Screen(LedScreen): # 实现具体协议B pass那新增一块屏就只是新增一个实现类主流程完全不用动。这个道理很多人都懂但在工厂项目里因为工期紧、预算少往往就省了等后期维护的时候才追悔莫及。4. 实操落地全过程从需求确认到上线验收4.1 第一周只干一件事梳理字段与显示规则对接工作开始之后我最不着急写代码而是先拉着生产主管、班组长、MES 实施顾问开了两次会把每个屏的显示需求确定了。车间里 7 块屏虽然都是产线看板但每块的侧重点还不一样1 号到 3 号屏放在机加工线重点显示当前工单号、计划数量、已完工数、不良数、达成率。4 号屏放在装配线除了产量还要显示当前工位状态运行/待料/故障。5 号屏是车间门口的总览屏显示各产线 OEE、今日总产量、异常告警数量。6 号和 7 号屏是品质区域的专门滚动显示最近 2 小时的不良缺陷 Top 5。我建议在做界面设计之前让每个产线的班组长把自己希望看到的信息按优先级排个序然后你再合并同类项。之所以这么麻烦是因为 LED 屏的显示区域是有限的尤其纯文本屏一行就能放那几十个字如果什么都想放上去最终结果就是字小到看不清工人根本不会抬头看。在确认字段的同时也要确认显示规则这个很容易被忽略。比如达成率怎么算按当班计划数算还是按日计划数算不良数包不包括返工件设备状态的字体颜色什么时候变红这些业务口径如果不定清楚程序写一半就会反复改。最终我们输出了一份《LED 看板显示字段及刷新规则说明书》里面每个字段都定义了来源表/接口、更新频率、显示格式、异常时的兜底文案。比如达成率低于 80% 时数字变红闪烁设备故障时显示设备异常请联系维修并每 30 秒切换一次故障代码。这份文档后来成了验收的依据强烈建议每个项目都做一次。4.2 第二周打通数据链路先跑通一块屏再说整体方案定了以后我先选了车间最具代表性的 3 号屏做试点。这期间做的事情第一步准备 MES 侧数据访问账号。因为数据库直连方案是只读视图所以我申请了一个最小权限的只读账号只给SELECT权限。注意绝对不要用 MES 业务账号去连一是权限太大有风险二是密码轮换会影响看板服务单独建账号更干净。第二步写数据采集和下发服务原型。我先用 Python 写了个一次性脚本手动调 MES 数据库视图再手动调控制卡 SDK确认数据能从库里出来、能推到屏上。这里最烦的就是控制卡 SDK 的编码问题有的卡只支持 GBKMES 数据库出来的是 UTF-8直接推上去就是乱码。这算是最常见的一个坑我下面会专门讲怎么处理。第三步验证显示效果。让班组长实际站在产线位置看字体大小、颜色是否清晰。如果发现字小了就减少一行的文本长度如果颜色对比度不够就把背景色和前景色调整一下。这个阶段就是快速试错不要怕改。3 号屏跑通之后我让班组长用了两天收集反馈没人说看不清、数据滞后再推广到剩下 6 块屏风险就小很多了。4.3 第三周编写正式服务并处理异常试点没问题之后就要把临时脚本改造成能长期运行的服务了。我这边的标准做法是用 C# Windows 服务或者 NSSM 把一个 Python/Node 进程注册成系统服务设置为开机自启、失败自动重启。因为工厂里上中班、夜班机器是不关的但偶尔会断电重启如果看板服务没跟着起来第二天早上白班的人就会发现看板全灭了。这个细节特别重要很多人写完程序就扔在那里第一次断电就原形毕露。服务本身要有三个核心模块数据采集模块定时访问 MES 数据库或 API拿到最新数据。采集失败时要有退避重试机制比如连续失败 3 次后间隔拉长到 30 秒并把错误写到日志。渲染下发模块把采集到的数据按照每个屏的模板格式化成文本或表格再调用控制卡 SDK 下发。下发之后可以主动查询屏的状态确认是否成功。看门狗与告警模块任何模块异常先把异常信息写日志然后通过企业微信/钉钉机器人推一条告警给值班人员。我建议在程序启动时发一条看板服务已启动的消息平时没消息就是正常。我还额外加了一个心跳巡检的玩法每隔 5 分钟程序会向每块屏的控制卡发送一个查询命令确认网络是通的。如果连续 3 次不通就在告警群里发3 号屏掉线的通知。这么做的原因很现实LED 屏平时没人专门盯着有时候电源跳闸或者网线松了屏幕停在最后一帧画面上看起来好像正常实际上数据早就停了。有了心跳巡检至少能第一时间发现问题。4.4 显示模板设计与刷新节奏的细节关于显示模板我总结了一个经验LED 看板不是给电脑屏幕做 UI字要够大信息量要克制。一块高度 32 像素的单红色文本屏一行能显示的中文字数大概是 16 个具体取决于点阵字体大小如果你硬塞 20 个字进去显示就会缺字或者滚动看起来非常难受。我们的文本屏模板一般按上中下或者左中右分区设计上/左区域固定标题比如3 号产线实时产量用固定颜色显示。中区域动态数据工单号、产量、达成率用高亮色黄/白。下/右区域异常状态或滚动提示语。如果是安装 PC 播放软件的全彩屏可以做得更灵活把整块屏分成多个区域每个区域对应一个 Web 页面或者一张图片通过软件内置的数据源功能比如绑定 Excel、数据库、HTTP 接口来自动更新。这里要提醒的是全彩屏的分区如果太复杂播放软件的 CPU 占用会高老旧工控机可能吃不消所以分区控制在 3-6 个为宜。刷新节奏上我坚持数据变化了才值得刷新的原则。比如工单状态这种东西可能 10 分钟都不变一次没必要每 5 秒推一次但产量数字是实时增长的可以每 10 秒刷新。我一般是把不同内容分成不同区域各自设独立的刷新周期这样既保证了及时性又不浪费资源。4.5 上线切换与验收测试上线那天的流程大概是这样提前和车间主任确认切换时间窗口一般选在中午休息或者交接班时间避免影响正常生产。把旧的人工更新方式停掉把新服务跑起来观察 30 分钟。在 MES 里模拟一次工单完工、一次异常停机分别看看板有没有正确跳转和变色。让班组长签字确认《LED 看板功能确认单》才算正式验收。验收测试时我特别强调测三种异常场景数据库宕机、网络断线、控制卡重启。数据库宕机时看板应该显示上一帧数据并附带数据更新超时的提示而不是直接黑屏网络断线后恢复时程序要能自动重连控制卡重启后服务要能识别到并自动把当前节目重新下发一遍而不需要人工干预。5. 常见问题与排查技巧实录5.1 高频问题速查表现象可能原因排查方法解决方法屏上中文乱码编码不匹配UTF-8 vs GBK查看 MES 数据库字符串编码与控制卡 SDK 要求编码统一转换为控制卡要求的编码一般推荐 GBK数据一直不变服务进程挂了检查 Windows 服务状态、看日志设置开机自启和自动重启加告警数据滞后很久查询频率过低或数据库视图刷新慢看数据库视图的执行时间调整轮询间隔让 MES 侧优化视图或建索引屏幕闪烁花屏电源功率不足或信号线干扰检查供电、网线远离动力线独立供电网线换成屏蔽线强弱电分管掉电重启后无显示控制卡没有保存节目或服务未自启检查控制卡设置确认服务恢复重新下发默认节目服务注册为自启某块屏单独连接不上控制卡 IP 冲突或网口松动ping 该 IP检查交换机端口指示灯重新绑定固定 IP更换网线/端口5.2 乱码问题几乎每个项目都会遇到乱码这个问题太典型我必须单独拿出一个部分来讲。很多工厂的 MES 数据库是 SQL Server默认排序规则是 Chinese_PRC_CI_AS存的是 GBK 编码的中文而控制卡 SDK 有的是按 ANSI 处理有的按 UTF-8 处理。两边的编码只要不一致屏幕上就是锟斤拷或者烫烫烫。我的处理办法是程序里做编码转换并且统一在下发前这个节点转换。也就是说从数据库或 API 拿到的数据先转成统一的 Unicode 字符串在调用控制卡 SDK 之前再按照该卡的协议要求编码成对应的字节流。例如content row[work_order] # 这是从数据库读到的 strPython3 默认 Unicode if control_card_encoding gbk: payload content.encode(gbk) else: payload content.encode(utf-8) send_bytes_to_card(payload)还有一个细节如果控制卡支持多语言字体库你需要下发前把中文字体选择对。有些卡默认只装了英文字库中文字符显示出来就是方框或空白这个跟编码无关是字库缺失问题。解决办法是在厂家软件里把中文字库烧录进控制卡。5.3 多品牌屏混用时的统一管理我这次项目里 7 块屏虽然都是同一家供应商但实际控制卡有两三个型号有的还是不同品牌。为了统一管理我在网关服务里维护了一个配置文件记录每块屏的 IP、端口、型号、对应产线代码、显示模板。配置修改之后不用重启服务隔几秒自动热加载这样现场维护人员自己改配置就行不用每次找我改代码。配置大概是这样的{ screens: [ { line_code: A01, screen_name: 1号产线看板, ip: 192.168.20.10, port: 9000, card_brand: 仰邦, template: production_line }, { line_code: A02, screen_name: 2号产线看板, ip: 192.168.20.11, port: 9000, card_brand: 卡莱特, template: production_line_with_status } ] }这样做的好处是如果后期新增一块屏只需要在 JSON 里加一段配置然后调一下接口测试即可上线不需要重新发版。5.4 网络故障与断电恢复的处理经验车间环境里网络和供电是不可控因素。我做这套系统的时候特意安排了连续一周的压测期间人为模拟了几次断电和交换机重启断电恢复之后控制卡会自动加载上次保存的节目所以我的服务启动时要主动做一次全量下发把最新数据推上去避免看到旧数据。交换机重启会导致所有屏瞬间断连服务里的 TCP 连接需要做重连机制不能一次失败就傻等。如果控制卡不支持 TCP 长连接而是走短连接则每次下发前都要重新建立连接稳是稳但耗时会长一点要预留足够的超时时间。还有一个很容易被忽略的坑工厂里偶尔会有电工检修把整个车间的电都断了。这种情况下所有屏都会断电等来电之后如果控制卡节目没保存好可能会恢复到一个出厂默认画面。所以在验收时我和电工确认了 LED 屏供电回路的空开尽量单控不要把几块屏的电源接在同一个插座排上否则一个跳闸全灭。最后再分享一点个人体会这次上海工厂的 MES 对接 LED 看板项目前后总共花了三周时间真正写代码的时间不到一半大部分精力都花在确定字段口径、调试硬件、处理网络问题、做好异常兜底这些事情上。我个人最大的体会是车间数字化改造的难点从来不在技术有多复杂而在于你要把软件的思维和硬件现场的物理世界缝合在一起。数据库、API、协议这些都可以在办公室调通但屏幕装在高处、工人仰头看到的字号大小、夏天车间温度对控制卡的影响、夜班断电之后有没有人管——这些才是真正决定项目能不能持续跑下去的关键。最后再分享一个小技巧上线之后的前两周每天早上去车间拍一遍 7 块屏的照片记录有没有数据异常。两周之后你会非常清楚这套系统在真实环境里的稳定性边界在哪里这时候再去做微调心里就有底了。数字化改造不是一锤子买卖上线只是开始后续的维护和优化才是真正见功夫的地方。 MES系统对接LED车间看板：从控制卡到数据链路实战指南
前阵子在上海松江帮一家汽配工厂做数字化改造老板上来就说想把 MES 系统的生产数据直接怼到车间那几块 LED 电子看板上省得每天让班长手抄产量、再跑去办公室更新表格。这个需求听起来很简单但真落地的时候坑不少——从控制卡选型、网络规划到数据接口协议每一步都有讲究。这篇我就把这套从零到上线的完整过程捋一遍把我踩过的坑和验证过的做法都写出来给正在做 MES 和 LED 看板对接的兄弟们一个可以直接抄的作业。这套方案适用于工厂已经有 MES 系统或者至少有计划上 MES、车间有或准备装 LED 电子显示屏、想自动展示实时工单进度、设备状态、产量达成率、异常报警等信息的场景。不论你是工厂的信息化工程师、MES 乙方实施顾问还是设备科负责看板维护的同事这篇内容都值得收藏。1. 项目背景与整体改造思路1.1 为什么车间看板非得和 MES 打通先说个场景。很多工厂早期都买过那种配套的 LED 看板U 盘插上去更新一次内容或者用厂商自带的软件手动改。这种模式在单班、品种少、节奏慢的小车间勉强能用但一旦上了 MES问题立刻暴露计划员在系统里排了今天的 20 个工单产线做完一个就得换下一个看板上的数据如果还要人工去改基本上就是摆设。我接手这个项目的时候车间里总共有 7 块 LED 屏分布在 4 条产线上。原来每块屏旁边配一台工控机靠人工在 Excel 里填数据再播放产线班组长每天至少花 40 分钟在更新看板内容上。老板的诉求很简单MES 里的工单号、计划数、完成数、不良数、当前良率、设备状态实时反映到看板上不用人管。这里要明白一个本质LED 看板对接 MES本质上不是两个软件联调而是打通一条从业务数据库到显示终端的实时数据链路。MES 管的是数据逻辑LED 屏管的是视觉呈现中间需要的是数据抽取、格式转换、下发显示这三个环节。只要这条链路稳了具体用哪种技术方案反而没那么重要。1.2 方案选型先定协议再定硬件在动手之前我花了整整两天时间做方案选型核心纠结三个问题第一LED 屏的控制卡支持什么接口协议。市面上主流控制卡主要分两类一类是老式的串口卡走 RS232/RS485传输距离短、要拉线另一类是现在的网口异步卡通过网线和局域网通信厂家一般提供 SDK 或者基于 HTTP 的自定义协议部分还支持 Modbus TCP。这个项目里 7 块屏都是近两年装的全部是网口异步卡这就给后续对接省了很多事。第二MES 系统能开放什么数据访问方式。厂里用的 MES 是某国产厂商的标准化产品后台是 SQL Server 数据库。厂商给了两种对接途径一是开放只读视图允许外部系统直接查数据库中的生产实时表二是提供 WebAPI 接口通过 HTTP 请求获取 JSON 数据。在实操中我建议优先问乙方要视图因为查询数据库的灵活度高想算什么口径自己写 SQL 就行不用等对方排期改接口。第三看板显示方案是走 PC 播放还是走控制卡本身渲染。这个选择最关键。市面上有两种常见做法一种是用一台迷你主机/工控机跑专用播放软件从 MES 拉数据再以图文形式投到 LED 屏上本质上是电脑当显示器另一种是控制卡直接支持文本/表格协议把数据推送过去后由控制卡本身完成排版渲染不需要电脑。前者显示效果好、能展示复杂图表但多了一套电脑硬件要维护后者稳定性更高、断点少适合显示实时数字、状态颜色块这种简单内容。我最终选了控制卡直接渲染为主、PC 播放为辅的混合方案4 块只显示产量和状态的大屏走控制卡协议3 块需要展示详细工单信息有表格、有进度条的屏走 PC 播放软件。这样既控制了硬件成本又保证了复杂画面的显示质量。2. 硬件准备LED 屏和控制卡你必须搞懂的底层逻辑2.1 控制卡的类型决定了你对接的难度很多搞软件的人第一次碰 LED 屏以为难点在屏本身其实错了。LED 屏就是一个显示终端真正决定你能否对接、怎么对接的是装在屏里面那张小小的控制卡。我建议先搞清楚你的屏用的是哪类卡。以最常见的异步控制卡为例它内部有存储和处理器能脱离电脑独立工作。你要做的就是把内容下发到卡上卡自己循环播放。异步卡按接口分又有串口卡和网口卡现在基本都网口了走 TCP/IP 协议。网口异步卡一般会配套一个节目制作软件你手工操作时是通过这个软件把内容传到卡里做对接时就要看这个软件或者厂家的 SDK 是否支持远程控制命令。常见品牌比如卡莱特、灵星雨、仰邦、诺瓦这些大厂基本都提供动态更新数据的接口只是调用方式各有差别。另外还有一个容易忽略的硬件——控制卡的型号和固件版本。同一品牌不同型号的卡支持的协议可能完全不同。我在现场就吃过亏供应商说这 7 块屏都是 同一款控制卡结果有两块是老库存固件版本老旧不支持 HTTP 动态数据接口后来只能先升级固件再对接。所以动工前一定要把所有屏拆开拍一下控制卡型号叫供应商确认支持列表避免做到一半发现卡脖子。2.2 网络规划别把所有屏塞进同一个摄像头那种局域网LED 看板对接 MES第一步是先把 7 块屏连到工厂局域网。听起来简单但实际做的时候有几个细节值得注意IP 地址规划。我建议给每块屏分配固定 IP不要用 DHCP 自动获取。因为控制卡软件在重连、下发内容时需要一个稳定的目标地址如果 IP 经常变调试起来会非常痛苦。我们当时规划了一个独立网段例如 192.168.20.10 到 192.168.20.16专门给 LED 屏用顺便在做防火墙策略时也好区分。带宽与隔离。屏的节目内容里如果带全彩图片、动画或者视频对带宽是有要求的。好在我们是文本数字为主占用极小。但要注意控制卡和 MES 数据库服务器之间如果有防火墙一定提前把端口放通。比如某些品牌卡的 SDK 用 9000 端口做数据下发另一些用 80 端口的 HTTP API这些都要在方案阶段就测试通道是否通。网线质量和交换机端口。车间环境粉尘大、电磁干扰严重超五类网线能用但建议上超六类屏蔽线尤其是走线靠近变频器、电机的地方。另外如果交换机端口支持 PoE 供电可以顺便给某些小尺寸控制卡供电少一根电源线也少一个故障点。2.3 供电与布线车间施工不能只图省事布线这块我单独拿出来说是因为它直接影响后面维护的幸福感。LED 屏的电源适配器一般放在屏体附近的防雨箱或者配电箱里要确保供电稳定建议每一路都加空开单独控制。施工时最容易犯的两个错误一是强弱电同管走线导致信号干扰严重屏幕出现花屏、乱码二是把控制卡放在密闭不透风的箱体里夏天车间温度高控制卡死机频繁。我后来让电工把所有信号线和电源线分管敷设控制卡箱体侧面加装了通风孔板这才彻底解决问题。这里分享一个我常用的经验值单块室内 P3 全彩屏约 3 平米功率大概在 200W-300W单色/双色文本屏功率更低约 50W-100W。7 块屏总功率不超过 1.5kW单独拉一路 220V 完全没问题但一定要算好线径2.5 平方毫米的铜线起步别用 1.5 的。2.4 控制卡参数设置与初始联调硬件接好电、连上网以后第一件事不是写代码而是把控制卡本身调试到能正常显示。用厂家软件打开之后依次做这几件事设置屏参包括屏宽、屏高像素点、扫描方式、颜色类型。这个参数不对屏幕显示就会错位或者直接花掉。一般屏体背面或者供应商给的资料里会有屏参表。设置网络参数给控制卡设置固定 IP、子网掩码、网关。如果跨网段访问 MES 数据库必须设对网关否则只在本网段内通信是通的跨网段就哑了。测试基本节目先添加一个最简单的文本节目比如测试 123看看显示颜色、位置、字号是否正常。这一步能验证屏体和控制卡工作正常后面 Debug 协议时就不用怀疑硬件了。确认动态数据接口可用用厂家软件的手动测试功能或 HTTP 工具尝试往控制卡推一条数据看屏幕是否刷新。例如仰邦的网口卡一般支持发送指定区域文本的指令你自己拼个 TCP 包发过去能看到屏幕变化就说明协议通道没问题。注意不同品牌的动态数据刷新机制不太一样。有的是发一条显示一条有的是先定义数据源再定时拉取。前者适合做实时推送后者适合做定时轮询。我建议优先选择支持按地址动态修改指定节目区域文本的卡这样对接最灵活。3. 软件对接三种主流通用方案的选型与实践3.1 方案一直连数据库 定时读表适合只读展示如果你的 MES 允许外部访问数据库而且看板只展示实时数据比如当前产量、良率、达成率那最快捷的路径就是直连数据库。我在这个项目里的做法是让 MES 乙方开放了几个只读视图视图结构是按照产线维度汇总的实时快照例如v_Production_Line_Realtime 字段LineCode, CurrentOrderNo, PlannedQty, CompletedQty, DefectQty, ProductRate, Status, UpdateTime对接程序我这里用的是 C# 写的一个 Windows 服务也可以换成 Python、Node.js每隔 10 秒执行一次SELECT * FROM v_Production_Line_Realtime把结果格式化后通过控制卡 SDK 推送到对应屏幕的指定区域。这个方案的优缺点非常分明优点实现简单SQL 人人都能写调试方便数据口径完全由 MES 侧来控制不会出现两边数据对不上的问题。缺点不是所有 MES 都允许开放数据库连接部分厂商出于安全考虑只给 API并且频繁查询数据库会占用连接资源查询频率不要太高。关于查询频率我自己的经验值是 10-15 秒一次。小于 5 秒基本上属于浪费因为 LED 屏上数字的变化对于现场的人来说并不需要毫秒级响应而且车间工人长时间盯着一块每 2 秒就跳一次的屏幕反而会疲劳。10 秒刷新既能保证数据及时性又不会给数据库增加太大压力。3.2 方案二调用 MES 的 WebAPI适合标准接口对接如果你们的 MES 有成熟的 API 接口比如用 RESTful 风格暴露了/api/production/line/{lineCode}/realtime这样的端点那对接方式会更干净。在代码层面你需要做的核心事情很简单写一个定时任务调用 HTTP 接口拿到 JSON 或 XML 数据解析之后映射到 LED 控制卡的显示字段。但实际操作时有两个坑一是高频轮询 API 会不会被限流。有些 MES 的 API 是有访问频率限制的之前我在别家就碰到过写了个后台服务每 3 秒请求一次结果跑了半小时 IP 被封了。所以对接前一定要和 MES 方确认限流策略保守起见轮询间隔保持 10 秒以上如果确实需要更高刷新率可以让 MES 那边单独开一个 Whitelist。二是 API 的认证 token 过期问题。很多系统用 JWT 或 OAuth2 做认证你的对接服务要处理好 token 刷新机制否则半夜 token 过期第二天早上看板就全变成无数据状态。我建议写一个启动时认证 定时刷新 token 失败告警的健壮逻辑不要等到用户自己发现看板没数据了才去重启服务。我用 Python 写了个 60 行左右的小脚本核心逻辑大致是import requests import time import json from led_sdk import send_text_frame # 假想的控制卡SDK token None def get_token(): global token resp requests.post(http://mes-api.company.com/auth, json{user: led, password: xxx}) token resp.json()[access_token] def fetch_line_data(line_code): headers {Authorization: fBearer {token}} resp requests.get(fhttp://mes-api.company.com/api/production/line/{line_code}/realtime, headersheaders, timeout5) return resp.json() def render_to_led(line_code, data): # 按控制卡的协议拼装文本帧推送到指定屏幕区域 frame f工单:{data[work_order]} 计划:{data[plan_qty]} 完成:{data[done_qty]} 良率:{data[yield_rate]} send_text_frame(line_code, frame) if __name__ __main__: get_token() while True: try: for code in [A01, A02, A03]: data fetch_line_data(code) render_to_led(code, data) time.sleep(10) except Exception as e: print([ERROR], e) time.sleep(30)脚本结构很简单但真正到了工程化落地还要加日志、告警、看门狗自动拉起这些后面在第四章统一说。3.3 方案三中间文件 消息队列适合跨部门协作与异构系统第三种方案我平时用得不多但在某些特殊场景下特别好用。比如 MES 系统是外购的数据库 IP 不开放给现场设备网段API 又因为商务问题迟迟协调不下来再比如车间里有不同品牌的 LED 屏有的支持协议 A、有的支持协议 B没有一个统一的对接入口。这时可以在中间的隔离区放一台采集服务器通过 MES 侧导出的文本文件Excel、CSV、TXT或者 MQTT 消息来中转数据。用文件的方式做最简单但不够实时一般适合每小时或者每班次刷新的看板比如显示今日各班次产量对比、月度达成率这种偏统计类的数据。实现上就是写个程序监控指定共享文件夹发现新文件就解析再分发到各 LED 屏。用 MQTT 消息做实时性高且架构清晰。MES 侧作为 Publisher 把生产事件推送到 Broker看板网关程序作为 Subscriber 订阅主题后自动更新 LED 屏。这个方案的优点是解耦彻底——MES 不需要知道 LED 屏的协议LED 屏也不需要理解 MES 的业务数据结构中间通过 topic 隔离。缺点是要额外部署一套 MQTT Broker对没有运维团队的工厂来说会增加一点维护成本。在方案选型时我习惯做一个对比表这样客户看着也清晰维度数据库直连WebAPI 对接中间文件/MQTT实时性高秒级高秒级文件分钟级MQTT秒级对接难度低中中高对 MES 影响需开放只读权限需开发/确认接口需 MES 侧推送/导出稳定性依赖 DB 连接稳定依赖 token 与限流策略文件依赖共享目录MQTT 依赖 Broker适用场景现场大屏实时产量多系统标准对接跨部门数据共享、多品牌屏混用3.4 协议再封装屏蔽底层差异方便以后扩展我特别想强调一点不管选了哪种对接方案写代码时最好把数据采集和LED 屏下发分成两层。数据采集层负责对接 MES下发层负责对接不同品牌的 LED 屏中间用统一的数据对象衔接。这样做的价值在项目后期会体现得特别明显。比如只做了一期对接二期老板突然说我们要在办公区再装一块拼接屏用另一个牌子的控制卡。如果你的代码里每个地方都直接调用某个品牌 SDK那就要全局改但如果你做了抽象把不同品牌的控制卡都封装成一个接口比如class LedScreen: def update_region(self, region_id: str, content: str, color: str): pass class BrandA_Screen(LedScreen): # 实现具体协议A pass class BrandB_Screen(LedScreen): # 实现具体协议B pass那新增一块屏就只是新增一个实现类主流程完全不用动。这个道理很多人都懂但在工厂项目里因为工期紧、预算少往往就省了等后期维护的时候才追悔莫及。4. 实操落地全过程从需求确认到上线验收4.1 第一周只干一件事梳理字段与显示规则对接工作开始之后我最不着急写代码而是先拉着生产主管、班组长、MES 实施顾问开了两次会把每个屏的显示需求确定了。车间里 7 块屏虽然都是产线看板但每块的侧重点还不一样1 号到 3 号屏放在机加工线重点显示当前工单号、计划数量、已完工数、不良数、达成率。4 号屏放在装配线除了产量还要显示当前工位状态运行/待料/故障。5 号屏是车间门口的总览屏显示各产线 OEE、今日总产量、异常告警数量。6 号和 7 号屏是品质区域的专门滚动显示最近 2 小时的不良缺陷 Top 5。我建议在做界面设计之前让每个产线的班组长把自己希望看到的信息按优先级排个序然后你再合并同类项。之所以这么麻烦是因为 LED 屏的显示区域是有限的尤其纯文本屏一行就能放那几十个字如果什么都想放上去最终结果就是字小到看不清工人根本不会抬头看。在确认字段的同时也要确认显示规则这个很容易被忽略。比如达成率怎么算按当班计划数算还是按日计划数算不良数包不包括返工件设备状态的字体颜色什么时候变红这些业务口径如果不定清楚程序写一半就会反复改。最终我们输出了一份《LED 看板显示字段及刷新规则说明书》里面每个字段都定义了来源表/接口、更新频率、显示格式、异常时的兜底文案。比如达成率低于 80% 时数字变红闪烁设备故障时显示设备异常请联系维修并每 30 秒切换一次故障代码。这份文档后来成了验收的依据强烈建议每个项目都做一次。4.2 第二周打通数据链路先跑通一块屏再说整体方案定了以后我先选了车间最具代表性的 3 号屏做试点。这期间做的事情第一步准备 MES 侧数据访问账号。因为数据库直连方案是只读视图所以我申请了一个最小权限的只读账号只给SELECT权限。注意绝对不要用 MES 业务账号去连一是权限太大有风险二是密码轮换会影响看板服务单独建账号更干净。第二步写数据采集和下发服务原型。我先用 Python 写了个一次性脚本手动调 MES 数据库视图再手动调控制卡 SDK确认数据能从库里出来、能推到屏上。这里最烦的就是控制卡 SDK 的编码问题有的卡只支持 GBKMES 数据库出来的是 UTF-8直接推上去就是乱码。这算是最常见的一个坑我下面会专门讲怎么处理。第三步验证显示效果。让班组长实际站在产线位置看字体大小、颜色是否清晰。如果发现字小了就减少一行的文本长度如果颜色对比度不够就把背景色和前景色调整一下。这个阶段就是快速试错不要怕改。3 号屏跑通之后我让班组长用了两天收集反馈没人说看不清、数据滞后再推广到剩下 6 块屏风险就小很多了。4.3 第三周编写正式服务并处理异常试点没问题之后就要把临时脚本改造成能长期运行的服务了。我这边的标准做法是用 C# Windows 服务或者 NSSM 把一个 Python/Node 进程注册成系统服务设置为开机自启、失败自动重启。因为工厂里上中班、夜班机器是不关的但偶尔会断电重启如果看板服务没跟着起来第二天早上白班的人就会发现看板全灭了。这个细节特别重要很多人写完程序就扔在那里第一次断电就原形毕露。服务本身要有三个核心模块数据采集模块定时访问 MES 数据库或 API拿到最新数据。采集失败时要有退避重试机制比如连续失败 3 次后间隔拉长到 30 秒并把错误写到日志。渲染下发模块把采集到的数据按照每个屏的模板格式化成文本或表格再调用控制卡 SDK 下发。下发之后可以主动查询屏的状态确认是否成功。看门狗与告警模块任何模块异常先把异常信息写日志然后通过企业微信/钉钉机器人推一条告警给值班人员。我建议在程序启动时发一条看板服务已启动的消息平时没消息就是正常。我还额外加了一个心跳巡检的玩法每隔 5 分钟程序会向每块屏的控制卡发送一个查询命令确认网络是通的。如果连续 3 次不通就在告警群里发3 号屏掉线的通知。这么做的原因很现实LED 屏平时没人专门盯着有时候电源跳闸或者网线松了屏幕停在最后一帧画面上看起来好像正常实际上数据早就停了。有了心跳巡检至少能第一时间发现问题。4.4 显示模板设计与刷新节奏的细节关于显示模板我总结了一个经验LED 看板不是给电脑屏幕做 UI字要够大信息量要克制。一块高度 32 像素的单红色文本屏一行能显示的中文字数大概是 16 个具体取决于点阵字体大小如果你硬塞 20 个字进去显示就会缺字或者滚动看起来非常难受。我们的文本屏模板一般按上中下或者左中右分区设计上/左区域固定标题比如3 号产线实时产量用固定颜色显示。中区域动态数据工单号、产量、达成率用高亮色黄/白。下/右区域异常状态或滚动提示语。如果是安装 PC 播放软件的全彩屏可以做得更灵活把整块屏分成多个区域每个区域对应一个 Web 页面或者一张图片通过软件内置的数据源功能比如绑定 Excel、数据库、HTTP 接口来自动更新。这里要提醒的是全彩屏的分区如果太复杂播放软件的 CPU 占用会高老旧工控机可能吃不消所以分区控制在 3-6 个为宜。刷新节奏上我坚持数据变化了才值得刷新的原则。比如工单状态这种东西可能 10 分钟都不变一次没必要每 5 秒推一次但产量数字是实时增长的可以每 10 秒刷新。我一般是把不同内容分成不同区域各自设独立的刷新周期这样既保证了及时性又不浪费资源。4.5 上线切换与验收测试上线那天的流程大概是这样提前和车间主任确认切换时间窗口一般选在中午休息或者交接班时间避免影响正常生产。把旧的人工更新方式停掉把新服务跑起来观察 30 分钟。在 MES 里模拟一次工单完工、一次异常停机分别看看板有没有正确跳转和变色。让班组长签字确认《LED 看板功能确认单》才算正式验收。验收测试时我特别强调测三种异常场景数据库宕机、网络断线、控制卡重启。数据库宕机时看板应该显示上一帧数据并附带数据更新超时的提示而不是直接黑屏网络断线后恢复时程序要能自动重连控制卡重启后服务要能识别到并自动把当前节目重新下发一遍而不需要人工干预。5. 常见问题与排查技巧实录5.1 高频问题速查表现象可能原因排查方法解决方法屏上中文乱码编码不匹配UTF-8 vs GBK查看 MES 数据库字符串编码与控制卡 SDK 要求编码统一转换为控制卡要求的编码一般推荐 GBK数据一直不变服务进程挂了检查 Windows 服务状态、看日志设置开机自启和自动重启加告警数据滞后很久查询频率过低或数据库视图刷新慢看数据库视图的执行时间调整轮询间隔让 MES 侧优化视图或建索引屏幕闪烁花屏电源功率不足或信号线干扰检查供电、网线远离动力线独立供电网线换成屏蔽线强弱电分管掉电重启后无显示控制卡没有保存节目或服务未自启检查控制卡设置确认服务恢复重新下发默认节目服务注册为自启某块屏单独连接不上控制卡 IP 冲突或网口松动ping 该 IP检查交换机端口指示灯重新绑定固定 IP更换网线/端口5.2 乱码问题几乎每个项目都会遇到乱码这个问题太典型我必须单独拿出一个部分来讲。很多工厂的 MES 数据库是 SQL Server默认排序规则是 Chinese_PRC_CI_AS存的是 GBK 编码的中文而控制卡 SDK 有的是按 ANSI 处理有的按 UTF-8 处理。两边的编码只要不一致屏幕上就是锟斤拷或者烫烫烫。我的处理办法是程序里做编码转换并且统一在下发前这个节点转换。也就是说从数据库或 API 拿到的数据先转成统一的 Unicode 字符串在调用控制卡 SDK 之前再按照该卡的协议要求编码成对应的字节流。例如content row[work_order] # 这是从数据库读到的 strPython3 默认 Unicode if control_card_encoding gbk: payload content.encode(gbk) else: payload content.encode(utf-8) send_bytes_to_card(payload)还有一个细节如果控制卡支持多语言字体库你需要下发前把中文字体选择对。有些卡默认只装了英文字库中文字符显示出来就是方框或空白这个跟编码无关是字库缺失问题。解决办法是在厂家软件里把中文字库烧录进控制卡。5.3 多品牌屏混用时的统一管理我这次项目里 7 块屏虽然都是同一家供应商但实际控制卡有两三个型号有的还是不同品牌。为了统一管理我在网关服务里维护了一个配置文件记录每块屏的 IP、端口、型号、对应产线代码、显示模板。配置修改之后不用重启服务隔几秒自动热加载这样现场维护人员自己改配置就行不用每次找我改代码。配置大概是这样的{ screens: [ { line_code: A01, screen_name: 1号产线看板, ip: 192.168.20.10, port: 9000, card_brand: 仰邦, template: production_line }, { line_code: A02, screen_name: 2号产线看板, ip: 192.168.20.11, port: 9000, card_brand: 卡莱特, template: production_line_with_status } ] }这样做的好处是如果后期新增一块屏只需要在 JSON 里加一段配置然后调一下接口测试即可上线不需要重新发版。5.4 网络故障与断电恢复的处理经验车间环境里网络和供电是不可控因素。我做这套系统的时候特意安排了连续一周的压测期间人为模拟了几次断电和交换机重启断电恢复之后控制卡会自动加载上次保存的节目所以我的服务启动时要主动做一次全量下发把最新数据推上去避免看到旧数据。交换机重启会导致所有屏瞬间断连服务里的 TCP 连接需要做重连机制不能一次失败就傻等。如果控制卡不支持 TCP 长连接而是走短连接则每次下发前都要重新建立连接稳是稳但耗时会长一点要预留足够的超时时间。还有一个很容易被忽略的坑工厂里偶尔会有电工检修把整个车间的电都断了。这种情况下所有屏都会断电等来电之后如果控制卡节目没保存好可能会恢复到一个出厂默认画面。所以在验收时我和电工确认了 LED 屏供电回路的空开尽量单控不要把几块屏的电源接在同一个插座排上否则一个跳闸全灭。最后再分享一点个人体会这次上海工厂的 MES 对接 LED 看板项目前后总共花了三周时间真正写代码的时间不到一半大部分精力都花在确定字段口径、调试硬件、处理网络问题、做好异常兜底这些事情上。我个人最大的体会是车间数字化改造的难点从来不在技术有多复杂而在于你要把软件的思维和硬件现场的物理世界缝合在一起。数据库、API、协议这些都可以在办公室调通但屏幕装在高处、工人仰头看到的字号大小、夏天车间温度对控制卡的影响、夜班断电之后有没有人管——这些才是真正决定项目能不能持续跑下去的关键。最后再分享一个小技巧上线之后的前两周每天早上去车间拍一遍 7 块屏的照片记录有没有数据异常。两周之后你会非常清楚这套系统在真实环境里的稳定性边界在哪里这时候再去做微调心里就有底了。数字化改造不是一锤子买卖上线只是开始后续的维护和优化才是真正见功夫的地方。