skybow

本文章轉錄自此連結:

http://www.ni.com/newsletter/51675/zht/

LabVIEW還是C?

「為什麼 LabVIEW 比 C 語言好？」身為 LabVIEW 的產品經理，常常有人問我這個問題。

老實說，這個問題本身就有問題。但只要稍微修改一下，再加上充分的應用背景，就會變成有用的問題 (比如說：「就這些限制而言，LabVIEW 還是 C 比較適合這個情況？」)。如果不提供細節，這個問題就和「為什麼麵包比麵粉好？」沒什麼兩樣。

如果想要建置量測或控制系統，那麼 NI LabVIEW 系統設計軟體就會是理想的選擇，有助於避免風險、節省成本與人力，不必像使用 C 這類的初階語言來建置系統那麼麻煩。我並不是說相較於 C 語言，LabVIEW 是「比較好」的程式語言，更何況除了 G 以外，大部分的 LabVIEW 也會透過 C 和 C++ 撰寫而成。程式設計師必須了解兩者的優點，才能做出最佳決策。

LabVIEW 和 C 之間的關係就像麵包和麵粉一樣。如果想要做一份三明治，就要有麵包；如果想要烤蛋糕，就要有麵粉。但如果要從頭開始用麵粉來製作麵包，不僅花錢，也非常浪費時間 (尤其是只想快點填飽肚子的情況下)；但如果是蛋糕的話，麵粉就變得非常重要。一樣的道理，你可能會覺得很難選擇合適的程式語言。其實到頭來就只是要如何「物盡其用」而已。


C 提供初階控制功能

一般來說，C 比較適合資源有限、必須密切管理的應用項目。由於 C 是比較初階的語言，因此程式設計師不能放過任何一個小細節，例如記憶體指派與執行緒等。好的程式設計師會運用這種初階控制功能，減少高階實作項目的經常性成本。這時還可善用系統架構或主機作業系統的屬性，進而達到更出色的效能。

因此 NI 程式設計師都會選用 C 或 C++ 撰寫大部分的 LabVIEW 函式庫。LabVIEW 執行檔案 I/O 與分析等作業的速度就像 C 一樣快，因為這些作業項目以初階語言寫成，並且針對 LabVIEW 所支援的平台與作業系統經過優化。


效率 vs. 控制

就某方面而言，開發效率遠比手動優化程式碼來得重要。如果願意放棄一點控制功能，並且吸收前輩所遇過的類似經驗，就可以有效提高專案的生產力。程式語言會朝向更高階的抽象化穩定邁進。這樣可協助工程師專心解決眼前的問題，不必浪費時間在運算細節上面。

LabVIEW：適用於平行執行與實際 I/O

無論實作語言為何，高階系統設計與初階實作勢必要分開處理。

就量測與控制應用而言，程式設計只是系統設計師的其中一項工作而已。通常工程師不可能為了支援運算與量測硬體、作業系統等其中的改良技術與功能，而撥出時間熟悉舊軟體或重新撰寫舊軟體。他們會想辦法擷取、操作並顯示實際資料，進一步提升舊有軟體的價值，而不是找出新的方法來處理記憶體分配與執行緒集區。有了 LabVIEW，就可以運用 NI 的初階程式碼函式庫，根據這些經過測試/支援/維護的基礎工具來著手開發。如果選擇 C，就必須親手實作、支援、維護自己的初階函式庫，或是購買廠商的函式庫 (NI 也提供適用的 NI LabWindows ™/CVI 軟體與 NI Measurement Studio)。
而且 C 以語法為基礎，極適合以 CPU 可支援的最高速度來連續執行指令。這對純運算來說很方便，因為只要執行一項作業，而且指令也屬於基礎指令。另一方面來說，如果有平行執行多項作業與實際時序限制等需求，那麼 LabVIEW 的圖形化語法就會是理想的選擇。

LabVIEW 不只是程式語言和相關函式庫而已。如果使用 LabVIEW 整合式開發環境 (IDE) 搭配 NI 硬體，就可以享有更出色的加乘效應，遠超過不同工具湊合起來的效果。此軟體可搭配現有的硬體資源，還可透過下拉式功能表與專案項目來顯示可用的 I/O 通道與執行系統。編輯時即可防止或修正錯誤設定，進而避免代價高昂且難以除錯的執行階段錯誤 (Runtime Error)。新一代的量測硬體 (例如 NI PXIe-5644R 向量訊號收發器) 甚至還能讓 LabVIEW 重新定義硬體本身的韌體，其效能遠超過傳統的程式語言和儀器。

許多專案會超出預算或進度延後，就是因為專案團隊低估了整合不同資源所需的時間與心力。使用 LabVIEW 時，硬體驅動程式回傳的資料格式與分析函式庫所接收的資料格式相同，而且 UI 小工具顯示的技術資料格式也與分析函式庫所產生的格式相同，所以不必費心整合多項元件。

到底哪個比較好？LabVIEW 還是 C？
答案可能是「一切皆有可能」。在此引用《銀河便車指南》(The Hitchhiker’s Guide to the Galaxy) 這本科幻小說的概念：只有確實知道自己的問題或有待解決的困難是什麼，才會找到有意義的答案。LabVIEW 與 C 都是很實用的工具，如果交到熟練的使用者手上，幾乎可解決各種問題：LabVIEW 適合高階測試、量測、控制應用；C 適合密集運算作業的初階實作。

如果下次有人問你 LabVIEW 是不是比 C 好，你就回答「一切皆有可能」吧。這或許是唯一能引導至有效討論的回應。

===========================================================================================

LabVIEW是編譯型語言還是解釋型語言?

http://it360.tw/article/info.asp?TID=6833&FID=165

LabVIEW 和常用的 VC++、VB 一樣，是編譯型語言。LabVIEW 的語法定義比較嚴格，在程式運行之前會檢查所有語句的語法，一旦查出有差錯，程式會報錯，不能運行。在LabVIEW是否是編譯型語言的問題上容易引起混淆的原因，一是用戶看不到編譯時生成的目標檔（在 LabVIEW 的環境中，可以直接運行一個 VI，並不生成任何其他可執行檔）；二是 LabVIEW 沒有編譯這個按鈕。此外，VI 運行前似乎也沒有佔用編譯時間。

　　我們可以把 LabVIEW 和 C 語言的存儲與編譯方法作一比較：C 語言的原文件存儲在 .c 文件中。需要編譯時，要顯式地告知編譯器進行編譯。在耗費一段編譯時間後，可以看到編譯後生成的含有可執行二進位碼的 .obj 文件。而LabVIEW 的原代碼是存儲在 .vi 文件中的。一個 .c 檔中通常保存了多個函數，一個由幾十個函數構成的 C 語言工程，也許只由兩三個 .c 檔組成。而通常情況下，一個 .vi 檔只存儲一個 VI，即相當於 C 語言中的一個函數。所以，一個小型 LabVIEW 工程也可能由幾十個 .vi 檔組成。但在某些情況下，一個 .vi 檔也可能包含了某些子 VI（子函數），即這些子函數沒有他們自己的 .vi 文件。這樣的子 VI 被稱為實例 VI（Instance VI）。LabVIEW 7版本中出現的、目前很常用的 Express VI就是這種 Instance VI。他們都是被存儲在調用他們的 VI 中的。

　　.c 檔只保存程式的原代碼；而 .vi 檔不僅保存了 LabVIEW 程式的原代碼，也保存了程式編譯之後生成的目標代碼。在 LabVIEW 的工程中看不到類似 .obj 這樣的檔，就是因為編譯後的代碼也已經被保存在了 .vi 中的緣故。

　　LabVIEW 在運行VI 之前無需編譯，是因為 LabVIEW 在把 VI 裝入記憶體的時候、以及在編輯 VI 的同時進行了編譯。

　　當把一個 VI 裝入記憶體時，LabVIEW 先要判斷一下這個 VI 是否需要被編譯。一般情況下，VI是不需要編譯的。但是在兩種情況下需要重新編譯。第一種，是在高版本 LabVIEW 中打開一個用低版本LabVIEW 保存的 VI；第二種，是在不同的作業系統下裝入和打開了同一個 VI。比如，要在 LabVIEW 8.0 中打開一個原來用 LabVIEW 7.0 編寫保存的 VI，則被裝入的 VI 需要被重新編譯，因為不同版本的 LabVIEW 生成的目標代碼會稍有不同。如果你的工程包含有上百個 VI，在新版本的 LabVIEW 中打開頂層 VI，就會明顯地察覺到編譯所佔用的時間。第二種情況的例子是，在 Linux 中打開一個原來是在 Windows XP 下編寫保存的 VI，LabVIEW 也需要重新編譯。LabVIEW 為不同作業系統生成的目標代碼也是不同的。在以上兩種情況下，打開一個 VI 後，會發現 VI 視窗的標題欄中的標題後面出現一個星號，這表示需要重新保存 VI。此時，雖然 VI 中的程式原代碼沒有改變，但是編譯生成的目標代碼已經變了，所以需要重新保存。在LabVIEW 安裝了升級補丁之後（比如8.01），程式會提示你是否需要把 LabVIEW 自帶的 VI 全部批量編譯（mass compile）。如果你選擇“是”，則可能需要佔用幾個小時的時間才能完成編譯。

　　LabVIEW 在你編輯程式原代碼的同時，就會對它進行編譯。LabVIEW 只編譯你當前正在編輯的這個 VI，它的子 VI 已經保存有已編譯好的目標代碼，所以不需要重新編譯了。因為每個 .vi 只相當於一個函數，代碼量不會很大，編譯速度就相當快，用戶基本上是察覺不到的。 你在編寫一個LabVIEW程式時，假如你把兩個類型不同的接線端聯在一起，會看到程式的運行按鈕立即斷裂，它表示程式已經編譯了，並且編譯後的代碼不可執行。程式編寫完畢，所有 VI也都已是被編譯好了，程式直接運行即可。

　　有時會出現這種情況：打開一個 VI，VI 左上方運行按鈕上的箭頭是斷裂的，表示 VI 不能運行。但是點擊斷裂的箭頭，在錯誤列表裏卻沒有列出任何錯誤資訊。此時箭頭斷裂是由於 VI 保存的編譯後的代碼不能執行引起的。例如在上一次打開這個 VI 時，有一個被此VI 調用的 DLL 檔沒有找到，編譯後的代碼自然不能執行。而後關閉 VI 再把缺失的 DLL 文件放回去。下次打開始 VI 時，理論上 VI 應當可以運行了，但是這時 LabVIEW 沒有重新編譯這個 VI，VI 中保存的是上一次不可執行的代碼，所以運行按鈕的箭頭仍然斷裂。而程式原代碼沒有任何錯誤，所以錯誤列表中什麼都看不到。修復箭頭狀態的方法是按住 Ctrl + Shift 鍵，再用滑鼠左鍵點擊運行按鈕（斷裂的箭頭）。在 LabVIEW 中按住 Ctrl + Shift 鍵 + 滑鼠左鍵點擊運行按鈕表示編譯，但不運行，這相當於其他語言的 Compile 按鈕。