聊聊最近刚收尾的这个项目上海某制造工厂的三块车间大屏做一套可视化电子看板系统。以前车间数据全靠班组长手动报数产量、设备状态、不良率都滞后半天这次一次性部署了三块1.8米大屏分布在三个不同楼层要求每块屏侧重点不一样但又必须保证数据实时同步显示。说实话画图表本身不难真正卡人的是多块大屏同步这六个字——时间基准、推送机制、断线重连、分辨率适配全是坑。这篇全指南我不讲虚的从硬件接线、网络规划到前端大屏可视化、同步数据调试把整个落地过程完整摊开。你在做工厂可视化、电子看板或者任何需要多屏同步显示的项目这篇可以直接抄作业。1. 项目整体设计与同步方案选型1.1 需求还原同源不同屏先还原一下现场需求。工厂一共三层每层一块竖装大屏一楼大厅面向访客和领导展示总产量、设备综合效率OEE、订单完成率这类宏观指标。二楼车间面向班组长展示产线实时节拍、当前工单进度、设备运行/停机状态。三楼质检区面向质检员展示不良率趋势、缺陷TOP排行榜、抽检合格率。三块屏信息侧重完全不同但底层数据必须来自同一套生产系统——这就是同源不同屏。很多工厂项目在这里就掉坑了每块屏单独对接数采接口结果二楼和三楼看到的不良率都不一样因为两个接口的查询时间差了十分钟。我的设计原则很简单所有屏只连一个数据出口不各自对接底层设备。每块屏配一台迷你工控机大屏本身只是显示器真正的电子看板跑在工控机里。这也是目前工厂可视化看板项目的主流玩法屏是显示屏脑子是工控机后端只维护一套数据服务。1.2 同步机制选型轮询、WebSocket还是MQTT这是整个项目最核心的技术决策。我当时对比了三条路方案实现难度实时性多屏一致性适用场景前端轮询30s一次低差差各屏请求时间不同数据变化极慢的报表WebSocket长连接中好好服务端主动广播多屏实时看板、工单状态MQTT订阅中高好好设备终端多、消息频率高的IoT场景最后选了 WebSocket Redis 方案原因有三点工厂数据来源不止一个——PLC、MES接口、人工录入Excel导入不同来源写入时间不一致。中间加一个 Redis 做统一状态存储相当于一个数据汇总缓冲区避免多数据源直接怼到前端导致同一时刻各屏读到的值不一致。WebSocket 是浏览器原生支持的协议前端不用额外引库Vue项目里封装一个连接管理器就能用省去维护 MQTT broker 的负担。三块屏加上后续可能加的移动端撑死几十个连接WebSocket 长连接在这个规模下实测非常稳没有必要上更重的消息队列。这里的核心知识点是多屏同步的本质不是同时刷新而是同一时刻看到的快照必须一致。服务端先把所有客户端拿到的数据写成同一个 Redis key再整体推送给所有大屏而不是各屏自己查数据库。这一步做好了同步问题就解决了一大半。1.3 可视化设计图表是给人看的不是给机器看的可视化电子看板最容易犯的毛病是把所有图表塞进一块屏里五颜六色什么都想展示结果现场工人根本找不到关键信息。这个项目的可视化设计我遵循了三个原则一屏一主题每块屏只回答3-5个核心问题一楼回答今天卖了多少二楼回答现在哪里停了三楼回答质量行不行。大数字优先核心指标直接用超大数字展示次要信息才用图表人站在三米外也能一眼看到产量数据。配色克制冷静深蓝底 高亮色点缀避免红绿黄满天飞看久了眼睛不累。前端图表用的 ECharts它是目前做可视化大屏最成熟的开源库各种企业大屏可视化项目里几乎都是标配。像我这种场景一个折线图加两个环形图加数字翻牌器ECharts 全都能覆盖而且性能稳定。需要提醒的是ECharts 版本升级很快老项目升级要小心配置项不兼容锁定版本号是个好习惯。2. 核心细节解析与实操要点2.1 数据链路怎么搭五层架构一套典型的工厂可视化大屏数据链路长这样设备层 → 采集层 → 汇聚层 → 推送层 → 渲染层设备层PLC、传感器、MES系统、人工录入表。采集层通过串口、网口、Modbus TCP、OPC UA 等方式把设备数据取出来。这一步最杂各家设备协议不一样。汇聚层采集到的数据清洗后写入 MySQL 做持久化同时把最新状态写入 Redis。Redis 存的不是历史明细而是当前快照。推送层Node.js 写的长连接服务监听 Redis 的变更一旦有更新就把最新快照通过 WebSocket 广播给所有客户端。渲染层Vue ECharts 的大屏页面接收推送后刷新图表。这个架构最关键的巧思在汇聚层MySQL 管历史Redis 管现在。大屏显示的是现在所以前端查询接口一律走 Redis查询速度毫秒级而且因为大家读同一个 key天然保证一致。如果前端直接查 MySQL不仅要面对慢查询问题还容易出现二楼刚查到的是旧数据一楼刚查到的是新数据的尴尬。2.2 多屏同步的三个关键点时间、状态、连接多屏同步不止是推送消息那么简单实操中要抠三个细节时间基准统一。如果每块屏的工控机时间不一致就算显示的是同一份数据看板的更新时间戳也会互相矛盾。这一步看起来小但实际现场很容易被忽略——工控机重启后 CMOS 电池失效时间回到出厂值所有看板的时间戳全乱了。解决办法是部署 NTP 时间同步让所有工控机和服务器对同一台 NTP 服务器校时。状态一致性。服务端推送的不只是数值还要带一个批次号或快照ID。比如每次数据更新生成一个自增ID客户端收到推送后如果发现批次号小于当前值就丢弃旧消息。这个方法在 WebSocket 网络抖动时有奇效能避免旧消息覆盖新数据导致画面闪烁回跳。连接心跳与断线重连。大屏的工控机长期通电运行网络设备偶尔重启WebSocket 连接很容易静默断开。前端必须实现心跳检测每30秒发一个 ping服务端回 pong以及指数退避的重连机制。实测下来不加心跳的看板运行一周后总有一两块屏静默失联页面也不报错就是数据不动了加上心跳和自动重连后这个问题彻底消失。注意断线重连后一定要主动拉一次最新快照不能光等推送。因为断线期间可能错过了多条增量信息只靠重连后的第一条推送数据会缺一段时间。2.3 大屏适配与分辨率处理三块屏虽然尺寸一样但工控机显卡输出分辨率不完全相同有的设成了 1920x1080有的被系统改成了 1366x768。如果前端页面写死像素会出现图表拉伸、字被截断。我的做法是用比例缩放适配前端页面按 1920x1080 设计然后通过 JS 获取实际屏幕宽高计算出缩放比例用 CSS transform: scale() 整体缩放根容器。这种方法比写响应式布局简单得多——复杂图表密集的大屏页面逐个做响应式太费时间整体缩放虽然左右会有黑边但胜在稳定可控。如果项目预算允许更推荐的做法是用可编程的 HDMI 分配器或者带缩放功能的拼接控制器但这属于硬件方案成本高出不少。软件缩放对于工厂车间场景已经完全够用。3. 实操部署与调试全流程3.1 硬件环境与网络规划这个项目用到的硬件3台迷你工控机i3处理器、8GB内存、128GB SSD分别驱动三块大屏。1台服务器/工控机跑数据采集、Redis、Node.js 推送服务。1台千兆交换机把服务器和所有工控机组成局域网。若干六类网线全走有线不用WiFi——车间里电焊、变频器干扰多WiFi 在大屏这种持续占用带宽的场景下不稳定。网络规划直接在交换机上做静态 IP设备IP地址说明数据采集/推送服务器192.168.1.20跑Redis Node.js服务一楼工控机192.168.1.101大厅看板二楼工控机192.168.1.102车间看板三楼工控机192.168.1.103质检看板NTP时间服务器192.168.1.30或直接用推送服务器兼任这里建议所有设备关掉 DHCP全走固定IP。因为看板系统依赖工控机自动启动浏览器并访问固定地址如果IP变了页面就白屏了现场没有人天天去改配置。3.2 服务端推送与前端渲染核心代码推送服务用 Node.js 实现核心逻辑分三块WebSocket 服务、Redis 读取、定时广播。贴一段简化但可直接运行的代码// server.js const WebSocket require(ws); const Redis require(ioredis); const redis new Redis({ host: 192.168.1.20, port: 6379 }); const wss new WebSocket.Server({ port: 8080 }); // 客户端连上后先推一次最新快照 wss.on(connection, async (ws) { const snapshot await redis.get(dashboard:snapshot); if (snapshot) { ws.send(JSON.stringify({ type: snapshot, data: JSON.parse(snapshot) })); } }); // 每5秒从Redis取最新快照广播给所有客户端 setInterval(async () { const snapshot await redis.get(dashboard:snapshot); if (!snapshot) return; const message JSON.stringify({ type: update, ts: Date.now(), data: JSON.parse(snapshot) }); wss.clients.forEach((client) { if (client.readyState WebSocket.OPEN) { client.send(message); } }); }, 5000);前端页面用 Vue ECharts核心是封装一个 WebSocket 管理器// useDashboardSocket.js export function useDashboardSocket(url) { const socket new WebSocket(url); let heartbeatTimer null; function connect() { socket.onopen () { // 连接建立后每30s发心跳 heartbeatTimer setInterval(() socket.send(ping), 30000); }; socket.onmessage (event) { const msg JSON.parse(event.data); if (msg.type update || msg.type snapshot) { // 更新Vue响应式数据 updateCharts(msg.data); } }; socket.onclose () { clearInterval(heartbeatTimer); // 指数退避重连5s起步最多60s setTimeout(connect, Math.min(60000, 5000 * Math.pow(2, retryCount))); }; } connect(); }一定要在后端写入 Redis 的位置加一个日志输出调试期间这是最直接的排查依据。实际项目中数据写入 Redis 用的是 Python 脚本从 PLC 采集到数据后组装成 JSON再redis.set(dashboard:snapshot, json.dumps(payload))。这个脚本我会在下文调试章节详细说。3.3 调试工具实战串口/网口助手与浏览器调试工厂里的设备调试离不开两样工具——串口调试助手和网口调试助手。这两样是这个项目的调试主力。串口调试助手用在与 PLC 通过 RS485 对接的场景。当时调试一台老型号 PLC通信参数设为 9600 波特率、8 数据位、1 停止位用串口助手发 Modbus RTU 报文直接能看到 PLC 返回的原始字节发送: 01 03 00 00 00 02 C4 0B 接收: 01 03 04 00 00 02 58 3B 44如果接收到的数据是乱码先从波形和字节流排查波特率对不对校验位是不是无校验线是不是 A/B 接反了。串口调试里 90% 的问题出在这三点而不是程序逻辑。网口调试助手用来测支持 Modbus TCP 的设备。当时一台新设备的通信地址不确定用网口调试助手直接建 TCP 连接发 Modbus 报文探路比写程序调试快得多。网口调试助手的另一个妙用是本地起一个假的 TCP 服务验证采集脚本连接逻辑不用每次都跑到车间设备跟前。浏览器开发者工具在前端阶段非常好用。WebSocket 的帧在 Network 面板里能看到断线重连、消息间隔一目了然。前端有任何报错Console 面板立刻能看到。多块大屏联调的时候我习惯在每台工控机上打开同一个监控页面三台工控机并排开三个浏览器窗口同时盯着数据变化判断同步是否正常。3.4 Redis 状态验证与可视化工具前面提到 Redis 存的是当前快照调试期间必须确认这个 key 在实时更新。直接用命令行比较原始redis-cli -h 192.168.1.20 GET dashboard:snapshot但现场用命令行不够直观我用了一个 Redis 可视化管理工具能看到所有 key 的列表和 TTL还能直接编辑 JSON 结构。这个工具在处理复杂嵌套数据时特别好用——前端报读不到字段打开工具看一眼 Redis 里存的结构立刻知道是 key 打错了还是层级不对省掉了来回打印日志的功夫。经验分享工厂项目上线初期一定要保留数据回放的后悔药能力。我在推送服务里加了一个简单的文件日志每5秒记录一次快照内容。一旦现场反馈看板数据不对翻日志就能定位是采集错了、Redis 里写错了还是前端渲染错了三个环节十分钟内就能分清责任。4. 常见问题与排查技巧实录4.1 屏与屏数据差了几秒上线第一天就遇到这个问题一楼和二楼的数据总差五六秒三楼有时候干脆停更。排查过程走了不少弯路最终定位是浏览器标签页后台限流——工控机的浏览器因为长期无操作被系统判定为后台标签页JS 定时器被降频WebSocket 心跳其实还在但渲染节流导致页面不刷新。解决办法很粗暴给工控机装了一个让浏览器保持前台模式的工具或者直接把页面做成 Kiosk 模式全屏运行。另外数据推送间隔从 5 秒改成 3 秒减小每次推送的数据量双管齐下后三块屏的数据偏差降到了 1 秒以内。4.2 大屏白屏和闪电断连第二周三楼看板出现白屏重启浏览器又恢复但过几小时又白屏。排查时先看了推送服务日志发现三楼工控机的 WebSocket 连接在反复断开重连但其他屏正常。后来去现场看工控机发现它接的是车间同一个插线板旁边有台大功率设备一启动电压浪涌就导致网卡短暂掉线。换成 UPS 供电并加装了一个工业级交换机后问题再没出现。工厂现场的硬件环境永远比你想的恶劣电磁干扰、电压不稳都是隐形杀手。4.3 设备数据乱码与幽灵数据对接到一台变频器数据时串口调试助手收到的报文时而正常时而乱码。用网口调试助手做对比测试发现故障只在现场那根 20 米长的 RS485 线路上出现。这属于典型的信号反射问题——没有加终端电阻而且屏蔽层没有单端接地。加了 120Ω 终端电阻后乱码消失。另外提醒一句RS485 的屏蔽层只能一端接地两端接地反而会形成地环路干扰这是新手很容易踩的坑。4.4 排查速查表把这次调试遇到的坑整理成表方便现场快速对照现象优先排查方向常见原因多屏数据不一致时间基准、推送频率工控机时间没同步、推送间隔太长某块屏白屏/断连网络、供电网线松动、电压浪涌、后台标签节流串口数据乱码参数、接线波特率不对、A/B反接、缺终端电阻页面图表长时间不更新Redis key、WebSocket连接数据写入脚本挂了、心跳丢失显示值偶尔回跳消息顺序旧推送覆盖新数据缺批次号过滤显示器拉伸变形分辨率适配页面固定像素未做缩放适配5. 扩展应用与落地心得5.1 从看板到数据库同步对接更多业务系统看板上线后工厂发现这套同步机制不仅能显示设备数据还能把 MES 系统的工单进度、ERP 的订单信息一起同步展示。这就需要把业务系统的数据库同步到可视化服务的数据库中来。最开始我试过定时任务直接跨库查询但业务库压力大查询一多就锁表。后来改用了数据库同步工具把业务库里的关键表增量同步到看板系统的本地库再做二次加工。这样看板系统完全不依赖业务系统的实时接口业务库也不会被看板查询拖垮。如果你要对接的系统和看板系统不在同一个网段数据库同步软件几乎是必选项。5.2 移动端与领导驾驶舱扩展三块大屏稳定运行后工厂提出新需求领导在外面出差也想看数据。方案很现成——同一个 Node.js 推送服务再加一个移动端适配的页面手机浏览器访问同一个地址就有简化版的看板。因为底层数据源完全一样移动端和大屏端天然同步不用再做任何额外工作。很多可视化项目走到这一步都会顺理成章扩展成领导驾驶舱——用手机、平板、办公室电脑都能访问的一整套数据可视化系统。核心就是把数据源和服务端做强换前端皮肤只是工作量问题。5.3 车间跑了半年后的一些维护建议项目交付半年我回访过两次总结几条落地后的维护要点工控机硬盘是易耗品建议 SSD 选工业级或至少带掉电保护车间意外断电频繁普通固态容易掉盘。大屏长期显示静态画面会有烧屏风险建议设置屏保或者每半小时切换一次背景图LED屏这个问题少但普通液晶拼接屏很常见。Redis 的 key 建议加过期时间比如快照 key 设24小时过期防止数据写入脚本停了之后前端还在展示昨天的假数据。这次项目就遇到过脚本挂了三天没人发现大屏上的产量数字一直停在三天前管理人员还以为数据是真的。把调试工具都留一套在现场工控机上包括串口调试助手、网口调试助手、Redis可视化管理工具和浏览器控制台快捷方式——现场维护的人不一定是你但工具齐全能帮他们少走很多弯路。我个人在实际操作中最深的体会是多块大屏可视化的技术难度并不高真正的复杂度全部来自工厂现场的不确定性。网络忽好忽坏、电压忽高忽低、浏览器自动更新、Windows 半夜自动重启——这些日常开发中根本不会注意的细节在车间环境里全都会变成事故。所以做这类项目别只顾着写代码和画图表多花时间在硬件稳定性、断线重连、异常自恢复这些不起眼的地方。看板系统能百分之九十的时间在线稳定运行比任何炫酷的可视化效果都重要。最后再分享一个小技巧所有工控机的浏览器主页锁定为看板地址并设置开机自启浏览器。配合 Windows 计划任务每天早上打卡前页面已经自动加载好。对于工厂用户来说他们不需要知道什么是 WebSocket也不用学怎么打开浏览器他们要的就是走到大屏前数据就在那——这才是电子看板项目落地的最终标准。