मॉडबस प्रोटोकॉल डेटा पॅकेटची रचना. डिव्हाइस नेटवर्क, MODBUS प्रोटोकॉल

आम्ही ModBus प्रोटोकॉलच्या सामान्य संरचनेचे विश्लेषण केले आहे. आज आपण या प्रोटोकॉलची एक भिन्नता पाहू - ModBus TCP, ज्याचा वापर इथरनेट नेटवर्कमध्ये ModBus कार्यान्वित करण्यासाठी केला जातो.

ModBus TCP नेहमी TCP/IP स्टॅकच्या शीर्षस्थानी कार्य करते, म्हणून त्याला त्याच्या क्लासिक स्वरूपात पूर्ण विकसित ModBus प्रोटोकॉल मानले जाऊ शकत नाही.

TCP/IP एकत्र वापरताना ModBus वर लादतो तो मुख्य फरक म्हणजे विशिष्ट पत्त्याशी थेट कनेक्शन. TCP/IP प्रोटोकॉल क्लायंट-सर्व्हर तत्त्वावर आधारित आहे. डेटाची देवाणघेवाण करण्यासाठी, क्लायंट सर्व्हरसह संप्रेषण सत्र उघडतो, त्याचा पत्ता दर्शवितो.

मॉडबस प्रोटोकॉलच्या शब्दावलीवर स्विच केल्याने, टीसीपी नेटवर्कमधील मास्टर डिव्हाइस (मास्टर) क्लायंट बनतो (क्लायंट डेटा एक्सचेंजचा आरंभकर्ता असल्याने) आणि स्लेव्ह डिव्हाइस (गुलाम) सर्व्हर बनतो.

अशा प्रकारे, टीसीपी नेटवर्कवरील स्लेव्ह डिव्हाइसवर विनंती प्रसारित करण्यासाठी, मास्टरने प्रथम त्याच्यासह संप्रेषण सत्र उघडणे आवश्यक आहे. शिवाय, सत्राची सुरुवात ModBus प्रोटोकॉल स्तरावर नाही तर TCP/IP स्तरावर केली जाते. त्यामुळे, ModBus RTU किंवा ASCII प्रमाणेच मास्टर डिव्हाइस ModBus वापरून वेगवेगळ्या डिव्हाइसेसवर विनंत्या पाठवू शकत नाही.

त्याच कारणास्तव, ModBus TCP (एकाच वेळी सर्व स्लेव्ह डिव्हाइसेसवर) कोणतेही प्रसारण संदेश नाहीत.

तथापि, मास्टर उपकरण TCP/IP प्रोटोकॉल वापरून आवश्यक नोड (स्लेव्ह) शी कनेक्ट करू शकते आणि नंतर ModBus भाषा वापरून त्याच्याशी संवाद साधू शकते.

आकृतीमध्ये, SCADA प्रणालीच्या नियंत्रणाखाली डिस्पॅचरचे कार्यस्थळ डेटा संकलन सर्व्हर आहे आणि त्याच वेळी ModBus TCP नेटवर्कमध्ये मास्टर आहे. हे प्रत्येक रिमोट कंट्रोलरशी क्रमशः कनेक्ट होते, TCP/IP नेटवर्कवर संप्रेषण सत्र उघडते आणि ModBus पॅकेट्सची देवाणघेवाण करते.

अर्थात, अशा एक्सचेंजला ModBus RTU च्या बाबतीत जास्त वेळ लागतो, कारण TCP/IP सत्र उघडण्यासाठी आणि बंद करण्यासाठी अतिरिक्त वेळ घालवला जातो. तथापि, हे ट्विस्टेड जोडी किंवा अगदी वायफाय वापरून बऱ्याच अंतरावर असलेल्या डिव्हाइसेसना कनेक्ट करणे शक्य करते.

याव्यतिरिक्त, ModBus TCP प्रोटोकॉल गेटवे असलेल्या नेटवर्कमध्ये वापरला जाऊ शकतो, जेथे गेटवे एक बुद्धिमान उपकरण आहे आणि उर्वरित ModBus नेटवर्क उपकरणांना संदेश पाठवते.

या कॉन्फिगरेशनसह, TCP नेटवर्क क्लायंट (मोडबस नेटवर्क मास्टर म्हणूनही ओळखले जाते) गेटवे (सर्व्हर) शी कनेक्ट होते आणि फक्त त्याच्याशी संवाद साधते. गेटवे मॉडबस बस (RTU किंवा ASCII) मधील संदेश त्या डिव्हाइसवर अग्रेषित करतो ज्याचा पत्ता ModBus पॅकेटमध्ये निर्दिष्ट केला आहे.

ModBus TCP पॅकेट रचना

प्रथम, क्लासिक मॉडबस पॅकेजची रचना लक्षात ठेवूया (RTU किंवा ASCII):

यात चार ब्लॉक्स आहेत: स्लेव्ह ॲड्रेस, फंक्शन नंबर, डेटा ब्लॉक आणि पॅरिटी ब्लॉक.

आणि ModBus TCP पॅकेटची रचना अशी दिसते:

तुम्ही बघू शकता, ModBus TCP पॅकेजमध्ये, ModBus RTU च्या तुलनेत, एक्सचेंज आणि प्रोटोकॉल आयडेंटिफायर्सचे ब्लॉक जोडले गेले आहेत आणि तेथे कोणतेही पॅकेज प्रमाणीकरण ब्लॉक नाही. नंतरचे हे स्पष्ट केले आहे की पॅकेट अखंडता नियंत्रण TCP/IP प्रोटोकॉलद्वारे प्रदान केले जाते, म्हणून त्याच्या ModBus अंमलबजावणीची आवश्यकता नाही.

ModBus TCP पॅकेजच्या प्रत्येक ब्लॉकचा अर्थ काय आहे ते पाहूया:

• एक्सचेंज आयडी- बहुतेकदा दोन शून्य. उत्तराची वाट न पाहता मालकाने गुलामाला सलग अनेक विनंत्या पाठवल्या तरच लागू होते. या प्रकरणात, आयडी तुम्हाला कोणत्या विनंत्या कोणत्या प्रतिसादाशी संबंधित आहे हे समजून घेण्याची परवानगी देतो.
• प्रोटोकॉल आयडी— नेहमी शून्य, लागू नाही. फील्ड भविष्यातील वापरासाठी राखीव म्हणून सोडले आहे.
• पॅकेट लांबी— “पत्ता”, “फंक्शन क्रमांक” आणि “डेटा” ब्लॉक्सची एकूण लांबी. पॅकेटची लांबी दोन बाइट्समध्ये प्रसारित केली जाते, सर्वात लक्षणीय पहिली आहे.
• गुलाम पत्ता- मॉडबस आरटीयू पॅकेजच्या संरचनेत समान ब्लॉकचे ॲनालॉग, परंतु सहसा वापरले जात नाही, कारण ,आधीच नमूद केल्याप्रमाणे, ModBus TCP मध्ये मास्टर आधीच फक्त एका स्लेव्हसह एक्सचेंज सत्र उघडतो (ज्यात अर्थातच, TCP/IP नेटवर्कवर IP पत्ता देखील असतो). हे फील्ड केवळ गेटवेसह ModBus TCP नेटवर्क आवृत्तीमध्ये वापरले जाते. मग गेटवे स्वतःच पॅकेटला निर्दिष्ट पत्त्यावर पुनर्निर्देशित करतो.
• फील्ड फंक्शन कोडआणि डेटाक्लासिक ModBus पॅकेजमधील संबंधित फील्ड प्रमाणेच आहेत.

Modbus प्रोटोकॉल संदेश रचना खालीलप्रमाणे आहे:

1. स्लेव्ह ॲड्रेस हा त्या यंत्राचा पत्ता असतो ज्यावर हा Modbus प्रोटोकॉल संदेश संबोधित केला जातो. उपकरणे केवळ त्यांना संबोधित केलेल्या संदेशांना प्रतिसाद देतात. प्रतिसाद गुलाम पत्त्याने सुरू होतो. पत्ता 1…247 च्या आत बदलतो. मॉडबस प्रोटोकॉल संदेशातील पत्ता 0 प्रसारण संदेशांसाठी राखीव आहे, 248..255 राखीव पत्ते आहेत.
2. फंक्शन क्रमांक - डेटाचा 1 बाइट.
3. डेटा - या फील्डमध्ये करण्याच्या फंक्शनबद्दल किंवा स्लेव्हने मॉडबस प्रोटोकॉल मास्टरला पाठविण्याची माहिती असते.
4. एरर डिटेक्शन ब्लॉक (सीआरसी) - एक चेकसम जो राऊंड रॉबिन आणि बिट-एलिमिनेशन अल्गोरिदम वापरून मागील सर्व बाइट्सवरून मोजला जातो.

कृपया लक्षात घ्या की मॉडबस प्रोटोकॉलद्वारे वाचताना, एका संदेशात तुम्ही एका ओळीत असलेल्या वेगळ्या किंवा ॲनालॉग इनपुट आणि आउटपुटचे मूल्य वाचू शकता, म्हणजेच, पहिल्या मूल्याचा पत्ता आणि त्यांची संख्या सेट करा.

मुख्य मानक फंक्शन्स त्यांच्या कोडनुसार पाहू (दशांश आणि हेक्साडेसिमल स्वरूपात):
1 (0x01) - अनेक वेगळे आउटपुट वाचणे
2 (0x02) - अनेक स्वतंत्र इनपुट वाचणे
3 (0x03) - अनेक इंटरमीडिएट रजिस्टर्स किंवा ॲनालॉग आउटपुट वाचणे
4 (0x04) – अनेक ॲनालॉग इनपुट वाचणे
जर, उदाहरणार्थ, विनंतीमध्ये व्युत्पन्न केलेल्या स्वतंत्र इनपुटची संख्या आठच्या गुणाकार नसल्यास, मूल्यांच्या बाइट्सची संख्या पूर्ण केली जाते आणि त्यानुसार, प्राप्त करण्यासाठी, उदाहरणार्थ, ची मूल्ये 15 स्वतंत्र इनपुट, ही संख्या दोन बाइट्स इतकी असेल.
मॉडबस संदेश डेटापूर्वी, एक बाइट प्रसारित केला जातो, ज्याचे मूल्य डेटाच्या बाइट्सची संख्या असते.
5 (0x05) - एका स्वतंत्र आउटपुटचे मूल्य रेकॉर्ड करा
6 (0x06) - एका ॲनालॉग आउटपुट किंवा रजिस्टरचे मूल्य लिहिणे
Modbus कमांडमध्ये पत्ता आणि वास्तविक मूल्य (2 बाइट्स) असतात. सामान्य प्रतिसाद म्हणजे मॉडबस प्रोटोकॉल विनंतीची पुनरावृत्ती.
15 (0x0F) - अनेक वेगळ्या आउटपुटवर मूल्ये लिहिणे
16 (0x10) - अनेक ॲनालॉग आउटपुट किंवा रजिस्टर्सची मूल्ये लिहितात
प्रतिसादात रजिस्टरचा प्रारंभिक पत्ता आणि बदललेल्या मूल्यांची संख्या असते.
मॉडबस प्रोटोकॉल विनंती/प्रतिसाद उदाहरण:

ट्रान्समिशन त्रुटी 2 प्रकारांमध्ये विभागल्या आहेत - ट्रान्समिशन विरूपण आणि तार्किक. "शांतता" वेळेद्वारे विकृतीचे परीक्षण केले जाते. संदेशांमधील सामान्य वेळ म्हणजे 3.5 वर्ण प्रसारित करण्यासाठी लागणारा वेळ. मॉडबस प्रोटोकॉल संदेशाच्या प्रसारणादरम्यान 1.5 पेक्षा जास्त वर्णांचा विराम झाल्यास, पॅकेट टाकून दिले जाते.

मॉडबस प्रोटोकॉलमध्ये तार्किक त्रुटी उद्भवतात जर स्लेव्ह संदेश अजिबात प्राप्त करू शकत नाही, किंवा तो प्राप्त करतो परंतु त्रुटी निर्माण करतो. या प्रकरणात, त्रुटीचे निदान कालबाह्यतेद्वारे केले जाते. स्लेव्ह विनंती स्वीकारतो, परंतु त्यावर प्रक्रिया करू शकत नाही (उदाहरणार्थ, अस्तित्वात नसलेल्या पत्त्यावर प्रवेश करणे) - या प्रकरणात, एक त्रुटी संदेश पाठविला जातो.

विनंतीसाठी मोडबस त्रुटी संदेशाचे उदाहरण:

मानक मोडबस प्रोटोकॉल त्रुटी कोड:
01 - फंक्शन स्लेव्हवर प्रक्रिया केली जाऊ शकत नाही.
02 - अस्तित्वात नसलेला डेटा पत्ता.
03 - विनंतीसाठी डेटा फील्डमधील मूल्य सॅल्व्हसाठी वैध नाही.
04 - गुलाम कृती करण्याचा प्रयत्न करत असताना एक गंभीर त्रुटी आली.
05 - स्लेव्हने विनंती स्वीकारली आणि त्यावर प्रक्रिया करण्यास सुरुवात केली, परंतु यास वेळ लागेल. हा कोड मास्टरला कालबाह्य त्रुटी फेकण्यापासून प्रतिबंधित करतो.
06 - गुलाम आदेशावर प्रक्रिया करण्यात व्यस्त आहे जेव्हा गुलाम मुक्त असेल तेव्हा मास्टरने संदेश पुन्हा पाठवला पाहिजे.
07 -स्लेव्ह विनंतीवरून फंक्शन कार्यान्वित करू शकत नाही. मास्टरने निदान माहितीसाठी विनंती पाठविली पाहिजे किंवा स्लेव्हकडून त्रुटी माहिती प्राप्त केली पाहिजे.
08 - स्लेव्ह मेमरी एरिया वाचण्याचा प्रयत्न करतो, परंतु समता त्रुटी आढळली आहे. मास्टर विनंतीची पुनरावृत्ती करू शकतो, परंतु सहसा अशा प्रकरणांमध्ये दुरुस्ती आवश्यक असते.

मॉडबस टीसीपी फ्रेम संरचना:

कुठे:
व्यवहार आयडी - दोन बाइट्स
प्रोटोकॉल आयडी - दोन बाइट्स (चार शून्य)
पॅकेट लांबी - दोन बाइट्स, त्यानंतरच्या संदेश फील्डचा आकार
गुलाम पत्ता - गुलामाचा पत्ता ज्यावर मॉडबस प्रोटोकॉल विनंती संबोधित केली जाते.
मॉडबस टीसीपी प्रोटोकॉलचे वैशिष्ट्य म्हणजे चेकसमची अनुपस्थिती, कारण सीआरसी तपासणी टीसीपी प्रोटोकॉलच्या वाहतूक स्तरावर होते. म्हणून, चेकसम RTU फॉरमॅटमध्ये तपासण्यात अर्थ नाही.

या लेखात मी प्रोटोकॉल कसे कार्य करते हे स्पष्ट करण्याचा प्रयत्न करेन. मोडबस, तो कोणता डेटा संग्रहित करू शकतो, तो कोणत्या स्वरूपात संग्रहित केला जाऊ शकतो, तो कसा वाचला जाऊ शकतो. हा लेख तुम्हाला ते काय आहे याची कल्पना देईल मोडबसप्रोटोकॉल आणि ते कसे लागू केले जाऊ शकते.

Modbus मध्ये डेटा पत्ताप्रोटोकॉल

गुलाम उपकरणांमध्ये माहिती साठवण्यासाठी ( गुलाम साधन 4 टेबल्स (किंवा ॲरे) वापरल्या जातात. प्रत्येक टेबल रजिस्टर्समध्ये समान व्हेरिएबल्सची माहिती साठवते. प्रत्येक रजिस्टरचा स्वतःचा आकार आणि पत्ता असतो. नोंदवही केवळ वाचनीय किंवा वाचनीय असू शकतात. चला या 4 प्रकारचे डेटा पाहू जे रजिस्टरमध्ये साठवले जाऊ शकतात:

कॉइल

हे डिजिटल आउटपुट आहेत ( डिजिटल आउटपुट). प्रत्येक कॉइल लिहिता किंवा वाचता येते. त्याचा आकार 1 बिट (म्हणजे 0 किंवा 1) आहे. ऐतिहासिकदृष्ट्या, हे रजिस्टर सेन्सर्स किंवा टर्मिनल उपकरणांवरील वास्तविक डिजिटल आउटपुटशी संबंधित आहेत. डिजिटल आउटपुट नियंत्रित करण्यासाठी वापरले जातात, उदाहरणार्थ, LEDs, रिले किंवा मोटर्स. त्या. अशा रजिस्टरला 1 लिहून, आम्ही LED चालू करू शकतो आणि 0 लिहून, आम्ही ते बंद करू शकतो (हे सशर्त आहे, खरं तर, 0 ते चालू करू शकते आणि 1 ते बंद करू शकते).

हे रजिस्टर वाचून, आम्ही आउटपुटची स्थिती शोधू शकतो (म्हणजे ते चालू किंवा बंद आहे). वाचन परिणाम देखील 1 बिट आहे, म्हणजे. 1 किंवा 0.

संपर्क

हे डिजिटल इनपुट आहेत ( डिजिटल इनपुट). डिजिटल इनपुट फक्त वाचले जाऊ शकते, म्हणजे हे रजिस्टर वाचून आम्हाला सेन्सर किंवा डिव्हाइसवरील वास्तविक डिजिटल इनपुटची स्थिती कळते. स्थितीचे निरीक्षण करण्यासाठी डिजिटल इनपुटचा वापर केला जातो - उदाहरणार्थ, प्रकाश चालू आहे किंवा बंद आहे की नाही, द्रव इच्छित स्तरावर पोहोचला आहे की नाही, रिले चालू आहे की नाही, इ.

ॲनालॉग इनपुट रजिस्टर्स

याचा अर्थ आमचा सहसा ॲनालॉग इनपुट्स ( ॲनालॉग इनपुट्स). ॲनालॉग इनपुट फक्त वाचले जाऊ शकतात, म्हणजे ते लिहिले जाऊ शकत नाहीत, परंतु फक्त कर इनपुटची वर्तमान स्थिती वाचली जाऊ शकते. सामान्यतः, विशिष्ट मूल्ये मोजण्यासाठी सेन्सरवर ॲनालॉग इनपुट वापरले जातात: इनपुट वर्तमान किंवा इनपुट व्होल्टेज. नंतर, प्राप्त मूल्य काही वास्तविक मूल्यात रूपांतरित केले जाऊ शकते, उदाहरणार्थ तापमान, हवेतील आर्द्रता, दाब किंवा इतर काहीतरी. या उद्देशासाठी, विशेष सूत्रे वापरली जातात जी सेन्सरसह येतात. परंतु अधिक वेळा सेन्सर त्वरित वास्तविक मूल्य परत करतो. उदाहरणार्थ, तापमान मोजणारा सेन्सर अंश सेल्सिअस 10 ने गुणाकार केल्यास मोजलेले मूल्य परत करू शकतो. म्हणजे. 253 म्हणजे 25.3°C. जेव्हा तुम्हाला पूर्णांक रजिस्टरद्वारे फ्रॅक्शनल व्हॅल्यू परत करायची असते तेव्हा हे तंत्र अनेकदा वापरले जाते.

एनालॉग आउटपुट होल्डिंग रजिस्टर्स

याचा अर्थ आमचा सहसा ॲनालॉग आउटपुट ( ॲनालॉग आउटपुट) परंतु बऱ्याचदा फक्त नोंदणी करतात जी काही मूल्ये संग्रहित करतात जी लिहिली आणि वाचली जाऊ शकतात. त्या. ही नोंदवही वाचता आणि लिहिली जाऊ शकतात. रेकॉर्डिंगसाठी सर्वाधिक वापरले जाते DACउपकरणे (डिजिटल ते ॲनालॉग कनव्हर्टर) किंवा काही मूल्ये साठवून ठेवणारी नोंदणी. DACते सहसा काहीतरी नियंत्रित करण्यासाठी वापरले जातात, उदाहरणार्थ: LED ची चमक, किंवा सायरनचा आवाज, किंवा इंजिन रोटेशनचा वेग.

हे रजिस्टर 16-बिट आहेत, म्हणजे. प्रत्येक रजिस्टर फक्त 2 बाइट्स साठवू शकतो.

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

कॉइल्स- डिजिटल आउटपुट पोर्ट किंवा बूलियन फ्लॅग्ज द्वारे उपकरणे नियंत्रित करण्यासाठी जसे की चालू/बंद, उघडे/बंद इ.

संपर्क- बुलियन ध्वजांची मूल्ये साठवण्यासाठी किंवा डिजिटल इनपुटमधून माहिती प्रदर्शित करण्यासाठी.

इनपुट्स- मूल्यांसाठी ज्यांना केवळ मुख्य बाजूने वाचण्याची आवश्यकता आहे आणि जे 16-बिट पूर्णांक म्हणून प्रस्तुत केले जाऊ शकतात. उदाहरणार्थ, एडीसी इनपुट, किंवा सिस्टमद्वारे व्युत्पन्न केलेली कोणतीही मूल्ये जी वाचण्याची आवश्यकता आहे (उदाहरणार्थ, चालू असलेल्या प्रक्रियेची संख्या किंवा डिव्हाइसचे अंतर्गत तापमान काही इनपुट रजिस्टरद्वारे वाचले जाऊ शकते)

धरून- या रजिस्टर्सचा वापर डिव्हाइस कॉन्फिगरेशन संग्रहित करण्यासाठी, नियंत्रित करण्यासाठी केला जाऊ शकतो DACकाही सेवा माहिती संचयित करण्यासाठी उपकरणे. तत्त्वतः, ही नोंदणी प्रणाली विकसकाच्या कल्पनेनुसार परवानगी असलेल्या कोणत्याही गोष्टीसाठी वापरली जाऊ शकते.

याव्यतिरिक्त, सर्किटमध्ये प्रत्येक रजिस्टर मोडबसएक अद्वितीय पत्ता असू शकतो, जो नोंदणी प्रकाराद्वारे निर्धारित केला जातो. खालील तक्ता पहा:

तुम्ही टेबलवरून बघू शकता, प्रत्येक रजिस्टर प्रकारात जास्तीत जास्त 9999 रजिस्टर्स असू शकतात. परंतु ते सर्व काही ऑफसेटसह सुरू होतात: 0, 10000, 30000, 40000.

खरं तर, प्रोटोकॉल कमांड्सच्या आत मोडबस, पूर्ण पत्ता वापरला जात नाही, परंतु मूळ पत्त्याशी संबंधित फक्त त्याचा ऑफसेट. त्या. सर्व प्रकारच्या नोंदणीसाठी, निर्देशातील खरा पत्ता 0 -9998 असेल. आणि कोणता बेस ॲड्रेस वापरता येईल हे कमांड ठरवते.

कल्पना करण्याचा सर्वात सोपा मार्ग म्हणजे डिव्हाइस प्रत्येकी 9999 घटकांचे 4 घटक ॲरे संचयित करते. ॲरेमधील निर्देशांक हा कमांडमध्ये निर्दिष्ट केलेला पत्ता आहे. आणि कोणता ॲरे वापरायचा हे कमांड ठरवते.

आपण टेबलवर बारकाईने पाहिल्यास, आपण पाहू शकता की आपण इच्छित असल्यास, आपण अधिक पत्ते वापरू शकता धरूननोंदणी: 40001 - 105537, म्हणजे एकूण 65535 नोंदणी. साठी समान संपर्क: 10001 - 29999, म्हणजे एकूण 19999. हे तथाकथित विस्तारित रजिस्टर आहेत. ते मानकांद्वारे समर्थित नाहीत मोडबसउपकरणे म्हणून, जर तुम्हाला तुमचे डिव्हाइस मानक क्लायंटसह कार्य करण्यास सक्षम बनवायचे असेल, तर तुम्हाला विस्तारित रजिस्टर्स वापरण्याची आवश्यकता नाही.

परंतु जर तुम्हाला खात्री असेल की तुमचे डिव्हाइस तुमच्या मास्टरसोबत काम करेल, ज्याला विस्तारित रजिस्टर्ससह कसे काम करायचे हे माहीत आहे किंवा तुम्हाला खात्री आहे की तुमच्या उत्पादनासाठी वापरल्या जाणाऱ्या मास्टर डिव्हाइसला विस्तारित रजिस्टर्सबद्दल माहिती असेल, तर त्यांचा वापर करा.

वर आम्ही शोधून काढले की डिव्हाइसमध्ये नोंदणी कशी संबोधित केली जाते. आता डिव्हाइसेसना कसे संबोधित केले जाते ते पाहूया.

मोडबस पत्ताउपकरणे

उपकरणांना संबोधित करण्यासाठी, एक विशेष अभिज्ञापक वापरला जातो, ज्याला म्हणतात गुलाम आयडी. हे एकल-बाइट मूल्य आहे जे संपूर्ण नेटवर्कमध्ये डिव्हाइसचा अद्वितीय पत्ता परिभाषित करते. मोडबस. मानकानुसार मोडबसती 1 ते 247 पर्यंतची संख्या असू शकते. म्हणजे एकूण, नेटवर्कवर अद्वितीय पत्त्यांसह 247 एंड डिव्हाइसेस (स्लेव्ह डिव्हाइसेस) असू शकतात.

जेव्हा मास्टर नेटवर्कला कमांड पाठवतो तेव्हा पहिला बाइट असतो गुलाम आयडी. हे पहिल्या बाइटनंतर डिव्हायसेसना कमांडवर प्रक्रिया करायची की ते दुर्लक्ष करू शकतात हे ठरवू देते. साठी हे खरे आहे मोडबस RTU. साठी मोडबस TCPप्रोटोकॉल वापरले युनिट आयडीअर्थ जरी आपण ते पाहिल्यास, ते फक्त एक वेगळे नाव आहे गुलाम आयडी. युनिट आयडी- हा देखील एक-बाइट डिव्हाइस पत्ता आहे, 1 ते 247 पर्यंत.

हे एकाच वेळी नेटवर्कवर असू शकतील अशा डिव्हाइसेसची संख्या मोठ्या प्रमाणात मर्यादित करते. म्हणून, जेव्हा उपकरणांना संबोधित करण्यासाठी 2 बाइट्स वापरले जातात तेव्हा एक पर्याय असतो. या प्रकरणात, डिव्हाइसेसची संख्या 65535 पर्यंत वाढते. हे पुरेसे आहे. पण एक अट आहे. ॲड्रेसिंगसाठी मास्टर आणि एंड डिव्हाइस 2 बाइट वापरणे आवश्यक आहे. त्या. ते समान डिव्हाइस ॲड्रेसिंग स्कीम वापरण्यासाठी कॉन्फिगर केले जाणे आवश्यक आहे: 1 किंवा 2 बाइट्स. तसेच, नेटवर्कवरील सर्व उपकरणांनी समान पत्ता योजना वापरणे आवश्यक आहे - 1 किंवा 2 बाइट्स. नेटवर्कवर वेगवेगळ्या ॲड्रेसिंग स्कीमसह डिव्हाइस असू शकत नाहीत.

मोडबस कार्ये

डेटाची विनंती करण्यासाठी किंवा ते लिहिण्यासाठी, मास्टरने अंतिम डिव्हाइसवर करू इच्छित कार्य सूचित करणे आवश्यक आहे. सर्व उपलब्ध वैशिष्ट्ये मानक म्हणून मोडबसप्रोटोकॉल खाली दिलेला आहे:

प्रत्येक कार्याची नंतर तपशीलवार आणि उदाहरणांसह चर्चा केली जाईल.

CRCचुका टाळण्यासाठी 16 मार्ग

मध्ये प्रत्येक संघ मोडबस RTUप्रोटोकॉल दोन बाइट्ससह समाप्त होतो ज्यात सर्व कमांड बाइट्सचे CRC16 मूल्य असते. CRC16 जोडल्याने तुम्हाला दूषित विनंत्या शोधता येतात आणि त्याकडे दुर्लक्ष करता येते. कमांडमधील प्रत्येक बाइट चेकसमची गणना करण्यासाठी वापरला जात असल्याने, कोणत्याही बाइटमध्ये एक बिट बदलल्यास पाठवलेल्या चेकसममध्ये आणि प्राप्त झालेल्या बाइट्समधून गणना केलेल्या चेकसममध्ये विसंगती निर्माण होईल. प्रसारित डेटाचे नुकसान होण्यापासून संरक्षण करण्याचा हा एक विश्वासार्ह मार्ग आहे (म्हणजे, खराब झालेला डेटा शोधा). क्लायंट, तसेच मास्टरने, प्राप्त झालेल्या बाइट्समधून व्युत्पन्न केलेल्या CRC16 सह प्राप्त कमांडचे CRC16 तपासणे आवश्यक आहे. चेकसम जुळत नसल्यास, प्राप्त झालेल्या विनंतीमध्ये दूषित बाइट्स असतात, जे पाठवलेल्या आदेशाचा अर्थ विकृत करतात. या आदेशाकडे दुर्लक्ष केले पाहिजे.

मध्ये CRC16 वापरलेले नाही याची नोंद घ्यावी मोडबस TCPप्रोटोकॉल TCP पॅकेटमध्ये आधीच स्वतःचे चेकसम अंगभूत असल्याने आणि डेटा अखंडतेसाठी तपासले जात असल्याने, CRC16 ची गणना करण्याची आवश्यकता नाही.

आणखी एक विविधता मोडबसप्रोटोकॉल, मॉडबस ASCII, वापरले LRC CRC16 ऐवजी (अनुदैर्ध्य रिडंडंसी चेक). LRC CRC16 पेक्षा खूप सोपे आहे आणि परिणाम 1 बाइट आहे. डेटा करप्शन एरर शोधण्यासाठी LRC कमी विश्वासार्ह आहे, परंतु ऐतिहासिकदृष्ट्या त्यात आहे मॉडबस ASCIIही अचूक पद्धत वापरते.

साठी CRC16 ची गणना कशी करावी याबद्दल मोडबस RTUसाठी प्रोटोकॉल आणि LRC मॉडबस ASCIIप्रोटोकॉल, मी स्वतंत्रपणे लिहीन.

नोंदींमध्ये साठवलेल्या डेटाचे प्रकार.

रजिस्टरमध्ये कोणता डेटा संग्रहित केला जाऊ शकतो याबद्दल बोलूया. सर्वात सोपा केस आहे गुंडाळीआणि संपर्क करानोंदणी हे रजिस्टर्स 1 बिट माहिती साठवू शकतात - 0 किंवा 1. जेव्हा मास्टर या रजिस्टर्स वाचतो तेव्हा त्याला 0 किंवा 1 प्राप्त होतो परिणामी रजिस्टर्स लिहिण्यासाठी विशेष स्थिरांक वापरले जातात:

0xFF00- म्हणजे तार्किक 1

0x0000- म्हणजे तार्किक 0

एकाधिक रजिस्टर्स लिहिण्यासाठी कमांड वापरल्यास, प्रत्येक रजिस्टर 1 बिट: 0 किंवा 1 वापरून लिहिले जाईल.

इतर सर्व रजिस्टर 16 बिट डेटा (2 बाइट) आहेत

आणि येथे सर्वात मनोरंजक गोष्ट आहे.

डेटाचे स्पष्टीकरण वर्णनात निर्दिष्ट केले जाणे आवश्यक आहे मोडबसनोंदणी (तथाकथित मोडबस नकाशादस्तऐवज). या दस्तऐवजात, तुम्हाला नक्की निर्दिष्ट करणे आवश्यक आहे की कोणते रजिस्टर कोणत्या डेटाची नोंदणी करते आणि त्यासाठी कोणती मूल्ये स्वीकार्य आहेत.

चला सोप्या केसेससह प्रारंभ करूया.

जर आपण वाचले तर 1 इनपुटकिंवा धरूननोंदणी करा, नंतर आम्हाला 16 बिट डेटा मिळेल. उदाहरणार्थ, हे मूल्य असू शकते 0x8D05- दोन बाइट्स 0x8Dआणि 0x05.

सर्वात सोप्या बाबतीत, हे एक स्वाक्षरी न केलेले पूर्णांक मूल्य असू शकते: 36101

परंतु ते स्वाक्षरी केलेले पूर्णांक असू शकते: -29435

दुसरे उदाहरण. आम्ही अर्थ वाचला आहे 0x4D4F

हे एकतर स्वाक्षरी न केलेले पूर्णांक, स्वाक्षरी केलेले पूर्णांक किंवा 2 ASCII वर्ण असू शकतात:

0x4D = एम

0x4F = ओ

आता प्रकरण अधिक मनोरंजक आहे. एकापेक्षा जास्त रजिस्टर एकत्र करून, आम्ही 16 बिट्सपेक्षा मोठे डेटा प्रकार संग्रहित करू शकतो.

उदाहरणार्थ, आम्ही 2 नोंदणी वाचली आणि खालील डेटा प्राप्त केला: 0xAE53 0x544D

हे असू शकते:

32 बिट स्वाक्षरी न केलेला पूर्णांक

0xAE53 0x544D = 2924696653

32 बिट चिन्हांकित पूर्णांक

0xAE53 0x544D = -1370270643

32 बिट फ्लोट - फ्लोटिंग पॉइंट नंबर

0xAE53 0x544D = -4.80507e-11

किंवा ASCII एन्कोडिंगमध्ये 4 वर्ण संग्रहित करा

0xAE53 0x544D = 0xAE 0x53 0x54 0x4D= ®STM

आम्ही पुढे चालू ठेवल्यास, अधिक नोंदणी एकत्र करून, आम्ही 64-बिट मूल्ये, 128-बिट मूल्ये, स्ट्रिंग्स आणि मुळात कोणत्याही प्रकारचा डेटा संचयित करू शकतो.

परंतु, रजिस्टर एकत्र करून, आमच्यासमोर खालील प्रश्न आहेत:

बाइट आणि शब्द क्रम

दुर्दैवाने प्रोटोकॉल मोडबसबाइट्स रजिस्टरमध्ये कसे संग्रहित केले जावे हे परिभाषित करत नाही. त्या. वेगवेगळ्या उत्पादकांकडील भिन्न उपकरणे यादृच्छिक क्रमाने बाइट संचयित करू शकतात.

उदाहरणार्थ, रजिस्टर वाचून, आम्हाला 0xA543 मूल्य मिळाले

मूळ रजिस्टरमध्ये बाइट्स ज्या क्रमाने संग्रहित केल्या गेल्या त्यानुसार, ही दोन पूर्णपणे भिन्न मूल्ये असू शकतात:

वापरले तर मोठा एंडियन format (प्रथम उच्च बाइट), नंतर आपल्याकडे मूल्य असेल 42307

पण वापरले तर लिटल एंडियन format (प्रथम कमी बाइट), नंतर आपल्याकडे मूल्य असेल 17317

जेव्हा आम्ही दोन रजिस्टर्समधून 32-बिट मूल्य तयार करतो तेव्हा हे आणखी मनोरंजक आहे.

4 संभाव्य बाइट संयोजन आहेत उदाहरणार्थ, 32-बिट संख्या 4014323619 (0xEF45B7A3) खालील 4 बाइट अनुक्रमांद्वारे प्रसारित केले जाऊ शकते:

0xEF45 0xB7A3

0x45EF 0x A3B7

0xB7A3 0xEF45

0xA3B7 0x45EF

अंतिम डिव्हाइसवर कोणता बाइट/शब्द क्रम लागू केला गेला आहे हे महत्त्वाचे नाही. मुख्य गोष्ट अशी आहे की मास्टरला हा क्रम माहित असणे आवश्यक आहे आणि प्राप्त झालेल्या बाइट्समधून योग्य मूल्ये तयार करण्यास सक्षम असणे आवश्यक आहे. अंतिम डिव्हाइसवर अचूक डेटा स्वरूप जाणून घेतल्यास, विझार्ड नेहमी योग्यरित्या नोंदणी मूल्ये तयार करेल. आणि हे तंतोतंत आहे का अशी एक गोष्ट आहे मोडबस नकाशा (मोडबस कार्ड).

मोडबसनकाशा

मोडबस नकाशाहे सर्व शक्यतेचे पूर्णपणे वर्णन करणारे दस्तऐवजीकरण आहे मोडबसडिव्हाइसवरील नोंदणी, त्यांचे पत्ते, उद्देश, उपलब्ध मूल्ये, डीफॉल्ट मूल्ये, प्रवेश पद्धत.

काही उपकरणे निश्चित रजिस्टर वर्णनासह येतात. त्या. रजिस्टर्सची यादी, त्यांचे पत्ते, संग्रहित डेटा इ. निर्मात्याने काटेकोरपणे निर्दिष्ट केले आहे आणि दस्तऐवजीकरणात वर्णन केले आहे.

आणि एक सानुकूल कॉन्फिगरेशन आहे. त्या. डिव्हाइसवर नोंदणीसाठी कोणतेही निश्चित पत्ते नाहीत. वापरकर्ता कॉन्फिगर करू शकतो मोडबस नकाशात्याला आवश्यक असलेला मार्ग (उदाहरणार्थ, काही रजिस्टर्स एका आदेशाने वाचण्यासाठी पत्त्यांच्या सतत क्रमाने जोडून).

निश्चित उदाहरण मोडबस नकाशा, जे तुमच्या डिव्हाइसेससाठी वापरण्यास अर्थपूर्ण आहे, खालील सारणीसारखे दिसू शकते.

मॉडबस काय करू शकत नाही

मोडबसहा एक अतिशय सोपा प्रोटोकॉल आहे, त्यामुळे तुम्हाला आवश्यक असलेल्या प्रत्येक गोष्टीला ते समर्थन देत नाही.

मोडबससंदेशांना (इव्हेंट) समर्थन देत नाही. त्या. शेवटचे उपकरण मास्टरला संदेश पाठवू शकत नाही. केवळ मास्टर अंतिम डिव्हाइसचे मतदान करू शकतो.

मोडबसऐतिहासिक डेटा वाचण्यास समर्थन देत नाही (विशिष्ट कालावधीत संचित). जरी कमांड रजिस्टर्स, ॲड्रेस रजिस्टर्स आणि ओव्हरलोड रजिस्टर्स तयार करून ही मर्यादा सहजपणे दूर केली जाऊ शकते. भविष्यातील लेखात याबद्दल चर्चा केली जाईल.

मानक मोडबसजटिल संरचित डेटा संचयित करू शकत नाही (किमान अंमलबजावणी करणे सोपे नाही).

याशिवाय, मोडबसप्रमाणीकरण किंवा एन्क्रिप्शनला समर्थन देत नाही. म्हणजेच, सर्व संप्रेषण असुरक्षित मोडमध्ये होते. जरी, काही इच्छेसह, आपण ओळखीचे काही प्रतीक अंमलात आणू शकता मोडबस TCPबहुतेक प्रकरणांमध्ये हे करणे अशक्य आहे. अनधिकृत प्रवेश आणि बदलांपासून डेटाचे संरक्षण करण्यासाठी काही पर्याय आहेत, परंतु ते फारसे विश्वासार्ह नाहीत (जरी ते वापरले जाऊ शकतात). मी भविष्यातील लेखांमध्ये त्यांचे वर्णन करेन.

आणि असे दिसते की या प्रोटोकॉलसाठी या सर्व स्पष्ट कमतरता आहेत. अन्यथा हे अगदी सोपे आहे आणि सोप्या मॉनिटरिंग सिस्टमसाठी उत्तम आहे ज्यांना काही सिस्टम मेट्रिक्सचे निरीक्षण करणे आणि रजिस्टर वाचून त्यांना प्रवेश प्रदान करणे आवश्यक आहे.

पुढील लेखात आपण प्रोटोकॉलद्वारे समर्थित सर्व मुख्य कार्ये पाहू मोडबस.

RS-48 इंटरफेस

ANSI TIA/EIA-485 मानक, ज्याला RS485 म्हणून ओळखले जाते, औद्योगिक हस्तक्षेप असलेल्या वातावरणात लांब अंतरावरील डेटा विश्वसनीयरित्या प्रसारित करण्यासाठी संतुलित पद्धत परिभाषित करते. मानक नेटवर्क टोपोलॉजी देखील परिभाषित करते आणि इंटरफेस लाइन प्रतिबाधा जुळवण्याच्या पद्धतींचे वर्णन करते आणि प्रयोगशाळेच्या चाचण्यांचे परिणाम प्रदान करते.

भौतिकदृष्ट्या, RS485 इंटरफेस भिन्न आहे, मल्टीपॉइंट कनेक्शन प्रदान करतो आणि डेटा दोन्ही दिशानिर्देशांमध्ये पाठविण्यास आणि प्राप्त करण्यास अनुमती देतो.

सोप्या भाषेत सांगायचे तर, RS485 इंटरफेस नेटवर्कमध्ये ट्विस्टेड जोडीचा वापर करून जोडलेले ट्रान्ससीव्हर्स असतात - दोन वळलेल्या तारा (चित्र पहा.तांदूळ २.१).

ट्रान्समीटरच्या ओळी A आणि B मधील ठराविक व्होल्टेज फरक 3V, किमान 1.5V, कमाल 5V आहे.

रिसीव्हरवरील रेषा A आणि B मधील व्होल्टेज फरक किमान 0.2V असणे आवश्यक आहे आणि सामान्य वायरच्या सापेक्ष परिपूर्ण संभाव्य फरक (-7...12) V मध्ये असणे आवश्यक आहे.

अशाप्रकारे, वळलेल्या जोडीच्या दोन तारांमध्ये नेहमीच संभाव्य फरक असतो. हा संभाव्य फरक सिग्नल प्रसारित करतो. ही प्रसारण पद्धत सामान्य मोड हस्तक्षेपासाठी उच्च प्रतिकारशक्ती प्रदान करते. RS485 इंटरफेसद्वारे डिव्हाइसची कमाल संवाद गती अनेक Mbaud पर्यंत पोहोचू शकते. कमाल अंतर 1200 मीटर आहे. 1200 मीटरपेक्षा जास्त अंतरावर संप्रेषण आयोजित करणे किंवा ट्रान्समीटरच्या लोड क्षमतेपेक्षा जास्त उपकरणे जोडणे आवश्यक असल्यास, विशेष पुनरावर्तक वापरले जातात. संप्रेषण दुव्याच्या कमाल लांबीची गणना करण्यासाठी एक सामान्य नियम खालीलप्रमाणे आहे: बॉड रेटचे उत्पादन आणि मीटरमधील लांबीचा परिणाम 108 पेक्षा जास्त नसावा.

ट्विस्टेड पेअर किंवा उच्च ट्रान्समिशन स्पीडद्वारे कनेक्ट केलेल्या उपकरणांमधील महत्त्वपूर्ण अंतरांवर, लांब रेषांचे तथाकथित प्रभाव दिसू लागतात. इलेक्ट्रोमॅग्नेटिक सिग्नल ट्रान्समिशन लाइनच्या उघड्या टोकापासून आणि त्याच्या शाखांमधून परावर्तित होतो. ओळीच्या टोकापासून परावर्तित होणारी सिग्नलची किनार वर्तमान किंवा पुढील सिग्नल विकृत करू शकते. अशा परिस्थितीत, प्रतिबिंब प्रभाव दाबणे आवश्यक आहे.

या समस्येचे मानक उपाय आहेत (आर, आरसी - टर्मिनेटर). कोणत्याही कम्युनिकेशन लाइनमध्ये वैशिष्ट्यपूर्ण प्रतिबाधा Zv असे पॅरामीटर असते. हे वापरलेल्या केबलच्या वैशिष्ट्यांवर अवलंबून असते आणि त्याच्या लांबीवर अवलंबून नसते. सामान्यतः संप्रेषण ओळींमध्ये वापरल्या जाणाऱ्या वळणा-या जोड्यांसाठी, वैशिष्ट्यपूर्ण प्रतिबाधा Zв (90-120) ओम आहे. चला पर्यायांचा विचार करूया:

1. जर रेषेच्या रिमोट शेवटी, वळणा-या जोडीच्या कंडक्टरच्या दरम्यान, रेषेच्या वैशिष्ट्यपूर्ण प्रतिबाधाइतके नाममात्र ओमिक प्रतिरोधक असलेले प्रतिरोधक जोडलेले असेल, तर विद्युत चुंबकीय लहरी पोहोचते."डेड-एंड" अशा रेझिस्टरद्वारे शोषले जाते. म्हणून त्याचे नाव - जुळणारे रेझिस्टर किंवा "टर्मिनेटर". या पद्धतीच्या फायद्यांव्यतिरिक्त (वाढीव वेग, वाढलेली लांबी आणि प्रतिबिंबांचे दडपण), तोटे देखील आहेत (ड्रायव्हर्सवरील अतिरिक्त भार विजेचा वापर वाढवते, ओळीच्या उर्वरित शाखा विकृतीचा परिचय देत राहतात, रिसीव्हर ड्रायव्हरमध्ये आहे. एक अस्पष्ट स्थिती: एकतर स्टँडबाय मोड किंवा प्राप्त मोड).
2. जर रिमोटच्या शेवटी, रेझिस्टरऐवजी, तुम्ही आरसी चेन R = (90-120) ओम, सी = 1000 पीएफ स्थापित केले, तर तुम्ही वाढीव वीज वापराची समस्या आणि रिसीव्हर ड्रायव्हरच्या अनिश्चिततेची समस्या दूर करू शकता (रिसीव्हरसाठी ओपन-लाइन आणि फेलसेफ फंक्शन्ससह). परंतु RC सर्किटच्या वेळेच्या स्थिरतेमुळे, जास्तीत जास्त प्रसारण गती आणि लाइनची लांबी कमी असेल.

प्रतिबिंब प्रभाव आणि योग्य जुळणीची गरज संप्रेषण लिंक कॉन्फिगरेशन (नेटवर्क टोपोलॉजी) वर निर्बंध लादते. कम्युनिकेशन लाइन एकल ट्विस्टेड जोडी केबल असणे आवश्यक आहे. सर्व रिसीव्हर्स आणि ट्रान्समीटर (माला) या केबलला जोडलेले आहेत. रेषेपासून RS485 इंटरफेस चिप्सपर्यंतचे अंतर शक्य तितके कमी असावे, कारण लांब फांद्या जुळत नाहीत आणि प्रतिबिंब निर्माण करतात. केबलच्या दोन्ही सर्वात दूरच्या टोकांवर टर्मिनेटर समाविष्ट केले जातात. ट्विस्टेड पेअर केबलची कॅलिबर AWG24 पेक्षा जास्त नाही.

हे असेही म्हटले पाहिजे की सर्व उपकरणे इंटरफेस लाइनशी विशेष मायक्रोक्रिकेट्स (RS485 इंटरफेस ड्रायव्हर्स) द्वारे जोडलेली आहेत. ते वेगवेगळ्या उत्पादकांकडून आणि भिन्न तांत्रिक पॅरामीटर्ससह असू शकतात आणि परिणामी, भिन्न खर्च. हे ड्रायव्हर्स मोठ्या प्रमाणावर डिव्हाइसेसचे ऑपरेशनल गुणधर्म निर्धारित करू शकतात: ट्रान्समिशन रेंज, नेटवर्कच्या एका विभागातील डिव्हाइसेसची संख्या आणि ट्रान्समिशन विश्वसनीयता.

MODBUS प्रोटोकॉल

MODBUS हा एक ऍप्लिकेशन लेयर प्रोटोकॉल (OSI लेयर 7) आहे जो विविध कम्युनिकेशन चॅनेल आणि नेटवर्क्सद्वारे कनेक्ट केलेल्या उपकरणांमधील संवाद सक्षम करतो.

वास्तविक, MODBUS हे 1979 पासून औद्योगिक नेटवर्कमध्ये एक मानक आहे. हे इंटरनेटसह जगभरातील लाखो उपकरणांना संप्रेषण प्रदान करते. प्रोटोकॉलची विविध अंमलबजावणी आहेत:

• असिंक्रोनस वायरलेस, ऑप्टिकल आणि वायर्ड कम्युनिकेशन चॅनेलसाठी (RS-232, RS-485, RS-422)
• इंटरनेटवर TCP/IP (पोर्ट 502) साठी
• MODBUS-PLUS - लेबल ट्रान्सफरसह हाय-स्पीड नेटवर्कसाठी(हाय स्पीड टोकन पासिंग नेटवर्क)

याव्यतिरिक्त, नेटवर्कचे विषम विभाग गेटवे (विशेष कन्व्हर्टर) द्वारे एकत्र केले जाऊ शकतात.

एसिंक्रोनस सीरियल कम्युनिकेशन चॅनेलसाठी, MODBUS-SERIAL-LINE प्रोटोकॉल MODBUS-RTU आणि MODBUS-ASCII (OSI मॉडेलचे स्तर 1 आणि 2) दोन अंमलबजावणी आहेत. त्यांच्यातील फरक डेटा एन्कोडिंगची पद्धत, फ्रेम सिंक्रोनाइझेशनची पद्धत आणि डेटा अखंडता सुनिश्चित करण्यासाठी अल्गोरिदममध्ये आहे. आमच्या बाबतीत, RS485 नेटवर्कमध्ये, MODBUS-RTU प्रोटोकॉल वापरून डेटा एक्सचेंज लागू केले जाते. पुढे मजकूरात आम्ही केवळ या पैलूमध्ये परिस्थितीचा विचार करू.

MODBUS-SERIAL-LINE प्रोटोकॉल हा मास्टर-स्लेव्ह प्रकारचा प्रोटोकॉल आहे (विनंती-प्रतिसाद प्रोटोकॉल). नेटवर्कमध्ये नेहमीच एक नेता असतो (MASTER). प्रत्येक SLAVE ला एक अद्वितीय क्रमांक 1-247 असणे आवश्यक आहे. पत्ता 0 ही एक प्रसारण विनंती आहे जी एकाच वेळी सर्व गुलामांना उद्देशून आहे. अशाप्रकारे, तार्किकदृष्ट्या नेटवर्कच्या एका विभागात 248 डिव्हाइसेस (मास्टरसह) असू शकतात. प्रत्येक विनंतीमध्ये फंक्शन कोड असतो. MODBUS फंक्शन्स म्हणजे मास्टरच्या अधीनस्थांकडून प्रदान केलेल्या काही सेवा. अशा प्रकारे, क्लायंटची भूमिका मास्टरद्वारे खेळली जाते आणि सर्व्हरची भूमिका, सेवा फंक्शन्सच्या विशिष्ट संचासह, स्लेव्हद्वारे खेळली जाते.

MODBUS प्रोटोकॉल कार्ये

प्रत्येक SLAVE मध्ये सेवा फंक्शन्सचा एक अद्वितीय संच असू शकतो, परंतु तेथे अनेक मानक कार्ये देखील आहेत ज्यांचे तपशील दस्तऐवजात वर्णन केले आहे ( www.modbus.org ). तसेच उपयुक्त माहिती दस्तऐवजात आढळू शकते “मॉडबस ओव्हर सीरियल लाइन स्पेसिफिकेशन आणिअंमलबजावणी मार्गदर्शक"( www.modbus.org).

आम्ही समर्थन देत असलेल्या कार्ये (तक्ता 4.1 - 4.2 पहा).

डिव्हाइसेसच्या पूर्वीच्या आवृत्त्यांमध्ये (२०१० पूर्वी), फक्त वापरकर्ता कार्ये लागू केली गेली होती, परंतु कालांतराने हे स्पष्ट झाले की पीएलसी (पीसी बायपास करून) डिव्हाइसेसचे सामायिकरण सुनिश्चित करण्यासाठी मानक कार्ये देखील आवश्यक आहेत.

सावधगिरी बाळगा आणि लक्षात घ्या की मानक कार्ये फक्त शब्दांवर (16-बिट) आणि बिग-एंडियन फॉरमॅटमध्ये कार्य करतात, परंतु चेकसम स्वरूप CRC16 लिटल-एंडियन आहे! म्हणून, MODBUS प्रोटोकॉलच्या वर्णनातील विसंगती दूर करण्यासाठी, CRC16 चेकसम बाइट्सच्या ऑर्डरच्या संदर्भात, एक साधा नियम वापरणे योग्य आहे: अखंड पॅकेटची अचूक गणना केलेली चेकसम (सीआरसी 16 च्या शेवटच्या 2 बाइट्ससह) नेहमी समान असते. शून्यावर

बरोबर क्वेरी: CRC16 (1 104 0 0 8 0 103 195) = 0

अवैध विनंती: CRC16 (1 104 0 0 8 0 195 103)<> 0

मानक कार्ये (टेबल 4.1 पहा) दस्तऐवजात तपशीलवार वर्णन केले आहेत "मॉडबस ऍप्लिकेशन प्रोटोकॉल स्पेसिफिकेशन" ( www.modbus.org).

फंक्शन 108 “सर्व्हिस कमांड्स” मध्ये खालील सबफंक्शन कोड आहेत (टेबल 4.8 पहा).
कोणताही डेटा परत करणारी सबफंक्शन्स GET सह प्रीफिक्स केली जातात. डेटा परत न करणाऱ्या सबफंक्शनमध्ये डेटा फील्ड नसतो आणि यशस्वी झाल्यास, इको बॅक.

सबफंक्शन 1 आणि 2 जे व्हॉल्यूम नंबर परत करतात ते नेहमी 4-बाइट DWORD मूल्य परत करतात.

सबफंक्शन 3 आणि 4, पृष्ठ क्रमांक मिळवून देणारे, डिव्हाइस मॉडेलवर अवलंबून, 2-बाइट (WORD) आणि 4-बाइट (DWORD) दोन्ही मूल्ये देऊ शकतात.

डिव्हाइस मेमरी वितरण नकाशे

खालील तक्त्या उपकरणांचे मेमरी वितरण नकाशे दाखवतात. हे लक्षात घेतले पाहिजे की मानक MODBUS फंक्शन्समध्ये डेटा प्रकारांचा आकार वापरकर्त्याने परिभाषित केलेल्या फंक्शन्सच्या डेटा प्रकारांपेक्षा (वाढत्या प्रमाणात) भिन्न असू शकतो जर डेटा प्रकाराचा आकार WORD प्रकार (2 बाइट्स) च्या एकाधिक नसेल.

बाइट ऑर्डर ऑर्डर कॉलममध्ये दर्शविली आहे. BE हे पद मोठ्या एंडियन ऑर्डरशी आणि LE लिटल एंडियन ऑर्डरशी संबंधित आहे.

दिलेल्या व्हेरिएबलसाठी उपलब्ध ऑपरेशन्स शेवटच्या स्तंभात, rw (रीड-राइट) मध्ये दर्शविल्या जातात. R - फक्त वाचण्याची परवानगी आहे, W - फक्त लिहिण्याची परवानगी आहे, RW - वाचणे आणि लिहिणे या दोन्हींना अनुमती आहे.

ॲरे शब्द ॲरे द्वारे दर्शविले जातात आणि ॲरेच्या घटकांची संख्या चौरस कंसात दर्शविली जाते [n].

सिंगल-फेज ओमिक्स डिव्हाइस 7 पॉवर गुणवत्ता पॅरामीटर्स मोजते, मेमरी ॲरे (ॲरे) मध्ये ते खालील क्रमाने स्थित आहेत - व्होल्टेज, - वर्तमान, - वारंवारता, - स्पष्ट शक्ती, - सक्रिय शक्ती, - प्रतिक्रियाशील शक्ती, - cos(Φ ).

• संतुलित व्होल्टेज डिजिटल इंटरफेस सर्किट्सची इलेक्ट्रिकल वैशिष्ट्ये, ANSI/TIA/EIA-422-B-1994, दूरसंचार उद्योग संघटना, 1994
• बॅलेंस्ड डिजिटल मल्टीपॉइंट सिस्टम्समध्ये वापरण्यासाठी जनरेटर आणि रिसीव्हर्सची इलेक्ट्रिकल वैशिष्ट्ये, ANSI/TIA/EIA-485-A-1998, दूरसंचार उद्योग संघटना, 1998
• TIA/EIA-485-A, TIA/EIA दूरसंचार प्रणाली बुलेटिन, दूरसंचार उद्योग संघटना, 1998 साठी अर्ज मार्गदर्शक तत्त्वे
• भिन्न समाप्ती तंत्रांची तुलना, जो व्हो, नॅशनल सेमीकंडक्टर, ऍप्लिकेशन नोट AN-903
• डेटा ट्रान्समिशन डिझाइन सेमिनार संदर्भ पुस्तिका, 1998, टेक्सास इन्स्ट्रुमेंट्स, साहित्य क्रमांक SLLE01
• डेटा ट्रान्समिशन लाइन सर्किट्स डेटा बुक, 1998, टेक्सास इन्स्ट्रुमेंट्स, साहित्य क्रमांक SLLD001
• MODBUS ऍप्लिकेशन प्रोटोकॉल स्पेसिफिकेशन
• MODBUS ओव्हर सीरियल लाइन स्पेसिफिकेशन आणि अंमलबजावणी मार्गदर्शक

Avtomatika LLC 2012

प्रोटोकॉलच्या दुसर्या फरकाचा विचार करण्याची वेळ आली आहे मोडबस – मॉडबस ASCII. प्रोटोकॉलची ही आवृत्ती डेटा ट्रान्समिशनसाठी फक्त ASCII वर्ण वापरते, जे बायनरी डेटाचे हेक्साडेसिमल प्रतिनिधित्व एन्कोड करते. थोडे अस्पष्ट आणि गोंधळात टाकणारे? ते ठीक आहे, कटमध्ये आपले स्वागत आहे आणि आपण काय हाताळत आहोत ते पाहूया.

पॅकेट विभाजक

प्रोटोकॉलमधील पहिला फरक मॉडबस ASCIIपासून मोडबस RTU- त्यात पॅकेट्समध्ये विभाजक आहे. मध्ये असल्यास मोडबस RTUसर्व पॅकेट्स एकामागून एक आली (व्यावहारिकपणे, पॅकेट्सच्या दरम्यानच्या ओळीवर थोडा विलंब असावा, सुमारे 2-5ms), नंतर मॉडबस ASCIIप्रत्येक नवीन पॅकेट एका विशेष परिसीमक वर्णाने सुरू होणे आवश्यक आहे.

मानकानुसार मोडबस RTUपॅकेट्समध्ये 3.5 चिन्हांचा विलंब आवश्यक आहे (संप्रेषण मार्गावर 3.5 चिन्हे प्रसारित करण्यासाठी लागणारा वेळ ट्रान्समिशन गतीवर अवलंबून असतो). हा विलंब मास्टरकडून नवीन विनंती शोधण्यासाठी वापरला जातो. त्या. हा विलंब नवीन विनंतीच्या प्रारंभास सूचित करतो. परंतु जेव्हा त्यांनी मॉडेम वापरण्यास सुरुवात केली तेव्हा ते काम करणे बंद केले. मॉडेमवर आवश्यक वेळ राखणे अशक्य आहे. म्हणून, आम्ही प्रोटोकॉलची नवीन आवृत्ती वापरण्याचे ठरविले - मॉडबस ASCII. हा पर्याय मोडेमसह काम करताना अनेक गैरसोयी दूर करतो: एक विशेष पॅकेट विभाजक वर्ण आहे आणि केवळ दृश्यमान ASCII वर्ण वापरले जातात.

तर, पॅकेटच्या सुरूवातीस असे वर्ण हे हेक्साडेसिमल कोडसह कोलन वर्ण आहे 0x3A. आणि प्रत्येक पॅकेटच्या शेवटी नवीन लाईन आणि कॅरेज रिटर्न वर्णांनी चिन्हांकित केले आहे - 0x0D 0x0A. अशा प्रकारे, बाइट्समधील विलंबावरील अवलंबित्व प्रोटोकॉलमधून पूर्णपणे काढून टाकले जाते. त्या. जर मॉडेमने बाइटला उशीर केला, तर यामुळे क्लायंटच्या बाजूने गैरसंवाद होणार नाही. आणि ते पॅकेट बाइट्स पूर्ण होण्याची प्रतीक्षा करेल 0x0D 0x0A. आणि जर तो एक सीमांकक वर्ण आढळतो 0x3A- बफर रीसेट करेल आणि पुन्हा पॅकेट तयार करण्यास सुरवात करेल. याव्यतिरिक्त, मॉडेम विशेष वर्णांपासून सुटण्याची आवश्यकता नाही, कारण डेटा ASCII सारणीच्या प्रारंभिक विभागातील वर्ण वापरत नाही.

डेटा बाइट्सचे प्रतिनिधित्व

IN मॉडबस ASCIIप्रोटोकॉलमध्ये, डेटाचा प्रत्येक बाइट 2 बाइट्स म्हणून दर्शविला जातो. प्रत्येक बाइट हेक्साडेसिमल नोटेशनमध्ये ASCII वर्ण दर्शवतो. समजून घेणे सोपे करण्यासाठी, एक उदाहरण देऊ:

टेबलसाठी थोडे स्पष्टीकरण.

उदाहरणार्थ, आम्हाला कॅरेक्टर संग्रहित करणाऱ्या डेटाचा बाइट हस्तांतरित करणे आवश्यक आहे # . या वर्णाचा ASCII सारणीमध्ये हेक्साडेसिमल कोड आहे 0x23. प्रोटोकॉल मध्ये मोडबस RTUआम्ही फक्त मूल्यासह एक बाइट पास करतो 0x23.

जर आपण समान वर्ण प्रोटोकॉलद्वारे प्रसारित करू इच्छित असाल तर मॉडबस ASCII, आम्हाला आधीच 2 बाइट्स हस्तांतरित करण्याची आवश्यकता आहे. पहिल्या चरणात, आम्हाला अक्षराचा हेक्साडेसिमल कोड मिळेल, 0x23. दुस-या चरणात, आम्ही दोन ASCII अक्षरे वापरून हे मूल्य एन्कोड करतो − 2 आणि 3 . आणि तिसऱ्या टप्प्यात आम्ही दोन बाइट्स डेटा ट्रान्सफर करतो, पहिला कॅरेक्टरचे हेक्साडेसिमल व्हॅल्यू आहे 2 , दुसरा बाइट वर्णाचे हेक्साडेसिमल मूल्य आहे 3 .

अशा प्रकारे, प्रोटोकॉलमधील डेटा बाइटसाठी मूल्यांची श्रेणी आहे मोडबस RTU – 0 .. 0xFF

प्रोटोकॉलमधील डेटा बाइटसाठी मूल्यांची श्रेणी मॉडबस ASCII- हेक्साडेसिमल अंक प्रदर्शित करण्यासाठी फक्त वर्ण आवश्यक आहेत, उदा. 0 - 9, A, B, C, D, E, F(सर्व टोपी).

Modbus ASCII साठी चेकसम

प्रोटोकॉल मध्ये मोडबस RTU 2-बाइट चेकसम वापरला जातो, जो दूषित विनंत्या शोधण्यात मदत करतो. प्रोटोकॉल मध्ये मॉडबस ASCIIएक चेकसम देखील आहे - LRC (अनुदैर्ध्य रिडंडन्सी चेक).

गणना LRCगणना करण्यापेक्षा खूप सोपे CRC. गणना करणे LRCआपल्याला पुढील गोष्टी करण्याची आवश्यकता आहे:

• संदेशात सर्व बाइट एकत्र जोडा मॉडबस ASCII, ते ASCII वर्णांमध्ये रूपांतरित होण्यापूर्वी. प्रारंभी कोलन आणि अनुगामी वर्ण गणनामध्ये समाविष्ट केलेले नाहीत CR/LF.
• 8 पेक्षा मोठे सर्व बिट्स साफ करा (म्हणजे कमी बाइट सोडा)
• प्राप्त करण्यासाठी परिणामी बाइट नकारात्मक करा LRCबाइट

अशा प्रकारे, जर तुम्ही डेटा पॅकेटचे सर्व बाइट्स आणि बाइट जोडले तर LRCडेटा पॅकेटच्या अचूकतेची ही सर्वात जलद तपासणी आहे.

खाली एक उदाहरण गणना आहे LRCविशिष्ट विनंतीसाठी मॉडबस ASCII.

उदाहरणार्थ, 17 पत्ता असलेल्या डिव्हाइसवरून #40108 - #40110 नोंदणी वाचण्याची विनंती करूया

आता सर्व बाइट्सची बेरीज काढू

ही ऋण संख्या आहे ( -130 किंवा 0x7E) आणि आहे LRCविनंती

हा चेकसम 2 ASCII वर्णांच्या स्वरूपात विनंतीमध्ये जोडला जातो − 7 आणि इ.

त्या. विनंतीच्या शेवटी तुम्हाला मूल्यासह 2 बाइट जोडणे आवश्यक आहे 37 आणि 45 .

Modbus RTU आणि Modbus ASCII विनंतीची उदाहरणे

हे सर्व कसे कार्य करते हे चांगल्या प्रकारे समजून घेण्यासाठी, काही सोप्या उदाहरणे पहा.

17 पत्त्याच्या डिव्हाइसवरून नोंदणी #40108 - #40110 वाचण्याची आमची विनंती घेऊ.

या मोडबस RTUशेवटच्या दोन बाइट्सशिवाय विनंती CRC. आता या क्वेरीचे रुपांतर करू मोडबस RTUव्ही मॉडबस ASCII. हे करण्यासाठी, विनंतीच्या सुरूवातीस एक कोलन वर्ण जोडा, विनंतीच्या शेवटी एक लाइन फीड आणि कॅरेज रिटर्न वर्ण जोडा आणि विनंतीच्या प्रत्येक बाइटच्या हेक्साडेसिमल प्रतिनिधित्वाशी संबंधित ASCII वर्ण म्हणून प्रत्येक बाइटचे प्रतिनिधित्व करा. परिणामी, आम्हाला अशी विनंती (ASCII वर्णांच्या स्वरूपात किंवा फक्त मजकूर स्ट्रिंगच्या रूपात) मिळेल. आम्ही विनंतीच्या शेवटी देखील जोडतो LRC.

आता तुम्हाला ही विनंती ASCII अक्षर कोड वापरून पोर्टवर पाठवायची आहे. बायनरी स्वरूपात, विनंती यासारखी दिसेल: