1. 从一块屏到一面墙上海工厂看板项目的真实起点去年秋天我接到一个活儿上海郊区一家做汽车水冷板的制造厂车间里要上电子看板。需求听起来不复杂产线上挂几块大屏实时显示产量、节拍、不良率、设备状态数据从MES里来。但真正到现场一看问题比想象的多——车间已经有四块LED单色屏两块是老的灵信控制卡两块是后来换的国产异步卡还有一块液晶电视挂在办公区走廊另外老板办公室里想再放一块同步显示的屏。五块屏三种硬件两个品牌的控制卡数据源是同一套MES但刷新频率、显示内容、字体大小全都不一样。这种场景在制造业里太常见了。很多工厂上电子看板不是一次性规划好的而是先上一块试试好用再加一块结果就是硬件五花八门协议各说各话。我见过最夸张的一个厂车间里七块屏四套不同的控制软件每次改显示内容要开四个远程桌面。所以这篇文章我想把上海这个项目的完整落地过程拆开讲——从需求梳理、硬件盘点、数据链路设计到NTP时间同步、多屏内容分发、MES接口对接再到调试阶段踩过的坑全部按实际发生的顺序写出来。如果你正在做工厂可视化看板或者准备做这篇内容应该能帮你少走至少两周弯路。先说清楚这个项目最终交付的形态五块屏其中三块LED屏两块P10单色、一块P4全彩显示产线实时数据一块液晶电视显示车间综合看板一块办公区大屏显示当日汇总。所有屏幕的数据来自同一个MES数据库通过一台工控机做数据中转和分发刷新周期统一为10秒时间基准由厂内NTP服务器提供。整套系统没有用任何商业看板软件全部是自研的轻量级服务跑在Windows工控机上用C#写的。为什么不用现成的商业软件后面会详细说。2. 需求拆解工厂到底要在屏幕上看到什么2.1 车间现场和办公区看的是两回事很多人做看板容易犯一个错误把所有数据都往屏幕上堆。我在项目启动会上问车间主任你最想在看板上看到什么他想了半天说产量。再问还有呢他说没了产量最重要。但办公区的生产经理要看的就多了当日计划完成率、各产线节拍对比、不良率趋势、设备稼动率。这两个场景的需求完全不同。车间现场的看板核心原则是三米之外能看清五秒之内能看懂。工人站在产线旁边抬头看一眼要知道现在做了多少、还差多少、有没有异常。所以车间屏上只放三样东西当前产量、目标产量、达成率。字体要大颜色要醒目异常状态要闪。办公区的屏就可以放更多信息因为看的人有更多时间停留也有分析需求。这个项目里三块LED屏分别挂在三条产线的线头位置显示各自产线的实时产量和达成率。液晶电视挂在车间入口显示三条线的汇总对比。办公区大屏显示当日全厂汇总和不良率趋势。每块屏显示什么内容在需求阶段就定死了后面不再改。这一点很重要——看板内容一旦上线改一次就要重新调试一次所以前期一定要让所有利益相关方确认签字。2.2 刷新频率不是越快越好MES里的数据更新频率其实不高产量数据一般是每完成一个工单或者每过一道工序才更新一次不良率数据是质检录入后才变。所以看板刷新频率定在10秒完全够用。我见过有的项目非要做到1秒刷新结果MES数据库被查询拖垮看板上的数字还因为缓存问题跳来跳去。这里有个经验看板刷新频率应该略低于数据源的实际更新频率。如果MES平均30秒才更新一次数据看板10秒刷一次就够了没必要更快。而且刷新频率越低对网络和数据库的压力越小系统越稳定。这个项目最终定的是10秒实测下来MES那边完全没有压力。2.3 异常状态怎么显示工厂看板最核心的价值不是显示正常而是暴露异常。正常生产的时候没人看屏出问题的时候屏上必须一眼能看出来。所以异常状态的显示逻辑要单独设计。这个项目里定义了三种异常产量落后计划超过10%、不良率超过阈值、设备停机超过5分钟。三种异常对应三种颜色和闪烁方式车间主任在办公室就能通过液晶电视看到哪条线出了问题。异常判断的逻辑放在数据中转服务里做不放在MES里。为什么因为MES是生产系统不应该被看板的业务逻辑污染。中转服务从MES读原始数据自己算达成率、自己判断异常然后把最终要显示的内容推给各块屏。这样MES那边只需要提供一个只读的数据接口不需要做任何改动。3. 硬件盘点LED屏、控制卡和那块被忽略的液晶电视3.1 LED屏和控制卡的对应关系这个项目现场已有的四块LED屏控制卡情况如下屏幕位置屏体规格控制卡品牌通信方式是否支持多区域一线线头P10单色灵信网口支持二线线头P10单色灵信网口支持三线线头P4全彩国产异步卡网口支持车间入口P10单色国产异步卡串口不支持灵信的控制卡在制造业里用得很多它的SDK比较成熟C#可以直接调用。国产异步卡那两块就比较麻烦一块支持网口但协议不公开另一块只有串口而且不支持多区域显示。所以这个项目的硬件策略是能复用的复用不能复用的换掉。三线那块P4全彩屏换了灵信的控制卡车间入口那块P10因为只显示汇总数据用原来的串口卡也能凑合但后来发现串口通信不稳定最终还是换了。这里有个坑要提醒LED屏的控制卡和屏体是分开的换控制卡不一定需要换屏体。很多工厂以为换控制卡就要换整块屏其实只要屏体的接口定义和控制卡匹配单独换卡就行。这个项目换了两块控制卡每块卡的成本不到一千块比换整块屏便宜太多了。3.2 液晶电视和办公区大屏怎么接入液晶电视和办公区大屏本质上就是显示器接入方式比LED屏简单得多。液晶电视通过HDMI线接了一台小主机小主机上跑一个浏览器全屏页面页面定时从数据服务拉数据。办公区大屏也是同样的方案只不过屏幕更大分辨率更高。这种方案的好处是内容可以用HTML/CSS做排版灵活改起来方便。LED屏那边就麻烦得多灵信的控制卡虽然支持多区域但每个区域的字体、颜色、对齐方式都要通过SDK设置没有HTML那么自由。所以这个项目里LED屏显示的是最核心的数字液晶屏显示的是更丰富的图表和列表。3.3 工控机的选型数据中转服务跑在一台工控机上配置不高i5处理器、8G内存、256G固态硬盘、双网口。双网口很重要——一个网口接车间内网连LED屏和MES一个网口接办公网连液晶屏和办公区大屏。为什么要分开因为车间内网的稳定性和安全性要求更高不能和办公网混在一起。如果只有一个网口所有设备都在同一个网段一旦办公网那边有人下载大文件车间屏的刷新就可能延迟。工控机放在车间电控柜里环境温度比较高所以选了无风扇的型号。这一点在夏天特别重要我见过有项目用普通台式机放在车间夏天过热死机看板黑屏工人以为系统坏了其实是电脑热挂了。4. 数据链路设计从MES到屏幕中间发生了什么4.1 为什么不用MES直接推数据到屏最直接的想法是让MES直接往LED屏推数据但这条路走不通。原因有三个第一MES是生产系统稳定性优先级最高不能因为看板的需求去改MES的代码或者加接口第二不同品牌的LED控制卡协议不一样MES不可能为每种卡都写一套适配第三看板需要的数据和MES里的原始数据不完全一样比如达成率是算出来的不是MES里现成的字段。所以这个项目在MES和屏幕之间加了一层数据中转服务。这个服务做三件事从MES读数据、按看板需求做计算和格式化、把结果分发给各块屏。MES那边只需要提供一个只读的数据库账号或者一个简单的WebService接口不需要做任何改动。4.2 数据中转服务的核心逻辑中转服务是用C#写的Windows服务跑在工控机上。核心逻辑不复杂但有几个细节值得说。第一数据读取用轮询而不是订阅。MES那边不提供消息推送所以中转服务每10秒去查一次数据库。查询语句要写得轻只查需要的字段不要SELECT *。这个项目里查的是三张表产量表、质检表、设备状态表每张表只查当天的数据加好索引之后查询时间在50毫秒以内。第二数据缓存和异常处理。如果某次查询失败比如MES数据库重启中转服务不能直接崩溃也不能把空数据推给屏幕。这里的做法是查询失败时保留上一次的数据同时记录日志连续失败超过3次才在屏幕上显示数据异常。这样偶尔的网络抖动不会影响看板显示。第三数据格式化按屏分别处理。三块LED屏显示的内容不一样液晶屏和办公区大屏又不一样。中转服务在推送之前会为每块屏生成一个独立的数据包包含该屏需要显示的所有字段。这样做的好处是屏幕端的逻辑非常简单收到数据直接显示就行不需要做任何计算。4.3 和MES对接的几种方式对比这个项目里MES提供的是数据库直连但实际中还有很多其他方式。我把常见的几种列出来对比一下对接方式实时性对MES的影响开发难度适用场景数据库直连高中查询压力低MES开放只读账号WebService中低中MES有标准接口中间表低低低MES愿意写中间表消息队列高低高MES支持MQ推送文件交换低低低老MES无接口数据库直连是最简单的方式但要注意查询频率和查询语句的优化。如果MES数据库负载已经很高就不要用直连改用中间表或者WebService。这个项目的MES负载不高所以直连没问题但我在查询语句里加了WITH (NOLOCK)避免查询锁表影响生产。5. NTP时间同步多块屏显示不一致的隐形杀手5.1 为什么看板需要时间同步这个问题很多人会忽略。看板上显示的数据都带时间戳如果几块屏的时间不一致就会出现一线显示10:00的产量二线显示10:02的产量看的人会困惑。更严重的是如果看板时间和MES服务器时间差太多数据对不上车间主任会怀疑看板不准。这个项目里工控机、MES服务器、所有LED控制卡、液晶屏小主机全部要同步到同一个时间源。厂里没有现成的NTP服务器所以我在工控机上搭了一个。工控机本身先同步到外部的NTP源然后作为厂内NTP服务器其他设备都同步到工控机。5.2 工控机上搭NTP服务的具体步骤Windows系统自带W32Time服务可以当NTP服务器用但默认配置不支持作为服务器。需要改注册表# 打开注册表找到 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\NtpServer # 把 Enabled 改为 1 # 再找到 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Config # 把 AnnounceFlags 改为 5 # 重启W32Time服务 net stop w32time net start w32time改完之后工控机就是一台NTP服务器了。其他设备同步到工控机的IP就行。LED控制卡的NTP设置一般在控制软件的时间设置里填工控机IP同步周期设1小时。液晶屏小主机如果是Windows同样用W32Time客户端同步如果是Linux用ntpdate或者chrony。5.3 NTP客户端要不要设置出入站规则这个问题在热搜词里出现了说明很多人遇到过。答案是如果工控机和客户端在同一个网段通常不需要额外设置出入站规则。Windows防火墙默认允许NTP的UDP 123端口出站入站的话如果工控机开了NTP服务器功能需要在防火墙里放行UDP 123入站。这个项目里工控机在车间内网LED屏和液晶屏小主机也在车间内网同一个网段防火墙没有额外设置NTP同步正常。但办公区大屏在办公网跨了网段就需要在工控机的防火墙上放行办公网段到UDP 123的入站规则。具体操作# 在工控机上执行 netsh advfirewall firewall add rule nameNTP Server dirin actionallow protocolUDP localport123如果还是同步不了先检查网络通不通ping工控机IP再检查UDP 123端口通不通用telnet或者端口扫描工具。我遇到过一种情况网络通但NTP同步失败最后发现是中间有台交换机做了ACL把UDP 123拦了。所以排查的时候要从网络层往上查。5.4 时间同步的验证方法同步设置好之后怎么确认真的同步了在Windows客户端上执行w32tm /query /status看源这一行是不是工控机IP上次同步时间是不是最近的。在Linux客户端上ntpq -p看reach列是不是377八进制表示最近8次同步都成功。LED屏那边没有命令行就看控制软件里的时间显示和工控机对比差在1秒以内就算同步成功。6. 多屏内容分发一套数据怎么喂给五块屏6.1 分发架构的设计取舍五块屏三种类型LED、液晶、大屏两种网络车间内网、办公网。分发架构有两种选择一种是中转服务直接推给每块屏另一种是中转服务推给一个中间节点中间节点再分发给各块屏。这个项目选了第一种中转服务直接推。为什么因为屏幕数量不多五块直接推的逻辑简单不需要维护中间节点。如果屏幕数量超过二十块或者跨多个车间那就需要中间节点做分级分发否则中转服务的连接数会太多。直接推的具体实现中转服务里为每块屏维护一个推送任务每个任务独立运行互不影响。一块屏通信失败不会影响其他屏。推送任务用C#的Timer实现每10秒触发一次从缓存里取最新数据格式化后发给对应的屏。6.2 LED屏的内容推送细节灵信控制卡的SDK里推送内容用的是LedNet相关的类。核心步骤是连接控制卡、创建节目、添加区域、设置区域内容和样式、发送节目。这里有几个细节第一区域坐标要提前算好。P10单色屏的分辨率是320x16032x16个模组分成三个区域产量区、目标区、达成率区。每个区域的左上角坐标和宽高在代码里写死调试的时候根据实际显示效果微调。P4全彩屏分辨率更高区域划分更灵活但坐标同样要提前定好。第二字体和颜色要按区域设置。产量数字用大号红色字体目标数字用中号白色字体达成率用大号绿色字体正常或红色闪烁异常。灵信SDK支持设置字体大小、颜色、对齐方式但不同型号的控制卡支持的字体大小范围不一样P10单色屏最大只能显示16x16点阵的字体再大就要用图形模式。这个项目里产量数字用的是16x16点阵三米外能看清。第三闪烁效果用定时切换实现。灵信SDK本身不支持闪烁需要在中转服务里做异常状态下每5秒切换一次区域的颜色红/黑交替产生闪烁效果。这个逻辑放在推送任务里不影响其他屏。6.3 液晶屏和办公区大屏的内容推送液晶屏和办公区大屏用的是浏览器全屏页面推送方式和中转服务的关系不大——页面自己定时从数据服务拉数据。中转服务只需要提供一个HTTP接口返回JSON格式的数据页面用JavaScript定时请求这个接口然后更新DOM。这种方式的优点是内容排版完全自由可以用HTML/CSS做各种图表、表格、进度条。缺点是依赖浏览器如果浏览器崩溃或者页面卡死屏幕就白屏了。所以这个项目里液晶屏小主机上设置了浏览器开机自启和定时刷新每4小时刷新一次页面避免长时间运行导致内存泄漏。办公区大屏的页面还加了自动重连逻辑如果HTTP请求失败页面不会白屏而是保留上一次的数据同时在角落显示连接中。这样即使中转服务重启屏幕也不会闪。6.4 数据格式的统一和差异化中转服务对外提供两种数据格式给LED屏的是二进制指令通过SDK发送给液晶屏和办公区大屏的是JSON。JSON的格式设计要兼顾可读性和扩展性{ timestamp: 2024-01-15T10:30:00, lines: [ { name: 一线, output: 1250, target: 1500, rate: 83.3, status: normal }, { name: 二线, output: 980, target: 1200, rate: 81.7, status: warning } ], summary: { total_output: 2230, total_target: 2700, total_rate: 82.6, defect_rate: 1.2 } }这个格式里status字段是给页面做颜色判断用的normal显示绿色warning显示黄色error显示红色。LED屏那边没有JSON但中转服务在推送之前会把同样的状态判断逻辑用一遍决定显示什么颜色。7. 调试阶段踩过的坑和排查过程7.1 第一块屏亮了第二块屏不亮项目调试第一天一线屏正常显示二线屏死活不亮。排查过程先检查网络ping得通再检查控制卡用厂家自带的测试软件能点亮再检查中转服务的日志发现推送任务报了连接超时。最后发现是两块屏的IP地址冲突了——一线屏和二线屏的控制卡出厂默认IP都是192.168.1.100只改了一线的二线忘了改。这个坑很典型。LED控制卡的默认IP通常是固定的多块卡在同一个网络里必须改IP。而且改IP之后要重启控制卡才生效。这个项目里我给每块屏分配了固定的IP段一线192.168.1.101二线192.168.1.102三线192.168.1.103车间入口192.168.1.104。改完之后在工控机上把IP和屏幕位置对应关系记在文档里后面排查问题的时候直接查文档。7.2 数据刷新了但屏幕没变二线屏亮了之后发现数据不刷新——屏幕上显示的还是第一次推送的数据。排查过程检查中转服务日志发现推送任务正常执行没有报错检查控制卡状态连接正常最后用厂家的测试软件手动推了一条新数据屏幕变了。说明问题出在中转服务的推送内容上。进一步排查发现灵信SDK在推送相同内容时不会刷新屏幕。也就是说如果这次推送的数据和上次完全一样控制卡会认为没有变化不更新显示。但看板需要的是即使数据没变时间戳也要更新屏幕上有个最后更新时间。解决办法是在推送内容里加一个每次都变化的字段比如当前时间戳这样控制卡就会认为内容变了强制刷新。这个坑在灵信的文档里没有写是我打电话问厂家技术支持才知道的。所以做LED看板厂家技术支持的电话一定要存好很多坑文档里没有但技术支持一句话就能点破。7.3 NTP同步了但时间还是差几秒NTP配置好之后检查发现工控机和LED屏的时间差了3秒。排查过程在工控机上查NTP服务状态正常在LED控制软件里查同步日志显示同步成功但时间就是差3秒。最后发现是LED控制卡的时间精度问题——有些低端控制卡的时钟晶振精度不够同步之后走一段时间就会漂移。解决办法是缩短同步周期从1小时改成10分钟。改完之后时间差控制在1秒以内。这个问题在P10单色屏上特别常见因为P10的控制卡成本低晶振用的是一般的。P4全彩屏的控制卡就好很多1小时同步一次也没问题。所以如果项目里有多块不同规格的LED屏NTP同步周期要按最差的那块屏来设。7.4 办公区大屏的页面在晚上自动变暗这个问题不是技术问题是显示器的自动亮度调节。办公区大屏是一台商用显示器默认开启了环境光感应晚上车间灯光暗了之后屏幕自动变暗看板内容看不清。解决办法是在显示器菜单里关掉自动亮度把亮度固定在一个值。这个坑很小但如果不注意晚上看板就等于废了。7.5 MES数据库查询偶尔超时运行了一周之后发现偶尔有几次数据刷新延迟日志里显示MES查询超时。排查过程检查MES数据库负载正常检查网络正常最后发现是查询语句没有加索引。MES的产量表数据量很大按时间查询的时候如果没有索引全表扫描会很慢。解决办法是让MES的DBA在时间字段上加了一个索引查询时间从2秒降到50毫秒。这里有个经验看板项目一定要和MES的DBA搞好关系。看板的查询语句再优化如果数据库本身没有索引也是白搭。而且加索引这件事必须由DBA来做看板开发人员没有权限。所以项目启动阶段就要把DBA拉进来提前沟通好需要哪些字段的索引。8. 上线之后的运维和扩展8.1 日常运维要做哪些事看板上线之后运维工作不多但有几件事要定期做。第一每周检查一次中转服务的日志看有没有频繁的查询失败或者推送失败。第二每月检查一次工控机的磁盘空间日志文件会慢慢变大要定期清理。第三每季度检查一次LED屏的显示效果看有没有坏点或者亮度不均。第四NTP同步状态要定期抽查特别是LED屏的时间。这个项目里我在中转服务里加了一个简单的自检功能每天凌晨3点服务会自己检查一遍所有屏幕的连接状态把结果写到一个日志文件里。第二天早上来看日志就知道有没有问题。这个功能不复杂但很实用省去了每天手动检查的麻烦。8.2 后续扩展的方向这个项目上线之后厂里又提了几个新需求一是想在手机上也能看这些数据二是想加一个历史数据查询功能三是想把设备状态也集成进来。这三个需求都不难实现因为中转服务已经提供了HTTP接口手机端直接调这个接口就行历史数据查询需要在MES那边加一个历史表中转服务定期把数据写进去设备状态需要和设备的PLC对接这个稍微复杂一点但也是可行的。扩展的时候要注意一点不要在中转服务里堆太多功能。中转服务的核心职责是读数据、算数据、推数据其他功能应该拆成独立的服务。比如手机端可以单独做一个Web应用调中转服务的接口历史数据可以单独做一个数据归档服务。这样每个服务的职责单一出问题的时候容易定位也容易维护。8.3 这套方案的成本和周期最后说一下成本和周期给准备做类似项目的人一个参考。这个项目的硬件成本主要是两块灵信控制卡约2000元、一台工控机约4000元、一台液晶电视约3000元、一台办公区大屏约5000元加上线材和安装辅料总共约1.5万元。软件全部自研没有采购商业看板软件开发周期约3周包括现场调试。如果采购商业看板软件一套授权费通常要几万到十几万而且很多商业软件不支持多品牌LED控制卡混用。所以对于这种多块屏、多品牌、数据源单一的场景自研是更划算的选择。当然自研的前提是有一个懂C#和数据库的开发人员如果厂里没有也可以找外包但外包的后期维护会比较麻烦。9. 几个容易被忽略的细节9.1 LED屏的消隐时间热搜词里出现了led驱动芯片消隐时间这个问题在LED看板上确实存在。消隐时间设置不当屏幕会出现鬼影——上一个字还没完全熄灭下一个字就亮了看起来有重影。灵信的控制卡在SDK里有消隐时间的参数默认值通常没问题但如果屏体比较老或者驱动芯片比较特殊可能需要调整。这个项目里没有遇到这个问题但如果你做LED看板发现显示有重影可以先查消隐时间。9.2 贴片LED的正负极热搜词里还有贴片led正负这是硬件层面的问题。如果自己维修LED模组换贴片LED的时候要注意正负极接反了不亮。一般贴片LED的负极有个标记比如缺口或者绿点焊接之前用万用表测一下。这个和看板软件无关但现场维护的时候可能会遇到。9.3 定时器中断实现LED闪烁热搜词里有定时器中断实现led闪烁和stm32点亮led这些是嵌入式开发的内容。在看板项目里LED屏的闪烁不是用单片机做的而是用控制卡的SDK做的。但如果你是用单片机自己驱动LED屏那就需要用到定时器中断。这个项目的方案是用现成的控制卡所以不涉及底层驱动开发。9.4 MES系统的选型热搜词里有mes系统和mes系统开源说明很多人关心MES的选型。这个项目的MES是厂里已有的不是我们选的。但如果你正在选MES我的建议是看板需求要在MES选型阶段就提出来。因为不同MES的接口开放程度差别很大有的MES提供标准的WebService接口有的只开放数据库有的什么都不开放。如果MES选型的时候没有考虑看板需求后面做看板会很痛苦。10. 写在最后的一点个人体会这个项目做完之后我最大的体会是工厂看板项目的难点不在技术而在沟通和细节。技术方案其实不复杂无非是读数据、算数据、推数据。但现场的情况千变万化屏幕的品牌、控制卡的型号、MES的接口、网络的架构每个环节都可能有意外。而且工厂的环境和办公室不一样温度、粉尘、电磁干扰都会影响设备稳定性。所以做这类项目我的习惯是前期多跑现场中期多留余量后期多写文档。前期跑现场是为了摸清硬件和网络的实际情况不要只看需求文档中期留余量是为了应对意外比如网络带宽、工控机性能、屏幕数量都要留出扩展空间后期写文档是为了自己——过半年再来看这个项目如果没有文档很多细节都忘了。另外和工厂的人打交道要尊重他们的工作习惯。车间主任关心的是产量设备科长关心的是设备状态IT关心的是网络安全。做看板的时候要把这些需求都照顾到不能只盯着技术。看板最终是给人看的人觉得好用项目才算成功。