上个月刚把一个上海工厂的可视化电子看板项目收尾车间里四块55寸大屏加中控室一块110寸屏全部跑实时生产数据。甲方验收时说了句很有意思的话“这五块屏看起来得像同一块屏。”说白了就是数据一致、刷新同步、画面还不能卡这个要求看上去不复杂真正落地起来才体会到“多屏同步”这四个字有多磨人。数据源这边有PLC、有电表、还有MES系统里的工单和不良品记录刷新频率从1秒到5分钟不等协议也是Modbus、OPC UA、数据库接口混着来。整个项目从需求梳理到上线调试用了三周半中间踩了不少坑也总结出一套可以复用的落地方法。这篇文章就把整个从方案设计、同步机制选型、采集与上屏的实操过程以及现场调试的经验完整梳理一遍给正在做或者准备做工厂大屏可视化项目的朋友一个参考。1. 开工前先想明白这块屏给谁看、看什么很多项目一开始就急着挑框架、写代码结果做出来的大屏是挺好看领导却不满意。核心原因不是技术不行而是没搞清楚“这块屏到底解决谁的什么问题”。工厂电子看板跟互联网公司的数据大屏有个本质区别看板是拿来日常用的不是拿来参观的。1.1 看懂需求的三个层级我在这个项目里拿到需求时第一时间不是画架构图而是把现场的使用者分成了三层。车间工人关注的是自己这条线的产量节拍、当前工单进度、设备是否报警班组长关注的是设备开动率、故障停机时长、人员效率中控室和厂长关注的是全局产能、不良趋势、能耗汇总这些偏管理维度的指标。这三类人对数据的需求完全不同大屏的展示逻辑也就不一样。车间里的屏要以“大数字”为主一眼扫过去就知道当前产量和目标差多少刷新频率要求高最好是1到2秒更新一次中控室里的大屏则更侧重趋势曲线和占比分析刷新频率可以放宽到5到10秒但图表要稳定、不能闪。把这两类需求混在一套模板里是做电子看板最常见的翻车点。所以我建议做需求调研时不要只盯着“显示什么指标”还要明确每个指标的使用场景和容忍延迟。数据过期30秒可能车间工人都无感但设备报警如果延迟了3秒现场可能就炸锅了。看板的视觉设计优先级反而要靠后指标分级和刷新策略才是设计的前提。1.2 把数据源清单列出来每个指标都找到“数据出处”这步是最容易偷懒又最不能偷懒的。工厂里的数据源往往比想象中复杂得多光说“设备状态”这一个指标背后可能是西门子PLC、三菱PLC、国产一体机、甚至一个独立的数据采集器。我在项目启动后花了一天半时间把所有需要展示的指标和数据源做了一个逐一对应的清单并且标注了协议、位置、刷新频率和负责人。指标数据源协议/接口采集频率展示位置设备开动率/停机时长PLCModbus TCP1秒车间大屏线体产量/节拍PLC 传感器计数OPC UA1秒车间大屏工单进度MES数据库SQL查询30秒车间大屏能耗曲线智能电表Modbus RTU5秒中控大屏不良品率/缺陷类型MES手工录入HTTP API事件触发中控大屏人员在岗状态门禁/打卡系统数据库同步1分钟车间大屏这张表的价值在于后面做同步机制设计时我直接就能看出哪些数据可以走实时推送、哪些可以走低频轮询、哪些必须做断线补偿。比如PLC状态数据走WebSocket推送MES工单数据走轮询完全没问题但如果反过来工单进度也用1秒轮询去查数据库那数据库压力和控制端复杂度都会指数级上升。这里多说一句凡是手工录入的数据一定要在源头做约束。MES里录不良品时如果允许空值和负值到了大屏端就会渲染出奇怪的数据轻则曲线少一段重则百分比直接爆掉。后面调试时我花了大功夫做数据清洗其实就是前端多写几行过滤但源头如果不规范清洗也只是一道不完善的补救。2. 架构与选型多屏同步不是靠蛮劲整个项目的技术核心是“多块大屏同步”。同步这两个字行业内有个标准说法叫“一致性与实时性的平衡”。五块屏都在同一个局域网里最简单的方案是每块屏自己定时去数据库拉数据。这个方案写起来很简单但它没法做到“同一时刻显示同一份数据”因为每块屏的轮询时刻有细微差别网络抖动也会让数据的到达时间各不相同。2.1 数据链路从采集点到浏览器的三段式设计我最终采用的是“采集端 → 分发端 → 展示端”三段式结构。采集端负责对接PLC、电表、数据库等原始数据源把数据统一成JSON格式后发到分发端分发端是一个消息中间件负责把同一份数据同时推送给所有订阅的大屏客户端展示端就是浏览器里的可视化页面通过WebSocket接收数据并渲染成图表。这种结构最大的好处是数据的生产和消费完全解耦。车间采集端换了协议、换了设备型号只要输出的JSON结构不变大屏端一行代码都不用改。分发端如果用Redis或者消息队列来做还能天然支持多个订阅者的场景——五块屏、十块屏本质上都只是这个topic的订阅者。数据仓库位的选择上实时数据我坚决不直接查数据库。原因有两个一是数据库查询的延迟不可控二是多块屏同时高频查同一张表打爆数据库是迟早的事。实时的最新状态放在Redis这类缓存里历史数据落库前端要查趋势图时走专门的查询接口。这也是很多可视化项目性能上不去的核心区别。2.2 三种同步机制按场景选而不是按名气选多屏同步的实现路径市面上常见的有三种HTTP轮询、WebSocket推送、消息队列广播。它们各有适用的场景我在项目里就是把三种结合起来用而不是粗暴地选一个。HTTP轮询适合低频指标。比如工单进度30秒更新一次大屏定时用axios去拉就行简单可靠。但WebSocket推送适合高频指标比如设备状态、产量节拍必须服务端主动往客户端推否则1秒轮询一次对服务器和网络都是不小的压力。消息队列广播MQTT或Redis Pub/Sub则适合“一对多”的场景它的意义是让五块屏收到同一条消息而不是五块屏各自去不同的地方拿数据。同步方式延迟并发能力适用场景项目中的使用点HTTP轮询秒级一般低频数据/兜底方案MES工单、不良率WebSocket推送毫秒级强高频实时数据产量、设备状态MQTT/Redis转发毫秒级强一对多广播采集端→服务端统一分发选型时还有一个容易踩的坑如果每块屏都直接连PLC去读数据先不说协议允许的并发连接数够不够光是五块屏各自维护一套采集逻辑就够维护的人喝一壶了。正确做法是只有采集端连设备所有屏从分发端拿数据。这条原则我是在项目里被一个三菱PLC的连接数限制教育了之后才彻底坚定的。2.3 前端可视化选型ECharts够用不必迷信大屏框架前端可视化框架选择上这个项目用的是Vue 3 ECharts 5没有套用市面上那些封装好的大屏模板框架。原因也简单模板框架确实出图快但工厂看板的指标和布局往往要反复调整绑定死在框架里之后扩展一个自定义组件可能比自研还麻烦。ECharts的强项在图表本身折线图、柱状图、仪表盘、关系图都有现成封装。大屏的边框、标题栏、数字滚动这些UI效果我在项目里是自己用CSS和简单组件实现的效果照样能打。而且不依赖重型大屏框架还有一个好处每块大屏就只跑一个浏览器页面资源占用更低页面崩溃和卡顿的概率会小很多。还有一个细节值得分享大屏页面的刷新策略不能全交给ECharts自己处理。我的做法是前端维护一个统一的数据分发器WebSocket收到消息后先放到一个store里再由ECharts组件通过watch去更新setOption。这样能保证同一屏上的多个图表按同一个节奏渲染不会出现产量数字刷新了但趋势图还要卡半拍的情况。3. 实施落地把同步机制真正跑起来方案设计做得再漂亮最终还是要落地。这一节我按采集、分发、展示、多屏对齐四个环节把关键实现和过程中值得注意的细节完整过一遍这些细节都是我在现场调试时逐一验证过的。3.1 数据采集层设备协议接入的可落地做法数据采集是整个系统里最脏最累的活每个设备的协议都有可能不同。这个项目里PLC用的是Modbus TCP电表走的是Modbus RTU串口。我采取的方案是写一个轻量的采集服务跑一台边缘网关或者直接用工控机装个Python服务把不同设备的数据读出来后统一清洗成标准JSON。# 示例Modbus TCP 读取PLC寄存器并标准化输出 from pymodbus.client import ModbusTcpClient import json, time client ModbusTcpClient(192.168.1.100, port502) client.connect() while True: # 读取从站地址1起始寄存器0读取10个保持寄存器 rr client.read_holding_registers(0, 10, slave1) if not rr.isError(): # 前两个寄存器是产量计数器组合成32位整数 output { device_id: SMT-LINE-01, ts: int(time.time() * 1000), yield_count: (rr.registers[0] 16) rr.registers[1], status: rr.registers[2], speed_rpm: rr.registers[3] / 10.0 } # 发送到本地分发端Redis或MQTT publish(factory/device/SMT-LINE-01, json.dumps(output)) time.sleep(1)注意代码里的一个细节PLC的32位计数器通常是“两个寄存器组合”这里有大小端和字序之分。西门子和三菱的排序习惯不一样Modbus标准没有完全统一实现现场我处理这个时用串口调试助手抓了帧和PLC侧的点表逐字对过才写死。这个坑如果开发阶段不看真实数据等上大屏发现产量数据忽大忽小再排查会很头大。电表那一路更麻烦Modbus RTU走RS485需要先确认串口参数波特率、数据位、校验位我这边是9600波特率8数据位无校验。采集时必须注意轮询命令之间的间隔不能太快有些老电表对连续请求没有缓存过快会直接不响应。我把串口采集间隔设置在5秒以上实测稳定。3.2 中间同步层统一分发与断线补偿采集端产生数据之后接下来就是分发。这个项目里我用了Redis Streams做消息分发比起Redis Pub/SubStreams多了一个“消费者可以按ID拉历史消息”的能力这对大屏断线重连后的补偿拉取特别有用。整理一下流程采集服务把数据写入Redis Stream后端服务作为消费者把最新数据转发给所有WebSocket客户端同时把最新状态写入Redis Hash作为实时快照。大屏断线重连时先通过接口拉一次Hash里的快照再根据断开的时间点从Stream补拉消息这样即使漏了30秒的数据也能平滑补回来不会出现中间一段空白。// Node.js 后端 WebSocket 广播逻辑简化版 const WebSocket require(ws); function broadcast(data) { const msg JSON.stringify(data); wss.clients.forEach(client { if (client.readyState WebSocket.OPEN) { client.send(msg); } }); }这里有个性能细节WebSocket广播时不能直接在forEach里做序列化和业务逻辑。我这个项目里五块屏问题不大但如果后面扩展到几十块屏广播逻辑一定要放到异步队列里做削峰。同时消息里带上ts时间戳前端拿到后用来校准显示时间。断线补偿是多屏同步里最容易忽略的一环。很多开发只做了断线重连但重连之后不同屏补齐的数据范围不一样就会导致几块屏显示的内容在接下来一两分钟内对不上。用带时间戳的消息流做补偿就可以保证所有屏最终收敛到同一个数据点这个体验细节对“看起来像同一块屏”非常关键。3.3 大屏渲染的工程化封装前端这边我的结构是页面层大屏布局、数据层store、组件层图表。每个大屏的功能区拆成独立组件比如设备状态面板、产量趋势图、报警滚动列表组件之间不直接通信统一走store。WebSocket推送的数据先进store组件响应式地更新自己。// 核心WebSocket 接收数据后统一进 store import { defineStore } from pinia; export const useDashboardStore defineStore(dashboard, { state: () ({ deviceStatus: {}, yieldData: [], alarmList: [], serverTimeOffset: 0 }), actions: { updateFromSocket(payload) { this.deviceStatus payload.devices; this.yieldData.push(payload.yield); if (this.yieldData.length 300) this.yieldData.shift(); // 控制缓存长度 this.alarmList payload.alarms; } } });ECharts组件更新的关键是只调用setOption不要重复init。我见过很多小伙伴每次数据更新都把整个图表销毁重建结果就是图表疯狂闪烁CPU居高不下。setOption时还有一个参数叫notMerge默认情况下ECharts会做diff更新这个默认行为正好适合咱们的流式数据场景。另外一个很实际的经验前端渲染要和刷屏周期做节流。WebSocket如果每秒推送一次产量数据产量趋势图每秒setOption一次其实没问题但如果同时还有多个曲线和动画低配工控机跑浏览器就容易掉帧。我给每个图表设置了最小更新间隔比如趋势图200毫秒一次数字面板不节流但要加过渡动画。实际观感上数字更新快一点、图表更新稍微平滑一点反而更自然。3.4 多屏时间对齐与刷新节奏控制多块大屏的“同步感”主要来自三个方面时间基准一致、数据消息一致、渲染策略一致。时间基准统一我用的是NTP。四台车间大屏各自配一台小主机中控室是一台高性能工控机这五台设备全部连到公司内网的NTP服务器确保系统时间误差在几十毫秒内。前面已经介绍过每条消息里都带服务端时间戳前端收到后用本地时间和服务端时间戳做一次差值计算后续显示文本的时间都用服务端校准时间避免光看系统时间造成显示偏差。消息一致依赖的是统一分发这块前面已经详细说明了。还有个容易忽略的问题是“不同大屏的分辨率不同”。车间屏和中控屏的分辨率、尺寸都不一样如果粗心把像素值写死同一张图在不同屏上布局会完全走样。我的做法是所有尺寸单位统一用vw/vh比例适配图表自适应容器保证视觉布局一致。最后是渲染策略。为了减少五块屏在动画上的随机差异我在前端做了一个简单的时钟对齐所有图表动画启动时间都基于服务端时间的整秒对齐比如每秒的0ms统一触发刷新动作。这样即使个体渲染有几十毫秒误差肉眼也完全看不出步调不一。实测下来这个方案比靠本地定时器各跑各的强太多了。4. 调试实录把现场问题一个个按下去任何项目上线前不调试是不可能的调试的功底基本决定了项目交付顺不顺利。这个项目里最耗时的不是写代码而是现场联调。我把自己常用的调试方法、遇到过的典型问题和排查思路整理成四个小节这部分在普通文档里基本找不到全是实操换来的。4.1 网络调试三板斧先看通断再看数据对不对多屏系统最常见的故障就是某块屏“没数据”。出现这种情况我一般先用网络工具做三层排查。第一层看主机到服务端的通断第二层看端口监听是否正常第三层再往应用层深入。# 第一层看主机到服务器的网络通不通 ping 192.168.1.50 # 第二层看服务器的WebSocket端口是否在监听 telnet 192.168.1.50 8080 # 第三层本地实时看TCP连接状态排查连接是否被断开 netstat -an | findstr 192.168.1.50做这些操作时我会配合抓包工具去看WebSocket握手和数据帧。浏览器开发者工具里的Network面板可以看到WS帧的收发这是最直接的手段。现场调试时如果发现连接经常断开多半是HTTP代理或防火墙空闲超时导致解决方式是在前端加心跳每30秒发一次ping帧保活同时配合前面说的断线重连和补偿机制基本能保证长连接稳定可靠。串口调试助手这类工具我主要用在电表采集链路。Modbus RTU的波形是二进制帧直接在屏幕上靠肉眼看根本分辨不出是乱码还是正常数据。把串口调试助手挂在采集设备和电表之间能看到采集端发出的请求帧和电表响应的应答帧对照Modbus协议文档里CRC校验和数据地址问题在哪一层很快就能定位出来。网口调试助手则用来模拟PLC服务端前端还没开发完的时候可以先让采集端连着调试助手跑确认逻辑没问题再接真实设备。4.2 多屏“看起来不同步”的排查清单这是整个项目里最有价值的一个排查清单记录的都是一手现场经验。如果遇到多屏刷新不同步、数据对不上按顺序检查以下内容基本能覆盖90%的原因。第一看各屏主机的系统时间是否一致。哪怕差了半秒数字翻页时都会看到明显错位。第二确认所有屏的WebSocket连接是不是都连到同一个分发服务。如果连到了不同的负载均衡节点而节点之间数据没有共享那就相当于各看各的永远对不上。第三检查浏览器页面是不是同一个版本。前端更新后有的大屏浏览器缓存没刷新还在跑旧代码新旧逻辑不同步画面自然不一致。第四确认没有用本地定时器做刷新。只要刷新动作完全由服务端推送驱动天然就是同步的。我在项目里遇到过一个很有意思的案例中控室的大屏总是比车间大屏慢2秒。排查了半天最后发现中控屏连接的交换机端口被限速到10Mbps画面推送卡在队列里。网络带宽这个点很容易被忽略多屏系统同时接收数据如果带宽被音频监控占满延迟就会飙升。后来给大屏相关设备专门划了VLAN问题立刻消失。4.3 从设备端到大屏的数据异常排查大屏上数据不正常问题往往不在前端而在数据采集和传输链路。最常见的问题之一是PLC的浮点数解析错误。Modbus报文里32位浮点数有两种字节序不同厂家的PLC和仪表实现甚至可能混用。我第一次接电表能耗数据时屏幕上显示出来的数字完全离谱用串口调试助手抓了几条原始报文和DLL里的数据定义仔细比对才发现是高字在前低字在后调整解析顺序后数据立刻就正常了。另一个高频坑是“脏数据导致图表翻车”。比如设备停机瞬间PLC寄存器里读到的是0xFFFF这是一个无效的极大值会让图表纵轴瞬间被拉爆。应对办法是在采集服务里做一次数值合理性校验超出了设备量程范围的数据直接丢弃并记录一条异常日志。可视化大屏的底线是“展示的数据必须是可信的”宁可少显示一个点也不能显示一个错误值。还有一类数据异常根因在业务层面。手工录入的不合格品数量可能在实际操作中录成了负数或者小数点错位。我的处理方式很直接前端渲染前再过滤一次同时保留了业务校验提示让录入端的人知道自己录错了。系统上线一个多月后这类录入错误明显减少因为录入员都能从大屏上直观看到自己录的数据影响了整个车间的统计结果。4.4 调试日志与显示并存的实践最后说一个所有调试工作都会用到的小技巧调试信息既要打印到日志文件也要实时显示在界面上。很多人调接口时习惯依赖浏览器的console但在车间现场开开发者工具既不方便也不直观而且console信息刷新太快根本看不清。我的做法是在前端页面角落放一个可收起的调试面板把关键日志同时输出到console和界面上。后端服务同样遵循这个原则日志同时写文件和终端窗口文件用于追查历史现场终端用于开发现场实时观察。这样联调时不用反复切换窗口一眼就能看到报文在哪个环节丢了。// 调试日志同时输出到控制台和页面调试区 function log(msg, level info) { const line [${new Date().toLocaleTimeString()}] ${msg}; console[level](line); const el document.getElementById(debugPanelContent); if (el) { el.innerHTML line br/; el.scrollTop el.scrollHeight; // 自动滚动到底部 } }调试面板上线时要不要保留取决于甲方态度。这个项目的甲方后来还蛮喜欢这个面板让我把它收小放到角落说是现场点检设备状态时能直接看底层原始数据反倒成了一个贴心功能。最后说点个人体会做工厂可视化电子看板技术难度本身并不高难的是把各种设备协议、网络环境、使用习惯这些“非标准化”的东西理顺。多屏同步表面上是个技术问题本质上是个工程问题——时间对齐、消息一致、断线补偿、渲染节奏每一样都要在设计阶段预留好扩展空间全靠现场临时补往往来不及。我个人的经验是做这类项目需求调研阶段多花两天完全不亏把数据源和刷新策略梳理清楚后面会顺手很多数据链路设计时永远不要高估网络环境现场无线干扰、交换机端口限速、防火墙策略拦截都真实遇到过调试阶段一定要有抓包和日志工具磨刀不误砍柴工。如果你正准备上马类似的可视化大屏项目希望这篇落地总结能帮你少走几步弯路让五块屏真正看起来像“同一块屏”。
