एक बेहतर/अधिक कुशल पीएलसी प्रोग्रामर

Question

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

मेरी समस्या नई नौसिखिया है, कि जब मैं पीएलसी सॉफ़्टवेयर कोड करता हूं तो मैं वास्तव में कुशल और तेज़ नहीं हो सकता।

हालांकि मैं बहुत ही कुशल हूँ जब मैं वी.एस./ग्रहण में सी # या जावा कोडिंग कर रहा हूँ

यह वास्तव में परेशान करती है कि मैं नहीं "वास्तविक" प्रोग्रामिंग भाषाओं का विरोध करने के पीएलसी के साथ वास्तव में उत्पादक हो सकता है।

• क्या यह कोड पूर्ण होने की कमी है?
• क्या यह स्वचालन पक्ष पर समग्र ज्ञान की कमी है?
• यह के रूप में वी.एस. (LINQ, गतिशीलता, लैम्ब्डा) करने का विरोध किया पीएलसी में नवाचार की कमी है

तुम लोगों पीएलसी के साथ किसी भी अच्छा अनुभव है? और आप इसके साथ उत्पादक कैसे प्राप्त हुए?

नोटिस: यह कंपनी में मेरा आखिरी साल है, यही कारण है कि मैं बहुत उत्पादक बनना चाहता हूं।

कई महान उत्तरों की प्रतीक्षा कर रहे हैं!

Answer 1

PLC प्रोग्रामिंग कई मायनों में पारंपरिक प्रक्रियात्मक प्रोग्रामिंग से अलग है:

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

2) पीएलसी प्रोग्रामिंग के अधिकांश को बूलियन समीकरणों के साथ करना है। आप अच्छा होना PLC प्रोग्रामिंग में, बूलियन तर्क के साथ काम पर कठिन काम करना चाहते हैं: बूलीय बीजगणित जानने के लिए, विशेष रूप से नहीं भर AND और OR वितरण (के बाद से PLC में आम तौर पर नहीं ऑपरेटरों की पेशकश नहीं करते के लिए की तरह डी मोर्गंस प्रमेय बातें , आपको इसकी बहुत अधिक आवश्यकता है अक्सर आप उम्मीद करेंगे)

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

4) PLC प्रोग्रामिंग की ज्यादातर सिद्धांत राज्यों से राज्यों में संक्रमण के बारे में, जहां एक राज्य पीएलसी बाहरी दुनिया के बारे में क्या जानता है का प्रतिनिधित्व करता है, और संक्रमण होते हैं जब पीएलसी एक बाहरी इनपुट पढ़ता है और पता चलता है दुनिया राज्य है कुछ हद तक बदल गया। जितना हो सके उतना सीखें जितना आप परिमित राज्य ऑटोमाटा और असतत प्रणालियों के पर्यवेक्षी नियंत्रण के बारे में सीख सकते हैं। यह आपको उदारतापूर्वक भुगतान करेगा।

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

6) यांत्रिक विफलताओं को संभालने के लिए ध्यान दें। अधिकांश पीएलसी कार्यक्रम मानते हैं कि नियंत्रित प्रणाली विज्ञापन के रूप में काम करती है; यह वास्तव में खराब अभ्यास है। असली दुनिया में, नियंत्रित सिस्टम केवल तब तक विज्ञापित होता है जब तक यह टूटता है, जो हमेशा अंततः करता है। यदि आप अपने पीएलसी कार्यक्रमों में यांत्रिक रूप से टूटा हुआ यह निर्धारित करने में सहायता के लिए डायग्नोस्टिक कोड शामिल करते हैं, तो आपको उन्हें लिखने के लिए अधिक समय लगेगा, लेकिन उपयोगकर्ता आपको प्यार करेंगे, क्योंकि से अधिक कुछ भी नहीं है जो टूट गया है लेकिन यह जीता है आपको कैसे नहीं बताता एक बंद कारखाना एक रोका गया नकद मशीन है, और कारखाने के प्रबंधकों से नफरत है।

Answer 2

पीएलसी सॉफ्टवेयर इंजीनियरिंग इसकी पृष्ठभूमि है:,

1. (समग्र प्रक्रिया प्रवाह डिजाइन के) यांत्रिक & विद्युत मॉडलिंग के लिए समाधान अंतरिक्ष के पूरक भाग
2. पीएलसी अधिक योग्य वैकल्पिक कार्यान्वयन किया जा रहा है पर निर्भरता में वृद्धि हुई किया जा रहा है लेकिन स्वतंत्र मॉडलिंग तकनीक के बिना
3. आईईसी 614 99 पीएलसी प्रोग्रामिंग के लिए डिजाइन तकनीक के रूप में यूएमएल की सिफारिश करता है।

विस्तार से बता दें:

1. पूरक घटक जा रहा है, पीएलसी अनुक्रम/राज्य/लूप नियंत्रकों, सुरक्षा आलिंगन, संकेत कंडीशनिंग, आदि के रूप में इस्तेमाल किया गया था, सुविधाओं होने के रूप में IEC61131 में तय करती। मैकेनिकल & विद्युत मॉडल के भीतर आवश्यकता अच्छी तरह से कब्जा कर लिया गया है, स्वतंत्र मॉडलिंग के लिए कोई आवश्यकता नहीं है।

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

3. पीएलसी सॉफ़्टवेयर मॉडलिंग और आईईसी 61158 (नींव फ़ील्डबस वितरित ऑब्जेक्ट/डेटा/निर्भरता मॉडलिंग) की विफलता की कमी को कम करने के लिए, आईईसी 614 99 को 2006 में यूएमएल की डिजाइन तकनीक के रूप में पेश करने के साथ पेश किया गया था।हालांकि, प्रवृत्ति कार्यात्मक ऑब्जेक्ट मॉडलिंग दृष्टिकोण को ड्रॉन्ग कर रही थी, जिसके परिणामस्वरूप जटिल ऑब्जेक्ट निर्भरताएं अस्थायी और राज्य बाइंडिंग के कारण आम तौर पर प्रक्रिया अनुप्रयोगों में निहित होती हैं जो आईटी उद्योग के रूप में भारी डेटा की बजाय भारी भारी होती है। ताकि लोगों को, परिणाम & तर्क विरोधाभास जांच के लिए विश्लेषण उपकरण, अलग अस्थायी & राज्य मॉडलिंग, आदि के साथ बाहर आने के लिए शुरू होता है वास्तव में चीजों को सरल बनाने नहीं, और समस्या अंतरिक्ष में कमी की इंजीनियरिंग सिद्धांत से भी घूम रहा है। यांत्रिक, विद्युत और प्रक्रिया मॉडलिंग दस्तावेजों से संबंध और निरंतरता में दृष्टिकोण की कमी भी है।

वर्तमान स्थिति है:

एक। IEC61131 & आईईसी 61499 निर्माता मानकों और रीयलटाइम ओएस मुद्दों पर काम करने की आवश्यकता से मुक्त नियंत्रण इंजीनियरों के रूप में,

बी आने के लिए लंबे समय तक आवेदन मानकों को जारी रखना चाहिए। यूएमएल बहुत संभव डिजाइन दृष्टिकोण

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

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

Answer 3

मैं 3 मुद्दों तुम उल्लेख पर आपसे सहमत हूँ।

मुझे कोडेसिस के साथ कुछ अनुभव है और मुझे लगता है कि 2 में से 2 समस्याएं संस्करण 3.x के साथ चली गई हैं।

* Is it the lack of code completion? 
* Is it the lack of innovation in PLC as opposed to VS (LINQ, Dynamics, Lambda) 

CoDeSys 3.x Intellisence और उपयोगकर्ता के अनुकूल संपादक है और यह पीएलसी दुनिया जो देखने की मेरी बात एक बहुत अच्छा नवाचार में है करने के लिए ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग लाता है।

मुझे लगता है कि यह उत्पादकता में सुधार लाने में मदद करता है। मुझे नहीं पता कि CoDeSys प्रतियोगियों समान चीजें कर रहे हैं लेकिन मुझे लगता है कि पीएलसी प्रोग्रामिंग बाजार पर दिलचस्प चीजें हो रही हैं।

ज्ञान की कमी सभी प्रौद्योगिकी के लिए आम बात है। आईईसी -1131 को आसानी से समझने के लिए डिज़ाइन किया गया है जो डेवलपर की पृष्ठभूमि (इलेक्ट्रीशियनों के लिए एलडी, ऑटोमेशन एनजिनियर के लिए एफबीडी, सी/पास्कल प्रोग्रामर के लिए एसटी ...)। तो मेरी राय में यह और अधिक जटिल नहीं है कि कुछ भी। वीएस की जटिलता भी है: अपने स्वयं के ओपीसी सर्वर को सी ++ के साथ बनाने का प्रयास करें और आप इस सुविधा को अधिकांश सॉफ्टप्लसी में उपयोग में देखने के लिए सराहना करेंगे। उस मामले में इंटेलिजेंस एक बड़ी मदद नहीं होगी।

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

मुझे आशा है कि यह मदद करता है

Answer 4

यह मुझे परेशान जब PLC प्रोग्रामिंग तथाकथित 'असली' प्रोग्रामर द्वारा तिरस्कार के साथ देखा जाता है।यहां कई पदों ने मूल तथ्य पर संकेत दिया है कि पीएलसी प्रोग्रामिंग स्वयं के लिए एक अनुशासन है।

"समझें कि पीएलसी प्रोग्रामिंग रीयलटाइम में नियंत्रण और प्रतिक्रिया के बारे में है। अधिकांश मानक प्रोग्रामिंग लैंगुग (जैसे जावा) इस खराब तरीके से संबोधित करते हैं।"

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

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

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

पीएलसी पीसी दुनिया में तथाकथित "प्रगति" के इतने सालों के बाद मौजूद है क्योंकि आज तक पीसी अभी भी बग-एडल डिस्पोजेबल कमोडिटीज हैं। और आपकी बहु मिलियन डॉलर असेंबली लाइन नहीं है।

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

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

टीएम

Answer 5

प्रोग्रामिंग भाषाएं उपकरण हैं। यदि आप केवल एक भाषा जानते हैं, तो आपके पास केवल एक उपकरण है। उपकरण एक नौकरी के लिए अच्छा हो सकता है, कुछ अन्य लोगों के लिए ठीक है, और बाकी सब कुछ के लिए बेकार है। यदि आप अधिक टूल्स जानते हैं, तो आप और अधिक काम कर सकते हैं।

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

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

Answer 6

इन दो उत्पादों सीमेंस Simatic चरण 7 के लिए पर एक नज़र डालें:

1. SCL
2. सीएफसी (अलग उत्पाद)
(पहले से ही चरण 7 प्रोफेशनल में भी अनुसूचित जनजाति या संरचित पाठ कहा जाता है)

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

उन दो तुम दक्षता आप के लिए मांग कर रहे हैं दे देंगे, तो आप पूरी तरह से के बारे में एसटीएल/LAD/FBD (जब अन्य लोगों के कोड का विश्लेषण करने को छोड़कर) भूल सकता है। संयुक्त, वे पीएलसी प्रोग्रामिंग के लिए बहुत शक्तिशाली और आरएडी उपकरण हैं।