🤶🏽 ⛹🏼 👂🏼 डेटा ट्रांसफर बैलड 🤾🏽 👨🏽‍🔬 🙏🏻

अपने पाठ रक्तस्राव की पहली पंक्तियों में मैं निम्नलिखित कहना चाहता हूं: इस बारे में बहुत कुछ लिखा गया है, मैं भी अपनी दृष्टि लिखूंगा। सूचना संचारित करने के लिए मानक इंटरफेस महान हैं, लेकिन मेरी जरूरतों के लिए वे पर्याप्त संतोषजनक (अच्छी तरह से, या लगभग) डेटा हस्तांतरण प्रदान नहीं करते हैं। मैं इसे सूट करने वाले राज्य में लाने के लिए कुछ अतिरिक्त प्रयास करने की कोशिश करूंगा।

पर्याप्त रूप से बड़ी (1-100 मीटर) दूरी पर 2 या अधिक उपकरण हैं, जिनके बीच डेटा संचारित होना चाहिए। कुछ इंटरफेस (rs232 / 422/485, I2C, ईथरनेट) की जांच करने के बाद, मैं इस नतीजे पर पहुंचा कि या तो वे एक अस्पष्ट डेटा ट्रांसफर की गारंटी नहीं देते, मुझे भी कई तार पसंद नहीं थे, उन्होंने इस बात का जवाब नहीं दिया कि सूचना स्वीकार की गई थी। मैंने आरएस 485 इंटरफेस को एक आधार के रूप में लेने का फैसला किया - यह इसके फायदे, 2 तारों से बहुत दूर जा सकता है, आप एक ही समय में उपकरणों का एक गुच्छा कनेक्ट कर सकते हैं, यह सरल है, (UART) लगभग किसी भी नियंत्रक पर है।

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

एक विनिमय चक्र।

मेरी डेटा ट्रांसफर जरूरतों को पूरा करने के लिए, मुझे केवल दो प्रश्नों को हल करने की आवश्यकता है। प्रश्न एक: प्रेषित बाइट की जाँच RS-485 इंटरफ़ेस पर ही आधारित है, लेकिन यह एक विश्वसनीय रूप से प्रेषित बाइट की गारंटी नहीं देता है - यदि एक बाइट इंटरफ़ेस में ही पाया जाता है, तो इसे प्राप्त डेटा से बाहर निकाल दिया जाता है, लेकिन यह अभी भी गलत बाइट को स्थानांतरित करना संभव है - यदि यह बदल गया है (यह खराब हो गया है) ) एक बाइट में बिट्स की एक संख्या। यानी संचरित डेटा में बाइट्स की संख्या और बाइट्स की वैधता के लिए एक जांच आवश्यक है।

प्रश्न दो: प्रेषित को एक प्रतिक्रिया संदेश प्राप्त करना।

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

नोट: चेकसम बाइट को मॉडुलो माना जाना चाहिए 2.

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

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

मैं यहां 2 और पैरामीटर भी दर्ज करता हूं - यह डिवाइस का वह नंबर (कोड) होता है, जिस पर डेटा प्रसारित होता है और नंबर (सबकोड) यह दर्शाता है कि किस कमांड को निष्पादित किया जाना चाहिए (या संदेश के अंदर कौन सा डेटा है)।

परिणामस्वरूप, मैंने इसे सभी को एक साथ रखा और एल्गोरिथ्म के माध्यम से जाना, रिले के थ्रेसहोल्ड को 5 डिग्री सेल्सियस बढ़ाने और 1 विनिमय चक्र के लिए दास से वर्तमान तापमान लेने के उदाहरण का उपयोग करते हुए: मैं

मास्टर से प्रेषित डेटा उत्पन्न करता हूं।

जब संदेश प्राप्त होता है, तो दास 2 बाइट्स को देखता है। बाइट्स की संख्या कहां भेजी गई है, अगर भेजे गए बाइट्स की संख्या प्राप्त संख्या के बराबर है, तो संदेश बाइट्स नहीं खो गया है, तो हम शुरुआती बाइट (चरित्र) को देखते हैं यदि यह = '$' है, और बाइट (वर्ण) समाप्त होने पर भी = # '- यह एक संदेश है गुलाम के लिए यात्रा।

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

1. स्टार्ट बाइट = '$', बाइट्स की संख्या = 7 (बाइट्स की संख्या = 7 भेजी गई), अंतिम बाइट '#' के बराबर नहीं है;
2. प्रारंभिक बाइट '$' के बराबर नहीं है, प्राप्त बाइट्स की संख्या = 7 (भेजे गए बाइट्स की संख्या = 7), अंतिम बाइट = '#';
3. स्टार्ट बाइट = '$', बाइट्स की संख्या = 7 (बाइट्स की संख्या = 7, बाइट्स की संख्या 7 के बराबर नहीं), अंतिम बाइट = '#'।

अगला, हम शेष 3 बाइट्स (बाइट्स 3, 4, 5) के चेकसम की गणना करते हैं, अगर यह बीसीएस के साथ मेल खाता है, तो हम डेटा को पार्स करना जारी रखते हैं, हम इस डेटा के लिए इस डिवाइस की तलाश करते हैं और इस पर क्या किया जाना चाहिए, हमारे मामले में दास कोड 55 और सबकोड 2 कहते हैं। वर्तमान तापमान डेटा भेजने के लिए रिले की दहलीज और प्रतिक्रिया संदेश में एक और 5 डिग्री जोड़ने की आवश्यकता के बारे में। मैं एनएस की जांच करता हूं यदि यह पिछले संदेश संख्या के बराबर नहीं है, तो मैं कमांड निष्पादित करता हूं और रिले थ्रेसहोल्ड के वर्तमान मूल्य में 5 डिग्री जोड़ता हूं। यदि वे समान (एनएस) हैं, तो मैं संकेत किए गए कार्यों को नहीं करता हूं, फिर मैं एक प्रतिक्रिया संदेश के गठन के लिए आगे बढ़ता हूं।

इस योजना का अनुप्रयोग ['$'] [भेजे गए बाइट की संख्या / प्राप्त] [...] ['# ’] - उच्च संभावना के साथ कि इस तरह के संयोजन को प्रेषित डेटा में नहीं मिल पाएगा, और एक गलत संदेश भड़काएगा।

मैं प्राप्त संदेश के आधार पर दास से प्रेषित डेटा बनाता हूं:

प्रसंस्करण सिद्धांत निम्नानुसार है: 2 बाइट्स को देखें, जहां भेजे गए बाइट्स की संख्या है, अगर भेजे गए बाइट्स की संख्या प्राप्त बाइट्स की संख्या के बराबर है और स्टार्ट बाइट = '@' और अंतिम बाइट = 'और' भी है - यह दास से गुरु का संदेश है। यदि आवश्यक हो, तो मैं 3 में से 2 तंत्र का उपयोग करता हूं, केवल वर्णित संदेश (वर्णों के लिए '@' और '&') के लिए ऊपर वर्णित के समान। यह संदेश प्राप्त करते समय, होस्ट चेकसम 9 (तीसरी से 11 वीं तक) बाइट्स का विश्लेषण करता है, यदि चेकसम मेल खाता है, तो संदेश में डेटा विश्वसनीय माना जाता है और आगे डेटा विश्लेषण जारी रहता है। यदि भेजे गए और प्राप्त संदेशों का कोड, सबकोड और एनएस मेल खाता है, तो हम मेजबान द्वारा भेजे गए संदेश की प्रतिक्रिया का विश्लेषण करना जारी रखते हैं। अगला प्राप्त आंकड़ों का विश्लेषण है,मेरे मामले में, 6 वीं बाइट में, 1 के मान का मतलब है कि रिले की दहलीज पर 5 डिग्री बढ़ाने के लिए आदेश सफल था, शेष 5 बाइट्स वर्तमान तापमान रीडिंग को इंगित करते हैं; 7 वें बाइट एक ध्वज है जो संचरित तापमान (यानी) की विश्वसनीयता का संकेत देता है। मैं इस विकल्प पर विचार कर रहा हूं कि गुलाम चालू है और जवाब दे रहा है, लेकिन सेंसर काम नहीं कर सकता है) और 4 बाइट्स प्रकार फ्लोट तापमान मान।

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

दास के दास के डेटा संचरण के बारे में थोड़ा सा, और मास्टर से सभी दासों को एक केंद्रीकृत संदेश।

सबसे पहले, आखिरी एक - दास द्वारा मास्टर से ट्रांसमिशन डिवाइस कोड 255 को असाइन करके किया जाता है, जो दास को बताता है कि यह एक केंद्रीकृत संदेश है, फिर यह केवल सामान्य उपकोड की समस्या को हल करने के लिए रहता है, यह डिवाइस कोड द्वारा समूह के लिए भी संभव है, अर्थात डिवाइस कोड असाइन करें 254 और 3 या 4 डिवाइस इस कोड का उपयोग करके एक संदेश प्राप्त करेंगे, बाकी इसे अनदेखा करेंगे, स्वाभाविक रूप से, दासों से प्रतिक्रियाएं भेजने का हिस्सा यहां काम नहीं करना चाहिए, अर्थात्। यह गारंटी नहीं है कि अनुयायियों ने अनायास ही इन संदेशों को स्वीकार कर लिया है!

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

प्रत्येक डिवाइस के लिए 248 तक कमांड / डेटा प्रकार के बारे में सैद्धांतिक रूप से जुड़े उपकरणों की इंटरफ़ेस क्षमता संख्या, संदेश में उपयोगी जानकारी की लंबाई 250 बाइट्स तक है।

नुकसान के बारे में बात करें:

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

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

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

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

पुनश्चमुझे संदेह है कि मैंने यहां कुछ नया खोजा है, यह सब कुछ हद तक अलग-अलग इंटरफेस में कहीं न कहीं इस्तेमाल होता है! इस स्क्रिबल के लेखक के हल्के हाथ और मेरे विकास में इस प्रोटोकॉल के अनुप्रयोग के साथ, मैं इस डेटा ट्रांसफर प्रोटोकॉल "SRDB2" को नाम देना चाहता हूं।

डेटा ट्रांसफर बैलड

More articles: