工厂电子看板多屏同步实战：从数据采集到现场调试

车间里同时亮起五块大屏，数据跳动却不同步，那种感觉就像乐队里五个乐手各弹各的。我在上海一家制造工厂做可视化电子看板项目时，第一周就在“多块大屏同步显示”这件事上栽了跟头。电子看板这东西，单独做一块屏谁都能搞定，无非是前端图表加数据接口；可一旦牵扯到多屏同步，问题就从前端扩散到了数据采集、缓存分发、通讯网络和现场调试。这篇文章不聊空泛的可视化理论，只讲我从需求评审到屏上亮数，再到现场排障的完整落地过程和可复用的细节，给准备做或者正在做工厂大屏项目的朋友一个参考。

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一份，大屏有问题先对照查一遍，再决定要不要找开发。

这张表建议直接打印贴在每个工控机旁边，不管是开发人员还是车间IT，看一眼基本能定位到问题方向。

6. 交付之后的运维与扩展空间

6.1 工控机标准化设置与看门狗机制

交付给工厂后，最容易被忽略的是工控机的系统设置。如果没处理，半夜Windows自动更新重启，第二天一早大屏黑屏，车间主任准找你麻烦。我前面提过，每台工控机要做一套标准配置：关闭系统自动更新、关闭休眠和睡眠、设置开机自动启动Chrome的kiosk模式、在BIOS里设为通电自启。

但光这些还不够，建议加一层“看门狗”机制。我是用Windows的计划任务加一个简单的批处理脚本，每5分钟检查一次Chrome进程是否存在，如果不存在就重新拉起。之所以用这个方案，是因为它简单可靠，不依赖第三方软件，Windows自带的计划任务就能搞定。对于这个量级的大屏系统，够用且好维护。

6.2 内部健康状态页与远程运维

大屏系统跑到一定阶段，维护的核心不是改代码，而是快速定位故障。我给每台工控机加了一个简单的内部状态页，通过远程访问IP加端口就能打开。页面上显示几个关键信息：WebSocket连接状态、最近一次帧号、Redis连接状态、内存占用。平时不用管它，一旦有问题，车间IT远程看一眼就知道是哪一环出了异常，不用跑到现场开开发者工具。

这个健康状态页实现成本很低，后端开一个简单接口返回JSON，前端一个静态页面展示，但价值很高。有一次客户反映总览屏卡了，IT远程看到最近一次帧号停留在很久之前，立刻判断是后端推送服务停了，而不是网络问题，直接重启服务就解决了。没有这个状态页，至少得跑到机房看服务进程，处理时长翻倍。

6.3 从电子看板走向数字孪生的扩展路径

电子看板做完了，只解决了“看得见”的问题。这套架构天然可以继续扩展，因为数据已经统一进了Redis，前端可视化的能力也具备，往后的方向很多。

最直接的是从数据展示走向异常联动。比如设备报警后，除了在大屏上标红，还可以通过企业微信或短信推送给班组长；质量超标时，可以联动产线暂停。其次是接安灯系统，把工位呼叫、物料缺料等状态都纳入看板，车间管理会更完整。再往后，如果现场已经有三维模型或者点云数据，可以把大屏从前端图表升级成数字孪生场景，数据管道、同步机制、调试方法论这三块地基都是现成的，不需要推倒重来。

最后再分享一点个人体会。做工厂数字化项目，最怕的不是技术复杂，而是需求没对齐、现场没人配合。多屏同步显示听起来是个技术题，做下来你会发现，它更多是沟通题和工程题。每次开工前，先把点位表、网络拓扑、刷新频率这些基础约定写下来跟客户确认清楚，后面会省掉大量的返工。项目上线那天，我站在车间门口，看着五块屏同时跳动的数据，最大的感受是：屏上的数字是表象，真正值钱的是背后那套同步机制和调试方法，它能承载的东西，远不只是一个看板。