यदि परियोजना "थियेटर" है, तो अभिनेताओं का उपयोग करें ...

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

हाल ही में, मैं एक बहुत ही दिलचस्प कार्य में भाग लेने में सक्षम था - आधुनिकीकरण, लेकिन वास्तव में - थिएटरों में से एक के लिए रैक उठाने के लिए एक नई स्वचालित नियंत्रण प्रणाली का विकास।

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

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

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

हम क्या कर रहे हैं?

तो, हमारी "नियंत्रण वस्तु" क्या है? Shtanketovy लिफ्टों की प्रणाली - यह मंच की पूरी चौड़ाई में 62 शंकेट्स (धातु के पाइप) हैं जो इस दृश्य के ऊपर लटक रहे हैं, मंच के किनारे से लगभग 30 - 40 सेमी गहराई में हैं। टांगें स्वयं रस्सियों पर लटकी होती हैं और ऊपर (नीचे की ओर खड़ी) अवस्था में ऊपर या नीचे उठ सकती हैं। प्रत्येक प्रदर्शन (या ओपेरा या बैले) में, श्लोक का एक हिस्सा सजावट के लिए उपयोग किया जाता है। दृश्यों को उन पर लटकाया जाता है और स्थानांतरित किया जाता है (यदि स्क्रिप्ट को इसकी आवश्यकता होती है) कार्रवाई के दौरान। "इंजन - केबल - वेटवेट" प्रणाली (लगभग घरों में लिफ्ट के समान) का उपयोग करके संचालकों की कमांड पर (उनके पास विशेष नियंत्रण पैनल) है। इंजन मंच के किनारों पर स्थित हैं (कई स्तरों पर), ताकि वे दर्शक को दिखाई न दें। सभी मोटर्स को 8 समूहों में विभाजित किया गया है और प्रत्येक समूह में तीन आवृत्ति कन्वर्टर्स (IF) हैं। प्रत्येक समूह में, तीन मोटर्स एक साथ सक्रिय हो सकते हैं, प्रत्येक अपने स्वयं के इन्वर्टर से जुड़ा हुआ है। कुल मिलाकर, हमारे पास 62 इंजन और 24 इनवर्टर की एक प्रणाली है, जिसे हमें नियंत्रित करना चाहिए।

हमारा कार्य इस अर्थव्यवस्था के प्रबंधन के लिए एक ऑपरेटर इंटरफ़ेस विकसित करना था, साथ ही प्रबंधन एल्गोरिदम को लागू करना था। प्रणाली में तीन नियंत्रण पद शामिल हैं। दो नियंत्रण पोस्ट सीधे मंच के ऊपर स्थित हैं और एक पोस्ट इंजन कक्ष (जहां नियंत्रण अलमारियाँ स्थित हैं) में स्थित है और ड्यूटी पर एक इलेक्ट्रीशियन के लिए काम की निगरानी करने के लिए डिज़ाइन किया गया है। नियंत्रण अलमारियाँ में नियंत्रक होते हैं जो कमांड निष्पादित करते हैं, पीडब्लूएम को नियंत्रित करते हैं, मोटर्स को बिजली की आपूर्ति करते हैं, शैंक की स्थिति को ट्रैक करते हैं। ऊपरी दो रीमोट पर नज़र रखी जाती है, एक सिस्टम यूनिट जहां नियंत्रण एल्गोरिदम और ट्रैकबॉल एक "माउस" के रूप में घूम रहे हैं। एक ईथरनेट नेटवर्क का उपयोग कंट्रोल पैनल के बीच किया जाता है। प्रत्येक नियंत्रण कैबिनेट में दो नियंत्रण पैनलों में से एक RS485 चैनल (यानी 8 चैनल) हैं। प्रबंधन दोनों रीमोट्स (जो कि स्टेज से ऊपर हैं) से एक साथ किया जा सकता है, लेकिन एक ही समय में रीमोट्स में से एक (ऑपरेटर द्वारा मुख्य ऑपरेटर के रूप में नामित) अलमारियाँ के साथ एक्सचेंज कर रहा है, इस समय दूसरा कंसोल एक बैकअप माना जाता है और इस पर एक्सचेंज को निष्क्रिय कर दिया जाता है।

और यहां के एक्टर्स

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

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

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

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

हमारे मामले में, नेटवर्क और इंटरप्रोसेस संचार के लिए, हमने अपने लंबे समय से चल रहे विकासों में से एक का उपयोग किया - libuniset2 लाइब्रेरी। नतीजतन, हमारे सिस्टम की वास्तुकला कुछ इस तरह दिखती है:

• libuniset नेटवर्क और इंटरप्रोसेस संचार (सेंसर पर आधारित) प्रदान करता है
• sobjectizer नियंत्रण एल्गोरिदम को लागू करने वाले (एक ही पते की जगह में) एक दूसरे के साथ बातचीत करने वाले अभिनेताओं की एक प्रणाली का निर्माण प्रदान करता है।

तो, मुझे आपको याद दिलाना है, हमारे पास 62 इंजन हैं। प्रत्येक मोटर को इन्वर्टर से जोड़ा जा सकता है, संबंधित स्टैंड को समन्वय दिया जा सकता है जिस पर आपको पहुंचना चाहिए और जिस गति से आपको चलना चाहिए। इसके अतिरिक्त, इंजन में निम्नलिखित स्थितियाँ हैं:

• जाने के लिए तैयार
• जुड़ा हुआ
• चल रहा है (कताई)
• दुर्घटना
• कनेक्शन (क्षणिक स्थिति)
• शटडाउन (क्षणिक स्थिति)

नतीजतन, प्रत्येक "इंजन" को एक अभिनेता द्वारा प्रणाली में दर्शाया जाता है जो राज्यों के बीच संक्रमण के तर्क को लागू करता है, सेंसर से घटनाओं को संसाधित करता है, और नियंत्रण आदेश जारी करता है। सब्जेक्टाइज़र में, अभिनेताओं को आसानी से बनाया जाता है, बस आपकी क्लास को बेस क्लास से इनहेरिट किया जाता है so_5 :: agent_t। उसी समय, निर्माणकर्ता को पहले तर्क के रूप में तथाकथित :: so_5 :: संदर्भ_t संदर्भ लेना होगा, शेष तर्क डेवलपर की आवश्यकता द्वारा निर्धारित किए जाते हैं।

class Drive_A: public so_5::agent_t { public: Drive_A( context_t ctx, ... ); ... } 

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

और इन अभिनेताओं के "राज्य" क्या हैं? क्या बात कर रहे हो

राज्यों और ACS के लिए उनके बीच संक्रमण का उपयोग आम तौर पर एक मूल विषय है। यह "कॉन्सेप्ट" इवेंट हैंडलिंग में बहुत अच्छी तरह से फिट बैठता है। Sobjectizer में, यह अवधारणा एपीआई स्तर पर समर्थित है। एक अभिनेता वर्ग में, राज्यों को आसानी से घोषित किया जाता है

 class Drive_A final: public so_5::agent_t { public: Drive_A( context_t ctx, ... ); virtual ~Drive_A(); //  state_t st_base {this}; state_t st_disabled{ initial_substate_of{st_base}, "disabled" }; state_t st_preinit{ substate_of{st_base}, "preinit" }; state_t st_off{ substate_of{st_base}, "off" }; state_t st_connecting{ substate_of{st_base}, "connecting" }; state_t st_disconnecting{ substate_of{st_base}, "disconnecting" }; state_t st_connected{ substate_of{st_base}, "connected" }; ... } 

और आगे, प्रत्येक राज्य के लिए, डेवलपर आवश्यक हैंडलर निर्धारित करता है। अक्सर किसी अवस्था में प्रवेश करते समय और बाहर निकलते समय कुछ क्रियाओं की आवश्यकता होती है। यह भी sobjectizer के लिए प्रदान किया जाता है, आप बस इन घटनाओं ("राज्य प्रविष्टि", "राज्य से बाहर निकलें") के लिए अपने हैंडलर्स को आसानी से परिभाषित करते हैं। यह महसूस किया जाता है कि अतीत में डेवलपर्स के पास व्यापक ACS-shny अनुभव है ...

इवेंट हैंडलर

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

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

 so_subscribe(drv->so_mbox()) .in(st_base) .event( &Drive_A::on_get_info ) .event( &Drive_A::on_control ) .event( &Drive_A::off_control ); 

यहाँ st_base स्थिति के लिए एक विशिष्ट बॉक्स में घटनाओं की सदस्यता का एक उदाहरण है। दिलचस्प बात यह है कि इस उदाहरण में, st_base अन्य राज्यों के लिए आधार स्थिति है, और तदनुसार यह सदस्यता उन सभी राज्यों के लिए मान्य होगी जो st_base से "विरासत में" मिले हैं। यह दृष्टिकोण आपको विभिन्न राज्यों के लिए एक ही हैंडलर निर्धारित करने के लिए "कॉपी-पेस्ट" से छुटकारा पाने की अनुमति देता है। उसी समय, एक विशिष्ट स्थिति में, आप निर्दिष्ट हैंडलर को ओवरराइड कर सकते हैं या इसे "अक्षम" कर सकते हैं (दबा सकते हैं)।

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

 so_subscribe(drv->so_mbox()) .in(st_disconnecting) .event([this](const msg_disconnected_t& m) { ... st_off.activate(); }) .event([this]( const msg_failure_t& m ) { ... st_protection.activate(); }); 

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

वैसे, साधारण मामलों के लिए जब किसी घटना को बस किसी राज्य में जाने की आवश्यकता होती है, तो एक और भी छोटा सिंटैक्स होता है:

 auto mbox = drv->so_mbox(); st_off .just_switch_to<msg_connected_t>(mbox, st_connected) .just_switch_to<msg_failure_t>(mbox, st_protection) .just_switch_to<msg_on_limit_t>(mbox, st_protection) .just_switch_to<msg_on_t>(mbox, st_on); 

प्रबंध

इस सभी अर्थव्यवस्था का प्रबंधन कैसे काम करता है? जैसा कि ऊपर उल्लेख किया गया है, shtankets के आंदोलन के प्रत्यक्ष नियंत्रण के लिए दो रिमोट कंट्रोल प्रदान किए जाते हैं। प्रत्येक रिमोट कंट्रोल में एक मॉनिटर, एक मैनिपुलेटर (ट्रैकबॉल) और एक स्पीड डायल ("कंप्यूटर" के अलावा रिमोट कंट्रोल में छिपा होता है, जिस पर सब कुछ कताई और सभी प्रकार के कन्वर्टर्स के ढेर) होते हैं। सिस्टम में shtankets की गति को नियंत्रित करने के कई तरीके हैं। मैनुअल और "स्क्रिप्ट मोड"। "परिदृश्य मोड" के बारे में आगे चर्चा की जाएगी, और अब थोड़ा "मैनुअल मोड" के बारे में चर्चा की जाएगी। इस मोड में, ऑपरेटर वांछित शैंकेट का चयन करता है, इसे आंदोलन के लिए तैयार करता है (मोटर को इन्वर्टर से जोड़ता है), शैंकेट के लिए चिह्न (लक्ष्य स्थिति) सेट करता है, और जैसे ही यह शून्य से अधिक की गति सेट करता है, टांगों को चलना शुरू हो जाता है। गति सेट करने के लिए, एक विशेष भौतिक समायोजक का उपयोग "घुंडी के साथ पोटेंशियोमीटर" के रूप में किया जाता है, लेकिन गति का एक "स्क्रीन समायोजक" भी है। अधिक "बदल गया", जोर तेज हो जाता है। अधिकतम गति 1.5 मीटर / सेकंड तक सीमित है। गति घुंडी - सभी के लिए एक। यानी मैनुअल मोड में, सभी ऑपरेटर-कनेक्टेड शांकेट एक ही सेट गति से चलते हैं। हालांकि वे विभिन्न दिशाओं में आगे बढ़ सकते हैं (यह निर्भर करता है कि ऑपरेटर ने उन्हें कहां निर्देशित किया है)। बेशक, एक व्यक्ति के लिए एक ही समय में दो या तीन से अधिक shtankets का ट्रैक रखना मुश्किल है, इसलिए आमतौर पर वे मैनुअल मोड में ज्यादा नहीं चल रहे हैं। दो स्टेशनों से, ऑपरेटर एक साथ अपने प्रत्येक shtankets का प्रबंधन कर सकते हैं। इसके अलावा, प्रत्येक कंसोल (ऑपरेटर) का अपना गति नियंत्रक है।

कार्यान्वयन के दृष्टिकोण से, मैनुअल मोड में कोई विशेष तर्क नहीं है। इंजन को जोड़ने की कमांड ग्राफिकल इंटरफेस से आती है, जो संबंधित अभिनेता को संदेश में परिवर्तित हो जाती है, जो इस पर काम करता है। राज्यों के माध्यम से "बंद" -> "कनेक्टिंग" -> "कनेक्ट"। उसी के साथ स्थिति को स्थापित करने की गति और गति निर्धारित करने के लिए। ये सभी घटनाएं अभिनेता के पास संदेश के रूप में पहुंचती हैं, जिस पर वह प्रतिक्रिया देता है। जब तक यह नोट नहीं किया जा सकता है कि ग्राफिकल इंटरफेस और नियंत्रण प्रक्रिया अलग-अलग प्रक्रियाएं हैं और उनके बीच libuniset2 का उपयोग करके "सेंसर" के माध्यम से एक "इंटरप्रोसेस" बातचीत है।

स्क्रिप्ट निष्पादन मोड (फिर, इन अभिनेताओं?)

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

• तैयार हो जाओ (इंजनों का सही समूह जुड़ा हुआ है)
• आइए चलते हैं (समूह प्रत्येक के लिए निर्धारित लक्ष्य स्थितियों पर चलना शुरू करता है)।

पूरे परिदृश्य को तथाकथित "एजेंडों" में विभाजित किया गया है। एक एजेंडा एक shtanket समूह का एक आंदोलन है। यानी प्रत्येक एजेंडा में shtankets का एक समूह शामिल है, लक्ष्य की गति और ब्रांड के साथ जहां आपको आने की आवश्यकता है। वास्तव में, स्क्रिप्ट को कृत्यों में विभाजित किया गया है, कृत्यों को चित्रों में विभाजित किया गया है, चित्रों को उप्पेन में विभाजित किया गया है, और उप-शतक विशिष्ट श्टनेट के लिए पहले से ही "लक्ष्य" से युक्त हैं। लेकिन प्रबंधन के दृष्टिकोण से, यह विभाजन महत्वपूर्ण नहीं है, क्योंकि यह एजेंडे पर है कि आंदोलन के विशिष्ट मापदंडों को अंत में संकेत दिया गया है।

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

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

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

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

इस तथ्य के कारण कि राज्यों के साथ काम करने के लिए सोबिजाइज़र के पास एक सुविचारित और सुविधाजनक एपीआई है, कार्यान्वयन कोड काफी संक्षिप्त है। उदाहरण के लिए, आंदोलन पर देरी एक पंक्ति में वर्णित है:

 st_delay.time_limit( std::chrono::milliseconds{target->delay()}, st_moving ); st_delay.activate(); ... 

Time_limit फ़ंक्शन किसी दिए गए राज्य में कितना खर्च किया जा सकता है और एक निर्दिष्ट समय (st_moving) के बाद किस राज्य को पारित किया जाना चाहिए, इसकी समय सीमा निर्धारित करता है।

संरक्षण अभिनेता

बेशक, ऑपरेशन के दौरान, खराबी हो सकती है। इन स्थितियों को संभालने के लिए प्रणाली की आवश्यकता होती है। यहाँ भी, अभिनेताओं के उपयोग के लिए एक जगह थी। इनमें से कई सुरक्षाओं पर विचार करें:

• वर्तमान सुरक्षा पर
• माप विफलता संरक्षण
• विपरीत दिशा में आंदोलन के खिलाफ सुरक्षा (और यह हो सकता है, अगर सेंसर या मीटर के साथ कुछ गलत है)
• एक आदेश के बिना आंदोलन के खिलाफ संरक्षण
• टीम के निष्पादन का नियंत्रण (नियंत्रण जो शंटकेट ने चलना शुरू किया)

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

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

निष्कर्ष के रूप में ..

... बेशक यह लेख "खोज" का कुछ प्रकार नहीं है। अभिनेता दृष्टिकोण लंबे समय से कई प्रणालियों में सफलतापूर्वक उपयोग किया गया है। लेकिन मेरे लिए यह अपेक्षाकृत छोटे प्रोजेक्ट में नियंत्रण प्रणाली के एल्गोरिदम के निर्माण के लिए सचेत रूप से अभिनेता के दृष्टिकोण का उपयोग करने का पहला अनुभव था। और अनुभव काफी सफल रहा। मुझे उम्मीद है कि मैं यह दिखाने में सक्षम था कि अभिनेता नियंत्रण एल्गोरिदम के साथ बहुत अच्छी तरह से ओवरलैप करते हैं, उन्हें हर जगह सचमुच जगह मिली।

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

और अभिनेता का दृष्टिकोण वास्तव में काम करता है! खासतौर पर थिएटर में।