Timing- Wait (ms) & Wait Until Next ms Multiple(ms)_ 修改版

前言:
自從上次自己搞的糊塗的地方:Timing- Wait (ms) & Wait Until Next ms Multiple(ms)，後來想想應該回歸最原本的測試，從簡易的觀點思考。

修改版本:

測試：
若按照原本的測試，同為"Wait" 或者 "Wait until next multiple"的設定時，的確從結果是可以看出合理。即在"Wait"的條件下，較高的code運行會持續地向下執行而不理會所設定的數值，但"wait until next multiple"會變成每圈執行的起始時間相同，就變成兩個迴圈變得沒有誤差了！
所以結果是：一個"wait"而另一個"wait until next multiple"在高於設定值時（ex: code running time = 120ms, looptime = 100ms），"wait"的執行圈數就會變得比"wait until next multiple"少了！

另外在上一篇有提到，在code time>=198以上的話，兩個loop幾乎就不會有次數差異，但是在198以下的話，大概就是兩個差異的時間造成的次數差異。整理如下：
code time---相差次數（wait是屬於較少圈的）
190---45
180---40
170---35
160---30
150---25
140---20
130---15
120---10
很有趣，就是190 & 100 (looptime)的平均時間，然後"wait"需要較久的時間，多出的時間可讓"wait until next multiple"多跑的時間。
然後code time在大於200ms後，又開始慢慢地增加兩種回圈的運行次數。但是次數稍微較少，例如：

code time---相差次數（wait是屬於較少圈的）
220---8
250---18
280---28

後記：
總結來看，目前大概的猜測是因為當進行"wait"時候需要較久，所以達到99次會需要較久時間，可是同時"wait until..."卻“似乎“不會受到影響，所以可以”多“執行幾次100ms的倍數。這...令人費解呢？怪哉～怎麼解釋比較合理？還是一頭霧水！！


參考資料：
LabVIEW Pro_基礎教學_程式執行架構

Image J 測試

前言：
之前因為計算採樣的Filter使用量，所以拍了照片，本來也是想使用ImageJ來計算，不過一開始小小的失敗，後來改用土法煉鋼的使用powerpoint計算面積也是可行。後來又異想天開地想說使用照片的色階程度(RGB-->Gray)，就再次的使用ImageJ，參考了手冊與幾個網頁，得到了很不錯的結果。

方式：
Open->selected picture
開啟Pixel inspection Tool,點選畫面上的位置就會出現Pixel Value table上面就有你所選擇的範圍內的資料。點選這個table左上方的Prefs就會出現“Pixel Inspector Prefs..”選項裡面可以修改點選的範圍＆RGB的輸出值，可以直接改成Gray Value，還有其它參數等等。

（小紅框就是點選的範圍）

另外，若要在更大的面積計算RGB或者Gray value可以使用安裝後已經有的套件可供計算。先選擇你想要計算的範圍，然後按照這個路近：
路徑：Plugins-->Analyze-->Measure RGB
就可以計算出完整的數值，如下：

（黃色的框框就是選取的範圍）

小結論：
目前看起來是8bit的解析，還不是很瞭解圖像的資訊，還要多收集資料學習囉，另外跟學弟討論過MATLAB好像讀入也是8 bit(~255)所以我想應該基本上都是這樣吧！
還有個小目標就是改用LabVIEW的方式讀取與做一樣的分析。

附記：
ImageJ是基於JAVA且可以通用在很多平台（不過還是有分平台選擇下載的版本），是個Open Source，可供修改、創造與分享。

(from ImageJ教學）
Pixel的校正，不過還不是很會用！
Analyze-Calibration-"select area"-"ctrl 1 + ctrl 3"-

Reference:
ImageJ教學
以ImageJ測量葉面積
Image J_ IJ 1.46r User Guide(PDF file from ImageJ website)

Projects & LLB manager

前言：

最近開始撰寫另個案子，為了整理方便，也開始來使用LLB或者Projects管理，使用LLB是之前就有養成的習慣，但是發現若含一些.dll檔案或者其他不是LabVIEW的物件，管理上比較不方便，所以改試著使用Projects manager，發現其中有很多新東西可以學。

Projects & LLB 了解：
首先在打開LabVIEW的時候就可以選擇，blank Project，或者在一般VI是窗下從File裡面點選new project。然後選擇主要的VI後其他的subVI就可以自動地匯入到Project裡的Dependencies項目。

比較有問題的發現是，若直接從main VI的時候建立blank VI然後寫成subVI，但此時subVI會變成與main VI落入"My Computer"的主項目之一，其實這只是看起來不順吧！（是嗎？）所以要避免此狀況的話，就必須在不是Project的VI內開啓(另外開啟新的!!)，就不會落入Project的項目內拉。因為到時候在main VI中放入subVI然後存檔後，subVI就會自動地出現在Project囉！！



參考：
Using LabVIEW Projects
Managing a Project in LabVIEW

LabVIEW 學習資料
LabVIEW 北方客棧
IT 360
LabVIEW Pro

人月神話_ The Mythical Man-Month

前言：
這篇記錄了閱讀人月神話所得到的感想或者筆記，閱讀的是中文版本，但一樣輔助英文版的電子書。這是一本被譽為經典的好書，雖然程式方面我還沒熟悉與精通，但看此書也得到非常多的建議與觀念，而且現在閱讀與以後閱讀我想也是可以有更多新的感觸。

Chapter 1-焦油坑 (The Tar Pit, P19)

Chapter 2-人月神話 (The Mythical Man-Month, P31)
軟體專案時程：(P41)
1/3- 規劃(Planning)
1/6- 寫程式(Coding)
1/4- 組件測試(Component test & early system test)
1/4- 系統測試，完成所有組件(System test, all components in hand)

惡性循環的時程災難(P43~P47)
1. 這幾頁可以提供計算人月關係與思考拖延的後果
2. 軟體專案會耗費多少時間是看他有多少連續性的限制。

Chapter 3-外科手術團隊 (The Surgical Team, P49)
盡可能用最少的人來完成專案！！-P53

Chapter 4-專制與民主 (Aristocracy, Democracy, and System Design, P79)
整體概念性(Conceptual Integrity)-P67
功能概念複雜度比(ratio of function to conceptual complexity)，好的設計既不可單獨偏重功能性，也不可只偏重簡單性。

創意工作: 架構設計-實作-實現; 事實上是可以同時開始合並行的。

以整體概念性為主軸，時程壓力終會迫使系統開發由更多人一起合作，使用兩個方式解決達成整體概念性：
1. 將工作分成“架構(architecture)”與“實作(implementation)”-P70
---architecture, 做什麼? ; implementation, 如何做?
2. 外科手術團隊(第三章)

約束對藝術而言是件好事(Discipline is good for art)-P73
形式就是解放(From is liberating)
成本校能比(Cost-performance ratio)

Chapter 5-第二系統效應 (The Second-System Effect, P79)
架構設計師 vs. 第二系統效應(chapter 5)-p87
架構設計師要如何避免第二系統效應呢？很明顯地，他無法跳過他的第二系統，但可以留意造成第二系統效應的獨特原因，再加上自律，以特別提醒自己避免設計出不相干的功能，或是做出違反原先假設與目的的功能。

Chapter 6-意念的傳達 (Passing the Word , P93)
量化(quantize)
”精確的說明“應該比”生動地表達“來得重要
英語，或任何其他人類語言，原本就不是用來精確描述定義的。
--使用"正式標記法(formal notation)"，另外好的規格書應該同時包含“正式定義”和“散文式定義”，以口語化的解釋使規格書易於領會和傳授。
Chronometer：羅盤
贊同開會：P98
第一種：每週會議，成功的原因，共五點
第二種：年度檢討大會（作者prefer半年一次）

Chapter 7-巴別塔為什麼失敗？ (Why Did the Tower of Babel Fail?, P107)
(p107即)提到五個重要的成功條件，但是皆以失敗結束。因為缺乏了兩樣因素：溝通(communication)以及隨之而來的組織(organization)。
--溝通：非正式方法(informally)，會議(meeting)以及工作手冊(workbook, P109)
--組織, P112：目的在於減少溝通介面和協調的需要量->人力配置(division of labor)以及專業分工(specialization of function)。

Chapter 8-預估(Calling the Shot, P123)
1. 練習就是最好的教練-西流士, Practice is the best of all instructors.- PUBLILIUS
2. 經驗的代價是昂貴的，但愚人就只能從經驗中學習, Experience is a dear teacher, but fools will learn at no other.- POOR RICHARD'S ALMANAC
ref:上面的第二點出自“窮查理年鑑”（中譯），也就是Benjamin Franklin(1706-1790)在1733-1758年在費城發表的年鑑。

另個比較有趣的是提到“即使只考慮個人創作，不含任何跟別人溝通的代價，寫程式的費力程度仍然跟程式的大小呈現指數倍數的關係”-雖然是淺顯易懂一句話，不過有時候還是會成為判斷錯誤的原因之一。

兩個新的名詞：
控制程式(control program)
    包含：操作，維護
語言轉譯程式(language translator)
    包含：編譯器，轉譯器（資料組譯器）

(p129), 在章節末段提出的兩點結論之一：若以“行”來算生產力，似乎是個固定的值，因為每一行程式得花多少腦筋思考，可能藴藏多少錯誤，都是固定的...。
好奇點在，對程式語言開發系統來說，“每一行”的長度很接近或一樣嗎？因為前述有提到每一行大概可抵三到五個字。恩！恩？

Chapter 9-地盡其利，物盡其用(Ten Pounds in a Five-Pound Sack, P135)
The author should gaze at Noah, and ... learn, as they did in Ark, to crowd a great deal of matter into a very small compass- SYDNEY SMITH, EDINBURGH REVIEW

空間就是金錢->A:程式大小的控制->B:節省空間的技術
A:
技術上 & 管理上
(p137)，存取規劃(access budget)
提到的兩種問題：
1. 重疊(overlay)
2. 分頁錯亂(page thrashing)
提到的三個教訓：
1. 做好“整體空間規劃(total size budget)”，
2. (p138)在規定某個模組的大小之前，先精確定義出這個模組該做的事情，
3. 系統架構師對系統的整體性保持警覺。
B:
“創意” & “技術”取代“規劃”與“管制”
第一種技術：功能和空間做取捨
1. 功能越單一，程式所佔的空間也會越少
第二種技術：空間和時間做取捨
1. 對同一個函式而言，能用的空間越多，執行的速度就越快，這道理幾乎在任何情況下都能成立，可以作為安排空間規劃的參考。

(p140)管理者可以做的兩件事情：
1. 確保程式設計師的本事是技術訓練而來，
2. 認知到寫程式有其專業的技術。
（兩套手冊必備：副程式或者巨集- queuing, searching, hashing, sorting，分成＝執行速度最快以及使用空間最少的）

(p141)又小、又快、又好的程式幾乎都源自於“策略”上的突破。
”譯註“資料(Data)或表格(Table)地呈現方式指的是“資料結構”，而“流程圖”所隱含的意義就是“演算法(algorithm)”。

(p142)有一段話寫得很好：
為了空間不足的問題而顯得黔驢技窮之際，通常最好的做法就是從程式碼中跳脫，回過頭重新思考所使用的資料。
“資料的呈現方式是程式設計的本質”
“Representation is the essence of programming”

Chapter 10-文件假說(The Documentary Hypothesis, P147)
假說：
在成堆的書面資料中，有一小部份關鍵性文件記錄着任何專案管理的核心工作。而這些文件是身為管理者最重要的工具。
The hypothesis:
Amid a wash of paper, a small number of documents become the critical pivots around which every projects management revolves. These are the manager's chief personal tools.

(p147)準備這一小部分文件是為了讓思考集中，並且使討論言之有物，而非淪為漫無目的的空談。

(p150)任何管理工作所關心的五件事情：
人、地、時、物、錢

(p150)規劃軟體開發專案的文件(很受用，值得參考！)
做什麼(What)：目標
做什麼(What)：產品規格
何時做(When)：時程
多少錢(How much)：預算
哪裡做(Where)：場地配置
由誰做(Who)：組織編制圖

(p151)最後一點有一句定律如-Conway定律：從事系統設計的組織所設計出來的系統將會是組織溝通結構的翻版。意思就是組織編制圖會初步反映出系統的第一次設計成果，而此設計幾乎可以確定並不是我們要的。

(p151)提到為什麼需要正式文件
第一：只有“寫”下來，才能引導更多細節的決定(mini-decision)，而這正是從模糊不清之中理出清晰而明確政策的具體方法。
第二：有“傳達決策給他人的功用”
-管理者的工作就是“制定計劃“，然後”實現它”，但唯有將計劃“寫”下來，整個開發工作才能做精確地推動與溝通。(p152)

Chapter 11-失敗為成功之母(Plan to Throw One Away, P157)
這世界唯一不變的就是這世界一直在變-斯威夫特
There is nothing in this world constant but inconstancy.-Jonathan SWIFT(1707)

你得以平常心看待失敗，試試這個，如果行不通，就老老實實接受行不通的事實，再試試那個。總之，要成功，就得去試試。-富蘭克林·羅斯福
It is common sense to take a method and try it. If it fails, admit it frankly and try another. But above all, try something.-FRANKLIN D. ROOSEVELT

"丟掉重做" 
1.毋須煩惱是否做一個試探性的系統，因為到時候勢必就會這麼做。
2.計畫做得再完美也會有百密一疏，因此必須有丟掉重做的準備。
3.所以無論如何，把必然的一次失敗納入正式計畫之中-plan to throw one way; you will, anyhow.
4.硬體是有形的且可以量化(quantize)並加以節制，但軟體是無形的，且易於操控(tractable)，使得開發人員面臨需求上無窮無境的改變。
5.定義出一個底線是必須的，而且隨著專案進行，這項限制應該要越來越嚴格，否則沒有任何產品會完成。
6.丟掉重作的改念本身就是要讓你接受先學到竅門、然後改變設計的事實。

使系統利於改變
7.(p159) 說的多做的少-設計一個系統且利於改變: 模組化、副程式、為內部模組之間定義出明確且完整的介面，並寫出完整的文件。盡可能使用標準的呼叫程序(calling sequence)和表格驅動技術(table-driven)。

使組織利於改變
8.類似"外科手術團隊"

軟體維護(program maintenance)在於軟體交付之後的變動
-主要來自"修正設計錯誤"、"增加新功能"。維護起碼付出相當於開發成本的40%，甚至更高。
-軟體使用者越多，維護成本越高。(p162-163)
可能遭遇到一個重要的問題，就是因修正錯誤而導致其他錯誤的可能性相當高(about 20~50 %)
-做到完整的迴歸測試(regression test)所需的成本相當高。

Pascal: 任何事物總是在開始的時候最完美。(p164-165, 進一步，退一步)

Chapter 12-神兵利器(Sharp Tools, P171)
巧匠以他所使用的工具而聞名。-諺語
A good workman is know by his tools.-Proverb

有哪些工具是管理者需要思索、規劃和組織的呢？
『目標機器』
機器（電腦設備）->作業系統（服務法則）->語言（語言政策）
『工具機器與資料維護』
另外還有：工具程式、除錯輔助軟體、測試案例產生器以及文書處理系統

p175, 可靠(dependable)跟精確(accurate)不同，模擬器需要可靠性，雖然新型機器架構相對來得精確。

p175, 對於模擬器(simulator)的描述必看（到p176)

p182, 交談式工具必須搭配高階語言。這兩者的結合確實造就了一組神兵利器。

Chapter 13-化整為零(The Whole and the Parts, P187)
我可以招喚地底的幽魂。
啊!這我也會，甚麼人都會；可是當您招喚它們的時候，它們就真的會來嗎? - 莎士比亞，《亨利四世》，上篇
I can call spirits from the vasty deep.
Why so can I, or so can any man; but will they come when you do call for them? - SHAKEPEARE, KING HENRY IV, PART I


測試方案有三大面向:
設計-組件-系統
(避免發生錯誤的設計方案-組件除錯-系統除錯)


p188, A good top-down design avoids bugs in several way.這裡面的第三點:The suppression of detail makes flaws in the structure more apparent.不是很瞭解!?為什麼隱藏的細節卻可以使結構中的缺陷更容易被突顯出來呢?


名詞解釋：dump (for computer)
(n) The act of copying raw data from one place to another with little or no formatting for readability. Usually, dump refers to copying data from main memory to a display screen or a printer. Dumps are useful for diagnosing bugs. After a program fails, you can study the dump and analyze the contents of memory at the time of the failure. Dumps are usually output in a difficult-to-read form (that is, binary, octal, or hexadecimal), so a dump will not help you unless you know exactly what to look for.

p193, 系統除錯:系統除錯所耗費的時間將超乎預期，而其困難也證明了有必要準備一套條理分明、規畫良好的測試方案。而在系統除錯中有5點:
A:
大致上提到的為:嘗試整合(bolt-it-together-and-try)還有讓各個組件互相測試。另外不建議"先將錯誤記錄起來"的做法。

B:
建立充分的測試鷹架(scaffolding)，屬於鷹架的部分占了產品全部程式碼的一半其實並不為過。
C-E
控制改變、一次只整合一個組件以及固定改版的時機

Chapter 14-釀成大災難(Hatching a catastrophe, P203)
沒有人會給報壞消息的人好臉色看。- 沙孚克里斯
None love the bearer of bad news.

為什麼專案會落後一年?
......因為每次落後一天。
How does a project get to be a year late?
...One day at a time.

p203, 時程總在不知不覺之間延誤，而且非常無情；事實上，顯而易見的事故很容易克服。

Milestone vs. Millstone (p203, 里程碑或者包袱?)
里程碑必須是具體、明確、可量測的事件，有沒有達成應該是一翻兩瞪眼的事情，絕不模稜兩可。

p206, 善用要逕網路圖 (critical-path network)[通稱"計畫評核圖"]

p206, 兩種必須知道的資訊:未如計畫預期的意外狀況，計畫的執行現況。
p207, 兩種知道真相的方法:降低角色的衝突以鼓勵據實回報，審查制度。

p207, 降低角色衝突:執行狀況報告 & 討論解決方案 應該明確分開。

p211, 建立"計畫監控小組"是可以擔任守門員的角色，也就是早期預警系統。

Chapter 15-一體兩面(The Other Face, p217)
我們無法主宰我們不了解的東西。- 歌德
What we do not understand we do not possess. GOETHE

哦!請賜予我簡單平實的評論者，他們不諱莫如深到讓人困惑不解。 - 克拉布
O give me commentators plain, Who with no deep researches vex the brain. CRABBE

**p217, 程式，其實就是人對電腦說話，其內容必須經過審慎、嚴謹的語法編排與定義，這都是為了能將意圖明確地傳達給那台笨電腦。

p218, 為使用程式而寫的文章，最常犯的毛病就是“缺乏”“概觀性的描述（Overview）”，通常可以歸納九點：
    目的、環境、輸入＆輸出值域、欲達成的功能與使用的演算法、輸出入格式、執行過程中的指示、選項、執行時間、輸出結果的精確度＆檢驗方式。

另外還有“為建立對程式的信心所寫的文件”，“為修改程式而寫的文件”（p218-220）

p220,惱人的流程圖，是最被過度強調的文件，許多程式一點都不需要流程圖，也很少有程式需要一頁以上的流程圖。
    繪製詳細的流程圖其實是個既落伍有麻煩的事情，僅適合用來幫助初學者起個頭，協助他進入演算法的思考。

p223, 自我說明程式（Self-documenting），資料處理的基本原則告訴我們，嘗試同步維護不同的文件是件愚蠢的事，“對於同一件事物的相關，應該盡可能統一放在同一份文件中比較好。

p230, 電腦終究是服務人類的，而非由人去配合電腦。

Chapter 16-沒有銀彈：軟體工程的本質與附屬工作 (No Silver Bullet-Essence and Accident in Software Engineering, p235)
在未來的十年之內，無論是在技術上或管理上，都不會有任何單一的重大突破能夠保證在生產力、可靠度或簡潔性上獲得改善，甚至，連一個數量級的改善都不會有。
There is no single development, in either technology or management technique, which by itself promises even one order-of-magnitude improvement within a decade in productivity, in reliability, in simplicity. 

p235, 所有的軟體創作都包括了“本質性(essential task)”和“
附屬性(accidental task)”。
    前者是抽象的軟體實體所組成的複雜概念性結構;
    後者則是用程式語言來表現這些抽象的實體，將程式對應至機器語言。

p238, 本質上軟體實體是由許多彼此環環相扣的概念所組成：
    資料集合、資料項目之間的關係、演算法、各種功能的執行。

p238, 現代軟體都有的天生特質：複雜性(complexity)、配合性(conformity)、易變性(changeability)、隱匿性(invisibility)

p243, 過去的突破都是解決附屬性的難題如：高階語言、分時技術、統一的軟體開發環境。

p245, 尋找銀彈，Ada的理念比Ada語言本身更先進的地方：
    模組化(modularity)
    抽象資料型別(abstract data type)
    階層式結構(hierarchical structure)
其它尋找銀彈的方向還有：物件導向程式設計(object-oriented programming, OOD)，人工智慧(artificial intelligence, AI)，專家系統，<自動化>程式設計(automatic programming)，圖形化程式設計(graphical programming)，軟體的驗證，環境與工具，工作站。

p247, 人工智慧，軟體開發難就難在決定要表達什麼，而不在於表達本身，表達的方式再怎麼簡化，所得到的效益也是有限的。

Chapter 17-再論『沒有銀彈』（"No Silver Bullet" Refired, p269）
無論中彈與否，都是命中注定
Every bullet has its billet.- William III of England, Prince of Orange

無論誰想要看到十全十美的東西，那麼就去想像一下那種過去不曾有過、現在也沒有，而未來也不會存在的事物。
Whoever thinks a faultless piece to see, Thinks what ne'er was, nor is, nor e'er shall be. - Alexander Pope, <An Essay of Criticism>

Chapter 18-<人月神話>的主張：是真是假？

Chapter 19-<人月神話>二十年

補充：
看到了一篇文章提到"吳信輝"先生提出的軟體開發工程師的十大特質：
0 喜歡寫程式
1 完成事情的能力
2 持續地重構你的程式碼
3 使用設計模式
4 撰寫程式碼的測試程式
5 利用現成的程式碼
6 專注在可用性上
7 必須寫出可以維護的程式碼
8 可以在不同的程式語言撰寫程式
9 必須瞭解基本的電腦科學基礎
    大部分都可以在此人月神話此書中相呼應，以學術界深入研究程式語言的角度（也許也曾在業界，沒有進一步查詢）也是將好的軟體開發工程師所需具備的重要特質都提到了。

後記:

Book List:
The Mind of the Maker- Dorothy Sayers
---Idea, Implementation and Interaction

Reference:
Backus-Naur Form(P95, formal notation)

呼叫subVI並以新視窗(VI)開啟程式

前言:
有時候主程式已經布滿了控制元件，或者有些子程式並不需要常態性的顯示，所以當需要的時候再呼叫"另一個"VI可以減少版面的設計。

Code:
Main VI  "本身" 不需要做特別的設定，只要採取底下的方法 ( 2選1 )：

方法一：使用「sub vi node setup」，然後把「Show Front Panel when called、Close afterwards if originally closed」打勾，看看這樣可不可以。

方法二：在 Sub VI 的VI Propertyes -> Window Appearance -> Custmize ->

左邊下方的兩個選項勾取即可:
Show front panel when called &
Close afterwards if originally closed

這樣就可以在主程式(mainVI)呼叫另一個子程式(subVI)囉。

參考網址:
IT360.com

Timing- Wait (ms) & Wait Until Next ms Multiple(ms)

前言:
最近在複習一些基本觀念，有些小細節總是容易搞混，即使用了很多次還是一樣。有關"wait" & "wait until next ms multiple"這兩樣時間控制的元件。

比較:
若以help的解釋來看，其實有點模糊不清楚。所以從網路資訊可以得到的概念大概就是:

wait:執行到包含此元件的時候會等待所設定時間，再繼續執行下一個流程(或下一個迴圈)。wait until...:有點類似wait，但是當要執行下一個流程(或者下一個迴圈)會以設定的時間"倍數"作為起始點。

這樣說起來還是有點ㄚ札，自己的理解大概就是使用wait until...可以保證每次迴圈起始時間都是所設定的整數倍。或者可以參考這裡(需加入會員)

那這樣就衍生一個有趣的問題，在這樣的假設下，在同樣的時間(例如五分鐘、十分鐘或者更長時間)下，超過wait或者wait until...設定時間的程式，那哪個程式可以執行比較多次呢??於是我設計了一個VI如下:

程式的設計是迴圈每兩個迴圈後持行執行一次包含time delay的迴圈。程式中的T1是設定wait的迴圈，另外T2是設定wait until...的迴圈，looptime是兩個並行迴圈共同執行的速度，而code time則是"假的"code運行速度。(使用的ICON為time delay)

狀況一:looptime=100 ms, code time=0.12(120 ms) 
在這樣的模擬下，執行時間與相對應的迴圈技術(i number)如下:
Time(second)-Code count-delta
60-(c1)561/ (c2)601-40
300-(c1)2795/ (c2)2996-201
以上的結果顯示了使用wait until...在相同的時間下，執行的次數反而比較多!??

狀況二:looptime=100 ms, code time(second)>=0.199
在這樣的模擬之下，兩個執行時間則會變成相當接近!!就不會再有持續的差距出現了!!真是有趣啊!?~WHY~ 

小結論:
不過我對這樣的結果也是稍微存疑，因為一來我沒有適合的程式可以真的測試運行時間，用Time delay不知道合不合理。第二因為兩個迴圈雖然是並行運行，但是不知道是否可以自行的變成多核心運行(雖然查詢到的資訊是說會自行轉換!)。至於狀況一與狀況二的差異，還需要思考一下真正導致的原因，雖然我覺得就跟time delay這個icon所造成的有關係，好像有一點點跟原本討論的不太一樣。

Arduino_Project12_Knock Lock

前言：
這次的專題計劃是設計可以上鎖的箱子（同樣地，也是先順利完成專題為主）。利用piezo可以反向的作為感測器（震動），敲打震動的次數來解開鎖定（servo motor）。

硬體：
servo motor, piezo, capacity, LED, resistor...etc

程式：
一開始也要先呼叫servo的函數庫(Servo.h)，在sketch裡面設定敲打的次數(knock number)，以及加入自定義函數來作初始的判斷，判斷piezo是否處在不正確的狀態（例如振動頻率過高或過低）。

Code：
boolean name = true (or false_ 定義"name"的布林參數。

圖片：

後記：
越到後面的專題，難度就越來越高，真是有很多有趣的挑戰性，不過code中的邏輯就更需要去思考為什麼這樣了。也瞭解與學到了如何自定義函數（記錄在後面的補充），雖然好像在之前也有看過的樣子！？～下個專題想必又是令人心動的學習過程。

參考：
Arduino reference

補充：（2013/3/17） 自定義函數（custom function），在這個專題裡面是先出現後，在完成void loop()後才進行“定義”，但是依然會運行在loop裡面！？（這裡還沒搞清楚）！

自定義函數可以有兩種結果：（1）不回傳數值（Value），則宣告此函數為void，類似loop()和setup()函數。（2）回傳數值（Value），則必須宣告數值的形態（int, long, float, etc.），但在這個case裡面是宣告成boolean type(布林形態）  

boolean checkForKnock(int value){....：這個自定義函數中的value是輸入數值，在主要函數內則是以knockVal輸入此位置（但是knockVal其實就是等同於analogRead(piezo)所得到的數值）。

目前測試下，ㄧ開始按下按鈕後，會變成locked然後在serial monitor會一直出現還需要knock的次數，但是敲得很大力會亮黃燈，但是還需敲打次數依然會減少！？然後滿足敲打數（knock number)後會變成unlocked(開鎖)，此時再次按下按鈕，會變成locked(亮紅燈）後馬上就再次變回unlocked（亮綠燈），再按幾次都是如此，是只能進行一次嗎？？怪哉！

解決方案：(2013/3/18)
在比較瞭解程式的邏輯後，我發現原本的code本來就只能執行一次，因為在 "numberOfKnocks" 增加後就不會回到起始點（雖然在“setup”有初始化int numberOfKnocks = 0），所以必須在"loop"的結束後加上以下的code就可以重復的使用此程式囉。

Code:

if(numberOfKnocks >=3){
  numberOfKnocks = 0;
  }