中大型LABVIEW软件三层设计架构 #1

fjczd

中大型LABVIEW软件三层设计架构 #1 通常一个VI若包含三、四十个以上的subVI(不包含LabVIEW本身在Functions中提供的VI)时，就可算是一个中大型的软件计划(software project)了。虽然比起软件工程中的一些作业环境软件(如Windows系列)或大型应用软件(如Word、Excel)等仍算是小工程，但其复杂性亦在一定程度之上，若没有事先想好在撰写程序时的一些规划与方法，想要完成这类中大型的软件绝对不是一件简单的事。尤其这类软件通常不是由一个人，而是由一个团队所共同完成的，因此整个软件的结构，就要能让团队中的每一成员都能清楚的了解，而且要够简单，才算是好的软件结构。以下将参考由Rick Bitter等人所着”LabVIEW Advanced rogramming Techniques”，中之第4章的部分内容，介绍所谓软件计划中的三层式结构(the Three-Tiered Structure)的概念及其优点。
   需要软件结构的主要原因，是当软件人员发展软件到某一阶段时，若没有计划或无意的创造了许多subVI，但各subVI之间有许多部分其实是重复撰写的；或各VI相互间呼叫时没有一定的纪律，使得在VI Hierarchy中所看到的各VI间的联机是错综复杂，像个盘丝洞一般，这将可能会使多人发展的软件计划增加所耗费的时间和可能出错的机会、减低程序的效率，以及增加debugging时的困难。为了改善上述的情形，所以要提倡三层式结构的概念。

   三层式结构由上而下依次为：Main Level、Test Level和Driver Level，这种结构是由经验中得来的，在多人发展的软件计划中显得简单明了，当大家都能遵照这个结构来写程序时，这种结构就可以充分显现出它的优点。那这三个阶层到底如何区别呢？以通俗的比喻来说，假设我们如果要组织一个篮球队参加全国比赛，每个球员要练习基本动作及体能，如何跑、如何跳、手脚该如何放置才是正确位置等，这就相当于系统中Driver Level所做的事情；接下来，将各球员组合练习某一套防守或进攻的战术，如二三区域联防、人盯人防守，每个人该在什么位置才能正确接应等，则像是Test Level中一项项的test了；而最后比赛时，场上的战略运用，包括何时要用什么战术组合、如何更换球员、何时喊暂停、终场前是不是要故意犯规或采拖延战术等等，对照过来，就像是在Main Level中，如何将Test Level中各test做最有效能的整合与排列组合等的工作。
   简单来说，Driver Level包含了程序与所有仪器、组件、马达或其它应用软件的沟通、控制等较低阶的事情，使其可完成某一项基本的动作，例如初始化、马达走到home位置、雷射以设定的能量及频率发射光束‧‧‧等。可注意到我们在这边所说的driver，并不像一般在别处所称驱动程序的那种driver那么低阶，真正最低阶的工作还是要有现成的VI来帮忙才行；在Test Level中，则是如何连接各个Driver VI的基本动作，使可做完出一套连续、有意义的流程，来执行某项测试，例如让手臂由A点走到B点，下降夹取一个螺丝，再走至C点装到某面板上，然后回到A点等待，类似这样控制一个流程的进行，便是Test VI的工作内容；Main Level则包含了使用者接口(User Interface)或称人机接口(Man-Machine Interface) ，目的是整合各项测试和例外处理(Exception Handling)等，将它们以适当的顺序及流程组合，很容易地让使用者操作。
    当一个软件计划严格的遵照上述的三层结构来撰写时，最大的优点是可使程序代码的再使用(code reuse)达到最大化，在不同的Test VI中，可重复使用相同的Driver VI；而在不同程序的Main Level中，又可重复使用相同的Test VI，这将使得程序维护或修改的时间与精力大幅减少；同时当我们已有一个程序的样板(template)后，可增加软件版本更新的速度。另一个很重要的好处是，当我们在撰写某一个level中的程序时，并不需要关心在另一个level中有什么其它的程序是如何执行的，而只要专注在自己的这个level的程序上就可以了，这使得由团队来共同完成一个大型计划的工作变得容易许多。

   以下将依Driver Level、Test Level、Main Level的顺序，来介绍在各level写程序时的原则与心得﹔
(1)  Driver Level﹔
通常在Driver Level所写的程序是比较低阶的，其功能是把一些最基本的I/O动作按某一顺序连接起来，形成基本动作，大致分为三大类﹔

a.  组态(configuration)：开启或关闭与仪器的连结、将仪器初始化及设定组态等。
b.  量测(measurement)：由仪器读出测量值或特定的资料。
c.  动作／状态(action/status)：一个流程的启始或结束动作、检查错误等。
简单来讲，Driver Level的内容是藉由一些接口(卡)，经digital I/O或analog I/O由仪器取得上一些sensor的电压值，或传出一些电压值来控制机器、仪器或马达等的组态与动作，使得仪器或机器能够正确设定及做出一些基本的动作。另外程序与仪器间的资料传递或在自身计算机的存取动作，规定档案的格式以及存取等等，也都属于Driver Level中应该完成的事项。但是真正最低阶的工作还是需要NI提供的VI来进行，我们所写的Driver VI仍是属于较高阶的。
以下举一个利用7344卡来控制马达动作，而使BM7移动的Driver VI实例﹔
首先要确定马达所有的动作有哪些，我们可简单分类如下﹔初始设定、找寻Home点、移到指定位置、以及回报现在位置等。当然我们必须先在MAX上做细部的设定，接下来再回到LabVIEW中来撰写Driver VI。
看起来我们必须写四个Driver VI来控制马达，但这样往往造成subVI过多的情形，因此我的建议是将关于同一个仪器或装置的Driver VI合并为一个。合并的方法为利用一个enumerated type的control加上case结构即可。完成后如下图﹔

利用名为Action的enum control来控制此Driver VI要进行何项动作。记得在编辑icon时，要将此enum control加到input terminal即可。
在Test Level中呼叫时的方法就可如下图所示了﹔
如此一来，我们便可以利用一个subVI来完成数个动作了，减少了一些管理subVI的辛苦。但请注意，这样的Driver VI要看情形而在其File> VI roperties…> Execution中设定为reentrant，因它很有可能同时被数个Test VI呼叫。

在大型程序计划发展时，一个观念很重要：Driver Level中的VI是整个软件计划中最重要的部分，它们的好坏直接决定了这个软件计划的成功与否和完成后的品质，就像要盖高楼大厦，打地基、灌水泥以及基本用料的好坏才是决定建筑物好坏最重要的地方，若基础的部分不好，无论大楼外观有多雄伟或多漂亮，假使地震一来，都有可能会倒塌。Driver VI若不先规划，往往会造成程序效率减低，以及重复的程序代码过多等现象。虽然在最后主程序执行时并看不到Driver VI，但它们可是最重要的无名英雄，所以在设计Driver VI时需要多费点心思喔！
(2)  Test Level：
在Test Level中的VI此处暂称为Test VI，它可以呼叫Driver Level的VI，但只能被Main Level中的VI呼叫。有一个不成文的规定：Test VI间不可以互相呼叫；否则会使三层结构又被破坏了。可是在写程序时，有时又觉得难以避免，或为了图方便想说就暂时先呼叫一下吧，若有这情形发生，那就要请重新检视一下Driver Level中的VI，是否要重写某些部分或在写一些新的Driver VI，以避免上述的情形发生。

有一个重要的原则，一个Test VI内只要安排一套完整的测试即可，不要在同一个Test VI中去完成两个(以上)的测试，否则未来若整个计划要作修改时，Test VI可能就又要修改了。一个完整的Test VI当然要包含对仪器设备的初始化，组态设定等，它是一个可以单独执行的VI，也就是说，即使此Test VI不放到Main Level之下，它也一样可以单独执行来完成一项测试。另一个重要观念是，各个Test VI间是不要有什么关联的，因为当在Main Level中的某个Test VI执行时，它并不确定前一个Test VI结束时的机器状态是否合于要求，因此要重新设定，或是要重新检查一下，以避免不能执行或有预料外的状况发生。
流程图对于我们来撰写Test Level中的VI是特别有用，因流程图的概念也正好就是LabVIEW中所谓data flow的概念，因此当一项测试的流程图清楚的画出来并能解释其流程时，即使我们还没有开始写程序，我们几乎可以说这个Test VI的程序设计已完成60%以上了，这一点也不夸张，因剩下的部分只是将流程图中各方块的连接，换成LabVIEW中各function VI或Driver VI的连接而已。
(3)  Main Level：

Main Level又称人机接口(Man-Machine Interface, MMI)，设计Main Level程序的中心观念是不仅要能完成测试外，而且操作上要越能user-friendly越好，因为当使用者在操作仪器设备时，他其实并不见得很关心细节的部分是如何运作的，他或许只希望能很轻松愉快的尽快完成工作，然后轻松愉快的下班回家。例如，使用者希望手臂能够走到某特定位置去夹取一个螺丝，最好是按下某个屏幕上的按钮就好了，只要看着屏幕上一切正常的讯息，说不定他还可以有时间悠闲地喝杯咖啡呢！

通常Main Level VI的设计往往利用while循环不断的polling，大部分的时候也不只一个while循环。其内容要包含几个重点：
a)     可让操作者设定或更改操作参数：
例如可选择何项测试及执行顺序、接口的地址、档案的路径等等，但也请注意，需设定的选项并非越多越好，太多的选项容易使人分散注意力而容易出错。
b)     在特定的情况下使用适当的Control：
有时Control需加些心思来点变化，以表示其不同的重要性，最简单的当然是以大小、颜色来区别，当然在执行时也可利用property node中闪烁的效果来强调，不过一般而言，常用的重要Control通常用按钮放在Front anel上显眼的地方；而较不常用的Control，通常利用放在cluster或tab control中，利用invisible的功能或换至其它页面使其平常不出现在Front Panel上。较不常用的按钮，也较不用按钮的形式，而可在Controls> Classic Controls> Boolean中选择Radio Button或Checkbox来使用。请记得一个原则，在Front Panel上可看见的Control越少越好，因出现越多的Control，设定的参数就越有可能因不小心而改变，进而造成错误发生，要避免这种情形，可将Control连上另一Indicator后，在将Indicator放到Front Panel显示其值即可。
c)     要将众多的Control及Indicator依使用功能分类，并适当地利用页面切换来显示。
d)     在执行程序时可以选择cancel或abort：
这对操作者而言是十分重要的，但却容易被程序设计者所忽视，因程序设计者会不经意的假设操作者是非常了解他所写的程序，又非常熟练，而且一定照正确步骤不会按错按键。但实际上操作者可能并不熟练或很粗心等等，有时若一旦按下某个按钮就不能后悔的话，很容易造成万劫不复的悲剧。请注意，程序设计者一定要在程序中加入在执行中跳出程序的方法，而尽量避免由操作者去按下toolbar上的abort(红色圆形按钮)来跳出程序。
e)     在Front Panel上多使用图形，避免过多的文字或数据。

f)      在Main Level中统一处理所有的exception massage：
这部分在程序设计中又称exception handling，在软件工程上也是需要专门课程来讨论的，同时，这部分对于产品的商品化是非常重要的，在此只先简单叙述，之后会有专门的专题来讨论。
先谈建立exception handling机制的好处：它可告知操作者哪里有出错，或需要注意，使不是十分熟练的新手操作者，减低发生状况的机会；也方便制造厂商与程序设计者容易做除错及故障排除的动作，使得整个系统的开发及维护能较有效且所短时间。
我们希望exception handling可达到下列几个功能：当测试过程有错误状况发生时，程序可以自动修复错误，并继续完成测试或重新测试一次；或当测试过程有错误状况发生，且此错误不能修复时，程序能自动跳过有问题的部分，并继续完成测试；或测试过程有错误状况发生时，程序会将整个系统暂停或终结，并告知操作者错误发生处。上面叙述起来似乎很简单，但实际上它需要程序设计者看到实际操作后的结果，再一项一项加到整个程序中，然后再故意发生错误来测试，也因为如此，它可算是整个软件计划发展过程中非常耗时耗力的一部分。
若藉用前述所提过的State Machine的写法，会使得exception handling的程序设计较为简单，因State Machine中原本就有安排一个error state，可让程序设计者在那里统一撰写处理各种exception/error message，然后在error state中判断，是回到原来的测试中，或是走到close state去结束此项测试。因此是强烈推荐采用State Machine的写法。

seanxl

深有体会，感谢共享！

summu

虽然没有机会编写大程序的机会，但是提高一下认识还是不错的！