Overclocking .NET

.Net का उपयोग प्रोग्रामिंग डेस्कटॉप और वेब अनुप्रयोगों के लिए किया जाता है, और क्या औद्योगिक सुविधाओं के प्रबंधन के लिए ढांचे का उपयोग करना संभव है?

आइए हम शुरुआत में जांच करें कि इस तरह के सॉफ़्टवेयर का उपयोग करना कहाँ संभव है।

औद्योगिक नियंत्रण प्रणाली में कई स्तर होते हैं:

• सेंसर स्तर
• नियंत्रण स्तर (पीएलसी, कंप्यूटर)
• विज़ुअलाइज़ेशन स्तर / SCADA

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

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

रियल-टाइम सिस्टम के लिए एक वास्तविक समय ओएस की आवश्यकता होती है। ऐसे ओएस में, कार्यों के संदर्भ को स्विच करने का समय, अर्थात। एक ही प्राथमिकता के साथ प्रत्येक स्ट्रीम को संसाधित करने के लिए समय का टुकड़ा समान आवंटित किया जाता है।

और "डेस्कटॉप" ओएस का उपयोग करते समय क्या हो सकता है?



मैं विचार करना चाहता हूं कि विंडोज और .Net का उपयोग करके किस गति को प्राप्त किया जा सकता है। इस मामले में, उच्च प्रदर्शन के लिए बाधाएँ होंगी:

• समानांतर चलने वाली ओएस प्रक्रियाएं
• पृष्ठभूमि सेवाएं
• .NET अनुप्रयोग कचरा कलेक्टर
• प्रबंधित कोड निष्पादित करते समय जाँच करता है

हम कार्य सेट करते हैं: FTDI नियंत्रक पर आधारित विंडोज XP + USB-COM एडाप्टर के साथ एक पीसी है। किस गति पर एडेप्टर के आरटीएस आउटपुट को स्विच करना संभव है ताकि एक स्थिर मेयर (पल्स रिपीटीशन अवधि को बदले बिना) प्राप्त किया जा सके? पीसी पर एक कार्यक्रम के साथ बाहरी उपकरणों के प्रबंधन के लिए ऐसा कार्य सबसे सरल विकल्प है।

कार्यक्रम के प्रदर्शन को वास्तविक समय मोड में अनुमानित करने के लिए, हम कार्यक्रम की प्राथमिकता और काम के प्रवाह को बढ़ाने का उपयोग करते हैं।

विंडोज टास्क शेड्यूलर थ्योरी का एक सा

कुल 32 प्राथमिकता स्तर हैं:

• 0 सिस्टम स्तर "शून्य पृष्ठ थ्रेड"
• 1-15 चर स्तर
• 16-31 वास्तविक समय स्तर

बदलती प्राथमिकताओं की श्रेणी में, कक्षाओं को अतिरिक्त रूप से प्रतिष्ठित किया जाता है:

• निष्क्रिय (2-6)
• नीचे सामान्य (4-8)
• सामान्य (6-10)
• सामान्य से ऊपर (8-12)
• उच्च (11-15)
• वास्तविक समय (22-26)

प्रत्येक प्रक्रिया (CreateProcess ()) बनाते समय, आप प्राथमिकता वर्ग निर्धारित कर सकते हैं; यदि यह निर्दिष्ट नहीं है, तो प्रक्रिया सामान्य (स्तर 8) की प्राथमिकता वर्ग प्राप्त करती है। प्रत्येक प्रक्रिया धागा को व्यक्तिगत रूप से एक प्राथमिकता स्तर सौंपा जा सकता है। धारा की अंतिम, बुनियादी, प्राथमिकता की गणना प्रक्रिया की प्राथमिकता के वर्ग के संयोजन और धारा की प्राथमिकता के स्तर से की जाती है। यदि किसी थ्रेड की मूल प्राथमिकता वास्तविक समय की प्राथमिकताओं (स्तर 16-31) के समूह से संबंधित है, तो यह गतिशील रूप से नहीं बदलता है, अन्यथा शेड्यूलर वर्तमान प्रोसेसर लोड और घटनाओं (यूआई, आई / ओ) के आधार पर थ्रेड्स की प्राथमिकता को थोड़ा बदल सकता है।

काम करने के लिए प्रत्येक थ्रेड के लिए समय की मात्रा एक प्रोसेसर के साथ सिस्टम के लिए 10ms है और सिस्टम मल्टीप्रेसर होने पर 15ms है। इसके अलावा, क्वांटम ओएस के प्रकार (नियमित या सर्वर ("लंबी क्वांटा" सर्वर में उपयोग किया जाता है)) पर निर्भर करता है, साथ ही आवेदन की स्थिति पर (यूआई थ्रेड और थ्रेड की प्राथमिकता इनपुट / आउटपुट डिवाइस के साथ काम करते समय अस्थायी रूप से जब इसी तरह की घटनाएं होती हैं)।

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

कार्यक्रम

using System;

using System.Collections. Generic ;

using System.Diagnostics;

using System.IO;

using System.IO.Ports;

using System.Threading;

using System.Windows.Forms;

using FTD2XX_NET;



private bool _exitThread;

private Thread _workThreadPort, _workThreadPortUnmanaged, _workThreadDriver;

private List < long > _durationsPort, _durationsPortUnmanaged, _durationsDriver;



public FormMain()

{

InitializeComponent();

//System.Diagnostics.Process.GetCurrentProcess().PriorityClass =

// ProcessPriorityClass.RealTime;

// SerialPort

_workThreadPort= new Thread(()=>

{

SerialPort port = new SerialPort( "COM5" );

port.BaudRate = 115200;

port.StopBits = StopBits.One;

port.Parity = Parity.None;

port.DataBits = 7;

port.Handshake = Handshake.None;

port.Open();

bool flag= false ;

Stopwatch stopwatch = new Stopwatch();

stopwatch.Start();

//Thread.CurrentThread.Priority = ThreadPriority.Highest;

while (!_exitThread)

{

_durationsPort.Add(stopwatch.ElapsedMilliseconds);

stopwatch.Reset();

stopwatch.Start();

port.RtsEnable = flag;

flag = !flag;

}

port.Close();

});

// (Win API)

_workThreadPortUnmanaged = new Thread(() =>

{

UnmanagedSerialPort unmanagedSerialPort = new UnmanagedSerialPort( "COM5" );

unmanagedSerialPort.Open();

bool flag= false ;

Stopwatch stopwatch = new Stopwatch();

stopwatch.Start();

//Thread.CurrentThread.Priority = ThreadPriority.Highest;

while (!_exitThread)

{

_durationsPortUnmanaged.Add(stopwatch.ElapsedMilliseconds);

stopwatch.Reset();

stopwatch.Start();

if (flag)

{

unmanagedSerialPort.On();

}

else

{

unmanagedSerialPort.Off();

}

flag = !flag;

}

unmanagedSerialPort.Close();

});

// API FTDI

_workThreadDriver= new Thread(()=>

{

FTDI myFtdiDevice = new FTDI();

myFtdiDevice.OpenByIndex(0);

bool flag= false ;

Stopwatch stopwatch = new Stopwatch();

stopwatch.Start();

//Thread.CurrentThread.Priority = ThreadPriority.Highest;

while (!_exitThread)

{

FTDI.FT_STATUS ftStatus = myFtdiDevice.SetRTS(flag);

if (ftStatus == FTDI.FT_STATUS.FT_OK)

{

flag = !flag;

_durationsDriver.Add(stopwatch.ElapsedMilliseconds);

stopwatch.Reset();

stopwatch.Start();

}

}

myFtdiDevice.Close();

});

_durationsDriver = new List < long >();

_durationsPort = new List < long >();

_durationsPortUnmanaged = new List < long >();

}



//

private void b_Save_Click( object sender, EventArgs e)

{

StreamWriter sw = new StreamWriter( "Port.csv" );

_durationsPort.ForEach(l => sw.WriteLine(l));

sw.Close();

sw = new StreamWriter( "Driver.csv" );

_durationsDriver.ForEach(l => sw.WriteLine(l));

sw.Close();

sw = new StreamWriter( "PortUnmanaged.csv" );

_durationsPortUnmanaged.ForEach(l => sw.WriteLine(l));

sw.Close();

}



private void b_RunViaPort_Click( object sender, EventArgs e)

{

_exitThread = false ;

_workThreadPort.Start();

}



private void b_Stop_Click( object sender, EventArgs e)

{

_exitThread = true ;

}



private void b_RunViaPortUnmanaged_Click( object sender, EventArgs e)

{

_exitThread = false ;

_workThreadPortUnmanaged.Start();

}



private void b_RunViaDriver_Click( object sender, EventArgs e)

{

_exitThread = false ;

_workThreadDriver.Start();

}



* This source code was highlighted with Source Code Highlighter .

पोर्ट के साथ काम करने के 3 विकल्पों पर विचार करें:

• वर्ग SerialPort
• अनवांटेड कोड (Win API: GetCommState, EscapeCommFunction, SetCommState)
• पुस्तकालय FTDI द्वारा आपूर्ति की

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

परीक्षण की स्थिति: प्रत्येक विकल्प को 30 एस के लिए जांचा जाता है, 10 एस के बाद प्रोसेसर को 10 एस (विनरार - हार्डवेयर प्रदर्शन परीक्षण) के लिए एक अतिरिक्त आवेदन के साथ लोड किया जाता है। प्रत्येक विकल्प स्ट्रीम (ब्लू ग्राफ) की सामान्य (स्तर 8) प्राथमिकता और वास्तविक समय (स्तर 24, लाल ग्राफ) के साथ जांच की जाती है।

परिणाम

क्लास का सीरियलपोर्ट



अप्रबंधित कोड और FTDI लाइब्रेरी



ग्राफ़ दिखाते हैं कि जब मानक सीरियलपोर्ट क्लास के माध्यम से काम करते हैं, तो "गैर-मानक" समाधान के माध्यम से काम करते समय चक्र समय लगभग 5 गुना अधिक होता है। धारा की प्राथमिकता बढ़ने से एक चक्र का समय 2ms तक कम हो जाता है, ऐसी धारा बाधित नहीं होती है।

निष्कर्ष

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

लेख का उद्देश्य दूसरी बाइक बनाना नहीं है, यह स्पष्ट है कि आप तकनीकी प्रक्रियाओं को नियंत्रित करने के लिए पीएलसी या माइक्रोकंट्रोलर के बिना नहीं कर सकते हैं; मैं यह दिखाना चाहता हूं कि .NET के लिए समस्याओं की एक निश्चित सीमा को हल करने में आवेदन प्राप्त करना संभव है, जहां प्रभाव के लिए सिस्टम की आवश्यक न्यूनतम प्रतिक्रिया समय 2-15ms से अधिक है।

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



Update1

संदर्भ

वास्तविक समय के लिए सी # - एक लेख जिसने मुझे इस विषय पर धकेल दिया

रीयल-टाइम .NET फ्रेमवर्क के लिए आवश्यकताएँ - यह आलेख जावा रीयल-टाइम की तुलना के आधार पर .NET RT को लागू करने के लिए आवश्यक सिद्धांतों का वर्णन करता है।

जावा में वास्तविक समय जीसी - संरक्षण के लिए धन्यवाद

Thread.Sleep (0) और Thread.Sleep (1) की तुलना: यहाँ और यहाँ - Frozik और tangro के लिए धन्यवाद