嚴重問題，我的功能程式才合成到10%而已（6.5m）
但是現在程式不管存檔，或是移動程式上任一個元件指令，
程式明顯變得很慢，我說的很慢不是程式Run的時候喔，
而是單存寫程式而已，真的是有夠嚴重的問題，我起出寫到3.xM
的時候就有感覺了，存檔都要一小段的延遲時間，
很難想像被我搞到30m是怎樣的情況。
要是繼續這樣下去，我可能要考慮用dll呼叫的方式了。
請問版內大大，寫過的程式容量大概多少呢？
真難想像你做的東西有多複雜,居然會寫到6.5M
你的程式裡面是不是有很多圖檔啊??..
你覺得你的程式中，最佔容量的是什麼呢?
因為這次測試功能程式，每個功能的寫法都一樣，
最佔容量這感覺好模糊，另外剛剛我的問題好像被我亂搞
之後就解決了，我就一直連點滑鼠左鍵，然後出現Labview執行錯誤，
在開啟一次LabView再一次連點就沒出現延遲現象了，
我剛剛又想到一點子，就是你如果覺得Labview吃電腦效能，
我是用win2000作業系統，你可以開啟工作管理員，監控你的cpu使用率，
因為我目前哪個延遲現象有消失了，我打算他再出現的時候，
在工作管理員哪邊將LabView的執行優先權改成即時。
我剛剛有打電話給Ni工程師，說明我剛剛發生的狀況，他的回答是
跟電腦有關問題是我的電腦p4級的（RAM：512M），下次再出現的話
我在試試看囉，有經驗的人麻煩也分享一下。
至於站長的問題，我的程式還是很簡單的普通寫法，並沒有應用到奇怪的指令，
再寫個別功能測試的時候，這方面的問題我就有再小心使用了，
所以之前我才有提出Local、Property的差別應用。
就等哪該問題再出現在試試看了。
你似乎可以利用Vis Profile去檢查程式的執行效能.我都會利用VIs Profile功能檢查各個VI程式的執行效能,並且針對執行時間較長的Vi進行簡化工作,來改善程式整體效能.
抱歉請問你說的Vis Profile，這是什麼觀念在LabView中要到哪去執行呢？<?:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />
可以麻煩說的詳細點嗎？我第一次看到這樣的觀念，現在好多淺藏的因素讓我好頭
痛喔。
有興趣的人，麻煩把你的程式（選最大的），用一個Sequence重覆貼在每一層重
複製貼上至5m以上，或者更高也可以，然後再選指令元件或是單純一動程式上任
一元件，看看移動程式元件是否移動速度變慢（先點選指令元件，案鍵盤方向鍵移
動），跟開重一程式兩個做比較看看，我剛剛也做了這樣一個測試確實變慢了，這
樣子會造成我程式越寫大越大，越寫越慢因為每拿一個元件就要延遲一下，
我下午問ni工程師他說他用到14M程式沒變化，他說是不是我的
人機介面的控制元件太多了（執行的面板），麻煩有閒暇的大大動手試試看吧！
是不是真的是我的電腦的關係，還是大家都會這樣呢？
這還只是單純的撰寫程式而已，如果整個程式執行起來怕會有其他
副作用。
各位好:
我也有碰過程式執行起來變慢的情況...
不過,並不是因為我的程式寫的太大....
而是我利用到彈跳式的視窗....
我的主視窗程式有呼叫到Matlab script(Matlab本身很占資源)..
如果單單只執行主程式的話...速度上是可以的...
可是當我將另一個彈跳式的視窗叫出來執行的時候...
我的主視窗程式的速度就會變慢...可是彈跳式視窗的程式並不會...
這樣的情況是因為我程式寫不好...
還是有沒有其他原因阿....
禾平38121.8989583333
[QUOTE=菜鳥]
抱歉請問你說的Vis Profile，這是什麼觀念在LabView中要到哪去執行呢？<?:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />
可以麻煩說的詳細點嗎？我第一次看到這樣的觀念，現在好多淺藏的因素讓我好頭
痛喔。
[/QUOTE]
抱歉,因為我一直無法將圖片上傳.所以我先用文字作步驟說明.
1)在LabVIEW的視窗上的tool>>Advanced>>Profile VIs.執行後出現Profile的視窗.
2)執行您的Vi程式.
3)勾選Timing Statistics及Timing Details並在Profile視窗上按下Start按鈕.
4)按下繼續按鈕.
5)按下Snapshot按鈕,更新Vi所執行的相關資訊.
執行Profile後,會將你的程式中,所有使用到的SubVi執行的相關資訊,顯示出來,執行次數,執行時間,執行一次平均時 間...等.
這樣不知道對你有沒有幫助.
註:每按下一次Snapshot按鈕,Profile內的相關資訊才會做更新動作.
[QUOTE=菜鳥]
有興趣的人，麻煩把你的程式（選最大的），用一個Sequence重覆貼在每一層重
複製貼上至5m以上，或者更高也可以，然後再選指令元件或是單純一動程式上任
一元件，看看移動程式元件是否移動速度變慢（先點選指令元件，案鍵盤方向鍵移
動），跟開重一程式兩個做比較看看，我剛剛也做了這樣一個測試確實變慢了，這
樣子會造成我程式越寫大越大，越寫越慢因為每拿一個元件就要延遲一下，
我下午問ni工程師他說他用到14M程式沒變化，他說是不是我的
人機介面的控制元件太多了（執行的面板），麻煩有閒暇的大大動手試試看吧！
是不是真的是我的電腦的關係，還是大家都會這樣呢？
這還只是單純的撰寫程式而已，如果整個程式執行起來怕會有其他
副作用。
[/QUOTE]
LabVIEW內有個功能叫做real-time complie,也就是說當你每做一個修改或新增的動作,Engine將會同時complie整個程式看邏輯上有沒有錯誤,這是 個優點,當你有錯誤發生,可以即時發現執行的箭頭呈現斷掉的符號,缺點呢你已經愈到了,當成是越來越龐大,整個LabVIEW環 境的動作就會越來越緩慢,試想你寫一個6M的C程式,當你執行compile動作時,一定至少得花費幾秒鐘才能完成整個動作.
試著從這個方向去找答案.
BTW,程式能寫到6M以上,除非panel上有很多圖片,不然寫的功能一定很複雜.
其實這問題我找到更恰當的做法了，記的前幾篇我有發表過
Call By Refernce Node的技巧剛剛好適合解決我目前的問題，
最近我蠻常跟Ni工程師請教問題，某位給我的建議是Subvi最好不要
超過1M，可以的話盡量把功能程式以小Vi簡化，即使因為你件很多Subvi
把程式量化了，但是當你Run程式的時候程式還是你把你應用的vi連結起來，
好處是你的主程式會變小，但是你Run的時候電腦資源還是吃蠻大的，
可以應用我上述的方式，做連結的方式（動態吧），有用到在去該設定路徑
讀取，做完就釋放，不知道這樣解釋對不對，有研究的人教導一
下。
[QUOTE=小小羊兒][QUOTE=菜鳥]
有[/QUOTE]
LabVIEW內有個功能叫做real-time complie,也就是說當你每做一個修改或新增的動作,Engine將會同時complie整個程式看邏輯上有沒有錯誤,這是 個優點,當你有錯誤發生,可以即時發現執行的箭頭呈現斷掉的符號,缺點呢你已經愈到了,當成是越來越龐大,整個LabVIEW環 境的動作就會越來越緩慢,試想你寫一個6M的C程式,當你執行compile動作時,一定至少得花費幾秒鐘才能完成整個動作.
試著從這個方向去找答案.
BTW,程式能寫到6M以上,除非panel上有很多圖片,不然寫的功能一定很複雜.
[/QUOTE]
你這樣子解釋我就更明白了，也就是我只要移動一個元件
就compile一次，難怪有時候我覺得一次移動大量元件，跟移動單一個元件，<?:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />
執行速度上有差別，也就是說我現在發生的狀況是必然的，這樣我的觀念
就更明確了。
[QUOTE=菜鳥]
其實這問題我找到更恰當的做法了，記的前幾篇我有發表過
Call By Refernce Node的技巧剛剛好適合解決我目前的問題，
最近我蠻常跟Ni工程師請教問題，某位給我的建議是Subvi最好不要
超過1M，可以的話盡量把功能程式以小Vi簡化，即使因為你件很多Subvi
把程式量化了，但是當你Run程式的時候程式還是你把你應用的vi連結起來，
好處是你的主程式會變小，但是你Run的時候電腦資源還是吃蠻大的，
可以應用我上述的方式，做連結的方式（動態吧），有用到在去該設定路徑
讀取，做完就釋放，不知道這樣解釋對不對，有研究的人教導一
下。
[/QUOTE]
又學到了一項技巧
其實之前有版友說過，LabView裡面有蠻多例子的，
或是把一些功能vi點進去看有蠻多技巧可以學習的，
一點一點慢慢看學起來在問人，反覆這樣做以後遇到問題，
腦袋裝的技巧應該可以解決蠻多問題的，只是有些例子
真的沒英文底子，看起來真的很累人，再加上電腦基礎不好。
慢慢來吧！一招一招學囉。
[QUOTE=菜鳥] 慢慢來吧！一招一招學囉。[/QUOTE]
完全同意，希望每個人都可以在討論或是觀看別人的解決問題方法的過程中，一點一滴學到實用的技巧，這也就是我們這個「LabVIEW技術研討社群」成立的目的與價值。
關於程式過大問題，我也來跟各位大大做個經驗分享。
其實 6M 的程式對我來說，可說是很難達到此要求，因為隨便寫個程式就 10MB 以上了，
更甚者還寫過 30MB 以上的程式，當然功能上算是較複雜的。
對於一支程式這麼大的容量，在程式撰寫上就必須做好物件、變數、迴圈、和 Case 的規
劃與運用：
1. 變數使用上盡量減少使用區域變數
2. 物件的限制是 555 個（若 Front Panel 上的物件超過 555 個，存檔後再開啟此程式
，就馬上掛給你看！）
3. Case 控制在 100 個以下。
4. 迴圈或 Sequence 也應盡量減少，若有宣告常數或是 Sub VI 只需執行一次的，應在迴
圈外宣告，再拉進迴圈內。
5. 盡量使用 LabView 所提供的元件，別再寫個 Sub VI 做相同的功能。
6. 數值變數應選擇適當的資料型態。
總而言之，就是要做到變數、迴圈、物件和 Case 最少啦，希望對各位能有幫助。
你所指的迴圈層次少於100，是指在同一個判斷下面嗎？
如Case100，是這樣嗎？
Front Panel 555目前我還無法超越你，不過我看也不久了。
我有一個技巧適用call by refernce node，我目前用這樣解決了
我程式過大的問題，因為我是做功能測試的，我的主程式目前僅做
功能是否接受測試判斷，哪真正的測試則是去呼叫該vi，這方法確實不錯
跟蠻多位ni工程師請教過了，不知道你還有其他方法適用嗎？
畢竟程式越大問題越多，最大的問題莫過於穩定度。
是的，沒錯，在同一迴圈、Case、Sequence，盡量不要太多。
Front Panel 的物件會超過 555 個是不小心的啦^^，但當時真的傻掉了，辛辛苦苦寫好久的程式
怎會開不起來，搞了半天才知道有這限制。但若物件真的太多，那建議用 Cluster ，因為 Cluster
內不管包含多少物件，LabView 都只當作是一個 Cluster。
程式越大穩定度當然一定不好，而且記憶體使用上是很驚人的（Ctrl+Shift+Esc --> 處理程序頁籤
，可以看到Labview目前佔用多少記憶體），更甚者，一按下按鈕或是移動一下畫面，就會馬上出現
＂使程式作業無效，請立即通知......＂視窗，真是有點給他......!@#$%
你所說的用叢集的觀念
我現在就用這樣了,因為我的輸入設定式多重型態的資料
當初想若是沒用叢集,程式可能會因此報掉,而且會應用到更多的暫存器
不過說真的把所有的控制器及合成一個一個的叢集
叢集的容量還是站蠻大的,我現在是在考慮用queue的技巧程式記憶上若是
真的出現問題像你這樣開不起檔案,我就會叫我們主管拿錢給我我要買記憶體了
給他擴充到1g這當然是最極端的做法了
還有我昨天去聽7.1發表會,7.1系統就是完全針對系統穩定度在做介紹喔
要是有這方面疑慮的人,踴躍參加不錯喔,不過聽到最後系統的穩定度
還是要用錢買來了,轉來轉去都去錢