जब एकएडवांटेस्ट टेस्ट मशीन V93000यदि परीक्षण हेड से कनेक्शन नहीं हो पा रहा है या संचालन के दौरान कनेक्शन टूट जाता है, तो यह न मानें कि इंस्ट्रूमेंट कार्ड खराब हो गया है। पहली त्रुटि को सुरक्षित रखें, यह सुनिश्चित करें कि नियंत्रक चालू रहा और पहले से मौजूद बिजली, शीतलन या सिस्टम संबंधी अलार्म की जांच करें।
एक संचार संदेश किसी असफल बातचीत की पहचान करता है। यह जरूरी नहीं कि उस घटक की पहचान करे जिसके कारण यह असफल बातचीत हुई।
पहला काम स्टार्टअप कनेक्शन विफलता और सफल संचालन के बाद कनेक्शन खो जाने के बीच अंतर करना है।
स्टार्टअप विफलता या रनटाइम डिस्कनेक्ट?
ये दोनों स्थितियाँ अलग-अलग प्रकार के साक्ष्य प्रस्तुत करती हैं।
| परिस्थिति | सबसे पहले क्या स्थापित करना है |
|---|---|
| स्टार्टअप के बाद टेस्ट हेड कभी उपलब्ध नहीं होता। | क्या नियंत्रक, परीक्षण-हेड की तैयारी और आरंभीकरण अनुक्रम आवश्यकतानुसार पूरा हुआ? |
| सफल आरंभीकरण के बाद कनेक्शन टूट जाता है | व्यवधान से ठीक पहले क्या परिवर्तन हुआ या क्या चिंताजनक स्थिति उत्पन्न हुई? |
| एक उपकरण का आरंभीकरण विफल हो जाता है जबकि हेड अभी भी सुलभ रहता है। | क्या समस्या केवल उस उपकरण तक सीमित है या उसकी निर्भरताओं तक? |
| डिवाइस का परीक्षण रुक जाता है लेकिन हेड कनेक्टेड रहता है | चाहे व्यवधान प्रोग्राम, इंटरफ़ेस या स्वचालन प्रवाह से संबंधित हो |
| कंट्रोलर खुद ही फ्रीज हो जाता है या रीस्टार्ट हो जाता है। | क्या होस्ट के नष्ट होने के कारण टेस्ट-हेड का स्पष्ट डिस्कनेक्ट हुआ? |
ऑपरेशन रुकने के सटीक चरण को रिकॉर्ड करें। "परीक्षक डिस्कनेक्ट हो गया है" की तुलना में "नियंत्रक प्रतिक्रियाशील बना रहा, लेकिन शीतलन अलार्म के बाद परीक्षण हेड अनुपलब्ध हो गया" कहना अधिक उपयोगी है।
V93000 मेंसेमीकंडक्टर परीक्षककनेक्शन में खराबी कंट्रोलर, संचार पथ या टेस्ट-हेड इंफ्रास्ट्रक्चर से संबंधित हो सकती है। यह तय करने से पहले कि किस घटक की जांच की आवश्यकता है, प्रभावित कनेक्शन की पहचान करें।
पुष्टि करें कि कौन सा कनेक्शन विफल हो गया है
केबल बदलने या रिप्लेसमेंट बोर्ड ऑर्डर करने से पहले, त्रुटि में शामिल एंडपॉइंट्स की पहचान करें।
संबंधित संबंध निम्न हो सकता है:
नियंत्रक परीक्षण हेड के साथ संचार कर रहा है।
सिस्टम एक व्यक्तिगत उपकरण को प्रारंभ कर रहा है।
परीक्षक, हैंडलर या वेफर प्रोबर के साथ संकेतों का आदान-प्रदान कर रहा है।
लाइसेंस सर्वर से संपर्क करने वाला सॉफ़्टवेयर।
एक रिमोट वर्कस्टेशन जो टेस्टर कंट्रोलर तक पहुंच रहा है।
हैंडलर टाइमआउट से यह सिद्ध नहीं होता कि कंट्रोलर और टेस्ट हेड के बीच का कनेक्शन विफल हो गया है। इसी प्रकार, कंट्रोलर तक रिमोट एक्सेस खो जाने से यह साबित नहीं होता कि टेस्टर का आंतरिक संचार पथ दोषपूर्ण है।
मूल संदेश और सिस्टम की स्थिति का उपयोग करके प्रभावित संबंध की पहचान करें। संचार से संबंधित प्रत्येक संदेश को एक ही त्रुटि के रूप में न मानें।
पुनः आरंभ करने से पहले पहली त्रुटि को सहेजें
स्क्रीन से उपयोगी संदर्भ हट जाने के बावजूद, रीस्टार्ट करने से संचालन अस्थायी रूप से बहाल हो सकता है।
यदि सुरक्षित हो, तो इसे संरक्षित करें:
पहली त्रुटि और उसके बाद के सभी संदेश।
संबंधित कंट्रोलर और टेस्टर लॉग।
व्यवधान का समय।
कौन से एप्लिकेशन और सेवाएं प्रतिक्रियाशील बनी रहीं?
टेस्ट-हेड और कूलिंग यूनिट की स्थिति।
क्या सभी उपकरण अनुपलब्ध हो गए या केवल एक संसाधन अनुपलब्ध हो गया?
उस समय कार्यक्रम और संचालन चरण सक्रिय थे।
हाल ही में सॉफ्टवेयर, हार्डवेयर या सुविधाओं में हुए बदलाव।
विभिन्न प्रणालियों के लॉग की तुलना करते समय टाइमस्टैम्प को संरेखित रखें। कंट्रोलर घड़ी और सुविधा निगरानी घड़ी में एक ही समय दिखाई नहीं दे सकता है।
किसी अन्य V93000 पीढ़ी के लिए मिले मिलते-जुलते संदेश से त्रुटि कोड की व्याख्या न करें। संबंधित दस्तावेज़ से मिलान करने के लिए मूल शब्द को सुरक्षित रखें।
यदि स्टार्टअप के समय टेस्ट हेड कनेक्ट नहीं होता है
नियंत्रक की तत्परता की जाँच करें
यह सुनिश्चित करें कि कंट्रोलर ने अपना सामान्य बूट पूरा कर लिया है और आवश्यक सॉफ्टवेयर वातावरण उपलब्ध है या नहीं।
यदि कंट्रोलर बूट नहीं होता है, बार-बार रीस्टार्ट होता है या अनुत्तरदायी हो जाता है, तो समस्या का कारण टेस्ट हेड को बताने से पहले उस स्थिति की जांच करें।
कंट्रोलर बदलने या सिस्टम इमेज को पुनर्स्थापित करने के बाद, समर्थित ऑपरेटिंग वातावरण और पुनर्स्थापित कॉन्फ़िगरेशन की समीक्षा करें। डेस्कटॉप का सही ढंग से काम करना यह साबित नहीं करता कि परीक्षक वातावरण सही ढंग से पुनर्स्थापित हो गया है।
मौजूदा स्थिति और बैकअप को सुरक्षित रखे बिना सॉफ़्टवेयर को दोबारा इंस्टॉल करने या कॉन्फ़िगरेशन फ़ाइलों को बदलने से बचें।
टेस्ट-हेड की तत्परता और पूर्व चेतावनी की समीक्षा करें
ऑपरेटिंग प्रक्रिया द्वारा अनुमत स्थिति संबंधी जानकारी की जाँच करें। पता लगाएं कि क्या किसी अनसुलझी सिस्टम समस्या के कारण आरंभीकरण बाधित हो रहा है।
बिजली, शीतलन या अन्य सुरक्षात्मक स्थितियाँ तत्परता में बाधा डाल सकती हैं और बाद में संचार त्रुटि उत्पन्न कर सकती हैं। केवल अंतिम संदेश की जाँच करने के बजाय, सबसे पहले हुई प्रासंगिक घटना की जाँच करें।
आरंभिकरण को जबरन करने के लिए इंटरलॉक को बायपास न करें या सुरक्षात्मक अलार्म को दबाएं नहीं।
प्रलेखित बाह्य संचार पथ का निरीक्षण करें
स्थापित नियंत्रक और परीक्षण-शीर्ष विन्यास के लिए सही संचार मार्ग की पहचान करें। केबल के प्रकार, कनेक्टर और बुनियादी ढांचा अलग-अलग प्रतिष्ठानों में भिन्न होते हैं।
जब सिस्टम निर्धारित सुरक्षित स्थिति में हो, तो योग्य कर्मी सुलभ कनेक्शनों की क्षति, तनाव, असुरक्षित जुड़ाव या हाल ही में की गई सर्विस के दौरान किए गए परिवर्तनों के लिए जांच कर सकते हैं।
यह न मानें कि कोई साधारण नेटवर्क केबल उपयुक्त विकल्प है। निर्धारित प्रक्रिया का पालन किए बिना ऑपरेटिंग सिस्टम को प्रयोग के तौर पर अनप्लग न करें या ऑप्टिकल कनेक्टर्स को न छेड़ें।
यदि कोई दृश्य लिंक संकेत मौजूद है, तो वह इस बात का सहायक प्रमाण है न कि इस बात का प्रमाण कि सभी आवश्यक संचार ठीक से काम कर रहा है।
यदि ऑपरेशन के दौरान कनेक्शन टूट जाता है
रनटाइम व्यवधानों के लिए, घटना क्रम विशेष रूप से महत्वपूर्ण है। संचार बाधित होने से पहले क्या हुआ था, यह निर्धारित करें।
| प्रेक्षित पैटर्न | जांच की दिशा | इससे यह साबित नहीं होता कि |
|---|---|---|
| कूलिंग या पावर अलार्म बजने पर कनेक्शन टूट जाता है। | प्रारंभिक अलार्म और सुरक्षात्मक प्रतिक्रिया की समीक्षा करें | संचार हार्डवेयर दोषपूर्ण है |
| कंट्रोलर एक ही समय पर फ्रीज या रीस्टार्ट हो जाता है | नियंत्रक और ऑपरेटिंग सिस्टम के साक्ष्य की समीक्षा करें | परीक्षण प्रमुख ने व्यवधान उत्पन्न किया। |
| टेस्ट-हेड की गति के कारण विफलता हुई। | अनुमत बाहरी केबल रूटिंग, तनाव और संबंधित कनेक्शनों का निरीक्षण करें। | उस आंदोलन ने असफल हिस्से की निर्णायक रूप से पहचान कर ली है। |
| सॉफ़्टवेयर या कॉन्फ़िगरेशन में बदलाव के बाद व्यवधान शुरू होता है | दस्तावेजी रूप से समर्थित कॉन्फ़िगरेशन से तुलना करें | सॉफ्टवेयर में बदलाव ही मूल कारण है |
| एक उपकरण व्यापक परिचालन हानि से पहले त्रुटियों की रिपोर्ट करता है। | मूल उपकरण त्रुटि और साझा निर्भरताओं की समीक्षा करें | केवल उस उपकरण के कारण ही शटडाउन हुआ। |
| विफलताएँ केवल एक विशिष्ट कार्यक्रम के दौरान ही होती हैं। | संसाधनों के उपयोग और परिचालन स्थितियों की तुलना करें | या तो प्रोग्राम में कोई खराबी है या हार्डवेयर ठीक है? |
ये पैटर्न जांच में मार्गदर्शन प्रदान करते हैं। ये निदान या पुष्ट मरम्मत निष्कर्ष का विकल्प नहीं हैं।
लोड संबंधी व्यवधान से पहले की स्थितियों को रिकॉर्ड करें
यदि परीक्षक निष्क्रिय अवस्था में कनेक्टेड रहता है लेकिन डिवाइस परीक्षण के दौरान डिस्कनेक्ट हो जाता है, तो सक्रिय कॉन्फ़िगरेशन और परिचालन स्थितियों को रिकॉर्ड करें।
बिजली और शीतलन व्यवहार, उपकरण गतिविधि, नियंत्रक घटनाएँ और प्रोग्राम निष्पादन सभी प्रासंगिक हो सकते हैं। निष्क्रिय कनेक्शन परीक्षण उत्पादन के दौरान मौजूद हर स्थिति को पुन: उत्पन्न नहीं करता है।
किसी संदिग्ध हानिकारक स्थिति को बार-बार दोहराकर केवल त्रुटि को पुन: उत्पन्न करने का प्रयास न करें।
गति संबंधी लक्षणों को एक अलग संकेत के रूप में मानें।
डॉकिंग, अनडॉकिंग या स्थिति परिवर्तन के बाद यदि कोई रुकावट आती है, तो विफलता उत्पन्न करने के लिए सिर को बार-बार हिलाए बिना संबंध को दस्तावेज़ित करें।
बाहरी केबल में खिंचाव या किसी हलचल से प्रभावित कनेक्शन की जांच आवश्यक हो सकती है। यांत्रिक स्थिति में बदलाव किसी अन्य परिवर्तन के साथ भी हो सकता है, इसलिए केवल समय के आधार पर निदान नहीं किया जा सकता।
केवल डिस्कनेक्ट संदेश के आधार पर PS1600 या AVI64 को न बदलें।
किसी एक उपकरण में खराबी और टेस्ट-हेड संचार के बाधित होने के लिए अलग-अलग साक्ष्य की आवश्यकता होती है।
यदि परीक्षण शीर्ष सुलभ रहते हुए भी कोई उपकरण निदान में विफलता की सूचना देता है, तो संबंधित प्रक्रिया का उपयोग करके उस संसाधन की जांच करें।
यदि कई उपकरण एक साथ गायब हो जाते हैं, तो यह निष्कर्ष निकालने से पहले कि कई कार्ड एक साथ विफल हो गए हैं, साझा बुनियादी ढांचे की समीक्षा करें।
किसी उपकरण को बदलने पर तभी विचार किया जाना चाहिए जब जांच से यह साबित हो जाए कि हार्डवेयर की आवश्यकता उचित है। बिना नियंत्रण के उपकरण बदलने से संगतता संबंधी समस्याएं, विन्यास में परिवर्तन और अतिरिक्त अंशांकन की आवश्यकता उत्पन्न हो सकती है।
जहां प्रतिस्थापन की अनुमति हो, वहां सत्यापित संगत हार्डवेयर का उपयोग करें और एक समय में केवल एक ही चर बदलें। मूल और प्रतिस्थापन की पहचान और तुलना के परिणाम रिकॉर्ड करें।
रिकवरी के बाद किन चीजों का सत्यापन करना आवश्यक है?
सफल पुनः कनेक्शन प्रारंभिक सुधार का परिणाम है। यह पूर्ण उत्पादन स्वीकृति नहीं है।
लागू स्टार्टअप और सेवा के बाद की प्रक्रियाओं का पालन करें, फिर सत्यापित करें:
हार्डवेयर की पहचान अपेक्षित है।
आवश्यक निदान प्रक्रिया पूरी हो गई है।
आरंभिक अलार्मों का समाधान।
हस्तक्षेप के लिए आवश्यक कोई भी अंशांकन।
संबंधित अनुप्रयोग स्थितियों के अंतर्गत स्थिर संचालन।
जहां लागू हो, वहां हैंडलर या जांचकर्ता के साथ सही संचार स्थापित करें।
किसी रुक-रुक कर होने वाली समस्या के लिए, विफलता कब हुई, इसके आधार पर एक सार्थक सत्यापन दायरा परिभाषित करें। लंबे समय तक संचालन के बाद पहले हुई किसी रुकावट के समाधान को प्रदर्शित करने के लिए एक संक्षिप्त स्टार्टअप परीक्षण अपर्याप्त है।
यदि कनेक्शन फिर से टूट जाता है, तो नए सबूतों को सुरक्षित रखें और बार-बार रीसेट करने पर निर्भर रहने के बजाय जांच जारी रखें।
मरम्मत या प्रतिस्थापन मूल्यांकन के लिए आवश्यक जानकारी
कंट्रोलर, इंटरफेस असेंबली या उपकरण भेजने से पहले, निम्नलिखित जानकारी प्रदान करें:
| जानकारी | उद्देश्य |
|---|---|
| V93000 पीढ़ी और परीक्षण-शीर्ष पहचान | हार्डवेयर संदर्भ स्थापित करता है |
| नियंत्रक मॉडल और सॉफ्टवेयर वातावरण | कॉन्फ़िगरेशन समीक्षा का समर्थन करता है |
| स्मार्टटेस्ट रिलीज़ | स्थापित सॉफ़्टवेयर संदर्भ की पहचान करता है |
| पहली त्रुटि और संपूर्ण लॉग | मूल विफलता अनुक्रम को संरक्षित करता है |
| स्टार्टअप या रनटाइम घटना | आरंभिकरण को आंतरायिक संचालन से अलग करता है |
| बिजली और शीतलन घटनाएँ | अपस्ट्रीम व्यवधान की पहचान करने में मदद करता है |
| हाल के बदलाव | प्रासंगिक तुलनाओं को परिभाषित करता है |
| संदिग्ध घटक लेबल | सटीक पार्ट मैचिंग में सहायता करता है |
जहां आवश्यक हो, गोपनीय डिवाइस-प्रोग्राम संबंधी जानकारी हटा दें, लेकिन खराबी की जांच के लिए आवश्यक नैदानिक विवरणों को सुरक्षित रखें।
विदेशी सेवा के लिए, यह साक्ष्य यह निर्धारित करने में मदद करता है कि अगला कदम स्थानीय सुविधा की जाँच, अधिकृत सिस्टम निरीक्षण, नियंत्रक मूल्यांकन या किसी विशिष्ट घटक की मरम्मत होना चाहिए या नहीं। इससे असंबंधित असेंबली को भेजने का जोखिम भी कम हो सकता है।
V93000 कनेक्शन-दोष मूल्यांकन का अनुरोध करें
मूल कनेक्शन त्रुटि, सिस्टम पहचान और घटना का संक्षिप्त समयक्रम भेजें। यह बताएं कि टेस्ट हेड कभी कनेक्ट नहीं हुआ, आरंभिकरण के बाद डिस्कनेक्ट हो गया या किसी अन्य अलार्म के बाद अनुपलब्ध हो गया।
पहले से पूरी की गई जांचों और पिछली सफल प्रक्रिया के बाद से किए गए किसी भी हार्डवेयर या सॉफ्टवेयर परिवर्तन को शामिल करें।
