4.3 LabVIEW圖形化編程語言的編程范式

當(dāng)前正在審批4.3LabVIEW圖形化編程語言的編程范式(LabVIEWgraphicalprogramminglanguage,programmingparadigm)版本7

創(chuàng)建于:2010-12-4下午7:01作者jwdz-最后修改:

2010-12-19上午12:35作者jwdz

上一節(jié)中曾簡要介紹了編程范式和幾種常見的編程范式。在本節(jié)中，我們將要進(jìn)一步說明LabVIEW圖形化編程語言的編程范式。

首先，我們要給出上節(jié)中所提到問題的最終答案。其實答案很簡單：LabVIEW是一種多范式的圖形化編程語言，它基本適合我們上面所談到的幾種編程范式。這也是上節(jié)中給出這幾種編程范式的真實目的。

下面我們就來一一的進(jìn)行簡單分析。

4.3.1LabVIEW圖形化語言的過程化（命令式）編程

我們已經(jīng)知道：過程化編程要求程序員必須要知道程序要完成什么，并且告訴計算機(jī)如何來進(jìn)行所需的計算工作，包括每個細(xì)節(jié)操作。簡言之，就是將計算機(jī)看作一個善始善終服從命令的裝置。

作為LabVIEW的實踐者，此階段可能已經(jīng)完成了許多圖形化代碼的程序設(shè)計工作，因為我們認(rèn)為本書的讀者對LabVIEW已經(jīng)有了充分的了解。但是，面對那些已經(jīng)完成的程序設(shè)計，大家可能根本無法感覺到我們在設(shè)計中采用了什么樣的編程范式。那么圖形化語言如何實現(xiàn)過程化編程的呢？

圖形化語言過程化編程的表示方法

回顧第3章的部分內(nèi)容，我們就不難發(fā)現(xiàn)：基于數(shù)據(jù)流編程思想的LabVIEW圖形化編程語言中，最基本、最廣泛使用的編程范式應(yīng)該就是過程化（命令式）編程范式。這點對于學(xué)習(xí)過和使用過這種編程語言的朋友們來講，我深信，應(yīng)該是非常好理解的。

在基于數(shù)據(jù)流的LabVIEW編程思想中，我們所強(qiáng)調(diào)的數(shù)據(jù)依賴性和充分利用公共線程必將導(dǎo)致其程序結(jié)構(gòu)都是基于過程化的。所以采用過程化編程范式是LabVIEW圖形化語言最基本、最顯著的特征，是我們必須自覺、不自覺采用的基本編程方式。特別是在儀器控制和數(shù)據(jù)采集過程中，由于圖形化語言的自身的點，這種過程化編程范式顯得更自然、更容易理解。

下面我們一起來看幾個簡單的實例。

例-1無相移濾波器

這個實例來自于LabVIEW2010(Mac版)自帶的例程（ZeroPhaseFiltering.vi）。這個例子就是依賴數(shù)據(jù)關(guān)系的過程化編程。

圖-1無相移濾波器實例

從工程應(yīng)用的角度看，通常所設(shè)計的濾波器的濾波結(jié)果對輸入信號都會產(chǎn)生一定的附加相移，有時候這個附加的相移是我們不希望出現(xiàn)的，而本例提供了實現(xiàn)無相移的濾波器。這個應(yīng)用在工程上是很實用的，通過這個實例可以加深對這個內(nèi)置vi的理解。

還有沒有更好的辦法來解決這樣的問題？當(dāng)然有，我認(rèn)為我所設(shè)計的“理想濾波器”（相對于周期信號而言）與它有異曲同工之處。其實，“理想濾波器”的性能應(yīng)該是更佳，因為它也實現(xiàn)了無相移的基波提取，同時給出基波的實際幅值。當(dāng)然它還可以改進(jìn)用來提取諧波分量等等。

感興趣的讀者不妨打開鏈接看看。

例-2利用公共線程的過程化編程

圖-2利用公共線程的過程化編程——34401DMM測量溫度（RTD）

在LabVIEW程序中利用公共線程實現(xiàn)過程化編程的實例很多，第3章中所描述的內(nèi)容都與此相關(guān)，這里就不一一列舉了。

其實，絕大多數(shù)的LabVIEW程序設(shè)計都是基于過程化編程實現(xiàn)的?；蛘哒f過程化編程是LabVIEW中最主要、最基本的編程范式。

圖形化語言過程化編程的基本特點

圖形化語言過程化編程基本的特點：

圖形化語言最基本的編程范式

毋庸置疑，對于圖形化程序設(shè)計，只要你貫徹數(shù)據(jù)流的編程思想一些程序自然都是基于過程化處理的。這樣的實例我們見到很多，并且也做過許多這樣的程序設(shè)計。其實，過程化編程并不局限于上面所介紹的數(shù)據(jù)依賴性、利用公共線程等等方面。比如：順序結(jié)構(gòu)、狀態(tài)機(jī)、生產(chǎn)者和消費(fèi)者循環(huán)等所展現(xiàn)的程序代碼也都屬于過程化編程。

這種過程化程序設(shè)計的自然性根本無須特別的強(qiáng)調(diào)，依據(jù)數(shù)據(jù)流的編程思想人們便會在程序設(shè)計中自覺、不自覺的采用這種程序設(shè)計方式（過程式編程）。

簡略的回顧一下，LabVIEW從誕生到現(xiàn)在的所有版本，一直都以過程化編程為最基本的編程范式，因為這些已經(jīng)貫穿在LabVIEW的編程思想中。

在測試、測量任務(wù)中，過程化的處理方式也是最基本操作模式之一。

自上而下還是自下而上的編程

通常的程序設(shè)計有兩種基本路線，自上而下和自下而上?；谖谋镜倪^程化編程，更強(qiáng)調(diào)“自上而下”的設(shè)計方式。圖形化的過程化編程即可以采用“自上而下”的設(shè)計方法，也可以采用“自下而上”的設(shè)計方法，當(dāng)然還可以同時采用這兩種設(shè)計方法同時進(jìn)行設(shè)計。這些僅僅取決于問題的表述和你的設(shè)計習(xí)慣。

在通用應(yīng)用程序設(shè)計時，我們常采用事件驅(qū)動VIServer或狀態(tài)機(jī)來控制程序的運(yùn)行（依據(jù)GUI的操作），開始時我們并不需要為每個狀態(tài)都填寫代碼，只要狀態(tài)運(yùn)行機(jī)制正確就可以。確定狀態(tài)運(yùn)行正確后，我們開始對不同狀態(tài)撰寫程序代碼，并且這些代碼可以分配給多人分別撰寫。

在測試應(yīng)用程序設(shè)計時，我們通常先設(shè)計、實現(xiàn)基本測試、分析功能，當(dāng)這部分工作正常后在開始設(shè)計其它的部分，如報告生成等。

實際上，我們習(xí)慣于先對涉及到硬件部分（數(shù)據(jù)采集、儀器控制等）的程序進(jìn)行整體設(shè)計（包括仿真試驗），最后綜合設(shè)計完成其它的部分。

模塊化設(shè)計

過程化編程的關(guān)鍵是將待解問題分解為自己可以理解的模塊。在LabVIEW中模塊是以子vi的形式出現(xiàn)的，每個子vi處理一個或多個任務(wù)。而子vi更優(yōu)異的特性是在于可重用。充分利用子vi的設(shè)計，實現(xiàn)程序代碼的直觀可讀性和簡潔性。

模塊化設(shè)計子vi是一個非常好的選擇，考慮到vi的可重復(fù)使用，采用通用式設(shè)計是一個有效的解決方案。比如：我們有許多NI的數(shù)據(jù)采集硬件產(chǎn)品，實際上在做數(shù)據(jù)采集時可能會根據(jù)測試任務(wù)選擇不同的硬件。事先，我們可以設(shè)計一個標(biāo)準(zhǔn)的vi，實現(xiàn)對不同硬件的通道配置。實現(xiàn)的方法很簡單，一個枚舉常量、一個Case結(jié)構(gòu)外加不同硬件的配置代碼。參見下圖。

-1模塊化的硬件配置

這是一個有效的模塊化設(shè)計的解決方案。由于NIDAQ產(chǎn)品配置與總線（PCI、PXI、USB、cDAQ）無關(guān)，所以它適用于大多數(shù)硬件配置。

它的最大好處是增加新的硬件很方便、很容易，僅僅需要添加一個枚舉常數(shù)和Case結(jié)構(gòu)中新硬件的配置代碼。

當(dāng)然，盡管這種方式提高了vi的重用性，但是同時也會增加vi所使用的內(nèi)存空間或磁盤空間，包括也增加了vi導(dǎo)入時所需的執(zhí)行時間。但這些對現(xiàn)代計算機(jī)的性能來講幾乎沒有什么負(fù)面的影響。

如果你注意到：LabVIEW2010的新特性，對模塊化的設(shè)計方法使用內(nèi)存過多的說法就應(yīng)該不存在任何顧慮。因為LabVIEW2010對編譯器進(jìn)行了優(yōu)化設(shè)計，使得vi經(jīng)過編譯后的執(zhí)行代碼會更簡單、更直接。這樣講，似乎很難理解，我們針對-1做簡單的說明。

在-1中，我們針對不同的硬件設(shè)計了不同的配置代碼，目的是用模塊化的設(shè)計方法提高vi的可重用性。實際上，在程序運(yùn)行中我們僅僅用到了一種硬件的配置代碼，也就是由枚舉常數(shù)所定義的那個Case結(jié)構(gòu)中的硬件，其它Case結(jié)構(gòu)中的硬件配置代碼根本沒有使用到。LabVIEW2010編譯器對此做了處理，在生成的可執(zhí)行代碼中去掉了其它Case結(jié)構(gòu)中根本沒有用到的硬件配置代碼，近而提高了程序的執(zhí)行效率。并且，編譯本身并不會破壞vi的源代碼。

請注意，LabVIEW2010的這個新特性是利用增加編譯的時間來換得程序執(zhí)行時間的降低，從而提高了編譯后程序執(zhí)行代碼的執(zhí)行速度。

(未完待續(xù))

4.3.2LabVIEW圖形化語言的事件驅(qū)動編程

需要提醒大家的是：本節(jié)所要討論的是圖形化語言事件驅(qū)動的編程范式。但我們不得不先介紹一些有關(guān)事件編程的其它知識。

我們知道：LabVIEW6.1推出了基于事件驅(qū)動的編程方法。但是，在LabVIEW較早期的版本中，如LabVIEW6，就已經(jīng)包含有基于事件通知的編程方法（應(yīng)該說是一種基于軟件的同步機(jī)制）。為了更好的說明事件驅(qū)動的編程機(jī)制，這里先簡單介紹一下這部分相關(guān)內(nèi)容。

事件通知是一種同步機(jī)制，它允許LabVIEW程序中并行處理部件之間在事件發(fā)生時進(jìn)行相互通知。由于它采用的是利用軟件觸發(fā)的方式發(fā)出事件通知，這樣就避免了使用輪詢技術(shù)所導(dǎo)致的系統(tǒng)開銷過大的問題。

在程序設(shè)計中，可以利用一個事件源（GenerateOccurrence）來通知多個等待事件的用戶（WaitonOccurrence），從而起到同步觸發(fā)的作用。

在函數(shù)選板上可以看到這些基于事件通知的內(nèi)置函數(shù)。參見下圖。

圖4.3.2-1基于事件通知的內(nèi)置函數(shù)

Occurrence一詞的意思是發(fā)生（事件），它與event是同義詞。

在許多教科書中我們可以看到Occurrence函數(shù)的一些介紹。但是，在實際的程序范例中，我們真的很少看到使用Occurrence函數(shù)的程序（至少我的感覺是這樣）?？墒窃贠penG的vi包中，我們確看到了它的實際應(yīng)用。這就是它的：OpenG_Wait（ms）.vi。

圖4.3.2-2OpenGWait(ms).vi

它是用LabVIEW_Wait（ms）函數(shù)創(chuàng)建的vi，但比LabVIEW_Wait（ms）函數(shù)功能更強(qiáng)大。下面就是它的程序框圖。

圖4.3.2-3OpenG_Wait(ms).vi程序框圖——Case=True

圖4.3.2-4OpenG_Wait(ms).vi程序框圖——Case=False

它不僅有錯誤簇輸入、輸出；還可以設(shè)定出現(xiàn)錯誤時是否停止定時；同時還有一個事件通知的信號輸入端。前面幾個特點我們這里不談了（在《LabVIEW——北方客棧》的“videsign”和“OpenG”專欄中已經(jīng)評述過），這里僅談?wù)勈录ㄖ@個特點。

眾所周知，如果在一個While循環(huán)中放置一個長時間的定時器，比如60s，當(dāng)用戶試圖使用條件終端停止這個While時，有可能需要等待很長時間（最長120s，為什么？）。參見下面的程序框圖。

圖4.3.2-5LabVIEW_Wait(ms)函數(shù)

這絕對是一件非常令人非常沮喪的事情。因為我們在停止定時后，真的不希望存在過長的等待時間。

現(xiàn)在來回答為什么可能要等待上120s的時間。

因為While循環(huán)首先要執(zhí)行60s的定時循環(huán)（初始條件端為“F”），即便是我們在定時開始后馬上按下了停止按鍵，定時循環(huán)也要執(zhí)行完這個定時。在完成這個定時后，條件端檢測到停止按鍵按下后(條件端為“T”)，還要在進(jìn)行一個循環(huán)才能結(jié)束。所以，最壞的情況下有可能需要等待120s時間。

現(xiàn)在，使用OpenG_Wait(ms).vi就可以解決這個問題，它利用了Occurrence事件通知來消除過長的等待時間。具體的程序框圖請參見下圖。

圖4.3.2-6利用Occurrence事件通知來立即停止定時循環(huán)（Case結(jié)構(gòu)假為空）

圖4.3.2-6最外面的循環(huán)是60s的定時循環(huán)，內(nèi)部是采用Occurrence事件來停止定時的循環(huán)。這樣我們就可以在任何時候都可以立即停止主定時循環(huán)。

其實僅僅使用Occurrence事件通知機(jī)制同樣可以實現(xiàn)同樣的定時功能（不使用Wait（ms）函數(shù)或vi），并且也可以立即停止定時循環(huán)。在《LabVIEW圖形編程》一書中就給出了這樣的實例，我們可以一起來看看它的程序框圖。

圖4.3.2-7利用Occurrence事件通知來消除過長的等待時間（Case結(jié)構(gòu)假為空）

它是利用超時值來做為定時值進(jìn)行定時處理，并利用Occurrence事件通知來消除過長的等待時間。

這里請注意：基于事件通知的圖形化程序代碼的運(yùn)行機(jī)制還是基于數(shù)據(jù)流的運(yùn)行機(jī)制。其圖形化代碼清晰、直觀、易理解。

清楚了事件通知的運(yùn)行機(jī)制，現(xiàn)在我們該回到本節(jié)的正題，LabVIEW事件驅(qū)動編程。

圖形化語言事件驅(qū)動編程的由來

我們前面曾經(jīng)談到過，計算機(jī)可視化操作系統(tǒng)（Mac、Windows、Linux）的陸續(xù)出現(xiàn)為LabVIEW提供了廣闊的生存空間和持續(xù)發(fā)展的基本環(huán)境。

在可視化操作系統(tǒng)中，人機(jī)對話基本上都是通過鼠標(biāo)、鍵盤的事件響應(yīng)來實現(xiàn)的。人們通過鼠標(biāo)的拖拽、點擊實現(xiàn)對計算機(jī)最基本的操作，計算機(jī)則通過用戶事件處理機(jī)制來響應(yīng)和處理來自用戶的要求。對于這些事件通常被稱為：GUI事件。

盡管在LabVIEW賴以生存的基本環(huán)境中，可視化操作系統(tǒng)都是采用用戶事件處理機(jī)制來響應(yīng)和處理用戶的要求。但是不知道什么原因，在LabVIEW6.1出現(xiàn)之前的早期版本中，人機(jī)對話并沒有相應(yīng)的GUI事件處理機(jī)制。那時，對用戶的操作響應(yīng)采用的是輪詢的方式來檢測用戶的操作，處理則采用隊列的方式來處理用戶需求。

輪詢的方法有兩個缺點：一是，占用CPU的資源；二是，可能遺漏用戶的操作請求。

自從LabVIEW6.1推出了事件驅(qū)動處理機(jī)制后，就完全去掉了輪詢的這兩個缺點。使得GUI事件驅(qū)動占據(jù)了用戶界面事件響應(yīng)處理的主導(dǎo)地位。這些事件包括鼠標(biāo)事件、鍵盤事件、窗體事件、對象事件等等。

事件驅(qū)動機(jī)制的建立，使得LabVIEW在處理復(fù)雜事情方面能力大大的增強(qiáng)，可以更方便的實現(xiàn)用戶的多種需求（不僅僅是GUI事件，還可以處理用戶自定義的事件）。這樣LabVIEW也就具備了通用編程語言最基本的特性。

圖形化語言事件驅(qū)動編程的表示方法

圖形化的事件驅(qū)動代碼參見下圖。

圖-1事件結(jié)構(gòu)的圖形化代碼

對于事件結(jié)構(gòu)的基本知識介紹，這里將不做更多的講解。比較具體的講解和應(yīng)用我們將會在下一章：《LabVIEW圖形化語言的設(shè)計模式》中給出。

下面通過一個演示程序來進(jìn)一步理解事件驅(qū)動編程。

例-1事件驅(qū)動的演示程序

圖-2給出了演示程序的前面版。

圖-2事件驅(qū)動演示程序的前面版

在前面版中，我們放置了三個控件。Door控件表示一個門（鼠標(biāo)點擊相當(dāng)于敲門）；Numeric控件用來紀(jì)錄事件的次數(shù)（敲門的次數(shù)）；Event控件用來停止演示程序的運(yùn)行。下面我們在來看看它的程序框圖。

圖-3事件驅(qū)動演示程序的程序框圖

這里我們創(chuàng)建了兩個事件源，一個是：“DoorMouseDown”，用來響應(yīng)和處理用戶的敲門事件；另一個是：“EventMouseDown”，用來停止這個演示程序。

“DoorMouseDown”事件處包含3個Case結(jié)構(gòu)。

首次敲門，彈出對話框：“Hello!”；

第2次敲門彈出對話框：“Pleasedonotknockit!”；

之后再敲門將彈出對話框：“Iwillcall"110"”。

感興趣的可下載看看！

思考題：

在圖-3中的Case結(jié)構(gòu)中，“Case2”被設(shè)定為“Default”，這是為什么？運(yùn)行程序試試看，選擇Case0或Case1為默認(rèn)Case結(jié)構(gòu)會出現(xiàn)什么現(xiàn)象？

圖形化語言事件驅(qū)動編程的特點

下面總結(jié)出事件驅(qū)動編程的一些基本特點

事件結(jié)構(gòu)框架需與While循環(huán)配合使用

如圖-1所示，如果僅用單獨(dú)事件框架，那么無論有多少個事件源、產(chǎn)生多少個事件，該事件結(jié)構(gòu)也僅能響應(yīng)最先發(fā)生的那個事件。也就是說：此時，只有一個事件會得到響應(yīng)和處理。

為了能夠順利地響應(yīng)多個事件發(fā)生，我們需在事件結(jié)構(gòu)外面加入一個While循環(huán)。有了這個While循環(huán)，我們就可以響應(yīng)和處理多次發(fā)生的事件，正如我們演示程序所示的那樣。

事件結(jié)構(gòu)的停止也應(yīng)采用事件處理方式

事件結(jié)構(gòu)中While循環(huán)的停止，也應(yīng)采用事件處理的方式完成。如演示程序中的“EventMouseDown”事件的處理方式。也就是說，在程序執(zhí)行時用布爾常數(shù)來控制While循環(huán)的條件端來停止事件結(jié)構(gòu)。

圖-4停止事件也采用事件處理機(jī)制

事件結(jié)構(gòu)不宜處理耗時過長的程序代碼

現(xiàn)在我們修改上面的例子，將事件處理中的對話框去掉，換成5s中的定時。參見下圖。

圖-5為每個事件處理加5s鐘定時

在例-5事件驅(qū)動的演示程序中，我們?yōu)槊總€事件處理程序（每個Case結(jié)構(gòu)）都加入了5s中的定時。也就是說，事件處理是需要一定的時間。如果事件連續(xù)發(fā)生會出現(xiàn)什么樣的情況呢？我們一同來看看。

運(yùn)行該程序后，我們馬上連續(xù)點擊3次Door，然后再點擊“Evert”。這時我們會發(fā)現(xiàn)，程序運(yùn)行了大約15s后停止下來。

這說明，程序能夠響應(yīng)所有的事件，并陸續(xù)執(zhí)行完所有的事件處理。事件處理時間取決于各個事件處理時間之和。所以我們建議在事件驅(qū)動機(jī)制中，事件結(jié)構(gòu)中不宜處理耗時過長的程序代碼。因為，我們通常希望看到快速響應(yīng)事件及快速的事件處理。

事件結(jié)構(gòu)中事件處理不宜包含對話框

在圖-3事件驅(qū)動中，我們使用了對話框來處理事件的響應(yīng)。實際上，在事件驅(qū)動處理程序中這種方式是不可取的、應(yīng)該盡可能不用的。原因就是：對話框操作可能導(dǎo)致其它事件暫時無法響應(yīng)。因為，如果對話框沒有被及時處理，程序會一直停止在那里等待對話框處理結(jié)果。

實際運(yùn)行該程序我們會發(fā)現(xiàn)，在對話框彈