做工厂的电子看板项目很多人第一反应是“不就是一堆图表嘛”等真正接手就会发现最磨人的不是图表画得漂不漂亮而是“多块大屏同步显示”这六个字。上个月我做完一个上海汽车零部件工厂的可视化电子看板项目车间正中央一组4块55寸屏拼成的显示墙实时刷产量、设备OEE、报警、能耗这几路数据前后干了两周半写页面只用了一周剩下的时间全耗在数据采集、多屏同步和现场调试上。我直接把这套项目的完整拆解思路、技术方案、关键代码和踩坑记录摊开讲给准备做同类工厂大屏的朋友一份可以直接参考的落地指南。这类项目有一个很常见的坑客户说“要同步显示”但他心里想的“同步”和工程师理解的“同步”很可能是两码事。所以我不急着讲代码先讲需求拆解再讲技术选型最后一步步讲调试和排障。如果你正在为车间大屏项目头痛按这个顺序走一遍能少走很多弯路。1. 项目背景与需求拆解1.1 这块看板到底展示什么客户是上海一家做汽车零配件的工厂车间里注塑机、压铸机、CNC加工中心加起来二十多台原来车间管理层要看生产进度得跑到电脑前翻MES报表或者让统计员定时去抄数。这次他们想在大厅和产线通道装一组屏把关键生产数据滚动展示出来让现场人员一抬头就知道当前设备状态和产量。物理环境是这样的车间正中间一面2×2的55寸拼接屏墙另外在车间的东侧和西侧各有一台独立大屏。数据内容我最终梳理成五类设备状态运行/待机/报警、当日产量与班次目标达成率、各线体OEE实时值、设备报警列表、车间温度与能耗趋势。这五类数据听起来简单但每一类背后的数据来源和处理方式都不一样。产量和OEE可以从MES或者PLC里取报警要单独轮询PLC的诊断缓冲区能耗则要看电表走的是什么协议。这个阶段最忌讳的是上来就画原型。我用了两天时间拉着客户的生产主管和设备维护工程师一起过了一遍数据清单每一条都明确标注“数据从哪个PLC读”“字段类型是什么”“更新频率要求多少”。后来调试期一半的故障定位靠的都是这张确认过的数据清单。1.2 “同步”其实是两种完全不同的需求客户说“要同步显示”我建议你把这里的“同步”拆开看。第一种是画面复制式的同步多块屏显示完全一样的画面比如电视墙播同一个宣传片这种要的是把一份视频信号分发到多个屏。第二种是数据一致性的同步每块屏布局可以不同但展示的底层数据必须是同一份不能出现左边屏幕产量显示1000、右边屏幕显示999这种尴尬。现在做的这个项目两种需求同时存在拼接墙本身是4块物理屏拼成一个大画面属于第一种车间东西两侧的独立大屏布局不同、展示模块不同但数据必须和拼接墙完全一致属于第二种。技术上要把两件事分开处理拼接墙的拼接由显卡和拼接控制器完成数据一致性则由一套统一的数据推送机制解决。如果需求阶段不把这个区别逼出来后面十有八九会选错方案。我们当时跟供应商确认过拼接墙支持直连模式才敢放心走“多个浏览器窗口 同一套数据服务”的路线。1.3 需求阶段必须问清的三个问题接这类项目我固定要问客户三个问题每个问题都能直接淘汰掉一批错误方案。第一数据从哪来。有没有现成的MES数据库、上位机组态软件还是数据都躺在PLC里如果有PLC点位表点位表是不是最新的、有没有人维护很多老工厂的设备是不同年代买的有的西门子、有的三菱、有的走Modbus没有一份统一的点位表后面联调就是灾难。第二谁会看、看什么。产线班组长盯着的是当班产量和报警车间主任看重的是OEE和设备利用率厂长可能更关心整体趋势。视角不同大屏上的信息层级和布局重心就完全不同。这个项目我们把产量和OEE放在第一屏最显眼的位置报警列表放在右下角就是这个逻辑。第三断电断网之后怎么办。工厂晚上断电、节假日关机非常正常客户希望第二天上班一启动大屏能自己恢复吗还是接受人工去点一下这决定了你要不要做开机自启、看板守护脚本、服务端自动重启这些额外功能。这个项目客户明确要求“开机自己恢复”后来我在自启脚本上花的时间比写页面还多。2. 系统架构与技术选型2.1 数据链路整体设计我最后落地的链路是这样的车间设备层PLC、电表、传感器→ 采集层一台Linux工控机上的Python采集脚本→ 缓存层Redis→ 推送层Node.js WebSocket服务→ 展示层各块屏上的Chrome浏览器全屏页面。为什么中间要插一层Redis而不是采集脚本直接推给浏览器因为采集脚本和展示端是不同生命周期的程序采集脚本要不停适配PLC协议展示端要不停改布局和图表两者耦合在一起任何一边改动都要重新部署整套系统。用Redis做中转后采集脚本只负责把数据写进Redis推送服务只负责定时从Redis读数据并广播给前端各管一段。另一个原因是调试方便Redis有现成的可视化管理工具打开就能看每个键的值在不在变比对着黑窗口敲命令高效太多。前端展示层每块屏是一个独立的浏览器窗口理论上这些窗口可以分布在不同机器上也可以像这次一样集中在同一台工控机上用显卡多输出。多窗口的好处是某块屏卡死了不会带崩其他屏重启某一屏只需要关掉那个窗口重新打开。2.2 PLC数据采集协议与寄存器细节设备层里西门子S7-1200居多我用的是python-snap7这个库直接走S7协议读取不需要额外买网关硬件。连接参数里有几个容易踩坑的地方S7-1200的机架号一般是0槽号一般是1填错就会连接报错读取DB块数据用db_read比如读DB1从偏移0开始的4个字节返回的是原始字节数组。西门子的多字节数值默认是大端存储读到一个DInt类的数据直接拿struct.unpack(i, data)解包才对。这个细节我们开始没注意读出来的产量数值翻了好几倍绕了好大一圈才发现是字节序问题。之前排查的时候把责任都推给点位表结果点位表没背这个锅锅在自己代码里。老设备里有几台走Modbus TCP联调时我用网络调试助手先手动发报文验证寄存器地址再写采集逻辑。Modbus协议里寄存器地址和厂商点位表里的地址经常有偏差比如点位表写“保持寄存器40001”实际报文里对应的地址却是0。这类偏差只能现场对着一台运转中的设备反复读、反复看数值变化不能光看文档。还有一个经验核对点位时间最好选在工厂午休或者设备批量开动的时段因为有些寄存器是设备开机运行才有数值变化停机时读出来全是0容易让人误判成地址填错。2.3 Redis WebSocket数据缓存与广播通道采集脚本把每个点位写进Redis键名按“产线:设备:属性”的规则设计例如production:line1:output、equipment:press1:status。推送服务每隔2秒从Redis把所有键聚合成一个JSON快照然后通过WebSocket广播给所有在线客户端。快照设计成完整状态而不是增量消息这是一个关键决定——客户端中途断线重连后下一个推送周期自动就能追平到最新状态不需要补发历史消息。WebSocket服务端核心逻辑很简单const WebSocket require(ws); const { getSnapshot } require(./snapshot); const wss new WebSocket.Server({ port: 8080 }); setInterval(() { const snapshot getSnapshot(); const payload JSON.stringify(snapshot); for (const client of wss.clients) { if (client.readyState WebSocket.OPEN) { client.send(payload); } } }, 2000);为什么推送比HTTP轮询更适合多屏同步因为轮询模式下每块屏到达服务器的时间点不一样哪怕数据值相同屏幕上数字变化的瞬间也会错开给人“没同步”的感觉。WebSocket是服务端在同一时刻把同一份数据推给所有客户端各屏拿到的完全一样同步感会明显好很多。要细究的话各客户端渲染还需要一点时间差但局域网内这个差值在毫秒级肉眼分辨不出来。2.4 可视化前端Vue ECharts 搭配细节前端选了Vue 3做框架ECharts 5做图表。大屏页面的边框、标题栏这些装饰性组件不用完全自己写DataV的开源组件库基本够用能省不少时间。页面按1920×1080设计每块屏独立一个页面页面内部用Grid布局按比例划分模块不要直接做一张3840×2160的大图再整体缩放那样字体和曲线会发虚。刷新性能上有两个细节值得单独说。一是动态图表的setOption要传true作为第二个参数也就是notMerge模式避免旧数据和残留动画造成闪烁二是实时刷新的图表建议直接关掉入场动画不关的话每隔2秒图表重播一次动画整面墙看起来像在不停抽动长时间盯屏眼睛很难受。折线图、柱状图这类高频更新的图我统一设置animation: false只在页面初始加载时让它动一次。拼接屏还有一个布局上的经验不要设计横跨两块物理屏的图表。拼接墙中间有一道物理缝隙折线图或柱状图从缝隙穿过去画面会被生生切断非常难看。我最后所有图表都严格落在单块屏的范围内宁可多分几个模块也不做跨屏元素。3. 多屏同步显示的实现方案3.1 先分清数据同步还是画面同步上一节说的两种“同步”在技术实现上分道扬镳。数据同步讲究的是各屏拿到的值一致、刷新节奏一致核心靠一个“中央消息源”广播给所有人画面同步讲究的是像素级一致要么用HDMI分配器把一份画面复制到多个显示器要么用视频流让所有终端看同一路画面。做方案的时候先回答一个问题如果一块屏上的产量数字变了其他屏上的数字要不要在同一瞬间变答案如果是“要”那你需要的是数据同步如果客户说“我只要大家看到的内容一模一样就行管他什么数据”那可能视频流或HDMI分配器更省事。这里最怕的是把需求理解反前期辛辛苦苦做了数据推送最后客户说我要的是所有屏都播同一个3D车间漫游画面那就得返工。我在这个项目里也跟客户确认过拼接墙的画面是各屏显示不同模块组成整体还是所有屏显示同一个数字大样最终确认是前者所以拼接墙走“独立浏览器 独立页面布局”整体视觉上像一整面墙但每块屏的页面内容是独立的。3.2 方案AWebSocket广播加本地渲染刚才提到推送服务对应到前端就是每块屏的浏览器连同一个WebSocket地址收到快照后各自渲染自己的图表。这是本项目的主方案。前端核心逻辑只有几行const ws new WebSocket(ws://192.168.1.200:8080/ws); ws.onmessage (event) { const snapshot JSON.parse(event.data); outputChart.setOption({ series: [{ data: [snapshot.production.line1.output] }] }, true); oeeChart.setOption({ series: [{ data: [{ value: snapshot.oee.line1 }] }] }, true); };因为服务端广播的是完整快照所以所有客户端拿到的数据永远来自同一个来源、同一个时间点。前端要做的只是把快照里的值“塞”进各自对应的图表里。布局上东侧屏可以只展示产量和报警西侧屏只展示OEE和能耗拼接墙展示全部但底层用的都是同一个snapshot对象数据天然一致。前端还要写心跳和断线重连。车间环境会断电第二天早上的开机顺序可能是屏幕先亮、服务器后起如果浏览器页面不主动重连客户就只能看到一块白屏。重连逻辑建议用指数退避第一次1秒后重试第二次2秒第三次4秒最多到30秒避免服务器还没恢复时几十个客户端疯狂重连把它砸垮。3.3 方案B视频流整屏推流视频流方案适合什么场景当显示终端是智能电视、专用播放盒没法跑网页的时候或者画面必须逐像素一致比如同一个3D效果图、一段宣传片。技术上可以用FFmpeg采集一个页面再通过WebRTC或HLS推给所有屏所有屏播放同一路流天然同步。我这次没有选视频流。第一数据看板的指标是要秒级刷新视频流再怎么优化也有几百毫秒编码传输延迟产量数字会“慢半拍”第二视频流的运维复杂度明显更高编码器挂了、码率不够花屏、客户端解码卡顿哪一个都会变成新的故障点。对工厂数据看板这种场景网页本地渲染永远是我的第一选择视频流只作为无法部署网页环境时的兜底方案。3.4 时间校准NTP配置与验证数据同步解决了还有一个隐藏问题看板页面上要显示“当前时间”还要给报警列表打时间戳如果各台客户端机器的系统时间漂移了几秒钟那不同屏上显示的“现在时间”就对不上拍验收照片时非常尴尬。解决方案是局域网里搭一台NTP服务器直接复用那台Linux采集服务器装chrony并开放ntp服务。Windows端用命令手动校时w32tm /config /manualpeerlist:192.168.1.200,0x1 /syncfromflags:manual /update w32tm /resync校时之后再用计划任务每小时执行一次w32tm /resync防止系统时间缓慢漂移。验证方法很简单做一个只显示当前时间的页面同时在四块屏上打开拍照对比NTP配置正常的话各屏时间差在几十毫秒肉眼完全看不出差别。3.5 刷新频率与数据量的参数核算客户问“你们这个看板多久刷新一次”不能只回一句“实时”现场验收时得有工程依据。我按这个项目实际规模算过一笔账活动点位大概200个聚合成一个JSON快照大约10到15KB每2秒广播一次单个客户端平均带宽约7.5KB/s。现场最多8个显示终端总带宽60KB/s左右千兆局域网的负载连1%都不到。瓶颈完全不在带宽而在前端渲染效率和服务端聚合快照耗时这两项在2秒周期下也都是毫秒级操作整条链路余量非常充足。刷新间隔我定的是2秒。为什么不设1秒因为工厂里多数统计指标产量、OEE在秒级的变化量本身就很小1秒刷新只是白白增加渲染压力还容易造成视觉疲劳。设备状态这类实时性敏感的数据可以单独走1秒通道趋势类统计算5秒一次。把“哪些数据按什么频率刷新”在前期就定清楚后面做前端时不会乱。4. 调试落地的完整流程4.1 第一轮先把单屏的数据链路跑通调试顺序很重要不要一上来就把四面屏全点亮出了错都不知道该查哪一段。我的做法是先拿一台笔记本连到局域网单独打开一块屏的页面把“PLC → Redis → WebSocket → 前端图表”全链路跑通再做多屏并行。具体步骤是这样第一步核对PLC点位表确认每台设备的IP、DB号和偏移地址第二步用网络调试助手或Modbus Poll手动发报文验证能读到正确数值第三步跑采集脚本打开RedisInsight逐键检查数据是否在更新第四步打开单屏页面看图表刷新是否正常第五步记录一次端到端延迟从PLC读到数值到浏览器显示实测一般小于1秒作为后面验收的基线。这一轮我踩了一个很典型的坑snap7连不上西门子PLC报错信息看起来像网络问题我甚至用ping和端口扫描查了半天后来翻示例代码才发现是机架号和槽号填错S7-1200要填0, 1。说起来都是细节但现场调试时这种低级问题最容易卡住进度因为你不会第一时间往“参数填错”这个方向想。4.2 第二轮多屏并行与误差测试单屏链路通了以后把所有显示终端接进局域网登录同一套看板页面。这一步要把所有客户端的系统时间先校一遍然后做“数据同步误差测试”把数据源停掉让画面停在最后一个快照上然后同时看各屏显示的值是否完全一致。如果所有屏都停了同一个数说明数据同步是通的。接下来验证刷新节奏。手机拍两张相隔2秒的照片对比各屏上的产量数字变化是否在同一节奏上。如果发现明显错位第一嫌疑是某台机器的CPU或GPU占用过高导致浏览器主线程卡顿消息收到但渲染慢了第二嫌疑是浏览器后台限频Chrome在非活动标签页会限制定时器和动画帧率。大屏机器不应该让Chrome长时间处于后台或未聚焦状态要用全屏Kiosk模式跑并且把相关限频策略关掉。4.3 第三轮72小时稳定性验证工厂大屏是7×24小时运行的不能调好当天没问题就上线。我给自己定了一个硬性标准连续运行72小时无白屏、无自动退出、无内存持续暴涨才算通过验收。稳定性验证要重点盯三件事。第一件是浏览器内存曲线在页面里嵌入一个调试信息条用performance.memory实时显示内存占用连续观察是否持续增长。ECharts图表实例如果反复创建不销毁内存会像温水煮青蛙一样涨上去一两周之后浏览器必然卡死。第二个是设备重启恢复我模拟过同时断电服务器和一台客户端再按顺序恢复供电验证开机自启和WebSocket自动重连是否正常。第三是WebSocket连接状态如果方案用的是HTTP轮询服务器端会积累大量TIME_WAIT连接时间长了端口资源耗尽新连接就进不来WebSocket长连接方案也要通过netstat定期观察连接数确认没有异常堆积。服务端我配了systemd服务设置Restartalways不管进程怎么退出都会自动拉起。客户端开机自启用一个批处理脚本延迟30秒等待网络和服务器就绪再用Chrome的Kiosk模式打开看板URL放全屏批处理放到Windows启动文件夹里基本能做到无人干预自动恢复。4.4 分辨率、拼接与信号线适配拼接墙部分工控机上插了两块显卡共4个HDMI输出Windows下设置成扩展桌面。关键点是每个浏览器窗口独立全屏到对应的那一块屏上而不是把浏览器窗口直接拖成4K大小跨四块屏。窗口跨屏后拼接缝会挡在页面正中间布局怎么排都是歪的。独立窗口各自全屏后再通过拼接控制器做边缘校正视觉上才是一整面墙。信号线这块是个隐藏大坑。超过10米的HDMI普通铜芯线经常出现闪屏、黑屏、分辨率自动降低的问题。我们现场有一根12米的线第一天验收时第三块屏间歇性黑屏换线之前排查了显卡驱动、拼接控制器、分辨率设置一堆东西最后问题落在线上。后来超过10米统统换成光纤HDMI线或者走HDMI转Cat6的延长器再没出过闪屏问题。线材成本多不了多少但能省掉大量排查时间。5. 常见问题排查实录与工具清单5.1 高频故障速查表把现场踩过的坑整理成表格方便后续维护人员快速定位故障现象常见原因排查与解法各屏右上角时间不一致系统时间漂移未配置NTP统一NTP服务器每小时强制校时数据刷新节奏参差不齐某台机器CPU/GPU占用高浏览器被限频查看任务管理器关掉无用程序用Kiosk模式跑某块屏白屏或黑屏显卡输出异常HDMI线过长或接触不良换光纤HDMI线检查显卡多屏输出设置PLC数据全部为0访问权限未开放机架槽号参数错误用snap7单独连接测试检查DB号和偏移寄存器数值明显偏大字节序不对西门子大端数据按小端解了用struct.unpack(i)大端解包图表刷新出现残影setOption未用notMerge模式动画重复播放统一加true参数实时图表关闭动画浏览器内存持续增长ECharts实例反复创建不销毁用单例管理图表实例无用实例及时dispose重启后看板没自动出现自启脚本失败或者时序太早脚本延时30秒加日志确认执行状态5.2 几个印象深刻的故障复盘第一个是字节序。读西门子S7-1200的DInt变量用Python的struct.unpack(i)去解产量数值翻了好几倍。排查的时候一开始怀疑是点位表给错地址后来把原始字节打出来一看发现高字节在前改成i就正常了。这个故障的教训是拿到PLC原始数据后第一步先看字节序和数据类型别急着套业务逻辑。第二个是DB偏移地址。点位表上写“DB1.DBX0.0”指的是DB1里的一个布尔位我一开始按字节整块去读读出来的数据串位了。后来逐点位核对发现有的点位是字对齐、有的是位对齐必须严格按点位表给的偏移和类型来读。这也是为什么我之前坚持要先拿到一份最新的点位表没有点位表硬调试效率会低很多。第三个是拼接控制器和显卡驱动打架。2×2拼接墙的控制器默认输出一种跨屏模板Windows那边识别成一个巨大的虚拟桌面浏览器窗口全屏后经常跑到错误的位置。最后我在显卡驱动里把四路HDMI输出改成各自独立扩展模式拼接画面由拼接控制器统一处理两边职责分清之后才稳。这个教训是拼接墙调试前先确认“拼接的活到底由谁干”要么显卡拼、要么控制器拼两边同时开工必然出问题。5.3 实用的调试设备与工具清单最后整理一份现场调试常用的工具清单都是这次项目实际用过的网口调试助手 / 网络调试助手验证Modbus TCP报文、测试WebSocket连接串口调试助手处理RS485/RS232协议的PLC网关和电表Modbus Poll模拟Modbus主站逐个验证从站寄存器地址和数值Wireshark抓包看TCP重传和WebSocket帧排网络层问题特别好用RedisInsightRedis可视化管理工具逐个键查看实时数据比命令行直观太多python-snap7西门子S7系列PLC的存取库配合struct处理字节序Chrome Kiosk模式全屏无地址栏跑看板防止员工误操作计划任务 批处理客户端开机自启配合延时等待网络就绪做这类工厂大屏项目从需求调研到验收来回磨的时间往往比写代码还长但真正让客户认可你的反而不是图表做得多炫而是“连续开了一星期不出问题”。多屏同步的功夫全在看不见的地方——数据源可靠性、重连机制、时钟校准、线材质量。我在这项目里把每个环节都过了一遍之后再去接类似需求心里基本有了一张明确的清单先问同步含义再定数据链路最后抓时钟和重连。希望这份整理也能帮你少踩几个我踩过的坑。