荣小菜补钙记第33期:基于labview Actor Framework的连续测量和记录系统1 同步更新于 WeChat:荣小菜在补钙 大家好,我是荣小菜,也可以叫我Richie,从本期开始打算开始写个小系列,基于LabVIEW Actor Framework来搭建一个数据连续采集处理系统,最终看看它能承受多大的数据量冲击。本期先从基础一点的开始讲,毕竟整个系统涉及执行速度优化、内存优化、架构设计等一系列问题。 1. Actor Framework简介 LabVIEW Actor Framework是什么不再多讲了。大家可以去看我原先发的帖子。 https://bbs.elecfans.com/jishu_1940632_1_1.html(LabVIEW OOP使用AF框架实现简易Chat Room) https://bbs.elecfans.com/jishu_1943690_1_1.html(LabVIEW Actor Framework学习之八皇后) https://bbs.elecfans.com/jishu_1944537_1_1.html(LabVIEW Actor Framework学习之N皇后) Actor的核心就是发送Message,触发对应的Vi执行。因此掌握Actor起码先要大概明白Message机理。对于新人来说,发送个Message,执行了对应Vi弹了个对话框,就感觉学会了。但是Message是如何指向对应Vi的,发送Message后又代码是如何运行的呢,不同Message是并行还是串行呢? 2. Actor的简单Demo演示 从Actor的底层可以看出,见vi.libActorFrameworkMessage DequeuerMessageDequeuer.lvclass 和 vi.libActorFrameworkActorActorCore.vi,每个Actor的Message执行是单线程的,通过Message Enqueue /Dequeue queue在Actor Core中运行对应Vi。 因此,一个Actor接收自身MessageEnqueue,虽然可触发对应Vi执行,但一个Vi执行完毕后才能执行下一个。若执行慢,则Message Wait Queue会累积。 具体演示见Demo,代码的话只需看的AlphaAcotor及其父操作者。Alpha操作者种,两Task都不断发送消息类,Task2 Vi种采用 延时3s来表运行耗时较多,结果Task 和 Task2 3秒刷新一次,展示了单个Acotr Message执行的方式,是单线程。
3. 系统关键点-大数据处理 可以想象,若大量数据快速采集,可能导致大量Messge发送,当快速发送Message并包含大量数据时,整个Actor调用链是需要仔细构思的,快速的Message很容易淹没其它低速Message,若是再包含大量用户事件触发,就会造成大量Message和事件累积,最终导致程序崩溃。 因此,在连续测量和记录系统中,当面临大数据冲击时,基本思路就是处理不了的合理丢掉或存盘,没必要显示的别折腾或变相/间隔显示。 解决办法1:建立二级缓存队列,多While出队列并行。Message对应的Vi只入二级缓存队列,但是这样意义不大,解决不了真正的问题,而且Actor工作机制本来就是队列了。层层缓存大大增加复杂度,Actor的灵活性降低。 解决办法2:将速度慢的部分拆分建立新Actor,这要求合理规划数据结构。 解决办法3(对于UI刷新):将涉及到更新UI的慢Actor Vi改为触发用户事件,能提高性能。但是更新UI终归是慢的,若快速大量触发更新UI用户事件,还是会造成事件累积。相当于将Message Queue累积转到UI更新的用户事件累积了。此时可选择定时清理累积的用户事件或合理减少触发UI更新用户事件次数。 大数据处理会遇到各种问题,可以预见整个系列都会围绕这些问题想办法。 其它注意事项:对于要求快速执行的Actor,不能在其Message Vi中使用弹出框等交互式UI,对于重要提示有时可能为了方便使用弹出框,但至少也应该采用定时关闭的。一种较好的解决办法还是改为触发用户事件。Demo演示如下,交互式UI弹出后就阻塞了Actor的正常运行。
4. 总结 写了将近6个小时,算是为该系列开个头,个人感觉LabVIEW Actor讲起来还是挺复杂的,由于本人水平有限,只能说说基础的应用。现在资料相对较少,还是希望大神们能多多分享,说说Actor的适用范围,有何优缺点;讲讲自己团队是如何使用的Actor的。 源代码:
(基于操作者框架模板,说实话该模板不太好) Actor Framework,期望各位大神分享更多实用资料^_^
|