现场调试最怕遇到两种画面一种是设备明明在跑界面上的数值却像冻住了一样操作员连按几下没反应你站在旁边怀疑程序挂了另一种是设备换备件新屏幕装上去一片空白得把老屏幕里的工程原样搬出来。前者归到Qt刷新屏幕这一类问题后者就是触摸屏上传程序这类问题。这两个事一个在代码层一个在工程配置层看起来八竿子打不着但我在产线现场发现它们经常在同一个项目里前后脚出现——界面刷新逻辑写不好的人往往也不清楚触摸屏上传程序时到底该备份哪些东西。这篇就按我自己的调试顺序把Qt刷新屏幕的机制、刷新策略怎么定、触摸屏程序上传的完整流程、以及两边各自容易踩的坑一件一件说清楚适合刚接手工业人机界面项目的开发也适合需要现场维护设备的工程人员对照着用。1. 先拆问题刷新屏幕和上传程序不是一回事1.1 两个场景的边界在哪里Qt刷新屏幕本质上是在问“我改动了数据界面什么时候、以什么方式把这个改动画出来”。这是运行时的行为发生在程序跑起来之后涉及事件循环、重绘请求、绘制函数调用这一整条链路。你可能只是想让一个温度值从25.3变成25.4但屏幕上的数字没动于是你开始怀疑信号没发出去、槽没连上、或者定时器停了。实际排查下来十有八九是重绘请求发了但被合并了或者压根没发。触摸屏上传程序是工程层面的操作发生在设备停机或者调试阶段。你要做的事情是把屏幕内部存储的组态工程读回电脑得到一个可以打开、可以修改、可以再下载回去的工程文件。这个过程不涉及任何代码逻辑考验的是通信参数、软件版本、权限设置这些东西。我之所以把它们放在一起讲是因为在实际项目里Qt做的一般是上位机监控界面或者边缘计算盒子上的本地界面而触摸屏是设备本体的操作面板两边往往共用一套数据源。上位机界面刷新不及时你会以为是通信问题触摸屏工程传不出来你会以为是屏幕坏了。把两者的机制分清楚排查的时候才不会互相甩锅。1.2 解决思路的差异刷新问题走的是“定位绘制链路”的路子。你要依次确认数据变了吗、变的时候有没有通知UI、通知了之后有没有触发重绘、重绘的时候画的是不是新数据。这四步任何一步断了屏幕就不动。上传问题走的是“打通通信链路”的路子。你要确认物理连接通不通、通信参数对不对、屏幕端有没有开权限、软件版本兼不兼容。这四步任何一步不通上传就失败。一个是逻辑链路一个是物理链路。前者靠读代码和加日志后者靠看指示灯和ping地址。混在一起想只会越查越乱。2. Qt刷新屏幕的几条路径与底层机制2.1 update() 和 repaint() 到底差在哪这两个函数是Qt里最容易被混用的。很多人代码里随手写repaint()程序也能跑但性能就是上不去原因就在这。update() 的做法是“标记加排队”。它把控件的一块区域标记为脏区域然后往事件队列里投递一个重绘请求等事件循环转到这一轮的时候统一处理。关键点在于“合并”你在一个循环里连续调用十次update()事件循环只会处理一次重绘因为脏区域被合并了。这对性能是好事但也意味着你不能指望调用完update()之后立刻就能在屏幕上看到结果。repaint() 的做法是“立即执行”。它不走事件队列直接同步调用paintEvent画完才返回。听起来很直接问题是它会打断当前的逻辑流。如果你在一个高频定时器里不停调repaint()事件队列里堆积的其他事件就得不到处理界面会变得一卡一卡的鼠标点击响应也会变慢。我自己的习惯是正常的数据更新一律用update()只有在极少数需要“这一刻必须画出来”的场景才用repaint()比如某个硬件触发的同步显示。剩下99%的情况update()都够用。提示如果调了update()但界面还是不动先确认控件是不是被遮挡、是不是visible、父控件有没有被禁用。这三个原因比“重绘机制坏了”常见得多。2.2 事件循环与刷新时机的关系Qt的界面刷新完全依赖事件循环。你的主线程在app.exec()里转圈每一圈处理一批事件其中就包括重绘请求。这就带来一个推论只要主线程被阻塞界面就不会刷新。我在现场见过太多这样的代码在按钮的槽函数里直接做了一个几百毫秒的通信等待或者是读了一个大文件结果就是点下按钮之后界面整个白掉等操作完成才恢复。用户以为是卡死其实是主线程被占住了重绘事件排在后面进不来。解决办法有两个方向。一个是把耗时操作挪到工作线程主线程只管收结果、更新界面。另一个是如果操作确实必须在主线程做那就在循环里定期调用QCoreApplication::processEvents()让事件队列有机会喘口气。第二种做法我不太推荐因为它会带来重入问题——你在处理A事件的过程中又处理了B事件B事件可能修改了A正在用的数据。真要用必须加锁或者加状态标志。还有一个细节是定时器的精度。QTimer默认用的是粗精度定时器实际触发时间可能有百分之几的偏差。做界面刷新一般无所谓但如果你拿它去卡数据采集的节奏就要显式设成Qt::PreciseTimer。不过即便是精确定时器Qt也不保证硬实时工业场景下要求毫秒级严格周期的得用专门的采集卡或者实时系统别指望QTimer。2.3 QML和图形视图框架的刷新入口如果你的界面是QML写的刷新逻辑和QWidget体系不太一样。QML里属性的变化会自动触发绑定更新你改了一个绑定到Text的变量界面会自己重绘不需要手动调update()。这是QML方便的地方也是坑所在的地方——有时候你没想改但绑定链上某个中间变量变了整个界面就跟着重绘了一遍频率高起来CPU就顶不住。QML里如果要强制刷新可以用QQuickWindow的update()但大多数情况下你不需要。真正需要关注的是别让绑定过于复杂别在绑定表达式里做函数调用和大量计算。图形视图框架QGraphicsView的刷新入口在场景或者视口上。改完图元之后调scene()-update()或者viewport()-update()效果和QWidget的update()类似都是标记脏区域等事件循环处理。这个框架适合画大量的自定义图元比如工艺流程图、拓扑图但图元数量上去之后重绘开销会明显增加需要配合图元的数据缓存和局部刷新来优化。3. 刷新策略的工程化设计3.1 刷新频率要跟数据源匹配这是我觉得最值得算一笔账的地方。很多项目里界面刷新频率是拍脑袋定的要么跟风写个10ms定时器要么干脆每次数据变化就刷一次结果CPU占用居高不下风扇呼呼转。正确的做法是先看数据源的真实更新频率。假设你的PLC或者采集模块是100ms上传一次数据那界面理论上最高也就10Hz的有效更新。你搞个5ms的刷新定时器中间19次画的都是同一份数据纯属浪费。我一般的做法是刷新周期等于或者略慢于数据周期。数据100ms来一次界面就100ms刷一次或者150ms刷一次用脏标志合并。具体怎么合并设一个bool变量数据来了置true定时器到点了看这个标志是true才调update()然后清掉。这样数据再快也不会把重绘压爆。算一个具体的一个界面上有4个实时曲线每条曲线200个点用QPainter画。如果按25Hz刷新每秒要画4×200×2520000个点加上坐标轴、网格、文字CPU占用轻松上到15%以上。降到10Hz同样的画面只要8000个点占用掉到6%左右肉眼几乎看不出差别。这个账在现场很值得算。刷新周期有效帧率曲线绘制点数/秒主观感受10ms100Hz80000无意义数据源跟不上40ms25Hz20000流畅但CPU偏高100ms10Hz8000够用占用可控250ms4Hz3200略顿适合非关键参数3.2 局部刷新和双缓冲怎么配合update()可以带参数指定只重绘某一块矩形区域。这个能力用好了效果很明显。比如一个界面上有个大表格只有一个单元格的数字在变你没必要整个表格重画只update那个单元格的区域就行。但局部刷新有个前提你的paintEvent里必须能把这块区域完整画出来。如果绘制逻辑里有依赖其他区域状态的比如渐变背景、跨区域的连线那局部刷新就可能画出残缺的画面。这时候要么把依赖区域一起纳入刷新范围要么老老实实全屏刷。双缓冲是Qt默认就开的QWidget内部会先画到一张后台缓冲区画完再整体贴到屏幕上所以一般不会看到闪烁。有些老代码里手动写了双缓冲逻辑其实是多余的。倒是有一个属性值得注意Qt::WA_OpaquePaintEvent告诉Qt这个控件是不透明的不用先画父控件的背景。在频繁刷新的控件上设上这个属性能省掉一层背景绘制。前提是你自己在paintEvent里把整个区域都填满了不然会看到花屏。还有Qt::WA_StaticContents适合内容只增不减的滚动区域能减少滚动时的重绘量。这些属性不是万能药用之前先确认自己的绘制逻辑能不能配合。3.3 高频刷新下的几个性能陷阱第一个陷阱是在paintEvent里做耗时操作。paintEvent会被频繁调用你在里面查数据库、做字符串格式化、算复杂几何每次都要重来一遍。正确的做法是把这些计算提前做好缓存起来paintEvent里只做绘制。第二个陷阱是频繁创建和销毁对象。有人在paintEvent里new一个QPen、new一个QFont画完delete。这种写法在低频刷新下看不出问题高频下就是灾难。QPen、QBrush、QFont这些都是轻量对象直接栈上创建就行没必要堆分配。第三个陷阱是信号槽的重复连接。界面初始化的时候连一次就够了如果每次数据更新都连一次槽函数会被调用N次重绘请求也跟着翻倍。这种问题在动态创建控件的时候特别容易出现建议连接之前先disconnect一下或者用Qt::UniqueConnection。第四个陷阱是字符串拼接。实时显示的数字转字符串如果每帧都做一次QString::number再加单位开销不小。可以用QLabel的setNum配合固定格式或者干脆自己维护一个字符缓冲区只在数值真正变化的时候才更新。4. 触摸屏程序上传的完整实操流程4.1 上传前必须确认的四件事触摸屏上传程序失败八成不是操作问题而是前置条件没满足。我一般会先确认这四件事能省掉大量来回折腾。第一确认屏幕型号和固件版本。不同型号支持的上传方式不一样有的只支持USB从口有的走以太网有的两者都行。固件版本也要看老固件可能有上传相关的bug新固件可能改了通信协议。型号一般在屏幕背面铭牌上或者开机画面、系统设置菜单里能看到。第二确认组态软件的版本。这一点最容易被忽略。工程文件是有版本号的用低版本软件打开高版本工程通常直接报错用高版本软件打开低版本工程一般能开但保存回去之后可能就不兼容老屏幕了。稳妥的做法是现场维护用的电脑上装和当初开发时一致的软件版本。第三确认屏幕端有没有开放上传权限。很多厂商出于保护知识产权的考虑默认关闭上传功能或者需要输入密码才能上传。这个开关通常在工程设置的“安全”或者“下载设置”里也可能在屏幕的系统菜单里。如果当初开发的人没开或者密码丢了那就传不出来只能找原开发者要工程文件。第四确认通信物理链路。USB线要接的是屏幕的“从口”或者标着“USB Slave”的口接错口是没反应的。网线要确认屏幕和电脑在同一网段比如屏幕是192.168.1.10电脑就设成192.168.1.100子网掩码255.255.255.0。电脑的防火墙有时候会拦通信端口测试阶段可以先关掉通了之后再按需放开。4.2 分步操作与参数配置前置条件确认完操作本身其实不复杂。下面这套流程是通用逻辑不同品牌的菜单文字会有差异但步骤顺序基本一致。第一步把屏幕切到可以通信的状态。有些屏幕正常运行时通信口是被占用的需要进系统菜单选择“下载模式”或者“传输模式”。这个状态下屏幕一般会显示等待连接的提示画面停止刷新属于正常现象。第二步打开组态软件新建一个空工程或者直接选择“从设备上传”。注意不要在有未保存修改的工程里做上传避免覆盖。第三步选择通信方式并填参数。以以太网为例需要填屏幕的IP地址、端口号。端口号每个厂商不一样软件里一般有默认值不确定就查手册。填完点“测试连接”能通再往下走。USB方式的话先确认设备管理器里能看到对应的串口或者USB设备看不到就是驱动没装好。第四步指定上传的工程保存路径和文件名。这一步建议单独建一个文件夹文件名带上设备编号和日期比如“包装机1号_20240520”以后回滚或者对比版本的时候方便找。第五步开始上传。进度条走的时候不要断电、不要拔线、不要切屏幕的页面。上传时间跟工程大小有关画面多、配方数据多的工程可能要几分钟。第六步上传完成后先别急着关软件直接打开刚传下来的工程逐个画面翻一遍。重点看画面数量对不对、控件位置有没有偏、变量地址表全不全、配方数据在不在、报警定义有没有丢、脚本和宏能不能正常打开。4.3 上传后的验证清单上传成功不等于工程可用。我整理了一份自己每次都会过的检查项照着走能避免很多回头路。检查项检查方法常见异常画面完整性逐页翻看对比原设备显示画面缺失、控件错位变量地址打开变量表核对地址和数据类型地址偏移、类型不匹配配方数据进入配方编辑看条目和数值配方为空、数值被截断报警定义查看报警列表和触发条件报警条目丢失脚本与宏打开脚本编辑器编译一次语法报错、函数缺失通信设置核对协议、波特率、站号参数被重置为默认值用户权限检查用户等级和密码设置权限表为空这份清单看着繁琐但一次完整的核对也就十几分钟比到了现场发现配方丢了再返工要划算得多。5. 常见问题速查与排查思路5.1 Qt刷新类问题的排查顺序界面不刷新我一般按这个顺序查从便宜到贵从常见到罕见。先看数据有没有真的变。在数据赋值的地方打一行日志或者在调试器里看变量。如果数据本身没变那问题在采集或者通信层跟刷新没关系。再看信号有没有发出去。如果用的是信号槽确认connect的返回值是不是true确认连接的类型是不是Qt::QueuedConnection导致延迟。跨线程的信号槽默认是队列连接数据到了槽函数里可能已经晚了一拍。然后看重绘有没有被触发。在paintEvent里打日志看它到底被调了几次。如果一次都没调说明update()没生效检查控件可见性、父控件状态、有没有被setUpdatesEnabled(false)关掉。最后看绘制内容对不对。如果paintEvent调了但画出来还是旧数据说明绘制时读的数据源不对可能是缓存没更新也可能是读了一个副本。还有一种情况是界面刷新了但看起来“没刷新”比如数值变了但颜色没变或者进度条动了但数字没动。这种属于局部更新逻辑写漏了改数据的时候只通知了部分控件。5.2 上传类问题的典型表现上传失败的报错信息往往很笼统就一句“连接失败”或者“设备无响应”得靠现象去判断。现象一点测试连接一直转圈然后超时。先ping一下屏幕的IPping不通就是网络层的问题查网线、查IP网段、查屏幕有没有进下载模式。ping得通但连不上多半是端口号填错了或者电脑防火墙拦了。现象二USB连接电脑没反应。打开设备管理器看有没有未知设备。有的话是驱动问题装厂商提供的驱动。没有的话换根线试试有些USB线是纯充电线没有数据线芯。现象三上传到一半中断。常见原因是工程太大超时或者通信质量不稳定。可以试着降低通信速率或者分段上传如果软件支持。也可能是屏幕存储空间不足清理一下再传。现象四上传成功但打不开工程。软件版本不匹配的可能性最大。看一下报错里的版本号装对应版本的软件。还有一种可能是工程被加密了上传下来的是加密包需要原开发者的密钥才能解开。现象五屏幕根本不允许上传。这个没辙只能找原开发者。如果实在找不到就只能根据设备实际运行表现反推逻辑重新做一版工程。所以我在项目交付的时候都会留一份完整的工程源文件给客户并且把上传密码写在交付文档里就是为了避免后面这种事。注意有些低端型号的触摸屏硬件上就不支持上传只能下载。采购的时候如果在意后期维护这一点要提前问清楚别等设备装到现场才发现。6. 把刷新和通信解耦一个更耐用的工程结构6.1 数据层到UI层的单向流前面讲的刷新问题很多根源在于数据和界面耦合太紧。数据一变就直接操作控件控件一多、逻辑一复杂就不知道该在哪一层做节流和合并。我习惯的结构是三层采集层负责从设备读数据写进一个共享的数据模型模型层做数据校验、单位换算、越限判断UI层只负责从模型里读值、按自己的节奏刷新。中间用信号通知“数据更新了”但不直接调控件的setText。这样做的好处是UI的刷新频率可以独立于数据频率。数据100ms来一次UI可以攒够5次再刷也可以只刷变化的部分。采集层出问题也不会把界面拖死界面卡了也不影响采集继续跑。调试的时候你可以在模型层加断点看数据流在UI层加断点看刷新两边互不干扰。具体实现上模型层维护一个带版本号的数据结构每次更新版本号加一。UI层的定时器到点了比较本地记录的版本号和模型的最新版本号不一样才刷新。这个做法比在每个数据变更点都发信号要省事尤其适合数据点很多的场景。6.2 现场维护与备份习惯上传程序的场景本质上是在做“灾难恢复”。与其等出了问题再想办法不如在项目还在自己手里的时候就把退路留好。我现在交付任何带触摸屏的项目都会做三件事。第一把完整的工程源文件、编译后的下载文件、软件安装包、驱动全部刻一张盘或者拷一个U盘跟设备一起交给客户并且在文件名上写清楚版本号和适用型号。第二把上传密码、系统菜单密码、各等级用户密码整理成一张纸贴在电控柜内侧只有维护人员能看到。第三在工程里把“允许上传”打开除非客户有明确的安全要求要关闭。这三件事花不了半小时但能省掉未来某一天在客户现场抓瞎的半天。我吃过这个亏——有一次设备换备件新屏幕是空白的原开发者已经离职工程文件找不到最后只能照着设备实际动作重新做界面和逻辑前后折腾了两天。从那以后备份这件事我就再没偷过懒。对于Qt这边我也有个类似的习惯把界面的刷新周期、数据源地址、关键参数都做成可配置的写在配置文件里。现场调试的时候不用重新编译改个配置重启就行。这个做法在需要适配不同型号设备的项目里特别好用同一套程序改几个参数就能用在不同的机台上。
现场调试最怕遇到两种画面一种是设备明明在跑界面上的数值却像冻住了一样操作员连按几下没反应你站在旁边怀疑程序挂了另一种是设备换备件新屏幕装上去一片空白得把老屏幕里的工程原样搬出来。前者归到Qt刷新屏幕这一类问题后者就是触摸屏上传程序这类问题。这两个事一个在代码层一个在工程配置层看起来八竿子打不着但我在产线现场发现它们经常在同一个项目里前后脚出现——界面刷新逻辑写不好的人往往也不清楚触摸屏上传程序时到底该备份哪些东西。这篇就按我自己的调试顺序把Qt刷新屏幕的机制、刷新策略怎么定、触摸屏程序上传的完整流程、以及两边各自容易踩的坑一件一件说清楚适合刚接手工业人机界面项目的开发也适合需要现场维护设备的工程人员对照着用。1. 先拆问题刷新屏幕和上传程序不是一回事1.1 两个场景的边界在哪里Qt刷新屏幕本质上是在问“我改动了数据界面什么时候、以什么方式把这个改动画出来”。这是运行时的行为发生在程序跑起来之后涉及事件循环、重绘请求、绘制函数调用这一整条链路。你可能只是想让一个温度值从25.3变成25.4但屏幕上的数字没动于是你开始怀疑信号没发出去、槽没连上、或者定时器停了。实际排查下来十有八九是重绘请求发了但被合并了或者压根没发。触摸屏上传程序是工程层面的操作发生在设备停机或者调试阶段。你要做的事情是把屏幕内部存储的组态工程读回电脑得到一个可以打开、可以修改、可以再下载回去的工程文件。这个过程不涉及任何代码逻辑考验的是通信参数、软件版本、权限设置这些东西。我之所以把它们放在一起讲是因为在实际项目里Qt做的一般是上位机监控界面或者边缘计算盒子上的本地界面而触摸屏是设备本体的操作面板两边往往共用一套数据源。上位机界面刷新不及时你会以为是通信问题触摸屏工程传不出来你会以为是屏幕坏了。把两者的机制分清楚排查的时候才不会互相甩锅。1.2 解决思路的差异刷新问题走的是“定位绘制链路”的路子。你要依次确认数据变了吗、变的时候有没有通知UI、通知了之后有没有触发重绘、重绘的时候画的是不是新数据。这四步任何一步断了屏幕就不动。上传问题走的是“打通通信链路”的路子。你要确认物理连接通不通、通信参数对不对、屏幕端有没有开权限、软件版本兼不兼容。这四步任何一步不通上传就失败。一个是逻辑链路一个是物理链路。前者靠读代码和加日志后者靠看指示灯和ping地址。混在一起想只会越查越乱。2. Qt刷新屏幕的几条路径与底层机制2.1 update() 和 repaint() 到底差在哪这两个函数是Qt里最容易被混用的。很多人代码里随手写repaint()程序也能跑但性能就是上不去原因就在这。update() 的做法是“标记加排队”。它把控件的一块区域标记为脏区域然后往事件队列里投递一个重绘请求等事件循环转到这一轮的时候统一处理。关键点在于“合并”你在一个循环里连续调用十次update()事件循环只会处理一次重绘因为脏区域被合并了。这对性能是好事但也意味着你不能指望调用完update()之后立刻就能在屏幕上看到结果。repaint() 的做法是“立即执行”。它不走事件队列直接同步调用paintEvent画完才返回。听起来很直接问题是它会打断当前的逻辑流。如果你在一个高频定时器里不停调repaint()事件队列里堆积的其他事件就得不到处理界面会变得一卡一卡的鼠标点击响应也会变慢。我自己的习惯是正常的数据更新一律用update()只有在极少数需要“这一刻必须画出来”的场景才用repaint()比如某个硬件触发的同步显示。剩下99%的情况update()都够用。提示如果调了update()但界面还是不动先确认控件是不是被遮挡、是不是visible、父控件有没有被禁用。这三个原因比“重绘机制坏了”常见得多。2.2 事件循环与刷新时机的关系Qt的界面刷新完全依赖事件循环。你的主线程在app.exec()里转圈每一圈处理一批事件其中就包括重绘请求。这就带来一个推论只要主线程被阻塞界面就不会刷新。我在现场见过太多这样的代码在按钮的槽函数里直接做了一个几百毫秒的通信等待或者是读了一个大文件结果就是点下按钮之后界面整个白掉等操作完成才恢复。用户以为是卡死其实是主线程被占住了重绘事件排在后面进不来。解决办法有两个方向。一个是把耗时操作挪到工作线程主线程只管收结果、更新界面。另一个是如果操作确实必须在主线程做那就在循环里定期调用QCoreApplication::processEvents()让事件队列有机会喘口气。第二种做法我不太推荐因为它会带来重入问题——你在处理A事件的过程中又处理了B事件B事件可能修改了A正在用的数据。真要用必须加锁或者加状态标志。还有一个细节是定时器的精度。QTimer默认用的是粗精度定时器实际触发时间可能有百分之几的偏差。做界面刷新一般无所谓但如果你拿它去卡数据采集的节奏就要显式设成Qt::PreciseTimer。不过即便是精确定时器Qt也不保证硬实时工业场景下要求毫秒级严格周期的得用专门的采集卡或者实时系统别指望QTimer。2.3 QML和图形视图框架的刷新入口如果你的界面是QML写的刷新逻辑和QWidget体系不太一样。QML里属性的变化会自动触发绑定更新你改了一个绑定到Text的变量界面会自己重绘不需要手动调update()。这是QML方便的地方也是坑所在的地方——有时候你没想改但绑定链上某个中间变量变了整个界面就跟着重绘了一遍频率高起来CPU就顶不住。QML里如果要强制刷新可以用QQuickWindow的update()但大多数情况下你不需要。真正需要关注的是别让绑定过于复杂别在绑定表达式里做函数调用和大量计算。图形视图框架QGraphicsView的刷新入口在场景或者视口上。改完图元之后调scene()-update()或者viewport()-update()效果和QWidget的update()类似都是标记脏区域等事件循环处理。这个框架适合画大量的自定义图元比如工艺流程图、拓扑图但图元数量上去之后重绘开销会明显增加需要配合图元的数据缓存和局部刷新来优化。3. 刷新策略的工程化设计3.1 刷新频率要跟数据源匹配这是我觉得最值得算一笔账的地方。很多项目里界面刷新频率是拍脑袋定的要么跟风写个10ms定时器要么干脆每次数据变化就刷一次结果CPU占用居高不下风扇呼呼转。正确的做法是先看数据源的真实更新频率。假设你的PLC或者采集模块是100ms上传一次数据那界面理论上最高也就10Hz的有效更新。你搞个5ms的刷新定时器中间19次画的都是同一份数据纯属浪费。我一般的做法是刷新周期等于或者略慢于数据周期。数据100ms来一次界面就100ms刷一次或者150ms刷一次用脏标志合并。具体怎么合并设一个bool变量数据来了置true定时器到点了看这个标志是true才调update()然后清掉。这样数据再快也不会把重绘压爆。算一个具体的一个界面上有4个实时曲线每条曲线200个点用QPainter画。如果按25Hz刷新每秒要画4×200×2520000个点加上坐标轴、网格、文字CPU占用轻松上到15%以上。降到10Hz同样的画面只要8000个点占用掉到6%左右肉眼几乎看不出差别。这个账在现场很值得算。刷新周期有效帧率曲线绘制点数/秒主观感受10ms100Hz80000无意义数据源跟不上40ms25Hz20000流畅但CPU偏高100ms10Hz8000够用占用可控250ms4Hz3200略顿适合非关键参数3.2 局部刷新和双缓冲怎么配合update()可以带参数指定只重绘某一块矩形区域。这个能力用好了效果很明显。比如一个界面上有个大表格只有一个单元格的数字在变你没必要整个表格重画只update那个单元格的区域就行。但局部刷新有个前提你的paintEvent里必须能把这块区域完整画出来。如果绘制逻辑里有依赖其他区域状态的比如渐变背景、跨区域的连线那局部刷新就可能画出残缺的画面。这时候要么把依赖区域一起纳入刷新范围要么老老实实全屏刷。双缓冲是Qt默认就开的QWidget内部会先画到一张后台缓冲区画完再整体贴到屏幕上所以一般不会看到闪烁。有些老代码里手动写了双缓冲逻辑其实是多余的。倒是有一个属性值得注意Qt::WA_OpaquePaintEvent告诉Qt这个控件是不透明的不用先画父控件的背景。在频繁刷新的控件上设上这个属性能省掉一层背景绘制。前提是你自己在paintEvent里把整个区域都填满了不然会看到花屏。还有Qt::WA_StaticContents适合内容只增不减的滚动区域能减少滚动时的重绘量。这些属性不是万能药用之前先确认自己的绘制逻辑能不能配合。3.3 高频刷新下的几个性能陷阱第一个陷阱是在paintEvent里做耗时操作。paintEvent会被频繁调用你在里面查数据库、做字符串格式化、算复杂几何每次都要重来一遍。正确的做法是把这些计算提前做好缓存起来paintEvent里只做绘制。第二个陷阱是频繁创建和销毁对象。有人在paintEvent里new一个QPen、new一个QFont画完delete。这种写法在低频刷新下看不出问题高频下就是灾难。QPen、QBrush、QFont这些都是轻量对象直接栈上创建就行没必要堆分配。第三个陷阱是信号槽的重复连接。界面初始化的时候连一次就够了如果每次数据更新都连一次槽函数会被调用N次重绘请求也跟着翻倍。这种问题在动态创建控件的时候特别容易出现建议连接之前先disconnect一下或者用Qt::UniqueConnection。第四个陷阱是字符串拼接。实时显示的数字转字符串如果每帧都做一次QString::number再加单位开销不小。可以用QLabel的setNum配合固定格式或者干脆自己维护一个字符缓冲区只在数值真正变化的时候才更新。4. 触摸屏程序上传的完整实操流程4.1 上传前必须确认的四件事触摸屏上传程序失败八成不是操作问题而是前置条件没满足。我一般会先确认这四件事能省掉大量来回折腾。第一确认屏幕型号和固件版本。不同型号支持的上传方式不一样有的只支持USB从口有的走以太网有的两者都行。固件版本也要看老固件可能有上传相关的bug新固件可能改了通信协议。型号一般在屏幕背面铭牌上或者开机画面、系统设置菜单里能看到。第二确认组态软件的版本。这一点最容易被忽略。工程文件是有版本号的用低版本软件打开高版本工程通常直接报错用高版本软件打开低版本工程一般能开但保存回去之后可能就不兼容老屏幕了。稳妥的做法是现场维护用的电脑上装和当初开发时一致的软件版本。第三确认屏幕端有没有开放上传权限。很多厂商出于保护知识产权的考虑默认关闭上传功能或者需要输入密码才能上传。这个开关通常在工程设置的“安全”或者“下载设置”里也可能在屏幕的系统菜单里。如果当初开发的人没开或者密码丢了那就传不出来只能找原开发者要工程文件。第四确认通信物理链路。USB线要接的是屏幕的“从口”或者标着“USB Slave”的口接错口是没反应的。网线要确认屏幕和电脑在同一网段比如屏幕是192.168.1.10电脑就设成192.168.1.100子网掩码255.255.255.0。电脑的防火墙有时候会拦通信端口测试阶段可以先关掉通了之后再按需放开。4.2 分步操作与参数配置前置条件确认完操作本身其实不复杂。下面这套流程是通用逻辑不同品牌的菜单文字会有差异但步骤顺序基本一致。第一步把屏幕切到可以通信的状态。有些屏幕正常运行时通信口是被占用的需要进系统菜单选择“下载模式”或者“传输模式”。这个状态下屏幕一般会显示等待连接的提示画面停止刷新属于正常现象。第二步打开组态软件新建一个空工程或者直接选择“从设备上传”。注意不要在有未保存修改的工程里做上传避免覆盖。第三步选择通信方式并填参数。以以太网为例需要填屏幕的IP地址、端口号。端口号每个厂商不一样软件里一般有默认值不确定就查手册。填完点“测试连接”能通再往下走。USB方式的话先确认设备管理器里能看到对应的串口或者USB设备看不到就是驱动没装好。第四步指定上传的工程保存路径和文件名。这一步建议单独建一个文件夹文件名带上设备编号和日期比如“包装机1号_20240520”以后回滚或者对比版本的时候方便找。第五步开始上传。进度条走的时候不要断电、不要拔线、不要切屏幕的页面。上传时间跟工程大小有关画面多、配方数据多的工程可能要几分钟。第六步上传完成后先别急着关软件直接打开刚传下来的工程逐个画面翻一遍。重点看画面数量对不对、控件位置有没有偏、变量地址表全不全、配方数据在不在、报警定义有没有丢、脚本和宏能不能正常打开。4.3 上传后的验证清单上传成功不等于工程可用。我整理了一份自己每次都会过的检查项照着走能避免很多回头路。检查项检查方法常见异常画面完整性逐页翻看对比原设备显示画面缺失、控件错位变量地址打开变量表核对地址和数据类型地址偏移、类型不匹配配方数据进入配方编辑看条目和数值配方为空、数值被截断报警定义查看报警列表和触发条件报警条目丢失脚本与宏打开脚本编辑器编译一次语法报错、函数缺失通信设置核对协议、波特率、站号参数被重置为默认值用户权限检查用户等级和密码设置权限表为空这份清单看着繁琐但一次完整的核对也就十几分钟比到了现场发现配方丢了再返工要划算得多。5. 常见问题速查与排查思路5.1 Qt刷新类问题的排查顺序界面不刷新我一般按这个顺序查从便宜到贵从常见到罕见。先看数据有没有真的变。在数据赋值的地方打一行日志或者在调试器里看变量。如果数据本身没变那问题在采集或者通信层跟刷新没关系。再看信号有没有发出去。如果用的是信号槽确认connect的返回值是不是true确认连接的类型是不是Qt::QueuedConnection导致延迟。跨线程的信号槽默认是队列连接数据到了槽函数里可能已经晚了一拍。然后看重绘有没有被触发。在paintEvent里打日志看它到底被调了几次。如果一次都没调说明update()没生效检查控件可见性、父控件状态、有没有被setUpdatesEnabled(false)关掉。最后看绘制内容对不对。如果paintEvent调了但画出来还是旧数据说明绘制时读的数据源不对可能是缓存没更新也可能是读了一个副本。还有一种情况是界面刷新了但看起来“没刷新”比如数值变了但颜色没变或者进度条动了但数字没动。这种属于局部更新逻辑写漏了改数据的时候只通知了部分控件。5.2 上传类问题的典型表现上传失败的报错信息往往很笼统就一句“连接失败”或者“设备无响应”得靠现象去判断。现象一点测试连接一直转圈然后超时。先ping一下屏幕的IPping不通就是网络层的问题查网线、查IP网段、查屏幕有没有进下载模式。ping得通但连不上多半是端口号填错了或者电脑防火墙拦了。现象二USB连接电脑没反应。打开设备管理器看有没有未知设备。有的话是驱动问题装厂商提供的驱动。没有的话换根线试试有些USB线是纯充电线没有数据线芯。现象三上传到一半中断。常见原因是工程太大超时或者通信质量不稳定。可以试着降低通信速率或者分段上传如果软件支持。也可能是屏幕存储空间不足清理一下再传。现象四上传成功但打不开工程。软件版本不匹配的可能性最大。看一下报错里的版本号装对应版本的软件。还有一种可能是工程被加密了上传下来的是加密包需要原开发者的密钥才能解开。现象五屏幕根本不允许上传。这个没辙只能找原开发者。如果实在找不到就只能根据设备实际运行表现反推逻辑重新做一版工程。所以我在项目交付的时候都会留一份完整的工程源文件给客户并且把上传密码写在交付文档里就是为了避免后面这种事。注意有些低端型号的触摸屏硬件上就不支持上传只能下载。采购的时候如果在意后期维护这一点要提前问清楚别等设备装到现场才发现。6. 把刷新和通信解耦一个更耐用的工程结构6.1 数据层到UI层的单向流前面讲的刷新问题很多根源在于数据和界面耦合太紧。数据一变就直接操作控件控件一多、逻辑一复杂就不知道该在哪一层做节流和合并。我习惯的结构是三层采集层负责从设备读数据写进一个共享的数据模型模型层做数据校验、单位换算、越限判断UI层只负责从模型里读值、按自己的节奏刷新。中间用信号通知“数据更新了”但不直接调控件的setText。这样做的好处是UI的刷新频率可以独立于数据频率。数据100ms来一次UI可以攒够5次再刷也可以只刷变化的部分。采集层出问题也不会把界面拖死界面卡了也不影响采集继续跑。调试的时候你可以在模型层加断点看数据流在UI层加断点看刷新两边互不干扰。具体实现上模型层维护一个带版本号的数据结构每次更新版本号加一。UI层的定时器到点了比较本地记录的版本号和模型的最新版本号不一样才刷新。这个做法比在每个数据变更点都发信号要省事尤其适合数据点很多的场景。6.2 现场维护与备份习惯上传程序的场景本质上是在做“灾难恢复”。与其等出了问题再想办法不如在项目还在自己手里的时候就把退路留好。我现在交付任何带触摸屏的项目都会做三件事。第一把完整的工程源文件、编译后的下载文件、软件安装包、驱动全部刻一张盘或者拷一个U盘跟设备一起交给客户并且在文件名上写清楚版本号和适用型号。第二把上传密码、系统菜单密码、各等级用户密码整理成一张纸贴在电控柜内侧只有维护人员能看到。第三在工程里把“允许上传”打开除非客户有明确的安全要求要关闭。这三件事花不了半小时但能省掉未来某一天在客户现场抓瞎的半天。我吃过这个亏——有一次设备换备件新屏幕是空白的原开发者已经离职工程文件找不到最后只能照着设备实际动作重新做界面和逻辑前后折腾了两天。从那以后备份这件事我就再没偷过懒。对于Qt这边我也有个类似的习惯把界面的刷新周期、数据源地址、关键参数都做成可配置的写在配置文件里。现场调试的时候不用重新编译改个配置重启就行。这个做法在需要适配不同型号设备的项目里特别好用同一套程序改几个参数就能用在不同的机台上。
