關於大程式之整理與設計技巧？

LabVIEW
1

各位好：

一般寫程式時,若想判斷"是否重複執行某部份之程式片段",好像皆大都使用while loop架構去搞

但若程式寫的比較大(佔front panel面積較大)
寫到到某節點B時,要判斷是否跳回到之前某節點A跑
而A與B在block diagram視窗距離非常遠,用while loop圈起來的話
實在非常不好圈,而且以後要維護好像也不太方便...

其方法似乎只有利用stacked sequence structure 或 將部份功能做成sub-VI 以縮減版面嗎?
因為有時候是寫到某個階段後才驚覺版面太大了
此時要再用stacked sequence structure or sub-VI 去整理程式實在很麻煩,要剪剪貼貼,重拉一些線

故希望各位前輩能否分享寫大程式的經驗^^
抑或LabVIEW有那種能"跳回到某指定點or指定迴圈"的元件呢?

剛溫阿～


ps. 小弟有搜尋過相關文章,只有這一篇(Q2),但無後續發展...
http://www.labview.com.tw/forum/forum_posts.asp?TID=1331&KW=%B0j%B0%E9+%B8%F5

小弟亦搜尋字串"大程式",但好像也無看到較相關之文章 > <"

2

個人在寫大型程式時，一般都會由程式的設計目的，來分析程式的架構。

從設計目的，去一步步劃分為一個個程式所具備的功能，
而該功能會是由許多具備某些功能的小程式所組成的，
如此一步步由大化小、由繁化簡。

當你將程式功能化分為最小單位時，就可以用 LabVIEW 所提供的 VI 來完成它，
如果 內建的 VI 無法滿足時，就自己去撰寫出來。

比方說：汽車

汽車具備了奔馳、運載、等特性及功能。

首先分析 奔馳 這功能，什麼東西讓汽車具備 奔馳 呢？
是引擎，但是有引擎還不夠，也需要有輪子。

引擎的動力誰提供？  怎麼傳送到輪子？   是汽油和傳動軸。

如此一步一步去分析，並且去完成輸子、引擎、傳動軸，而汽油可能是資料來源，
整個汽車，必需被拆解成小零件。

因為小零件具備了可重覆利用性 及 容易管理、除錯的特性。

當小零件被驗証沒問題時，再組裝到車子上去時，也才能夠提到組裝時可能不出錯的最低保証。
我們不可能為每一個需要上一樣尺寸螺絲釘部分，重新開一個模來製做一個螺絲釘，這是很沒效率的。
我們也不可能因為窗戶破了，但是窗戶跟車子是連成一體，而去換掉整個車子，這是不具經濟效益的。

所以如果你問我怎麼規劃一個大型程式，我會說，去分析 (拆解)，去蒐集、完成你的零件及
工具 (subVI)，然後一個個完成功能模組，再把功能模組合成你要的程式。

 

而且將程式模組化的另一個好處是就如同，我把
『Functions -> File I/O -> Read Characters From File.vi』拿來用一樣，
我不需要去了解它底層如何運作，我只要需要知道它該怎麼用，可以完成我要的需求就好。

相對的，在你程式裡，不需要將『Read Characters From File.vi』的所有底層的 subVI
直接貼上去，這樣可以避免你的程式看起來過大，而且在 maintain 時，花太多精神再追縱整個程式碼，
當你在 debug 時，盯著 dataflow 看，只需知道當 data 流進 『Read Characters From File.vi』後，
流出來的資料正確即可。

Airbolt38679.4090162037
3

我會先想我要做什麼?(功能),然後我要如何達到我要做的事(流程規劃),我希望它是如何模樣(介面)?
規劃出整體的架構,然後針對比較細部的地方 再另外規劃流程。
然後利用函式(就labview來說 應該叫subVI)的方式去完成這個大程式,
因為這樣最方便維護,同時也可重覆利用該函式。
拿Linux做比喻...有的人會寫USB驅動程式、有的人會寫光碟機驅動程式...有的人會寫開發工具...
這些都能在Linux上使用...




chzn122638679.436724537

4

呼~感謝前輩們的經驗分享^^

小弟前幾天去翻了大一時(唉～年輕真好...)必修C語言的書
找到"goto"指令,能任意跳出到某個迴圈
但書上提及,大部分程式撰寫專家皆建議"莫輕易使用goto指令"
因為其破壞了程式邏輯之順暢性與可讀性
但某些特殊情況用來取代break還不錯用...

後來想想,LabVIEW之撰寫乃以dataflow為其架構
若有了類似goto之功能,感覺似乎會讓dataflow之流暢性大為降低

看來於撰寫程式前,好好規劃程式架構與sub-vi才是王道阿...

由於小弟自從大一那陣子學過C,到最近搞上了LabVIEW,
這之間都沒再撰寫過任何程式,所以規劃程式架構之經驗值頗低
常常是想到哪才寫到哪@@"

由於是買書一邊學,一邊上手而直接用到自己的研究上
常常在討論區上前輩們分享之小程式中
看到某些類似功能,自己想了好久才搞出來
但前輩們卻用了幾個小弟沒看過元件或技巧,即簡潔地達到目的
此時小弟心中之景仰有如滔滔江水,綿延不絕阿...
此種感覺有如玩on-line game時,有高手帶你打怪
你經驗值就賺的多,升級就升得快

但小弟這一個多月於討論區上之文章亦了解到
當自己真的想破頭,或由各種管道皆找不到解決方式時
再上來po文問問題,亦才會得到大家熱心之協助
並真正學到自己不懂之處...

總之,小弟非常高興並感恩台灣有此論壇之存在,水！

ps.雖然小弟LabVIEW之技巧仍"2266"～
但為了順利畢業,還是得硬著頭皮直接應用於實驗上硬*
有時候好希望能早一年確立研究方向,真是相見恨晚阿...
歹勢啦～小弟發發牢騷

5

Hi ,<?:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />

我也是個新手,看了各位的心得後,我也來說說我的一點經驗吧!

 

我接觸 LabView大約也只有半年的時間,之前完全沒有什麼程式經驗,唯一的經

驗就是以前念書時,邏輯設計的概念還可以,因此一開始就是先去找一些書來研究

,在了解了LabView的程式架構與觀念後,就這樣開始上陣了.

 

在下寫的程式其實並不難,大致上就是設計一個程式的界面,給工程師做為測試的

功能,因為我本身也是測試工程師轉任的,所以對測試的需求很了解,一開始整個

架構其實滿模糊的,都是邊想邊做,不過雖然是個不大的程式,我也在設計的過程

中慢慢的去思考,之後我的程式大約被我分成幾個部份:

1.        與儀器溝通與讀取資料-這個部份讓我學了很多GPIB指令與除錯還有儀器指令

2.        進行數據比對與判斷-這個部份就真的都是用邏輯概念硬做出來了

3.        使用者界面的設計-這部份其實很有趣但也很傷腦筋,因為要思考一個使用者會怎麼”玩”這個程式,以及測試各種可能性,還要考慮介面好不好用,主管常常要追加功能或修改格式,真的滿有挑戰性的

4.        輸出報告-這部份不會很難,但是說真的一開始也不好做,花了不少時間研究

5.        儲存資料與讀取資料-這部份我目前還沒有很好的架構,原因是我還想不出理想的資料存放格式,目前只用兩種方式存放資料,就是純文字檔與Config檔兩種.

好處是一開始我就有 SubVI與程式分工的概念,所以我的做法就是針對每一種目標

再各別設計出需要的 SubVI,正如前輩所說,我只要去檢查每一個我需要的 SubVI所

得到的是不是我要的結果就好,這在Debug上真的方便很多,最後在整合時再檢查看

是否會有問題就可以.

可是目前因為功力不夠的關係,還有常常被要求追加與修改的原因,整個主程式的架

構莫名其妙的越來越大=_=,因此在每個程式段落中加上註解以及每個VI加上說明

檔已經是我的習慣了.

 

真的很高興能有這個網站,說真的書本教我的只是基本的入門,真正讓我穫益良多的

其實是這個網站的眾多前輩你們,雖然工作還是很忙,可是有空我都會上來看看大家

的討論,每次看到有人提出一些有趣的概念就會趕快嘗試看看,並且試著在下一個程

式裡偷偷用上去,現在技術還是差的很遠,所以還有很多學習的機會,也希望大家能一

起多多討論與指教了.