आप अपने हार्डवेयर डिज़ाइन निर्णयों का दस्तावेज़ कैसे बनाते हैं?


43

आप डिजाइन चरण में अपने हार्डवेयर निर्णयों का दस्तावेज कैसे बनाते हैं? पिछले दिनों आपके द्वारा किए गए हार्डवेयर डिज़ाइन की समीक्षा करते समय आप स्वयं से निम्नलिखित प्रश्न पूछने से कैसे बचते हैं:

  • इस घटक को क्यों चुना?
  • मैंने / इस घटक के लिए इन विशेष मापदंडों को क्यों / कैसे चुना?
  • सर्किट का यह हिस्सा क्या करता है?
  • इस घटक के माध्यम से बिजली अपव्यय क्या है?
  • इस सर्किट की कुल बिजली खपत कितनी है?
  • क्या मैं इस घटक को इस अन्य के साथ बदल सकता हूं? क्या इस घटक के समतुल्य घटक हैं? आदि।

सर्किट के डिज़ाइन चरण के दौरान अपने निर्णयों और गणनाओं का दस्तावेज़ीकरण करने का एक अच्छा तरीका क्या है? मुझे सैकड़ों डेटाशीट पृष्ठों के माध्यम से फिर से जाने के बिना ऊपर दिए गए सवालों के जवाब कैसे मिलेंगे?

एक तरीका है कि मैं योजनाबद्ध फाइलों में नोट जोड़ सकता हूं (यदि आपका ईडीए इसे समर्थन करता है), लेकिन मैं बहुत अधिक जानकारी के साथ योजनाबद्ध अव्यवस्था नहीं करना चाहता।


1
इन विवरणों को कौन देखने जा रहा है? क्या वे सिर्फ आपके संदर्भ के लिए हैं या वे दूसरों द्वारा देखे जाएंगे?
stanri

@Stacey प्रलेखन मेरे और अन्य डिजाइनरों दोनों के लिए पढ़ने के लिए अभिप्रेत है। मैं अपने भविष्य के अधिकांश डिजाइनों को खुला स्रोत बनाना चाहता हूं और यह बहुत महत्वपूर्ण है कि वे ठीक से प्रलेखित हों।
एम। क्लिन

9
@ स्टेसी लेकिन वास्तव में .. क्या अंतर है? थोड़ी देर के बाद आप अपने स्वयं के डिजाइन को देखेंगे जैसे कि यह पहली बार आप इसे देख रहे हैं ..
m.Alin

2
अंतर इस तरह से है कि सूचना प्रस्तुत की जाती है। पेशेवर स्वर में किए गए हर निर्णय की व्याख्या करने वाला एक औपचारिक दस्तावेज, आपके द्वारा चुने गए मूल्यों के बारे में सूत्रों को नोट करने और नोट करने की तुलना में बहुत अधिक काम करने वाला है। इसके अतिरिक्त, यदि कोई अन्य व्यक्ति नोटों को देखने जा रहा है, तो यह तथ्य कि वे डिजिटल हैं, महत्वपूर्ण है।
stanri

4
OMG मुझे यह सवाल पसंद है। (क्षमा करें, मुझे पता है कि इसकी वास्तव में मदद नहीं की जा रही है, लेकिन यह एक ऐसी चीज है जिस पर मैं अभी काम कर रहा हूं, इसलिए यह बहुत अच्छा है)। लगे रहो।
efox29

जवाबों:


15

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

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

मैंने कई बार डिजिटल होने पर विचार किया है, लेकिन जब मैं काम करता हूं, तो मेरे सामने अपनी नोटबुक रखना अच्छा होता है और मुझे औपचारिक रूप से लेखन काफी अजीब लगता है। हाथ से गणनाएँ लिखना बहुत आसान है।

एक बोर्ड डिजाइन के लिए एक युक्ति या औपचारिक दस्तावेज तैयार करते समय, मैं आमतौर पर अपनी नोटबुक का संदर्भ देता हूं जो मैंने किया था (या मैं उसी समय डिजिटल दस्तावेज लिखता हूं)। भले ही ऐसा लगता है कि मैं दो बार एक ही काम कर रहा हूं, लेकिन मुझे लगता है कि मेरी नोटबुकें अपने लिए सभी गणना और स्पष्टीकरण हैं, जहां प्रलेखन बहुत कम क्रिया है और दूसरों के लिए बहुत अधिक औपचारिक और व्याख्यात्मक है। जैसे, मैं अक्सर नहीं पाता कि मैं एक ही बात दो बार लिख रहा हूं।


सूत्रों के मुद्दे पर पूरी तरह से सहमत हूं, लेकिन मैंने लगभग 5 साल पहले कागज के नोटों का उपयोग बंद कर दिया था। टंकण लेखन की तुलना में कहीं आसान है, और सभी सामान्य इलेक्ट्रॉनिक पाठ फायदे हैं - खोज करने योग्य, sendable, backupable, आदि
Markt

2
हमारे समय के सबसे प्रभावशाली / महत्वपूर्ण डिजाइन नोटबुक में से कुछ: computerhistory.org/collections/fairchild । पेपर लॉगबुक / नोटबुक में एक महत्वपूर्ण लाभ ड्राइंग है। यह मेरे लैपटॉप पर चीजों को खींचने / स्केच करने में काफी अधिक प्रयास करता है (हालांकि यह iPad पर आसान है - उदाहरण के लिए मेरी पत्नी अपने आईपैड पर अपने डिजाइन नोट्स रखती है)। मैं ग्राफिक रूप से सोचने की प्रवृत्ति रखता हूं इसलिए मैं ब्लॉक आरेखों को चित्रित करके अपने डिजाइनिंग का बहुत कुछ करता हूं।
स्लीपबेटमैन

11

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


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

इसके बाद PRD (उत्पाद आवश्यकताओं दस्तावेज़) को आमतौर पर इंजीनियरिंग द्वारा लिखा जाता है, एक शब्द टेम्पलेट में भी। यह अधिक तकनीकी विस्तार से वर्णन करता है कि उत्पाद क्या करेगा, टुकड़ों की क्या आवश्यकता है, और उच्च स्तर पर उनमें से प्रत्येक कैसे कार्य करेगा। अक्सर हम लक्ष्य प्रदर्शन, मूल्य, शक्ति, आकार और अन्य मैट्रिक्स यहां शामिल करेंगे।

प्रत्येक अनुभाग के लिए विस्तृत कार्यात्मक ऐनक है। योजनाबद्ध तरीके से डालने से पहले कुछ डिज़ाइन कार्य वास्तव में यहाँ अच्छी तरह से किए गए हैं। उदाहरण के लिए शक्ति की गणना की जाएगी, भागों का चयन किया जाएगा, और बहुत सारे शोध किए जाएंगे। यह वह जगह है जहां हम किसी भी गैर-स्पष्ट डिजाइन निर्णयों का दस्तावेजीकरण करेंगे।

अंत में हम उन स्कीमैटिक्स पर पहुंचेंगे जो इस बिंदु पर आसान हिस्सा है क्योंकि विनिर्देश चरण में बहुत सारे कठिन डिजाइन कार्य किए गए थे। जहाँ यह मेरी राय में किया जाना चाहिए :) अगर योजनाबद्ध चरण के दौरान कुछ परिवर्तन होता है, उदाहरण के लिए, हम समझ लेते हैं कि कुछ काम नहीं करेगा या कोई मार्केटिंग व्यक्ति हॉल में यह कहते हुए भागता है कि उसे नीले रंग के बजाय अब लाल होने की आवश्यकता है, तो हम वापस जाएगा और चश्मा अद्यतन करेगा।

सभी ऐनक, PRD, MRD को SVN में आंतरिक विकि पर डॉक्स के लिंक के साथ रखा जाता है। कल्पना में बदलाव के परिणामस्वरूप एसवीएन को अपडेट किया जाएगा और इच्छुक पार्टियों को एक अधिसूचना दी जाएगी। आप निश्चित रूप से इसे कहीं साझा फ़ोल्डर में मैन्युअल रूप से रख सकते हैं।

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


ठीक है, शायद मुझे भी प्रत्येक प्रश्न को संबोधित करना चाहिए :)

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

इस घटक को क्यों चुना? मुझे लगता है कि कार्यात्मक कल्पना इसके लिए एक अच्छी जगह है, पागल होने की कोई ज़रूरत नहीं है, लेकिन सिर्फ एक सरल रेखा या दो के बारे में यह क्या फायदे थे। मैं इसे महत्वपूर्ण घटकों के लिए आरक्षित करूंगा, मुझे नहीं लगता कि आप यह वर्णन करना चाहते हैं कि आपने उदाहरण के लिए पुल-अप रोकनेवाला क्यों चुना।

मैंने / इस घटक के लिए इन विशेष मापदंडों को क्यों / कैसे चुना? इसे ऊपर से मिलाएं।

सर्किट का यह हिस्सा क्या करता है? यह आपके कार्यात्मक कल्पना का हिस्सा होगा, यदि सर्किट इस प्रश्न को वारंट करने के लिए महत्वपूर्ण है, तो यह कल्पना का अपना खंड होना चाहिए।

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

इस सर्किट की कुल बिजली खपत कितनी है? मुझे लगता है कि यह आपके विनिर्देश के बिजली आपूर्ति अनुभाग में है।

क्या मैं इस घटक को इस अन्य के साथ बदल सकता हूं? क्या इस घटक के समतुल्य घटक हैं? आदि यह मुझे लगता है कि आपके BOM में है या जो भी प्रक्रिया आप निर्माण के लिए उपयोग करते हैं। वैकल्पिक भागों में सोर्सिंग को आसान बनाना है। हमारे लिए फिर से यह सब एक डेटाबेस डेटाबेस से बाहर आ रहा है।


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

1
@ m.Alin SHG मेरी तरह काम करता है, और एक युक्ति है जो एक योजनाबद्ध पर काम करने से पहले किया जाता है। इस दस्तावेज़ में सर्किट के लिए विस्तृत आवश्यकताएं, समग्र प्रणाली की जानकारी, प्रमुख निर्णयों के पीछे तर्क आदि शामिल हैं। यह दस्तावेज़ आपकी विचार प्रक्रिया को सूचीबद्ध करता है और उन आवश्यकताओं को सूचीबद्ध करता है जिन्हें आप अपने योजनाबद्ध को डिज़ाइन करने के लिए ले सकते हैं। यह एक पेशेवर सेटिंग में जाने का तरीका है, लेकिन आप नोटबुक से दूर हो सकते हैं और जैसे कि आप घर पर डिजाइन कर रहे हैं। मैं आमतौर पर अपने काम के सर्वर पर एक फ़ोल्डर रखता हूं
I. वुल्फ

1
कमरे से बाहर भाग गए ... किसी भी दस्तावेज, किसी भी परीक्षण दस्तावेज, समग्र प्रणाली के किसी भी ब्लॉक आरेख, किसी भी महत्वपूर्ण भागों के लिए डेटशीट आदि के साथ, यह सब एक सबफ़ोल्डर (योजना फ़ोल्डर में नियोजन / विनिर्देश फ़ोल्डर) में है। एक अलग फ़ोल्डर में मैं योजनाबद्ध, पीसीबी लेआउट, और किसी भी प्रासंगिक विधानसभा / विनिर्माण प्रलेखन होगा। आदर्श रूप से आप चाहते हैं कि कोई व्यक्ति किसी एक दस्तावेज़ से सभी जानकारी प्राप्त करने में सक्षम हो, लेकिन कभी-कभी डेटशीट या विस्तृत परीक्षण जानकारी / गणना की आवश्यकता के आसपास कोई नहीं होता है।
वोल्फ

हमारी प्रक्रिया इनलाइन पर कुछ टिप्पणियां जोड़ दीं
कुछ हार्डवेयर लड़के

4
महत्वपूर्ण दस्तावेजों के लिए संस्करण नियंत्रण का उपयोग करने के लिए +1। सभी को इसका उपयोग करना चाहिए, यहां तक ​​कि एक भी, स्वयं कार्यरत इंजीनियर।
जूनियर बिलिया

5

मैं बहुत सारे क्विक-टर्न डिज़ाइन करता हूं और मुझे यह कहना है: योजनाबद्ध तरीके से एनोटेट करना अब तक की सबसे सुविधाजनक चीज़ है। मेरे किसी भी डिज़ाइन के 2 या 3 A4 शीट से अधिक होना दुर्लभ है, इसलिए डिज़ाइन निर्णयों की मात्रा सीमित है। बहुत सारे डिज़ाइन निर्णय बहुत अधिक स्वचालित होते हैं; मुझे हर एक भाग के कारणों को सूचीबद्ध करने की आवश्यकता नहीं है। बस एक या दो मुख्य भाग और शायद कुछ फिल्टर या संवेदन निष्क्रिय। बाकी किसी भी अनुभवी डिजाइन इंजीनियर के लिए तुरंत स्पष्ट है।

आपके अंतिम प्रश्न के रूप में: वैकल्पिक भाग आम तौर पर एक डिजाइन निर्णय नहीं है, लेकिन एक सोर्सिंग निर्णय है, और जैसे कि यह आपके सोर्सिंग वर्कफ़्लो का हिस्सा है। मेरे मामले में, वैकल्पिक हिस्से मेरे हिस्से के गुणों में हैं और यदि प्राथमिक भाग या स्रोत पर स्टॉक खत्म हो जाता है तो स्वचालित रूप से स्रोतहीन हो जाते हैं।

बड़े डिज़ाइन और सिस्टम डिज़ाइन के लिए, मैं डिज़ाइन दस्तावेज़ टेम्पलेट के साथ Google डॉक्स का उपयोग करता हूं।

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


3
आमतौर पर एक पेशेवर दस्तावेज़ में कम से कम एक कल्पना दस्तावेज़ होना बेहतर होता है। उदाहरण के लिए यदि मैं जानना चाहता हूं कि मैंने फ्यूज मान क्यों चुना, तो यह जानना अच्छा होगा कि मेरा आउटपुट 50uS के लिए 700mA और फिर 3s के लिए 300mA का है। यह जानकारी बस एक योजनाबद्ध का सुराग लगाती है जहां आपको वास्तव में फ्यूज रेटिंग डालने की आवश्यकता होती है, लेकिन कुछ बिंदु पर इसकी आवश्यकता हो सकती है। ऐसी परिस्थितियाँ भी हैं जहाँ मुझे 6 नियामक एक नियामक से चल रहे हैं, और मुझे यह जानना होगा कि कितनी मोटरें एक साथ चलेंगी। फिर से कुछ की जरूरत है, लेकिन योजनाबद्ध पर नहीं।
वुल्फ

1
बेशक, राय अलग-अलग होगी। मैं केवल इतना कह रहा हूं कि मेरे बेल्ट के नीचे 200+ डिजाइन के साथ मुझे लगता है कि यह वास्तव में अच्छी तरह से काम करता है। 'प्रोफेशनल' को सख्त प्रोटोकॉल और कार्यप्रणाली से मतलब नहीं है; अपेक्षाकृत छोटे डिजाइनों के लिए (जो कि मैं जो काम करता हूं उसका बहुमत है) यह अच्छी तरह से काम करता है। बड़े डिज़ाइन और विशेष रूप से सहयोगी डिज़ाइन (जो इन दिनों बहुत दुर्लभ है, यहां तक ​​कि रास्पबेरी पाई की तरह सामान भी एक ही आदमी द्वारा डिज़ाइन और बाहर रखा गया है) हालांकि थोड़ा अधिक बॉयलरप्लेट की आवश्यकता होती है।
user36129

4

मेरी कई छोटी परियोजनाओं के लिए, मैं आमतौर पर उप-सर्किट के आसपास एक साधारण ग्रीन लेबल और बॉर्डर लगा रहा हूं। बड़ी परियोजनाओं के लिए, कुछ eCAD सॉफ़्टवेयर आपको ब्लॉक आरेख से नीचे बनाने की अनुमति देते हैं, जहां प्रत्येक शीट आगे एक एकल ब्लॉक का वर्णन करती है। किसी भी समस्या को विघटित करने के लिए एक कला है, और ट्रेडऑफ़ का प्रबंधन (यह इंजीनियरिंग IMHO है)। जहां एनालॉग फ़िल्टरिंग जैसे घटकों की पसंद के लिए स्पष्ट रूप से कुछ विश्लेषण है, मैं कटऑफ आवृत्ति और फिल्टर प्रकार (उदाहरण के लिए लो-पास फ़िल्टर (f_c = 100Hz)) पर ध्यान दूंगा

सामान्य ब्लॉक जिन्हें मैं समय पर चलाता हूं और फिर से शामिल करता हूं:

  • पावर मैनेजमेंट (वोल्टेज रेगुलेटर, रिवर्स-पोलरिटी प्रोटेक्शन, टीवीएस डायोड, पावर स्विच, बाइपास कैप आदि)
  • MCU (माइक्रोकंट्रोलर, प्रोग्रामिंग हेडर या पैड, चिप बाईपास कैप)
  • संकेतक (जैसे एल ई डी, ईएल तार, 7-सेग डिस्प्ले, वाइब मोटर)
  • किसी विशेष सुविधा के लिए सेंसिंग (जैसे करंट सेंसिंग, टच सेंसिंग, जीएसआर, एक्टिविटी, एनवायरनमेंटल सेंसिंग, आदि)
  • डिबग कॉम (फेराइट बीड, USB, I2C, UART, SPI, जानकारी प्राप्त करने का कोई तरीका)
  • रेडियो (कई रेडियो के लिए सभी समर्थन घटक)
  • वीडियो (एक कैमरे के लिए सभी समर्थन घटक और चिप्स)
  • बाहरी संग्रहण (जैसे बाहरी फ्लैश, स्टोर करने के लिए EEPROM चिप, आदि)
  • आपके डिज़ाइन के लिए कोई अन्य विशेषता अद्वितीय है

इन उप-ब्लॉकों के साथ स्पष्ट रूप से संगठित और लेबल किए गए, मैं आमतौर पर एक दो मिनट से भी कम समय में योजनाबद्ध उपभोग कर सकता हूं।


3

मैं एक डिजाइन नोटबुक रखता हूं, और ध्यान से दस्तावेज़ की आवश्यकताएं / चाहता हूं। जल्द से जल्द प्रोटोटाइप के लिए, मैं सभी वास्तविक निर्णयों पर नोट्स लेते हुए, भाग चयन के माध्यम से जाऊँगा। बाद के बदलावों के लिए, मैं एक बहुत ही औपचारिक FMEA प्रक्रिया का उपयोग करता हूं, जिसमें दस्तावेज की आवश्यकता होती है ताकि किसी बदलाव को सही ठहराने के लिए ऐसा नहीं किया जा सके - क्योंकि जाहिर है, अगर कोई आवश्यकता नहीं है, तो बदलाव की कोई आवश्यकता नहीं है!

यदि मैं इस बारे में पर्याप्त कठोर हूं, तो मैं हर डिजाइन परिवर्तन (हार्डवेयर, सॉफ्टवेयर, यांत्रिकी) को एक आवश्यकता पर ट्रैक कर सकता हूं।

सभी चीजों के सभी संस्करणों को तोड़फोड़ का उपयोग करके ट्रैक किया जाता है।

यह एक डिजाइन हिस्ट्री फाइल का एक महत्वपूर्ण घटक हो सकता है, जो कि एफडीए के लिए जरूरी है।


3

मैंने अक्सर कीनोट का उपयोग किया है (आप पावरपॉइंट का उपयोग करना भी चुन सकते हैं)। यह सिमुलेशन सॉफ्टवेयर जैसे SPICE GUI और इस तरह के स्क्रीन कैप्स को अनुमति देने का लाभ है।

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

मुझे यह भी पता चलता है कि मैं कागज पर पेंसिल का उपयोग करके गणित और चित्र बनाना चाहता हूं। इसलिए मैं अपने फोन के साथ एक फोटो लेता हूं और बिना रिट्वीट के कीनोट में छोड़ देता हूं। कभी-कभी छोटे समीकरणों के लिए मैं LaTeX का उपयोग कर सकता हूं और इसे अंदर छोड़ सकता हूं।

मैं वैज्ञानिक सॉफ़्टवेयर जैसे कि ओक्टेव द्वारा तैयार किए गए भूखंडों को भी शामिल कर सकता हूं।

आजकल, विशेष रूप से कम्प्यूटेशनल रूप से गहन कार्यों के लिए मैं इस काम में से कुछ IPython पुस्तिकाओं में करना चुन सकता हूं, लेकिन मैंने विशेष रूप से सर्किट डिजाइन के लिए, सिर्फ भौतिकी गणना के लिए नहीं किया है।

अंत में, कीनोट्स / पावरपॉइंट दूसरों के लिए बहुत ही आसान हैं और गैर-कम तकनीकी लोगों को वितरण के लिए पीडीएफ के रूप में निर्यात करते हैं।


3

स्कीमैटिक्स पर इंजीनियरिंग नोट्स रखें और यदि आवश्यक हो तो अधिक शीट बनाएं। मैं हमेशा अपनी सभी योजनाएं पर इंजीनियरिंग नोट्स रखता हूं क्योंकि मेरी दुनिया में मुझे एक समय अवधि के लिए 1/2 पके हुए डिजाइनों को फिर से देखना पड़ सकता है, फिर एक और डिज़ाइन लेने के दौरान इसे वापस बर्नर पर रख दिया जाए; बहुत तरल पदार्थ का प्रवाह। ये ईई नोट्स मुझे और दूसरों को थोड़े प्रयास से डिजाइन के इरादे को फिर से अपनाने में मदद करते हैं। मैं भी महत्व या संदर्भ को इंगित करने के लिए पाठ / ग्राफिक्स के विभिन्न रंगों का उपयोग करता हूं। नीचे उदाहरण ...यहाँ छवि विवरण दर्ज करें

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