车间里同时亮起五块大屏数据跳动却不同步那种感觉就像乐队里五个乐手各弹各的。我在上海一家制造工厂做可视化电子看板项目时第一周就在“多块大屏同步显示”这件事上栽了跟头。电子看板这东西单独做一块屏谁都能搞定无非是前端图表加数据接口可一旦牵扯到多屏同步问题就从前端扩散到了数据采集、缓存分发、通讯网络和现场调试。这篇文章不聊空泛的可视化理论只讲我从需求评审到屏上亮数再到现场排障的完整落地过程和可复用的细节给准备做或者正在做工厂大屏项目的朋友一个参考。1. 需求盘点与整体技术选型1.1 先把“看什么数据”和“多实时才算实时”问清楚很多工厂做电子看板第一步就错了急着选型买屏幕却没搞清数据从哪来、刷新要多快。我接手的这个上海项目客户车间里规划了五块屏车间门口一块总览看板两条产线各有两块工位看板加上办公室一块质量分析屏。第一轮需求沟通生产经理张口就要“实时数据”但追问下去才发现他真正要的是“产线不停机的时候产量、节拍、不良率能在一分钟内更新”——这个“一分钟”就是需求和技术的分水岭。我习惯把电子看板的数据需求拆成三个维度数据源类型、刷新频率、异常联动需求。数据源类型一般分三种PLC设备数据、MES或ERP业务数据、人工录入数据三类数据的采集方式和实时性完全不同。刷新频率要具体到秒级、分钟级还是小时级这决定了你用消息队列还是定时任务。异常联动需求是指数据超标时要不要弹窗、要不要响铃这个必须在设计阶段就约好别等屏上墙了再加。这里有个经验能跟客户把“频率”和“精度”两条线谈清楚后面技术方案就成功了一半。比如客户说“设备状态要实时”那就按秒级轮询设计说“产量看板一分钟更新就行”就没必要上太重的消息队列。需求阶段多花半天能省掉开发阶段的好几天返工。1.2 技术栈选型别一上来就上大而全的平台很多开发一听到“可视化大屏”第一反应就是上商业BI平台或者自己搭一套微服务架构。实际上工厂这种场景业务逻辑不复杂但稳定性和易维护性要求极高。我这次选型是数据采集层用Node-RED加Modbus TCP采集PLC数据业务数据用MySQL存储中间层用Redis做缓存和消息分发大屏前端用Vue3配合ECharts多屏同步用WebSocket推送加帧号机制。这套组合看起来朴素但每一环都有明确理由。Node-RED上手快、断线重连逻辑成熟产线设备多的时候调试成本低Redis本身支持发布订阅模式一台服务器就能给五块屏做数据分发不用额外引入Kafka这类重量级组件。当然如果后续要接上百台设备的实时数据流再考虑Kafka或者RocketMQ不迟至少这个项目阶段用不上。为什么不用商业BI大屏平台因为工厂多屏同步有一个绕不开的需求屏与屏之间要精确地对齐刷新而商业平台大多只解决了“单块屏展示”对同步、权限、嵌入自有后台这些事支持得很差。自研这套方案前期多花一两周后期维护却省心得多数据想怎么聚合、视图想怎么切换都是自己说了算。2. 大屏硬件与网络组网实战2.1 屏端方案对比与选型工厂大屏常见的实现方式有三种普通电视加智能盒子、商用显示屏加电视盒子、工控机直连大屏。三种方案的成本和稳定性差别很大我直接说结论。电视加盒子最便宜一台50寸电视加一个百元级盒子成本两三千就够但盒子的GPU解码能力参差不齐ECharts动画一多就掉帧长时间运行还容易过热重启。商用屏加盒子稳定性好一些但本质上还是有中间层调试时要处理盒子和屏的HDMI握手问题。工控机直连最稳一台能塞进机柜的迷你工控机i3级别、8GB内存、带DP和HDMI接口直接输出给屏幕本地跑Chrome的无边框全屏模式省掉一层设备的烦恼。我这次选了工控机直出方案五块屏对应五台迷你工控机预算上确实比盒子方案多花了一万多但现场调试时不用跟电视系统抢资源Chrome全屏模式下动效流畅长时间待机也几乎没出过问题。如果你预算紧张用盒子方案也不是不行但建议选RK3568这类相对主流的芯片方案网口调试和串口调试都方便别贪便宜买杂牌安卓盒子后面刷机、连调试工具的时候会非常痛苦。2.2 网络拓扑与IP规划多屏同步显示网络是大动脉。必须在实施前把网络拓扑和IP规划写清楚否则现场必定乱成一团。我这次采用三层结构设备层、数据层、显示层。设备层是PLC和传感器通过车间环网接入采集网关数据层是MySQL服务器和Redis服务器放在机房交换机显示层是五块大屏通过单独的可视化专网接入。IP规划上我给每个角色都划了固定网段并且全部用静态IP。PLC设备用192.168.10.x采集网关用192.168.10.200数据服务器用192.168.20.x五块屏幕用192.168.30.101到105。静态IP是必须的因为大屏前端的WebSocket地址、采集程序的点位配置都是写死的一旦DHCP把IP分乱了屏直接连不上数据服务排查起来非常头痛。这里有个坑很多工厂车间网络和办公网络是同一张网广播域很大大屏推送数据时很容易被别的流量干扰。我不建议省这个事至少给可视化系统拉一条独立的物理网段或者用VLAN隔离同步质量会好很多。现场有台工控机一开始接了车间公共交换机数据包延迟时不时飙到几百毫秒后来改到可视化专网瞬间恢复正常。2.3 工控机端的系统准备工控机买回来不能直接装个浏览器就往墙上挂。机器里的系统配置直接影响后续长时间运行的稳定性。我在每台工控机上做了一套基础准备安装Windows 10 LTSC版本不带应用商店和乱七八糟的预装软件关闭系统自动更新防止半夜自动重启关闭休眠和睡眠防止硬盘停止导致程序假死设置Chrome开机启动并进入kiosk展台模式。这里每一步都不能省。我见过不止一次大屏运行得好好的结果第二天早上黑屏一查是Windows推送更新后自动重启了Chrome没起来。另外建议给每块屏配一个智能插座一旦断电重启可以远程重新上电不用每次都跑到车间里插拔电源。工控机的BIOS里也要设置通电自启这样断电恢复后大屏自己能起来。3. 数据采集层从PLC和数据库到统一数据出口3.1 设备数据采集Modbus TCP轮询与点位表设计工厂看板最核心的数据来自设备。这个项目现场的设备主要有两类支持Modbus TCP的智能设备和不支持通讯的老旧设备。能联网采集的设备是主要数据源老旧设备如果实在没有通讯接口只能通过传感器加采集模块或者人工录入补充。我重点说说Modbus这条线。Modbus TCP轮询本身不难难点在点位表设计。我强烈建议在写采集程序之前先跟设备工程师把“点位表”逐个确认清楚每个寄存器对应什么变量单位是什么量程多少异常值是多少。最好把点位表做成Excel按设备分组一屏一张表后面写采集脚本和维护都会快得多。我这次用了Node-RED的Modbus节点每个设备配一个TCP客户端轮询间隔设为2秒20个点位一次轮询也就20毫秒左右完全不构成压力。轮询周期也要算好。假设一台设备有20个点位Modbus TCP一次请求最多可以读125个寄存器一台设备大概只需要1到2个请求就能读完。按每个请求10毫秒算一台设备轮询一次20毫秒50台设备也才1秒所以秒级刷新完全可做到。如果你的设备是串口连接的那就得用串口调试助手先确认参数波特率、数据位、停止位通常默认是9600 8N1再通过串口服务器转成TCP让采集程序统一走Modbus TCP协议。3.2 业务数据同步数据库同步工具与增量任务设备数据之外还有大量业务数据产量日报、不良品统计、考勤出勤、订单进度。这些数据一般在MES系统或ERP系统的数据库里。我这里的做法是不对生产库直接做可视化查询而是用数据库同步工具把需要的数据定期同步到可视化专用的MySQL库里。同步逻辑很简单就是定时任务每5分钟跑一次增量同步用时间戳或自增ID作为增量断点。比如产量表里有一个update_time字段每次同步就取上次同步时间之后新增的数据插入到可视化库里。这一步建议把同步任务的状态也记一张表包含同步时间、影响行数、是否异常后面排查数据对不上的问题时特别有用。为什么要单独同步一个库两个原因。一是避免可视化查询把生产库拖垮工厂MES库往往还有ERP、仓储系统在调用查询压力大了会影响生产业务流程。二是方便做数据清洗和聚合比如把不同单位、不同口径的数据统一过来减少前端代码的转换负担。数据同步工具可以用开源的DataX或者自己写Python脚本这个项目数据量不大我用的是Node-RED的定时节点加SQL节点几行配置就完成了。3.3 中间层Redis缓存与发布订阅的作用多屏同步显示不能每块屏都直接连数据库轮询。五块屏如果各自每秒查一次数据库数据库压力不小而且每块屏查到的时刻不一样看到的数字就不一样同步问题就会非常严重。我用Redis做中间层解决了两个问题。第一个问题是缓存和统一数据出口。采集层的程序把最新数据写入Redis大屏后端服务只从Redis读数据数据源统一各屏读到的值就一致。第二个问题是发布订阅做消息分发。数据一更新采集程序往Redis频道里发布一条消息大屏后端订阅这个频道收到消息后再通过WebSocket推给前端。这个机制的好处是链路清晰每一层都是单向依赖排查问题时按顺序查就行。值得一提的是排查问题的时候Redis可视化管理工具非常香。我用一个开源的Redis Desktop Manager直接看某个key的值更新没有、频道里消息发没发出去比在代码里打半天日志高效得多。现场调试时我几乎每天都要打开它看几眼尤其是数据“看起来没更新”的时候先看Redis里的值再决定是查采集层还是查前端。3.4 数据质量边界值与异常值处理设备数据采集上来不能直接往屏上展示必须先做数据质量处理。这里的核心是边界值处理和异常值过滤。比如一个温度传感器量程是0到100度Modbus读回来的原始值可能是0到65535的数字这中间有比例换算关系没换算对屏上就是十几万度的离谱数据。还有一个很常见的问题设备断电或者通讯瞬断时采集程序可能读到0或者一个极大值如果不处理大屏上会出现产量暴跌或者温度爆表。我的做法是在采集层配置每个点位的最小值和最大值超出范围的值直接标记为“数据异常”前端显示为灰色并提示而不是把错误数据画在图表里。同时给关键点位做个简单平滑比如连续三次读到同一个异常值才判定为真实异常避免单次毛刺导致大屏数字狂跳。4. 多块大屏同步显示的落地实现4.1 同步方案路线对比时间戳对不齐怎么办多屏同步是这个项目的核心先聊聊几种路线。最简单的思路是每块屏各跑各的轮询后端定时从数据库查数据各屏按自己的节奏刷新。但这种方式因为网络延迟、浏览器渲染时间不同两块屏刷新时刻很容易差几百毫秒甚至几秒人眼一眼就能看出问题。要解决这个常见的有三种方案。第一种是服务端统一推送客户端被动刷新。所有大屏只连接一个WebSocket服务端服务端按固定频率把数据快照推给所有在线客户端。这个方案实现最简单绝大多数工厂场景都够用。第二种是精确帧同步客户端在收到数据后本地对发送时间戳做校正保证每块屏在同一个时间基准上执行渲染这种适合对同步精度要求极高的场景实现复杂度和成本都高不少。第三种是用UDP广播加本地时钟同步所有屏通过局域网UDP广播接收同一个时钟源然后约定在同一帧序号触发刷新常用于灯光联动这类工业现场控制但工厂电子看板数据量不大、更新频率不快用WebSocket推送完全足够。我最终选了第一种方案并在数据包里加了一个递增的帧号前端收到新帧号才刷新UI帧号相同就直接丢弃。这个设计看似简单实际是解决多屏不同步最有效的方法因为不管网络怎么抖动只要帧号对齐各屏就会统一跳变到最新状态不会出现旧数据覆盖新数据的情况。4.2 消息格式、帧号与推送节奏设计具体到实现我定义了一个统一的消息格式包含帧号、时间戳和业务数据。帧号是单调递增的整数时间戳是服务端生成数据的时刻业务数据是一个JSON对象里面是所有看板需要的指标。后端每2秒生成一帧数据从Redis里读取所有最新值组装成消息体然后通过WebSocket的broadcast推给所有大屏端。前端在收到消息时先比较帧号大于当前帧号才更新渲染否则直接忽略。这个机制保证了多屏的一致性。推送节奏这个参数要调。太密比如500毫秒一推前端频繁diff和重绘CPU占用高动效也容易卡太疏比如10秒一推客户又觉得不实时。一般工厂看板2到5秒一个周期比较合适具体看业务类型。我在总览屏上先用2秒一推跑了两天确认稳定后才把其他四块屏统一接入这样万一有问题也不会五块屏一起崩。稳妥起见推送服务还做了一层降级保护如果Redis读数异常就沿用上一帧数据并标记告警避免大屏直接卡死或黑屏。4.3 大屏前端适配与ECharts动效优化大屏前端不能按普通PC页面来做有几个细节值得重点说说。一是屏幕适配。五块屏分辨率不完全一样有1920x1080的也有一块3840x1080的条屏我用了百分比加rem的方案。设计稿按1920x1080根字体用flexible.js动态计算图表容器全部用百分比宽高。这样同比例缩放后一套代码能覆盖所有屏只要设计稿本身不超边。二是ECharts动效。ECharts做数据图表没问题但大屏上要特别注意性能。尽量避免频繁setOption加动画我的做法是对产量、节拍这类数字用数字滚动组件自己写一个计数器平滑滚动的视觉效果对图表数据则用setOption的全量替换默认关闭动画只在初始加载时开一次。实测下来如果开着动画每秒更新CPU占用轻松超过30%关掉之后降到10%以内五块屏同时跑都稳稳的。三是字体。工厂大屏观看距离远建议用笔画粗的标题字体数字用等宽字体避免跳动。字体文件必须放本地别引在线字体车间网络一旦抖动字体加载失败整个大屏布局就乱了。4.4 分屏布局与轮播策略五块屏不是所有内容都同时看。我的方案是车间门口总览屏固定显示整体视图包括总产量、总不良率、当前产线状态产线工位屏每30秒轮播“当前工位详情”和“整线汇总”两套视图办公室质量屏固定显示质量趋势图。轮播实现很简单前端一个定时器切换视图但有个坑视图切换时如果图表还没销毁内存会慢慢涨跑几天后页面就会卡顿。我封装了统一的显示和隐藏方法切换前先销毁图表实例切换后再初始化稳定跑了两周内存始终在合理区间。如果你的屏上内容特别多也可以做成一套大屏框架用JSON配置驱动视图切换后续改布局不用动代码这个扩展方案在后续接更多显示设备时特别有用。5. 现场调试工具链与排障实录5.1 我随身带的调试工具清单现场调试工具强则效率高。我这次用到工具大致分四类。第一类是网口调试工具我用的是NetAssist和MobaXterm。NetAssist用来直接发Modbus TCP报文、验证PLC点位通不通MobaXterm用来连工控机改前端代码、看日志。第二类是串口调试工具处理老旧设备串口通讯时用串口调试助手设置好波特率之后先发几个点位读一下确认返回数据正常再让采集程序接管。串口调试这步不能省现场很多设备地址跟图纸不一致必须实际测过。第三类是Redis可视化管理工具我用的是Redis Desktop Manager看缓存、发测试消息、查频道很方便。第四类是浏览器开发者工具工控机上Chrome按F12能看到WebSocket连接状态看Network面板就知道数据有没有真的推到前端。这个工具组合基本覆盖了从物理层到应用层的整个排查链路。每次问题先确定链路到哪一环断了再针对性用对应工具效率翻倍。5.2 典型故障排查实录实际调试中遇到不少问题挑三个最典型的说说都是以后可能复现的。第一个故障某一块屏数据一直不动其他屏正常。我当时第一反应是看Chrome的Network面板打开F12发现WebSocket连接已经是断开状态。再一查这台工控机电源选项里没有关闭休眠系统空闲后自己睡了网络连接自然断了。处理方法是把电源选项里的休眠和硬盘停止全部关掉然后设置Chrome开机自启进入全屏展台模式。这个故障告诉我们屏端靠“人类操作”来维护是不行的全自动才是王道。第二个故障两块屏数据都有更新但刷新不同步肉眼能看出先后差。检查后端日志发现推送服务在本地没开实际是每块屏各自连了一个不同端口的数据服务。处理方法是统一入口地址把五块屏的WebSocket URL改成同一个服务不再各连各的。排查过程中我一度以为是网络问题走了不少弯路这反而验证了流程化排查的重要性先从架构上确认连接关系再往底层查。第三个故障设备数据偶尔变成0大屏产量一下子少了几百。排查时用Modbus轮询工具直接读寄存器发现某个PLC的寄存器地址在图纸上是40001实际应该用400001差了一位偏移量。处理方法是跟设备工程师确认点位表把偏移量在采集程序里统一处理数据恢复正常。这个问题的隐蔽之处在于大部分时候能读到正常数据只有遇到特定设备状态时才触发没有Modbus工具直读根本发现不了。5.3 常见问题速查表我把整个调试过程中遇到的高频问题整理成了一张速查表给团队成员和车间IT一份大屏有问题先对照查一遍再决定要不要找开发。问题表现可能原因快速排查方法某块屏数据完全不动WebSocket连接断开、后端服务崩溃Chrome F12看连接状态查服务日志数据在更新但数值明显不对点位表偏移、单位换算错误用Modbus工具直读寄存器对比点位表多屏刷新时间不一致各屏连接了不同数据服务、网络拥堵统一WebSocket入口检查各屏URL长时间运行卡顿图表实例未销毁内存泄漏定时dispose图表关闭ECharts动画开机后黑屏无内容HDMI信号握手失败、Chrome未自启检查信号源设置开机自启数据偶尔变成0通讯瞬断、异常值未被过滤配置点位边界值平滑处理毛刺页面元素错位分辨率适配策略不对校对rem和百分比布局检查字体加载这张表建议直接打印贴在每个工控机旁边不管是开发人员还是车间IT看一眼基本能定位到问题方向。6. 交付之后的运维与扩展空间6.1 工控机标准化设置与看门狗机制交付给工厂后最容易被忽略的是工控机的系统设置。如果没处理半夜Windows自动更新重启第二天一早大屏黑屏车间主任准找你麻烦。我前面提过每台工控机要做一套标准配置关闭系统自动更新、关闭休眠和睡眠、设置开机自动启动Chrome的kiosk模式、在BIOS里设为通电自启。但光这些还不够建议加一层“看门狗”机制。我是用Windows的计划任务加一个简单的批处理脚本每5分钟检查一次Chrome进程是否存在如果不存在就重新拉起。之所以用这个方案是因为它简单可靠不依赖第三方软件Windows自带的计划任务就能搞定。对于这个量级的大屏系统够用且好维护。6.2 内部健康状态页与远程运维大屏系统跑到一定阶段维护的核心不是改代码而是快速定位故障。我给每台工控机加了一个简单的内部状态页通过远程访问IP加端口就能打开。页面上显示几个关键信息WebSocket连接状态、最近一次帧号、Redis连接状态、内存占用。平时不用管它一旦有问题车间IT远程看一眼就知道是哪一环出了异常不用跑到现场开开发者工具。这个健康状态页实现成本很低后端开一个简单接口返回JSON前端一个静态页面展示但价值很高。有一次客户反映总览屏卡了IT远程看到最近一次帧号停留在很久之前立刻判断是后端推送服务停了而不是网络问题直接重启服务就解决了。没有这个状态页至少得跑到机房看服务进程处理时长翻倍。6.3 从电子看板走向数字孪生的扩展路径电子看板做完了只解决了“看得见”的问题。这套架构天然可以继续扩展因为数据已经统一进了Redis前端可视化的能力也具备往后的方向很多。最直接的是从数据展示走向异常联动。比如设备报警后除了在大屏上标红还可以通过企业微信或短信推送给班组长质量超标时可以联动产线暂停。其次是接安灯系统把工位呼叫、物料缺料等状态都纳入看板车间管理会更完整。再往后如果现场已经有三维模型或者点云数据可以把大屏从前端图表升级成数字孪生场景数据管道、同步机制、调试方法论这三块地基都是现成的不需要推倒重来。最后再分享一点个人体会。做工厂数字化项目最怕的不是技术复杂而是需求没对齐、现场没人配合。多屏同步显示听起来是个技术题做下来你会发现它更多是沟通题和工程题。每次开工前先把点位表、网络拓扑、刷新频率这些基础约定写下来跟客户确认清楚后面会省掉大量的返工。项目上线那天我站在车间门口看着五块屏同时跳动的数据最大的感受是屏上的数字是表象真正值钱的是背后那套同步机制和调试方法它能承载的东西远不只是一个看板。