LED控制卡软件从单机到联网：MySQL方案实战复盘
去年有个客户找过来，说他们工厂有18块LED屏，分布在3个车间、2个仓库、1个办公楼，全部用U盘拷贝节目，人工换内容。
"最怕发紧急通知，"客户说，"比如某个批次的产品要召回，要在所有屏幕上同时显示。现在要一个人拿着U盘跑遍全厂，最快也要40分钟。"
这个问题，本质上是LED控制从单机走向联网的必经之路。今天复盘一下我们怎么用MySQL数据库方案解决这个问题。
单机版的痛点，谁用谁知道
传统的LED控制卡软件，基本都是单机版：
- 节目用U盘拷贝到控制卡
- 播放列表在本地编辑，不能远程改
- 多块屏幕无法同步，各播各的
- 播放记录存在控制卡里，要人工去拔U盘才能导出
工厂环境里，这些问题被放大：
1. 紧急通知发不出。上面说的召回通知，40分钟才能全覆盖，这40分钟里如果产线继续生产，损失就是几十万。
2. 节目更新靠人工。一个人管18块屏，每天来回跑，效率低不说，还容易漏。我们接手之前，客户有两块屏的节目过期了两周才发现。
3. 播放记录追溯不了。有块屏装在仓库，播放记录只能存在控制卡的Flash里，要查只能去现场拔U盘。客户想追溯某个通知有没有播过，完全没办法。
联网方案的技术选型
我们给客户设计的方案是：LED控制卡 + 局域网 + MySQL数据库 + 自研管理软件。
技术架构：
+———————–+
| LED控制卡（带网口） | ← 每块屏一个，通过网线接入局域网
+———————–+
↓
+———————–+
| 局域网（工业交换机） |
+———————–+
↓
+———————–+
| MySQL数据库服务器 | ← 存节目、播放列表、播放记录
+———————–+
↓
+———————–+
| 管理软件（Qt6开发） | ← 统一界面，远程更新节目
+———————–+
为什么选MySQL？
有几个原因：
1. 稳定可靠。MySQL在工业环境里跑了很多年，稳定性没得说。断电、网络闪断，都能自动恢复。
2. 支持多客户端并发。我们的管理软件可以同时有多个人登录，分别管理不同的屏幕，不会互相冲突。MySQL的锁机制保证数据一致性。
3. 播放记录可以集中存储。每块控制卡把播放记录定时上报到MySQL，管理人员在电脑上就能查，不用跑现场。
4. 成本几乎为零。MySQL是开源的，不需要额外买数据库授权。我们算过，整套方案软硬件成本比商业LED管理平台便宜60%以上。
开发中的几个技术难点
方案说起来简单，做起来坑不少。记录几个关键难点：
难点1：控制卡通信协议不统一
不同品牌的LED控制卡（灵星雨、诺瓦、卡莱特…），通信协议完全不一样。有的用TCP，有的用UDP，有的用HTTP API，报文格式更是各家自定。
我们的解法是做一层抽象：把"发送节目""查询状态""获取播放记录"等通用操作抽象成接口，不同品牌的控制卡各自实现这个接口。这样上层的MySQL和管理软件就跟具体硬件解耦了。
难点2：网络不稳定时的容错
工业现场的网络，不像办公室那么稳定。交换机偶尔重启、网线被叉车压断，都是常事。
我们的处理策略：
- 管理软件向控制卡发指令，超时3秒就重发，最多重发3次
- 如果3次都失败，标记这块屏"离线"，记录到MySQL，同时触发告警
- 控制卡端做本地缓存，网络断了也能继续播存在本地的节目
难点3：节目文件比较大，怎么高效下发
一个完整的LED节目，包含视频、图片、字幕，文件大小可能几十MB。18块屏同时下发，对局域网带宽是个考验。
我们的优化方案：
- 节目文件分块传输，每块64KB，断点续传
- 多块屏同时下发时，用组播（Multicast），一份数据流同时发给多块屏
- 控制卡收到节目后，计算MD5校验码，回传给管理软件确认完整性
实际效果
项目上线后，客户反馈几个明显改进：
- 紧急通知全覆盖时间：从40分钟压缩到90秒（在管理软件上点"一键推送"，90秒内所有屏幕都切换到紧急通知）
- 日常节目更新：从人工跑现场改为远程操作，一个人能管50块屏不费力
- 播放记录追溯：在管理软件里能查任意一块屏的任意时间段的播放记录，导出Excel一键搞定
- 故障告警：哪块屏离线了，管理软件立即弹窗提示，不用等人工发现
克杰网络的LED软件方案
克杰网络自研的LED数据库管理软件，目前已经在实际项目中验证，支持：
- 多品牌控制卡接入（灵星雨、诺瓦、卡莱特…）
- MySQL数据库统一存储节目、播放列表、播放记录
- 远程更新节目，支持断点续传和组播下发
- 播放记录自动上报，可追溯、可导出
- 离线告警，屏幕故障第一时间发现
- 多用户权限管理，不同人员分配不同操作权限
如果你工厂里也有多块LED屏，还在用U盘拷贝节目的方式，可以找克杰网络聊聊。我们不做控制卡硬件，我们做的是让您的LED系统真正联网、真正好用。
联系方式在网站底部，微信同号。