LabVIEW中的引用、属性节点、局部变量全局变量等的区别

本文深入探讨了LabVIEW中全局变量、局部变量、属性节点及控件引用的合理使用方法,强调了滥用变量对程序性能与可读性的负面影响,以及属性节点和控件引用在特定场景下的高效应用。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

最近想深入学习LabVIEW,对于控件的使用上遇到了选择上的问题,如何合理的使用控件引用、属性节点、局部变量全局变量等,结合帮助文档和网上资料,总结如下:

1、全局变量和局部变量

局部变量和全局变量是内存数值操作,属性节点是对控件值的属性进行的操作。理论上,变量的效率比属性节点高。局部变量的作用域是整个VI,它用于在单个VI中传输数据;全局变量的作用域是整台计算机,它主要用于多个VI之间共享数据。

但在实际写程序中,大量全局变量的应用和不必要的局部变量会拖慢程序的性能和可读性,并且一般使用变量的时候有很大的随意性,导致后期维护的难度增加,牵一发而动全身,改变了一次赋值后要挨个去找这个变量的影响应用范围。再者,根据实际经验,全局变量在多层VI嵌套之后再赋值,另个一VI或同VI中其他循环对数据进行轮询,会出现两者不同步的现象,原因可能有循环的时间间隔不同,内存相应时间不同等,尤其是在通讯数据处理过程中,隐藏了很大的BUG。以下为官方帮助文档内容

谨慎使用局部变量和全局变量:

局部和全局变量是高级的LabVIEW概念。它们不是LabVIEW数据流执行模型中固有的部分。使用局部变量和全局变量时,程序框图可能会变得难以阅读,因此需谨慎使用。错误地使用局部变量和全局变量,如将其取代连线板或用其访问顺序结构中每一帧中的数值,可能在VI中导致不可预期的行为。滥用局部变量和全局变量,如用来避免程序框图间的过长连线或取代数据流,将会降低执行速度。

局部变量和全局变量的初始化:

如需对一个本地或全局变量进行初始化,应在VI运行前将已知值写入变量。否则变量可能含有导致VI发生错误行为的数据。如变量的初始值基于一个计算结果,则应确保LabVIEW在读取该变量前先将初始值写入变量。将写入操作与VI的其它部分并行可能导致竞争状态。

要使变量初始化在VI其他部分执行之前完成,可将把初始值写入变量的这部分代码单独放在顺序结构的第一帧。也可将这部分代码放在一个子VI中,通过连线使该子VI在程序框图的数据流中第一个执行。

如在VI第一次读取变量之前,没有将变量初始化,则变量含有的是相应的前面板对象的默认值。

竞争状态:

两段或更多代码并行执行并访问同一部分内存时会引发竞争状态。如果代码是相互独立的,就无法判断LabVIEW按照何种顺序访问共享资源。

竞争状态会引起不可预期的结果。例如,两段独立的代码访问同一个队列,但是用户未控制LabVIEW访问队列的顺序,这种情况下会引发竞争状态。

竞争状态随着程序运行的时间因素而改变,因此具有一定的危险性。操作系统、LabVIEW版本和系统中其他软件的改变均会引起竞争状态。

如改动了VI的时间要素(例如,更新操作系统或LabVIEW版本),请检查访问同一部分数据的并行代码,并使用定时条件来控制哪一部分代码首先执行。

使用局部变量和全局变量时的竞争状态:

对同一个存储数据进行一个以上更新动作均会造成竞争状态,但是竞争状态通常在使用局部变量和全局变量或外部文件时出现。以下程序框图显示了一个局部变量造成竞争状态的范例。

该VI的输出,即本地变量x的值取决于首先执行的运算。因为每个运行都把不同的值写入x,所以无法确定结果是7,还是3。在一些编程语言中,由上至下的数据流模式保证了执行顺序。在LabVIEW中,可使用连线实现变量的多种运算,从而避免竞争状态。下列程序框图通过连线而不是局部变量执行了加运算。

提示:  如必须在局部变量或全局变量上执行一个以上操作,则应确保各项操作按顺序执行。

如两个操作同时更新一个全局变量,也会发生竞争状态。如要更新全局变量,需先读取值,然后修改,再将其写回原来的位置。当第一个操作进行了读取-修改-写入操作,然后才开始第二个操作时,输出结果是正确的,可预知的。第一个操作读取值,然后第二个操作读取值,则两个操作都修改和写入了一个值。这样操作造成了读取-修改-写入竞争状态,会产生非法值或丢失值。

要避免全局变量引起的竞态,可使用功能全局变量(高级应用暂不介绍)保护访问变量操作的关键代码。使用一个功能全局变量而不是多个本地或全局变量可确保每次只执行一个运算,从而避免运算冲突或数据赋值冲突。

使用局部变量时应考虑内存:

局部变量复制数据缓冲区的数据。从一个局部变量读取数据时,便为相关控件的数据创建了一个新的缓冲区。

如使用局部变量将大量数据从程序框图上的某个地方传递到另一个地方,通常会使用更多的内存,最终导致执行速度比使用连线来传递数据更慢。如在执行期间需要存储数据,可考虑使用移位寄存器。

使用全局变量时应考虑内存:

从一个全局变量读取数据时,LabVIEW将创建一个数据的副本,保存于该全局变量中。

操作大型数组和字符串时,将占用相当多的时间和内存来操作全局变量。操作数组时使用全局变量尤为低效,原因在于即使只修改数组中的某个元素,LabVIEW仍对整个数组进行保存和修改。如一个应用程序中的不同位置同时读取某个全局变量,则将为该变量创建多个内存缓冲区,从而导致执行效率和性能降低。

2、属性节点

获取(读取)和/或设置(写入)引用的属性。通过属性节点对本地或远程应用程序实例、VI或对象获取或设置属性和方法也可通过属性节点访问LabVIEW类的私有数据。

属性节点可自动调整为用户所引用的对象的类。LabVIEW的属性节点可访问XML属性、VISA属性、.NET属性和ActiveX属性。

连线引用句柄至引用输入端可指定执行该属性的类。例如,要指定的类是VI类、通用类或应用程序类,可连线VI、VI对象或应用程序引用至引用输入端。节点将自动调整为相应的类。此外,也可右击节点,在快捷菜单中选择类。

可将LabVIEW类连接至属性节点的引用输入。如该LabVIEW类拥有属性节点可用的访问器VI,可通过属性节点读取或写入访问器。

属性节点在Labview中是一个很重要的概念,属性节点用于访问控件的属性,例如需要改变控件在前面板的大小,运行时候的状态等都需要通过属性节点来进行操作,与引用结合起来讲就是属性节点可以设置引用的属性。Labview的属性节点功能强大,不同的控件有不同的引用,这些不同的引用都可以通过各自的属性节点来进行设置,但需要注意的是,属性节点的执行效率比较低,甚至比全局变量的效率还要低,所以NI一般建议少用属性节点。

3、控件引用

在Labview中称为引用句柄,在Windows编程中,引用句柄指的是指向指针的指针,换句话说,引用句柄保存的是其他一些数据类型的地址,例如窗口句柄。在Labview中,控件的引用句柄指的也是指向特定数据类型的指针,在Labview中,控件的引用句柄是长度为四个字节,引用句柄不但能够表示控件的类型,还与空间一一对应,这是通过句柄的编号来实现的,引用句柄自身未代表任何空间,但是通过引用句柄指向特定的实例后,就可以操作具体的控件了,简单的理解就是通过对引用句柄的操作,可以改变控件的属性参数。

参考资料:

(1)https://www.cnblogs.com/yuexinzheng1989/p/4443048.html

(2)NI官方帮助文档

<think>嗯,用户想比较LabVIEW属性节点引用局部变量队列传递在速度内存占用方面的性能差异。这个问题很专业啊,看来用户应该是LabVIEW的开发者,正在做性能优化相关的工作。 从用户提供的引用内容来看,有几个关键点值得注意:引用[1][3]都提到属性节点执行效率低,甚至比全局变量还低;引用[2]强调了队列引用释放的重要性;引用[4]则详细讨论了内存优化的各种技巧,特别提到前面板控件属性节点会占用较大内存。 用户可能正在开发一个对性能要求较高的LabVIEW应用,遇到了内存占用过大或执行速度慢的问题,所以想了解不同数据传递方式的性能差异。用户可能最关心的是在实际工程中如何选择最优方案。 让我想想怎么组织这个回答。首先需要明确几个概念:属性节点主要用于操作控件属性引用是对象的句柄,局部变量用于访问前面板控件值,队列则是线程安全的数据传递机制。性能方面可以从执行速度内存占用两个维度来分析。 在速度方面,根据引用内容,属性节点是最慢的,因为它需要与前面板交互;局部变量次之;引用队列相对较快。内存方面,队列需要注意及时释放引用,否则会内存泄漏;属性节点会保持前面板在内存中;局部变量会复制数据。 用户可能还需要一些实际应用建议,比如什么时候该用什么方式。引用[4]提到的“避免在子VI中使用属性节点”、“使用移位寄存器减少内存复制”这些建议都很实用。还应该提醒用户,在需要线程安全时队列是最佳选择,而单纯传递数据时局部变量可能更高效。 对了,用户提供的引用[2]有个很好的队列使用示例,可以借鉴来说明队列的正确用法。引用[4]关于数组处理的建议也很有价值,因为大数组处理不当会严重影响性能。 最后考虑设计几个相关问题,帮助用户深入理解:比如如何检测内存泄漏、多循环通信的最佳实践、性能测试方法等。这些问题应该能覆盖用户可能遇到的后续疑问。</think>以下是LabVIEW属性节点引用局部变量队列传递的性能对比分析(综合速度与内存占用): --- ### **1. 属性节点** - **速度**: 最慢的执行方式。每次操作需通过LabVIEW UI线程访问前面板控件属性(如颜色、尺寸),涉及跨线程通信界面渲染开销[^1][^3]。 - **内存占用**: 高。属性节点会强制将控件关联的前面板保留在内存中,即使该VI未显示[^4]。频繁操作大控件(如图表、数组)时内存消耗显著增加。 - **适用场景**: 动态修改控件外观(如禁用按钮、调整图表范围),但需严格限制使用频率[^1][^3]。 --- ### **2. 引用** - **速度**: 中等。引用是对象的轻量级句柄(如控件引用、VI引用),传递效率高于属性节点,但低于局部变量[^1]。 - **内存占用**: 低(引用本身)。但若未正确释放(如队列引用、文件引用),会导致**内存泄漏**,长期运行后内存持续增长[^2][^4]。 - **关键注意事项**: 必须配对使用 **“打开引用”** **“关闭引用”** ,否则引用资源无法释放[^2][^4]。 --- ### **3. 局部变量** - **速度**: 较快。直接访问控件数据缓冲区,无前面板交互开销[^3][^4]。 - **内存占用**: 中等。读取时可能复制数据(尤其大数组/字符串),但写入时若数据类型匹配可复用内存[^4]。 ⚠️ **风险**:竞态条件(多个局部变量同时读写同一控件时数据冲突)。 - **优化建议**: 对数组/字符串操作时,优先使用 **移位寄存器**(强制内存复用)[^4]。 --- ### **4. 队列传递** - **速度**: 中等(单线程)至高效(多线程)。队列是线程安全的FIFO结构,适合并行循环间通信,避免加锁开销[^2][^3]。 - **内存占用**: 可控但需主动管理。队列元素存储于独立缓冲区,传递时**不复制数据**(仅传递引用)[^2]。 ⚠️ **关键风险**:未调用 **“释放队列引用”** 会导致内存泄漏[^2][^4]。 - **最佳实践**: ```labview 创建队列 → 入队/出队操作 → 明确释放队列引用 ``` --- ### **性能对比总结** | **方式** | 速度排名 | 内存风险 | 线程安全 | 适用场景 | |----------------|----------|------------------------|----------|------------------------------| | 属性节点 | 最慢 | 高(滞留前面板) | 否 | 动态修改控件外观 | | 引用 | 中 | 泄漏风险(需手动释放) | 部分 | 跨VI对象控制 | | 局部变量 | 快 | 中等(可能复制数据) | 否 | 同一VI内快速数据访问 | | 队列传递 | 中-快 | 可控(需手动释放) | **是** | 多线程通信、流式数据处理 | --- ### **工程优化建议** 1. **减少属性节点**:仅在必要时操作控件属性,避免在循环中高频调用[^1][^4]。 2. **释放资源**:对队列、文件引用等,严格使用 **“关闭引用”** 或 **“释放队列”**[^2][^4]。 3. **大数组处理**: - 用 **移位寄存器** 替代局部变量,避免内存复制[^4]。 - 队列传递大数组时,启用 **“队列元素为引用”** 选项(LabVIEW 2018+)。 4. **内存监测**: 通过 **“性能与内存”工具包** 监控实时内存占用,定位泄漏点[^4]。 > 示例:队列的正确释放流程 > ```labview > 创建队列 → 循环内入队/出队 → 循环外调用“释放队列引用” > ``` > 若未释放,每次运行将累积内存占用[^2][^4]。 ---
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值