各位前輩們好
我在試做小綠人的時候，是用到兩個While loop 一個管理秒數，一個是管理小綠人的速度
但是放上去meeting的時候被說架構很爛，可以用到狀態機來做，但是我想不到該如何利用狀態機來做，
因為我之前把他們兩個小迴圈同時放在一個while loop裡，可是一定要等到秒數跑完一次，小綠人才會再跑一次
想請各位幫幫忙，只用一個while loop就可達成
這次問題的核心關鍵就在，要把最頻繁更新/偵測秒數的放在最內部。
這個寫法的偷吃步在於，秒數就是秒數，讓事情簡單化，而不是兩個不同速度的變速齒輪。
如果你要用燈號秀Elapsed Time
你一樣可以建立一個10 Pages的2D秒數圖形(的3D Array)，然後用Case，決定取得哪一個Index Array。
小綠人可以1秒10個動作，你用10個Pages是沒問題。小綠人動作10 fps就很夠了。
但是秒數倒數，你最好練習自己寫兩位數七段顯示器，會比較漂亮。然後Case結構中，用99..代表所有大於等於99的Case，用..0代表所有小於等於0的(非負)整數。
在學習過程中，狀態機比多迴圈的架構還簡單。平行運算就沒有所謂的單迴圈狀態機了。多迴圈才會跟平行運算沾上邊。
因為你們主要運用的可能是機械控制或自動控制，狀態機可能比較常用，但就LabVIEW架構來說，多迴圈是比較進階的。
我今天小綠人如果1秒17個動作，狀態機裡面的倍數不就有除不盡的風險了。
若用單迴圈狀態機，或我這種無平行迴圈的方式，小綠人58ms*17或59ms*17，986ms跟1003ms才能更新一次秒數，這樣都會造成「秒數的更新不夠及時。」
今天如果是倒數鳴槍起跑，你要怎麼負這個失去3ms的責任?
雙迴圈才可以打從根本避免這個問題。秒數更新解析度可以達到軟體該負責的1ms或更快，誰管你把小綠人切幾半。大致上推測你們主要的領域是機械控制，切多少步是可以自己選的而不是被決定的。
回到原本建議你用單迴圈狀態機的看法來說，
你自己有點出關鍵在某些東西不跑完，就代表外層迴圈要等「裡面都跑完」才能下一次。讓「小綠人」更新10次你才更新1次「秒數」，就是一種答案。
補充：單迴圈也可以用每一圈1ms，計數100次更新1張小綠人，計數1000次更新一張秒數。
這樣可以達到1ms的更新速率，同時簡單地hold住小綠人跟計數之間的比例。
這個方法的核心在於採用極小的時間間隔控制迴圈，採用計數的方式控制不同元件的更新的counting timing。
但這有下面兩個風險：
1. 關鍵時刻，小綠人與秒數同時更新時，還是會有瞬間同時繁忙的衝突。只要一沒有寫好，這兩個部分就會用同一個CPU去執行。只要一繁忙，就容易造成這一圈迴圈超過1ms的機會大增。除非謹慎地選擇這個時間間隔。
2. 不論使用Wait還是wait until next ms multiple，(不討論第一圈)都只能保證這一圈「至少」執行1ms。但這個1ms非常容易被超過。
這個方法相信可以用「計數」1ms替代時間，但只要一繁忙，單圈超過1ms，假定突然花了3ms，這個delay就再也回不來了。
必須要增加額外的時間檢查來對時。
一旦需要對時，你的損失就是小綠人要「失步」，計數要偷偷對準。但小綠人的「起步」跟「計數秒數+1」的起步同步性你還是可以hold住。
這就是這個方法可能會產生的幾項缺失。