एक समय में बग, लेकिन उच्च प्राथमिकता


16

मैं एक सीएनसी (कंप्यूटर संख्यात्मक नियंत्रण) परियोजना पर काम कर रहा हूं जो लेजर की मदद से धातु में आकृतियों को काटती है।

अब मेरी समस्या एक बार में है (20 विषम दिनों में 1-2 बार) कटिंग गलत है या जो सेट किया गया है उसके अनुसार नहीं।

लेकिन इससे नुकसान होता है इसलिए ग्राहक इससे बहुत खुश नहीं होते हैं।

मैंने इसके कारण का पता लगाने की कोशिश की

  1. सहित लॉग फ़ाइलें
  2. डिबगिंग
  3. उसी माहौल को दोहराते हुए।

लेकिन यह दोहराना नहीं होगा।

बग को फिर से देखे बिना एक ठहराव और जारी संचालन इसे फिर से सुचारू रूप से चलाने के लिए बनाएगा।

मैं इस समस्या से कैसे निपटूं? क्या मुझे इसे हार्डवेयर समस्या के रूप में बताना चाहिए?


15
Heisenbug * 8 ' के अद्भुत संसार में आपका स्वागत है )
मार्क बूथ

जब आप कहते हैं कि ऐसा होता है 20 दिनों में 1 से 2 बार, या कि यह 20 के बारे में दिन लगते हैं यह प्रकट करने के लिए के लिए मतलब है यह कभी कभी दिन 1, कभी कभी 3 दिन आदि के बाद दिखाई देता ...
डंक

@ डंक इसका कोई खास समय नहीं है, लेकिन अब तक एक हफ्ते में दो बार भी सामने आया है।
शिरीष ११

@ शिरीष - मैं एक घड़ी के अतिप्रवाह की समस्या की ओर झुक रहा था, जिसे ठीक से संभाला नहीं जा रहा था, जो मैंने सिस्टम पर कई बार देखा है जिसकी समस्या हर इतने दिनों और आगे के निरीक्षण पर होती है, ठीक इतने दिनों में (या कई बार) ।
डंक

सिस्टम को विराम देते समय क्या हो रहा है? क्या मेमोरी / काउंटर / हार्डवेयर अभी भी बदल रहे हैं? जब आप जारी रखते हैं तो क्या होता है? ऐसा लगता है जैसे आप उन कार्यों को करते समय जो कुछ भी बदलाव करते हैं वह समस्या के कारण का एक सुराग है।
डंक

जवाबों:


25

चारों ओर काम

जैसा कि क्रिसएफ सुझाव देता है, व्यावहारिक अल्पकालिक समाधान ठहराव और फिर से शुरू करने की चाल का उपयोग करने के लिए हो सकता है , लेकिन आपको यह जानने के लिए अपने ग्राहकों से बात करनी होगी कि आपकी प्राथमिकताएं क्या होनी चाहिए। उदाहरण के लिए:

  • यदि गलती सप्ताह में एक बार £ 1000 भाग या डाउनटाइम के 4 घंटे का कारण बनती है, जबकि ठहराव फिर से शुरू होने से उत्पादन में 1% की कमी आती है, तो वे शायद अभी फिक्स को पसंद करेंगे।

  • यदि गलती सप्ताह में एक बार £ 1 भाग या डाउनटाइम 4 मिनट का कारण बनती है, लेकिन पॉज़-रिज्यूम फ़िक्स 1% से उत्पादन कम कर देता है, तो वे संभवतः एक फिक्स प्रतीक्षा करना पसंद करेंगे जो उत्पादन दर को प्रभावित नहीं करता है।

कई वर्षों तक लेजर माइक्रो-मशीनिंग उद्योग में काम करने के बाद, मुझे पता है कि आप इस प्रक्रिया का अनुकूलन करने के लिए कितना दबाव में रह सकते हैं और अपनी मशीन को प्रति घंटे कई भागों के रूप में तैयार कर सकते हैं, इसलिए किसी भी तरह से आप नीचे जा रहे हैं समस्या को ठीक करने के लिए दबाव।

लॉगिंग

मेरे अनुभव में, हाइजेनबग को प्रभावी ढंग से ट्रैक करने का एकमात्र तरीका प्रचुर लॉगिंग है। कोड के उस भाग में और उसके आसपास सब कुछ लॉग करें जो त्रुटि के लिए जिम्मेदार हो सकता है। अपनी लॉग फ़ाइलों को प्रभावी ढंग से पढ़ने का तरीका जानें, सुनिश्चित करें कि आप अपने मोटर्स पर त्रुटि के बाद निगरानी कर रहे हैं (क्या आपके चरण चल रहे हैं जहां उन्हें चाहिए?)। मशीन पर मेमोरी के उपयोग को देखें, क्या मेमोरी लीक एक गंभीर प्रक्रिया का कारण बनती है?

सुनिश्चित करें कि आप उपयोगकर्ता कार्रवाइयाँ भी लॉग इन कर रहे हैं, क्या आप सुनिश्चित हैं कि ऑपरेटर आपातकालीन स्टॉप को हिट नहीं कर रहा है, ताकि जब वह ठीक हो रहा हो तो वे एक शिफ्टी सिगरेट ब्रेक के लिए पॉप आउट कर सकें? मैंने ऐसा होते देखा है!

स्थैतिक विश्लेषण

इसके अलावा, कुछ निश्चित पैटर्न और बग को कम या ज्यादा बार ट्रिगर करने के बीच सहसंबंध देखें। यदि आप ऐसे पैटर्न पा सकते हैं जो समस्या को अधिक बार ट्रिगर करते हैं (या इसे कभी ट्रिगर नहीं करते हैं) तो ये आपकी समस्या की ओर इशारा कर सकते हैं।

पैटर्न बनाने की कोशिश करें जो समस्या को और भी अधिक बार ट्रिगर करें । यदि आप समस्या को मज़बूती से ट्रिगर करने का एक तरीका खोज सकते हैं तो आप समाधान का आधा रास्ता हैं।

अन्य विकल्प

अंत में, हार्डवेयर को दोष देने के लिए जल्दी मत बनो, लेकिन कभी भी यह मत मानो कि यह बिल्कुल सही है। कई बार मुझे उन समस्याओं के लिए दोषी ठहराया गया है जो प्रकृति में विद्युत या यांत्रिक हो गई हैं, इसलिए आपको हमेशा अपने दिमाग के पीछे रहना होगा।

भले ही आप आमतौर पर मशीन तक नहीं पहुंच सकते हैं, याद रखें कि कुछ समस्याएं केवल मशीन पर कुशलता से हल की जा सकती हैं। कभी-कभी कुछ दिन ऑन-साइट दूरस्थ डेस्कटॉप और महीनों ऑफ-लाइन के माध्यम से सप्ताह के लायक हो सकते हैं। यदि आप ऑफ-लाइन विकल्पों से बाहर निकलते हैं, तो साइट की यात्रा का प्रस्ताव करने से डरो मत, वे केवल नहीं कह सकते हैं।

आप यह भी देख सकते हैं कि आप हाइजेनबग के साथ क्या करते हैं? और उन कीड़े के साथ क्या करना है जो पुन: नहीं करते हैं? लेकिन ये आपकी स्थिति के लिए इतने उपयोगी नहीं हो सकते हैं।


मेरी समस्या में जोड़ने के लिए और मेरे पास मेरे निपटान में हार्डवेयर नहीं है। और क्लाइंट को इन प्रोग्रामिंग शर्तों को समझने के लिए शिक्षित नहीं किया जाता है। इसलिए उसके सिस्टम पर लटकना संभव नहीं है। सलाह के लिए BTW धन्यवाद चारों ओर एक काम की कोशिश करेंगे।
शिरीष 11

6

मैं एक ऑफ-द-वॉल सुझाव देने जा रहा हूं।

कारखाने के प्रबंधक के पास जाओ और उस उपकरण, या उस क्षेत्र के लिए, जब खराबी हुई थी, उस समय के लिए बिजली लाइन मॉनिटर रिकॉर्ड देखने के लिए कहें। यह भी पूछें कि क्या उस समय के आसपास कोई वेल्डिंग, या कोई अन्य असामान्य गतिविधि थी।

कई दशक पहले, मेरे पिता को एक मिनीकॉम्प्यूटर के साथ एक समय का नरक था जो बिना किसी कारण के दुर्घटनाग्रस्त हो गया था। उन्होंने निर्माता के ग्राहक प्रतिनिधि को बुलाया।

प्रतिनिधि अपने कार्यालय में, कारखाने के क्षेत्र में आया, और एक वाल्टमीटर को दीवार में, मिनी के बगल में प्लग किया, और फिर कहा "यह देखो।"

कुछ मिनट बाद, वाल्टमीटर अचानक झपटा, काफी, फिर वापस आ गया। प्रतिनिधि ने कहा "वह अपने परीक्षण चाप को मार रहा था। एक मिनट रुको।" उसके तुरंत बाद, वाल्टमीटर फिर से sagged, और इस बार यह sagged रहा।

प्रतिनिधि ने कहा, "यह आपकी समस्या है। आपको कारखाने के फर्श पर एक वेल्डिंग करने वाला लड़का मिल गया है, और वह उसी पावर लेग पर है जो आप कर रहे हैं। मैंने देखा कि जैसे वह अंदर जा रहा था, मैंने उसे सेट किया।"

उन्हें कार्यालय में एक पूरी तरह से अलग बिजली फीड चलाना था।


इस की याद दिलाता है: thedailywtf.com/articles/that-70-s-paper-mill
cst1992

4

समस्या उपयोगकर्ता के लिए वास्तविक परिणामों के साथ एक वास्तविक एक है - अर्थात बर्बाद कार्य आदि इसलिए इसे ठीक करने की आवश्यकता है। हालाँकि, इसे "ठीक से" तय नहीं करना है। आप बताते हैं:

एक विराम और जारी रखने का संचालन फिर से बग पुन: प्रकट होने के साथ सुचारू रूप से चलाने के लिए कर देगा।

उस मामले में बस ऐसा करें। ग्राहक खुश होगा कि वे दोषपूर्ण रनों पर सामग्री बर्बाद नहीं कर रहे हैं, भले ही सामान्य रन कुछ सेकंड लगते हैं।

स्पष्ट रूप से लंबे समय में आपको इसे "ठीक से" ठीक करने की आवश्यकता हो सकती है, लेकिन समय के लिए अपने नुकसान में कटौती करने के लिए, वर्कअराउंड के साथ जाएं और कुछ और प्राप्त करें।


4

मेरे पास एक खेल में एक बग था जो एक अरब में केवल 1 बार हुआ। सौभाग्य से इसका मतलब है कि मैं इसे हर 15 से 30 मिनट में देख रहा था, लेकिन डिबगर में कोड के माध्यम से कदम रखना काम नहीं कर रहा था। मैंने डिबग संदेशों में डाल दिया। अगर वे बयान चाहते थे तो उन्हें फैंसी का उपयोग करने की आवश्यकता थी क्योंकि समस्या होने पर मैं कुछ करना चाहता था। अधिकांश मामलों में डिबगिंग कोड नियमित कोड में गणना दोहरा रहा था लेकिन विभिन्न तकनीकों का उपयोग कर रहा था। दोहराव सटीक नहीं था। अगर मुझे पता था कि एक संख्या हमेशा 10,000 से कम होनी चाहिए और यह अवसर पर 150,000 मारा गया था, तो मैं सिर्फ 100,000 से अधिक मूल्य की जांच करूंगा। हर बार बग होने के बाद, मैं अपने परिणामों का अध्ययन करता हूं, और अधिक विस्तृत डिबगिंग संदेश तैयार करता हूं (या अधिक सटीक रूप से, अधिक विस्तृत जांच करता हूं कि क्या मुझे एक संदेश प्रदर्शित करना चाहिए), और समस्या फिर से आने का इंतजार करें।

आपका चक्र मेरा होने की तुलना में बहुत लंबा होने जा रहा है, लेकिन आप अंततः समस्या को बंद कर देंगे। मुझे आशा है कि आप कुछ अन्य, तेज विधि द्वारा समाधान पा सकते हैं, लेकिन यह अंततः पकड़ लेगा यदि कुछ और नहीं करता है, और आपको यह समझ देगा कि आप कुछ कर रहे हैं जब तक कि आप एक बेहतर विचार नहीं लाते।

(यदि यह मददगार है, तो मैंने अंत में कोड की कुछ पंक्तियों को साफ करके अपनी समस्या को हल कर लिया है, जिन्हें मैंने अंततः समस्या के रूप में पहचाना है। मैं शपथ लूंगा कि उनके साथ कुछ भी गलत नहीं था, लेकिन मुझे लगता है कि दोनों अनुकूलक और सीपीयू के लिए निर्देश पुन: व्यवस्थित कर रहे थे। प्रदर्शन, और मुझे लगता है कि एक बार थोड़ी देर में वे कुछ अतिरिक्त गति प्राप्त करने का मौका ले रहे थे। यहां तक ​​कि इन दिनों एक भी कोर मल्टी-प्रोसेस, और मुझे लगता है कि एए में हर महान एक बार जबकि एक रजिस्टर पढ़ने से पहले लिखा गया था। मैंने स्थानीय चर के साथ काम करने के लिए सभी गणनाओं को बंद कर दिया। "इंस्टेंस फील्ड" मानों को शुरू में ही स्थानीय चर में स्थानांतरित कर दिया गया था, और स्थानीय मूल्यों को केवल सिंक्रनाइज़ेशन ब्लॉकों के अंदर बहुत अंत में वापस ले जाया गया था। और मैंने स्थानीय मूल्य का उपयोग किया। विधि उदाहरण के बजाय "उदाहरण क्षेत्र"मैं उपयोग कर रहा था।)


+1 की जाँच करने के लिए और समस्या की जड़ में धर्मान्तरित करने के लिए लॉगिंग संदेशों की पुनरावृत्ति सुधार।
मार्क बूथ

1

डिबगिंग में नियम 1 नंबर एक: आपको एक प्रतिलिपि प्रस्तुत करने योग्य परिदृश्य की आवश्यकता है

यदि आपके पास एक नहीं है, तो आपको पहले उस पर काम करना चाहिए। क्या आप उस बग को किसी प्रकार के मशीन के "सिमुलेशन मोड" में पुन: पेश कर सकते हैं, जहां वास्तव में कोई धातु नहीं काटी जाती है? यह यहाँ समझ में आता है। क्या आप कुछ ही मिनटों में 20 दिनों की प्रक्रिया का अनुकरण करते हुए, जल्दी और स्वचालित रूप से कई अलग-अलग कटिंग प्रोग्राम चला सकते हैं? इससे समस्या के बढ़ने की संभावना बढ़ सकती है।

फिर, जब आपके पास इस तरह का परिदृश्य होता है, तो अगला कदम संभव के रूप में अधिक जानकारी इकट्ठा करना और वास्तव में डिबगिंग शुरू करना है।


कुछ दिनों में 20 दिनों की प्रक्रिया का अनुकरण संभव नहीं है। मुझे हार्डवेयर पर विचार करना होगा।
शिरीष ११

2
मैं कभी भी एक हाइजनबग भर में नहीं आया हूं जिसे सिमुलेशन मोड का उपयोग करके पुन: पेश किया जा सकता है । समस्याएं लगभग हमेशा उन घटकों में होती हैं जो बाहर सिम्युलेटेड हैं या उनके बीच युग्मन है। जैसा कि मैंने कहा, यदि आप समस्या को मज़बूती से हल कर सकते हैं, तो आप समाधान का आधा रास्ता हैं।
मार्क बूथ

@ शिरीष: "कुछ ही मिनटों में प्रक्रिया का अनुकरण करना" एक चरम हो सकता है, लेकिन बग के होने के लिए 20 दिनों की प्रतीक्षा करना और बहुत सी धातु को काटने देना ताकि बग को पॉप अप किया जा सके। शायद बीच में कुछ संभव है।
डॉक्टर ब्राउन

2
@ शिरीष-अगर आपने हार्डवेयर को अलग नहीं किया है तो इसका अनुकरण करना संभव हो जाता है इसका मतलब है कि डिज़ाइन में कमी है। इसका मतलब यह भी है कि आपके सिस्टम को पर्याप्त रूप से परीक्षण नहीं किया जा सकता था। इस प्रकार, यह कोई आश्चर्य की बात नहीं है कि सिस्टम के पास मुद्दे हैं।
डंक

1
@ डंक - क्या आपने कभी लेजर स्क्राइबिंग इंडस्ट्री में काम किया है? आपके पास हमेशा एक सिम्युलेटर की विलासिता नहीं होती है और यहां तक ​​कि अगर आपके पास एक अच्छा था, तो एक जटिल मेज़ट्रोनिक सिस्टम की सभी जटिलताओं को पूरी तरह से अनुकरण करने के लिए प्रभावी लागत नहीं होगी। निम्नलिखित त्रुटि, वेग प्रोफाइलिंग, सब-माइक्रोन सटीक पर पल्स ट्रैकिंग, सॉफ्ट और हार्ड रियल-टाइम सिस्टम के बीच इंटरैक्शन, टैक टाइम प्रेशर - वास्तविक समय में बहुत से अनुकरण करने पर एक क्लस्टर लगेगा, इसे अकेले 1 / 10,000 में कर दें। रियल टाइम। तेज़ / बेहतर / सस्ता - आप शायद ही तीनों हो सकते हैं, इसलिए कृपया कोशिश करें कि यह इतना न्यायपूर्ण न हो।
मार्क बूथ

1

सुनिश्चित नहीं हैं कि भाषा इस में चलाया जाता है, लेकिन अगर मैं अपने कोड (C ++) में अनियमित कीड़े का अनुभव है, मैं जैसे किसी उपकरण का उपयोग करेगा valgrind या cppcheck सुनिश्चित करने के लिए कुछ भी नहीं स्मृति के लिहाज से चल रहा है।


0

राल्फचैपिन के उत्तर पर एक विस्तार:

इन वर्षों में मुझे बगों की एक उचित संख्या का शिकार करना पड़ा है जो केवल उन प्रणालियों पर खुद को दिखाता है जो मैं संलग्न हार्डवेयर के कारण डुप्लिकेट नहीं कर सका।

पागलों की तरह लॉग करने के अलावा एक और चीज मुझे उपयोगी लगी: स्क्रीन पर जानकारी डालना जहां कोड था और कुछ प्रासंगिक चर के मान थे। जब समस्या दिखाई दी तो कारखाने के फर्श के कर्मचारी भी मुझे जानकारी पढ़ सकते थे।

आमतौर पर इसे ठीक करने के लिए परिशोधन के कुछ दौर लगते थे लेकिन यह बहुत प्रभावी था।

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.