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

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

right_he兄,需要復(fù)習(xí)一下流程圖各符號代表的意義哦.

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

Delay Time內(nèi)部:

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;
}

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

精彩的在後面 :-)

謝謝各位的分享

優(yōu)化二:告別Delay Time方案二

500) {this.resized=true; this.width=500; this.alt='這是一張縮略圖，點(diǎn)擊可放大。\n按住CTRL，滾動鼠標(biāo)滾輪可自由縮放';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);">

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

方案二流程簡單,高效率.很好很強(qiáng)大!

優(yōu)化三: 6011的Relay & TLL設(shè)置
6011的Relay & TLL的設(shè)置是件很痛苦的事,優(yōu)化一下就會很方便了!
改善建議:Set6011Dev_AllRelayOnOff之類的命,參數(shù)直接傳遞為布爾數(shù)組(0/1).
2349801208854685.rar
500) {this.resized=true; this.width=500; this.alt='這是一張縮略圖，點(diǎn)擊可放大。\n按住CTRL，滾動鼠標(biāo)滾輪可自由縮放';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);">

優(yōu)化四:在沒有6011的情況,測試時(shí)間.
這個(gè)是猛料,先賣個(gè)關(guān)子 :-).

呵呵,強(qiáng)烈期待.

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

各位觀眾,這是替偶們老大KIKO發(fā)出的流程圖!
500) {this.resized=true; this.width=500; this.alt='這是一張縮略圖，點(diǎn)擊可放大。\n按住CTRL，滾動鼠標(biāo)滾輪可自由縮放';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);">

優(yōu)化四: 在沒有6011的情況下,測試時(shí)間:
流程圖是測試開機(jī)時(shí)間的例子,開機(jī)時(shí)間很長時(shí),很實(shí)用,而且比6011的NA卡來得快.
Chroma公司的6011以後賣得少了該不會...! :-)
500) {this.resized=true; this.width=500; this.alt='這是一張縮略圖，點(diǎn)擊可放大。\n按住CTRL，滾動鼠標(biāo)滾輪可自由縮放';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);">

量測時(shí)間還是有區(qū)別的,可以用6011卡和gettimer()比較以下量測時(shí)間,用gettimer()量測時(shí)你會發(fā)現(xiàn)測試的結(jié)果不是很穩(wěn)定,如果是測量rise time等小時(shí)間時(shí),這種區(qū)別就出來了.

歡迎wolf兄參加討論!

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

ps: 也不知Chroma有人關(guān)注沒? 上面這些流程假如導(dǎo)入8200等,效能、適用性提高一個(gè)數(shù)量級應(yīng)問題不大吧:-)

Chroma當(dāng)然有關(guān)注,
這個(gè)功能放在8200裡肯定有問題,因?yàn)?200測試也是一些通用的電源,UUT的時(shí)間單位都是ms級;
但是這個(gè)功能在Chroma 8100系統(tǒng)就是標(biāo)準(zhǔn)的測試項(xiàng)目,因?yàn)镃hroma 8100系統(tǒng)是專門的通信電源測試系統(tǒng),UUT都是有軟啟動這個(gè)功能,開機(jī)的時(shí)間基本上大於8S,所以使用這種方法沒有問題;

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

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