拓冰建站拓冰建站
首页 / 资讯中心 / 正文

LabVIEW让多个测试用例共享同一个波形图控件的实现方案

阅读时间约5分钟适用人群自动化测试与测量程序的开发者需要在多个测试用例、多个循环之间复用同一个前面板波形图并希望了解数据传递机制与程序架构设计原则的LabVIEW使用者一、背景与问题现象在自动化测试程序中经常需要根据用户选择的测试类型执行不同的测量流程并在同一个仪器前面板上展示测量结果。以常见的电流-电压特性曲线测量为例用户可能从多种设备或多种测试条件中选择其一程序随后进入对应的测量循环对被测对象逐点扫描并得到一系列数据点。此时一个很自然的问题是不同测试用例产生的数据能否汇入同一个波形图控件进行显示直觉的实现方式是为每个测试用例单独放置一个波形图在各自的用例分支内完成绘制。这种做法虽然简单直接却会带来明显的弊端随着测试类型增多前面板上会出现大量内容重复的图表界面空间被严重浪费每个图表各自维护坐标范围、显示外观与曲线样式统一管理十分困难更重要的是各图表之间相互孤立数据散落在不同控件中无法横向对比后续处理也相当不便。当被测对象本身需要连续多次测量、测量程序已经处于循环之中时问题会进一步加剧。测量循环每迭代一次就要刷新一次图表而用户切换测试用例又发生在不同时刻如何在循环不断迭代、用例不断切换的情况下让同一个图表持续正确地更新成为设计上的关键难点。二、根因分析之所以会出现每个用例一张图的困境根源在于把显示控件错误地当成了用例内部的局部资源。波形图控件位于前面板本质上是程序与用户之间共享的资源一旦被放进某个用例分支内部它就成了该分支私有的显示出口其它用例自然无法访问只能各自复制一份。更深层的原因在于对数据传递机制的理解不足。波形图在循环中需要持续更新而数据产生的位置测量循环内部与显示的位置前面板控件之间隔着循环边界与用例分支。跨过这条边界传递数据必须借助LabVIEW专门的数据流机制例如反馈节点、移位寄存器、队列或局部变量。如果对这些机制缺乏认识就容易退回到复制控件这种最笨拙的方案。此外很多程序在架构上把所有逻辑堆在一个循环里把界面控件当作全局变量使用既容易引发读写竞态也使数据流向变得混乱最终导致共享显示无从谈起。要解决这个问题关键是把测量产生数据与图表显示数据两个职责分离开来。三、共享显示的几种实现方案针对多个用例共享一个图表的需求有以下几种经过实践验证的方案。方案一是独立显示循环配合队列。在程序中单独开辟一个循环专门负责更新波形图各测试序列通过队列把测量数据发送给这个显示循环。显示循环不断从队列中取出数据并更新图表与测量循环互不干扰。这种方案把采集与显示彻底解耦测量循环可以任意切换用例只要数据送入队列图表就能持续更新不会因某个用例的阻塞而中断。方案二是利用反馈节点在测量循环内累积数据。反馈节点会在本次迭代结束时把输入值暂存起来并在下一次迭代开始时把暂存值送回上一次连线的位置从而在循环内形成数据的自我引用与历史累积。在测量循环中每次完成一次扫描后把新测量的波形数据与反馈节点输出的历史数据合并再送入波形图更新显示。如此每迭代一次图表就追加一个数据点所有用例分支都可以把各自的测量结果汇入同一条反馈通道。需要注意反馈节点的初始化端应连接到空数组常量以保证首次迭代从空数据开始避免图表第一帧出现异常。方案三是移位寄存器配合事件结构。将测量数据保存在移位寄存器中当检测到数值变化事件时再把最新数据写入波形图。事件结构会在相关控件值发生变化时触发此时将寄存器中的最新测量结果推送到图表。这种方案同样实现了采集与显示的解耦数据随循环流动显示仅在需要刷新时进行避免高频采集下图表控件的无谓刷新。方案四是将多个图表组成数组或簇数组通过切换显示索引来展示对应测试的数据。该方法把若干图表控件放入数组每个用例对应一个索引用户选择测试时即切换当前显示的那个图表。这种方案适合曲线数量固定、每个测试的数据结构差异较大的场景界面仍能保持整洁。四、程序整体架构的选择上述方案解决了数据传递问题但要支撑用户选择多个测试、数据全部进入同一张图的完整需求还必须在整体架构上作出安排。实践中常见三种架构改造工作量由小到大排列。状态机架构以程序状态作为主要控制信息每个状态对应一类操作。可以在空闲状态中放置事件结构处理界面操作在其它状态中执行测量。状态集合推荐使用类型定义的枚举常量进行管理后续新增测试类型时只需扩展枚举并添加对应分支代码的模块化程度会显著提高。状态机的实现形式有直接式、数组式、队列式和事件式之分其中直接式结构最简单通常已能满足需求必要时可以平滑迁移到其它形式。事件驱动架构以事件结构为主控制器在超时分支或用户事件分支中执行测量适合界面交互密集的应用。生产者消费者架构则把采集与显示分离到两个不同循环中采集循环负责测量并写入队列显示循环从队列取出数据更新图表两个循环通过队列解耦、速率彼此独立。三者之中生产者消费者架构的改造量最大但灵活性与健壮性也最好尤其适合高数据率场景。三种架构有一条共同的核心原则主循环中的状态与数据都应通过移位寄存器传递而不是借助大量的前面板控件或局部变量。这样既能避免不必要的控件读写与数据副本也能让数据流清晰直观便于维护和扩展。五、易错点与常见误区共享显示的实现过程中有几个易错点需要特别注意。第一把波形图控件直接放进用例分支内部这会使图表随用例数量成倍增加是首要避免的做法。第二忘记给反馈节点连接初始化端导致首次迭代读到的历史数据是默认值图表第一帧出现异常。第三多个循环同时读写同一个前面板控件容易引发竞态条件数据更新可能出现丢失或覆盖。第四滥用局部变量和全局变量传递测量数据虽然局部变量可以跨循环读取控件值但它引入的隐式数据流难以追踪是程序难以维护的常见原因。第五高频采集时在每次迭代中都强制刷新图表可能拖慢测量循环正确做法是仅在数据发生变化时刷新或在独立的显示循环中更新。六、实践建议与小结在实际项目中可以遵循以下建议。第一优先把波形图从用例分支中移出放到主循环或独立的显示循环中让每个用例只负责产生数据而不是负责绘制。第二若测量速率较高优先采用生产者消费者架构通过队列在采集与显示之间传递数据即使测量循环短暂阻塞显示也不会丢帧。第三状态集合使用类型定义枚举管理新增测试类型只需扩展枚举并添加对应分支无需改动原有逻辑。第四尽量把状态与数据保存在主循环的移位寄存器中减少对控件的读写保持数据通路清晰。从根本上看波形图控件的数量不应随测试类型增长而应保持唯一由数据通路决定显示内容。把测量逻辑与显示逻辑分离用队列、移位寄存器或反馈节点这类数据机制完成跨用例的数据汇聚才能得到界面简洁、扩展方便、易于维护的测试程序。
分享:

看完干货,该让你的企业上线了

免费需求沟通 · 48 小时内出具建站方案 · 河南本地可上门