吓人的技术之不需要编程的LabVIEW界面刷新

--界面改动的原因--

对测控软件来说，界面改动，是很常见的事：

1）对于软件来说，正是灵活性、易修改（现在来看这个已经不是说成本问题，而是可能性问题），使它从硬件手中接过业务设计，双方形成互补（注意，不是软件配合硬件，而是硬件配合软件，因为基础技术包括软件层的基础技术是要为业务服务的），因而软件的界面乃至功能修改，客观来说是存在的，因为它为此而设计；

2）前期需求沟通不明确导致后期修改频繁，这是硬件主导项目的弊病，因为基础技术越来越呈现出可互换的透明性，尤其是数据采集领域，硬件基础技术向通用化发展的代价就是业务相关转化为软件开发，所以硬软占比几乎从1:1转变为1:3，前期软件工程师从硬件手中获取的需求几乎没有（业务需求和系统需求，业务需求从客户流经硬件已损失掉大半需求）

3）客户看到软件后，会刺激他的想法，激发出更多需求，逻辑思维不是超强的人，通常只能做最近几步棋的部署，对于客户也是一样，在看到雏形之前很可能无法细化自己的需求（这也是迭代、原型软件工程盛行的原因），对于我们手机上的各种app，我们随随便便就能点评出不少不方便的地方，尽管他们面世之前，我们根本想不到还能有个这样的东西。这其实是软件的功劳，是对基础需求+深度需求的满足，是软件代替系统工程师完成了需求挖掘。

--界面改动分类--

界面改动，在测控界经常存在于以下几种情况：

1）控件摆放

2）表达形式

3）增加通道（采集通道和算法通道）

4）功能和实现的变动

第四种情况比较复杂，我们集中讨论前三种情况。

从需求分析到设计时，我们首先会设计软件中的数据流和命令流，根据功能拆分，把界面做拆分，再根据界面呈现的需求，进行控件样式的确定和摆放，然后根据数据走向选取队列命令或者数据池获取数据等多种方式中一种或多种进行设计。

这个设计过程层层紧扣，这也是为什么更改需求带来的软件改动成本也是很大的，因为需要自上而下再次修改，改完设计还要改实现。

但我们可以借助一些通用型的工具或组件，将功能实现分为若干个微服务，改进我们的程序设计（微服务是可以独立开发和应用的单一服务或应用，我们可以借鉴这种风格）

--设计--

基于这种思路，界面刷新总体可以分为

1）界面布局

2）数据准备

3）控件获取

4）刷新规则

5）控件刷新

当做界面布局改动，包括控件在不同子面板间移动时，只有1）做改动；当控件表现样式改动，只做5）改动；当增加通道，只对2）和3）做改动（当然，还有一种方法使2）改动也省略掉，不过那是采集配置和数据池方面的设计，不在今天讨论范围内）

在界面布局上，做到界面只留有控件，而不在该界面中直接赋值；

数据准备上，把采集的数据按来源和类型分到不同的数据池中；

控件获取根据vi引用拿到全部控件的引用；

刷新规则，测控行业的刷新通常为采集数据和算法处理数据，我们可以为采集通道和算法通道编一组唯一tag，数据池和刷新根据tag建立对应关系。

控件的引用获取

通过面板引用，获取的控件引用不包括tab页中的，簇中的，需要根据tab页引用和簇引用进一步获取：

选项卡获取每页中的控件引用

簇引用中的控件引用

并应该注意到控件的嵌套，比如簇中包含簇。

根据vi，获取控件引用的tag 类型 方向。

建立规则

在刷新前确定好通道和控件的绑定关系，避免在每次刷新时根据tag查找数据池数据更新。

刷新

根据规则建立的关系，直接刷新控件

对项目的工艺图进行打乱和重整 形成的demo界面

上图界面，界面刷新不需要编程，只需要tag对应，其中包括簇、数值、布尔控件的刷新

应用这种方法，我们的界面可以根据客户需求拆分出多个子vi，vi不需要编程，只需要在刷新控制的vi里，加入上述刷新工具包即可。

对于界面的事件，也可以通过注册事件来简化界面上的编程，但相对于改动来说，代价较大，因为这方面的改动通常来源于需求分析不彻底。

这种方法，对测控的界面需求做了分类和针对性的工具设计开发。但并非适应所有的情况，我们还可以通过其他方法，来简化开发和后期改动。

没有最好的架构，只有最适合的架构，这对于工具包的选取也是一样的。

下一次，将介绍一个控件搞定所有（有点夸大），欢迎阅读～