Chroma8000的優化(20080509更新)

寫得好呀!
目前我這邊也在要求Chroma FAE自己編寫得測試ITEM都按照這樣得流程來寫;目前有光寶(長安 ADARPTER部門及廣州)都有在使用這樣的測試項目;改天我將我們的這個測試流程放到網上給大家參考!

那有沒有考慮到,實際輸出電壓 >你設定的Vcheck 而超出規格怎麼辦?
Delay Time 不可以少!!

right_he兄,需要復習一下流程圖各符號代表的意義哦.

等待kiko兄的流程,不過我建議固化成System Item, FAE就不會那麼累了 :-)

Delay Time內部:

VB版:
Private Declare Function timeGetTime Lib "winmm.dll" () As Long
Private lngStartTime As Long

Public Sub StartTimer()
    lngStartTime = timeGetTime()
End Sub

Public Function EndTimer() As Double
    EndTimer = timeGetTime() - lngStartTime
End Function

Public Sub DelayTime(msdelay As Long)
   ' creates delay in ms
   Dim temp As Double
   StartTimer
   Do Until EndTimer > (msdelay)
   Loop
End Sub

CVI版:
void DelayTime (double seconds)
{
    double stime;
    stime = Timer ();
    while (Timer () - stime < seconds)
    {
        ProcessSystemEvents ();
        break;
    }
    maxdelaytime = maxdelaytime + Timer () - stime;
}

你有優化一的方案;
還有沒有其他的方案給大家共享一下?

精彩的在後面 :-)

謝謝各位的分享

優化二:告別Delay Time方案二

500) {this.resized=true; this.width=500; this.alt='这是一张缩略图，点击可放大。\n按住CTRL，滚动鼠标滚轮可自由缩放';this.style.cursor='hand'}" onclick="if(!this.resized) {return true;} else {window.open('http://u.dianyuan.com/bbs/u/64/2349801208490977.jpg');}" onmousewheel="return imgzoom(this);">

方案一的缺點:
1) DelayMS與TimeReset命令接合組成的流程存在精度的問題(記得好像55ms的樣子與CPU配置相關),在執行DelayMS時
CPU在高佔用率的運行,所以精度可能還會更低.CVI的ProcessSystemEvents就處理得很好;
2) 流程稍顯復雜.

方案二流程簡單,高效率.很好很強大!

優化三: 6011的Relay & TLL設置
6011的Relay & TLL的設置是件很痛苦的事,優化一下就會很方便了!
改善建議:Set6011Dev_AllRelayOnOff之類的命,參數直接傳遞為布爾數組(0/1).
2349801208854685.rar
500) {this.resized=true; this.width=500; this.alt='这是一张缩略图，点击可放大。\n按住CTRL，滚动鼠标滚轮可自由缩放';this.style.cursor='hand'}" onclick="if(!this.resized) {return true;} else {window.open('http://u.dianyuan.com/bbs/u/64/2349801208738795.jpg');}" onmousewheel="return imgzoom(this);">

優化四:在沒有6011的情況,測試時間.
這個是猛料,先賣個關子 :-).

呵呵,強烈期待.

他的流程劃錯了,批評他!

各位觀眾,這是替偶們老大KIKO發出的流程圖!
500) {this.resized=true; this.width=500; this.alt='这是一张缩略图，点击可放大。\n按住CTRL，滚动鼠标滚轮可自由缩放';this.style.cursor='hand'}" onclick="if(!this.resized) {return true;} else {window.open('http://u.dianyuan.com/bbs/u/65/2444381209699620.jpg');}" onmousewheel="return imgzoom(this);">

優化四: 在沒有6011的情況下,測試時間:
流程圖是測試開機時間的例子,開機時間很長時,很實用,而且比6011的NA卡來得快.
Chroma公司的6011以後賣得少了該不會...! :-)
500) {this.resized=true; this.width=500; this.alt='这是一张缩略图，点击可放大。\n按住CTRL，滚动鼠标滚轮可自由缩放';this.style.cursor='hand'}" onclick="if(!this.resized) {return true;} else {window.open('http://u.dianyuan.com/bbs/u/65/2349801210301164.jpg');}" onmousewheel="return imgzoom(this);">

量測時間還是有區別的,可以用6011卡和gettimer()比較以下量測時間,用gettimer()量測時你會發現測試的結果不是很穩定,如果是測量rise time等小時間時,這種區別就出來了.

歡迎wolf兄參加討論!

測試ms級的Rise Time用上面的流程當然不適用了,Windows系統用軟件計時精度好像是51ms左右, 況而經8000幾次折騰,精度不要期望超過500ms,ms級的精度隻能通過硬件級的方法量測,我想eLoad應可以量測riseTime而不用6011, 但Chroma公司可能不大願意這樣做.

ps: 也不知Chroma有人關注沒? 上面這些流程假如導入8200等,效能、適用性提高一個數量級應問題不大吧:-)

Chroma當然有關注,
這個功能放在8200裡肯定有問題,因為8200測試也是一些通用的電源,UUT的時間單位都是ms級;
但是這個功能在Chroma 8100系統就是標準的測試項目,因為Chroma 8100系統是專門的通信電源測試系統,UUT都是有軟啟動這個功能,開機的時間基本上大於8S,所以使用這種方法沒有問題;

我沒見過8200, 據說是簡化8000而來.我的建議是導入自動DelayTime , 6011_Relay/TLL設置等,從而整提高測試效率,簡化一些設置.當然在底層dll改善更好,整體性能保守可提高50%.

8200在你們2樓ADP部門,至少40套在用;