<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>automatika protokoli Archives - Automatika.rs</title>
	<atom:link href="https://www.automatika.rs/tag/automatika-protokoli/feed" rel="self" type="application/rss+xml" />
	<link>https://www.automatika.rs/tag/automatika-protokoli</link>
	<description>Portal za inženjere</description>
	<lastBuildDate>Thu, 21 Dec 2017 09:40:47 +0000</lastBuildDate>
	<language>en-US</language>
	<sy:updatePeriod>
	hourly	</sy:updatePeriod>
	<sy:updateFrequency>
	1	</sy:updateFrequency>
	<generator>https://wordpress.org/?v=6.9</generator>
	<item>
		<title>Profibus DP protokol &#8211; Povezivanje, komunikacija i mreža</title>
		<link>https://www.automatika.rs/baza-znanja/obrada-signala/profibus-dp-protokol-povezivanje-komunikacija-i-mreza.html</link>
					<comments>https://www.automatika.rs/baza-znanja/obrada-signala/profibus-dp-protokol-povezivanje-komunikacija-i-mreza.html#respond</comments>
		
		<dc:creator><![CDATA[Marko Nikolić]]></dc:creator>
		<pubDate>Fri, 22 Dec 2017 00:00:53 +0000</pubDate>
				<category><![CDATA[Obrada signala]]></category>
		<category><![CDATA[automatika protokoli]]></category>
		<category><![CDATA[komunikacijski protkoli]]></category>
		<category><![CDATA[plc program]]></category>
		<category><![CDATA[profibus]]></category>
		<category><![CDATA[profibus dp]]></category>
		<category><![CDATA[profibus komunikacija]]></category>
		<category><![CDATA[profibus protokol]]></category>
		<category><![CDATA[serijska komunikacija]]></category>
		<guid isPermaLink="false">https://www.automatika.rs/?p=9446</guid>

					<description><![CDATA[<p> Kao što je pre spomenuto, PROFIBUS DP protokol je specijalno projektovan da zadovolji potrebe brze komunikacije između distribuiranih periferija u automatizovanim postrojenjima industrije.  Fizički medijum za PROFIBUS DP zasniva se na RS-485 standardu koji definiše upotrebu oklopljenog, uvijenog, dvožilnog kabla, koji je prikazan na slici br.1. Mogu se odabrati brzine prenosa u opsegu od 9.6Kbit/s do [&#8230;]</p>
<p>The post <a href="https://www.automatika.rs/baza-znanja/obrada-signala/profibus-dp-protokol-povezivanje-komunikacija-i-mreza.html">Profibus DP protokol &#8211; Povezivanje, komunikacija i mreža</a> appeared first on <a href="https://www.automatika.rs">Automatika.rs</a>.</p>
]]></description>
										<content:encoded><![CDATA[<p style="text-align: justify"> Kao što je pre spomenuto, <a href="https://www.automatika.rs/baza-znanja/obrada-signala/profibus-dp-komunikacioni-protokol-dp-v0-protokol.html" target="_blank" rel="noopener noreferrer">PROFIBUS DP protokol</a> je specijalno projektovan da zadovolji potrebe brze komunikacije između distribuiranih periferija u automatizovanim postrojenjima industrije.</p>
<p style="text-align: justify"> Fizički medijum za PROFIBUS DP zasniva se na RS-485 standardu koji definiše upotrebu oklopljenog, uvijenog, dvožilnog kabla, koji je prikazan na slici br.1. Mogu se odabrati brzine prenosa u opsegu od 9.6Kbit/s do 12Mbit/s, pri čemu se ta brzina odnosi na sve uređaje koji su priključeni na magistralu.</p>
<p style="text-align: justify"><img decoding="async" class="size-full wp-image-9449 aligncenter" src="https://www.automatika.rs/wp-content/uploads/2017/12/profibus_protokol_serijska_komunikacija_dp_protokol_automatizacija_plc_programiranje_mreze_automatika.rs_.jpg" alt="" width="425" height="26" srcset="https://www.automatika.rs/wp-content/uploads/2017/12/profibus_protokol_serijska_komunikacija_dp_protokol_automatizacija_plc_programiranje_mreze_automatika.rs_.jpg 425w, https://www.automatika.rs/wp-content/uploads/2017/12/profibus_protokol_serijska_komunikacija_dp_protokol_automatizacija_plc_programiranje_mreze_automatika.rs_-300x18.jpg 300w" sizes="(max-width: 425px) 100vw, 425px" /></p>
<p style="text-align: center">Slika br.1  Bakarni kabl za PROFIBUS komunikaciju</p>
<p style="text-align: justify"> Povezivanje uređaja na PROFIBUS mrežu omogućeno je korišćenjem 9-pinskog sub-D konektora (slika br.2). U konektore su ugrađeni otpornici za terminaciju bus-a. Pomeranjem prekidača koji se nalazi na kućištu konektora u ON položaj vrši se terminacija.</p>
<p style="text-align: center"><img fetchpriority="high" decoding="async" class="size-full wp-image-9450 aligncenter" src="https://www.automatika.rs/wp-content/uploads/2017/12/1_profibus_protokol_serijska_komunikacija_dp_protokol_automatizacija_plc_programiranje_mreze_automatika.rs_.jpg" alt="" width="600" height="211" srcset="https://www.automatika.rs/wp-content/uploads/2017/12/1_profibus_protokol_serijska_komunikacija_dp_protokol_automatizacija_plc_programiranje_mreze_automatika.rs_.jpg 600w, https://www.automatika.rs/wp-content/uploads/2017/12/1_profibus_protokol_serijska_komunikacija_dp_protokol_automatizacija_plc_programiranje_mreze_automatika.rs_-300x106.jpg 300w" sizes="(max-width: 600px) 100vw, 600px" />Slika br.2 Izgled 9-pinskog sub-D konektora (levo-prolazni, desno-standardni konektor)<br />
i otpornici za terminaciju bus-a</p>
<p style="text-align: justify"> Kao što je na slici br.2 prikazano, terminacija bus-a je ostvarena korišćenjem tzv. &#8221;pull-down&#8221; otpornika prema DGND potencijalu i &#8221;pull-up&#8221; otpornika prema napajanju -Vp potencijal. Ova dva otpornika služe za definiciju potencijala na bus-u između dva telegrama. Linija A i linija B predstavljaju oznake krajeva PROFIBUS kabla.</p>
<p style="text-align: center"><img decoding="async" class="size-full wp-image-9451 aligncenter" src="https://www.automatika.rs/wp-content/uploads/2017/12/2_profibus_protokol_serijska_komunikacija_dp_protokol_automatizacija_plc_programiranje_mreze_automatika.rs_.jpg" alt="" width="600" height="302" srcset="https://www.automatika.rs/wp-content/uploads/2017/12/2_profibus_protokol_serijska_komunikacija_dp_protokol_automatizacija_plc_programiranje_mreze_automatika.rs_.jpg 600w, https://www.automatika.rs/wp-content/uploads/2017/12/2_profibus_protokol_serijska_komunikacija_dp_protokol_automatizacija_plc_programiranje_mreze_automatika.rs_-300x151.jpg 300w" sizes="(max-width: 600px) 100vw, 600px" />Tabela 1: Raspored pinova na 9-pinskom sub-D konektoru</p>
<p style="text-align: justify"> RS 485 tehnologija prenosa se odlikuje jednostavnošću i niskom cenom, a primenjuje se u sistemima gde se zahteva velika brzina prenosa. Moguće brzine prenosa su između 9.6 kbit/s i 12Mbit/s . Maksimalan broj uređaja koji se može povezati na jedan segment linije je 32. Veći broj uređaja zahteva korišćenje repetitora između pojedinačnih segmenata. Maksimalna dozvoljena dužina linije unutar jednog segmenata zavisi od brzine prenosa i manja je što je brzina prenosa veća.</p>
<h3 style="text-align: justify">Topologija mreže</h3>
<p>Osnovni elementi, koji pored kablovske veze, sačinjavaju mrežu mogu se podeliti u dve osnovne grupe:</p>
<ul>
<li>Master uređaji</li>
<li>Slave uređaji</li>
</ul>
<p style="text-align: justify"> S obzirom da je RS485 komunikacija half duplex (označava dvosmernu komunikaciju u kojoj jedan čvor-uređaj trenutno priča). Iz tog razloga je mreža organizovana tako da master ima kontreolu nad njom. Primer master uređaja može biti PLC, a kao primer slave elementa može se uzeti distribuirana periferija, drugi PLC i slično. Kod PA mreže slave uređaji mogu biti senzori, aktuatori i sl.</p>
<p style="text-align: justify"> Ovde se mora napomenuti da postoje dve vrste DP Master uređaja:</p>
<ul>
<li style="text-align: justify"><strong>DP Master Class 1 (DPM1)</strong> &#8211; ovo je centralni kontroler koji ciklično razmenjuje podatke sa slave uređajima, u zadatom ciklusu. Tipični uređaji ovog tipa su programabilni logički kontroleri. DPM1 ima aktivni pristup magistrali, preko kojeg može vršiti očitavanja ulaza sa distribuiranih uređaja, kao i zapisivanje odgovarajućih rezultata na njihove izlaze.</li>
<li style="text-align: justify"><strong>DP Master Class 2 (DPM2)</strong> &#8211; služi za konfigurisanje, sakupljanje podataka, kao i održavanje dijagnostiku i upravljanje priključenih uređaja, kao na primer PC.</li>
</ul>
<p style="text-align: justify"> Tipična DP konfiguracija ima mono-master strukturu što se može videti na slici br.3.</p>
<p style="text-align: center"><img loading="lazy" decoding="async" class="size-full wp-image-9452 aligncenter" src="https://www.automatika.rs/wp-content/uploads/2017/12/3_profibus_protokol_serijska_komunikacija_dp_protokol_automatizacija_plc_programiranje_mreze_automatika.rs_.jpg" alt="" width="348" height="367" srcset="https://www.automatika.rs/wp-content/uploads/2017/12/3_profibus_protokol_serijska_komunikacija_dp_protokol_automatizacija_plc_programiranje_mreze_automatika.rs_.jpg 348w, https://www.automatika.rs/wp-content/uploads/2017/12/3_profibus_protokol_serijska_komunikacija_dp_protokol_automatizacija_plc_programiranje_mreze_automatika.rs_-284x300.jpg 284w" sizes="auto, (max-width: 348px) 100vw, 348px" />Slika br.3 DP mono-master struktura</p>
<p style="text-align: justify"> Komunikacija između DP master i DP slave uređaja je bazirana na master-slave principu. Ovo znači da DP slave uređaji mogu biti aktivni na magistrali samo onda kada je to zahtevano od strane master-a. Komunikacija se odvija ciklično u tačno određenom vremenu. DP slave uređaji su adresirani u rastućem redosledu od DP master-a preko liste poziva (polling list). Slika br.4 pokazuje kao se lista poziva obrađuje na DP master-u. Vidi se ciklično procesiranje slave uređaja slanjem zahteva i dobijanjem odgovora od njih.</p>
<p style="text-align: center"><img loading="lazy" decoding="async" class="size-full wp-image-9453 aligncenter" src="https://www.automatika.rs/wp-content/uploads/2017/12/4_profibus_protokol_serijska_komunikacija_dp_protokol_automatizacija_plc_programiranje_mreze_automatika.rs_.jpg" alt="" width="465" height="401" srcset="https://www.automatika.rs/wp-content/uploads/2017/12/4_profibus_protokol_serijska_komunikacija_dp_protokol_automatizacija_plc_programiranje_mreze_automatika.rs_.jpg 465w, https://www.automatika.rs/wp-content/uploads/2017/12/4_profibus_protokol_serijska_komunikacija_dp_protokol_automatizacija_plc_programiranje_mreze_automatika.rs_-300x259.jpg 300w" sizes="auto, (max-width: 465px) 100vw, 465px" />Slika br.4 Obrada liste poziva na DP master uređaju</p>
<p style="text-align: justify"> DP sistem može imati i multi-master strukturu što je prikazano na slici br.5:</p>
<p style="text-align: center"><img loading="lazy" decoding="async" class="size-full wp-image-9454 aligncenter" src="https://www.automatika.rs/wp-content/uploads/2017/12/5_profibus_protokol_serijska_komunikacija_dp_protokol_automatizacija_plc_programiranje_mreze_automatika.rs_.jpg" alt="" width="666" height="437" srcset="https://www.automatika.rs/wp-content/uploads/2017/12/5_profibus_protokol_serijska_komunikacija_dp_protokol_automatizacija_plc_programiranje_mreze_automatika.rs_.jpg 666w, https://www.automatika.rs/wp-content/uploads/2017/12/5_profibus_protokol_serijska_komunikacija_dp_protokol_automatizacija_plc_programiranje_mreze_automatika.rs_-300x197.jpg 300w, https://www.automatika.rs/wp-content/uploads/2017/12/5_profibus_protokol_serijska_komunikacija_dp_protokol_automatizacija_plc_programiranje_mreze_automatika.rs_-640x420.jpg 640w" sizes="auto, (max-width: 666px) 100vw, 666px" />Slika br.5 DP multi-master struktura</p>
<p style="text-align: justify"> Ovo podrazumeva da nekoliko DP master uređaja može biti povezano na jednu magistralu. Kod ove strukture master uređaji pristupaju magistrali u skladu sa rastućim vrednostima svojih adresa. Ukoliko je završena komunikacija jednog mastera, on daje znak sledećem da može da pristupi magistrali, odnosno da koristi resurse. U PROFIBUS terminologiji se to naziva &#8221;token ring&#8221;. Da bi se ovakva procedura izvršila, pri inicijalizaciji mreže detektuje se broj mastera kojima se dodeljuju sledeće adrese: PS (Previous Station) &#8211; predhodna stanica i NS (Next Station) &#8211; sledeća stanica.</p>
<p style="text-align: justify"><em>Dalja upustva i pojašnjenja pojmova možete prinaći u sledećoj literaturi: Realizacija elektromotornog pogona primenom PROFIBUS i USS komunikacije, autor: Milorad Kaplarević</em></p>
<p>The post <a href="https://www.automatika.rs/baza-znanja/obrada-signala/profibus-dp-protokol-povezivanje-komunikacija-i-mreza.html">Profibus DP protokol &#8211; Povezivanje, komunikacija i mreža</a> appeared first on <a href="https://www.automatika.rs">Automatika.rs</a>.</p>
]]></content:encoded>
					
					<wfw:commentRss>https://www.automatika.rs/baza-znanja/obrada-signala/profibus-dp-protokol-povezivanje-komunikacija-i-mreza.html/feed</wfw:commentRss>
			<slash:comments>0</slash:comments>
		
		
			</item>
		<item>
		<title>TTCAN protokol &#8211; Formiranje čvorova, sinhoronizacija i implementacija</title>
		<link>https://www.automatika.rs/baza-znanja/obrada-signala/ttcan-protokol-formiranje-cvorova-sinhoronizacija-i-implementacija.html</link>
					<comments>https://www.automatika.rs/baza-znanja/obrada-signala/ttcan-protokol-formiranje-cvorova-sinhoronizacija-i-implementacija.html#respond</comments>
		
		<dc:creator><![CDATA[Marko Nikolić]]></dc:creator>
		<pubDate>Fri, 26 May 2017 00:00:20 +0000</pubDate>
				<category><![CDATA[Obrada signala]]></category>
		<category><![CDATA[automatika protokoli]]></category>
		<category><![CDATA[automatizacija]]></category>
		<category><![CDATA[can protokol]]></category>
		<category><![CDATA[industrijski protokoli]]></category>
		<category><![CDATA[ttcan protokol]]></category>
		<category><![CDATA[visi can protokoli]]></category>
		<guid isPermaLink="false">https://www.automatika.rs/?p=8459</guid>

					<description><![CDATA[<p> Da podsetimo, TTCAN (time – triggered communication on CAN) je viši CAN protokol koji obezbeđuje sinhronizaciju svih čvorova na mreži, kao i planiranje i realizaciju vremenski determinisanog rasporeda prenosa poruka (time triggered – TT). Osnovno o TTCAN protokolu možete pronaći OVDE. Formiranje osnovne jedinice za merenje vremena na TTCAN mreži  Izvršavanje osnovnog ciklusa na mreži [&#8230;]</p>
<p>The post <a href="https://www.automatika.rs/baza-znanja/obrada-signala/ttcan-protokol-formiranje-cvorova-sinhoronizacija-i-implementacija.html">TTCAN protokol &#8211; Formiranje čvorova, sinhoronizacija i implementacija</a> appeared first on <a href="https://www.automatika.rs">Automatika.rs</a>.</p>
]]></description>
										<content:encoded><![CDATA[<p style="text-align: justify"> Da podsetimo, TTCAN (time – triggered communication on CAN) je viši CAN protokol koji obezbeđuje sinhronizaciju svih čvorova na mreži, kao i planiranje i realizaciju vremenski determinisanog rasporeda prenosa poruka (time triggered – TT). Osnovno o TTCAN protokolu možete pronaći <a href="https://www.automatika.rs/baza-znanja/obrada-signala/ttcan-visi-can-protokol.html" target="_blank" rel="noopener noreferrer">OVDE</a>.</p>
<h3 style="text-align: justify">Formiranje osnovne jedinice za merenje vremena na TTCAN mreži</h3>
<p style="text-align: justify"> Izvršavanje osnovnog ciklusa na mreži je u svakom čvoru kontrolisano preko tzv. ciklusnog vremena (cycle time). Ciklusno vreme garantuje TT rad ovog protokola. Brojač koji meri ovo vreme se restartuje nakon svakog završetka osnovnog ciklusa. Rezolucija sa kojom se može iskazati ciklusno vreme je tzv. mrežna vremenska jedinica (network time unit – NTU). U osnovnoj verziji TTCAN protokola, NTU je jednak nominalnom vremenskom intervalu trajanja jednog bita i fiksnog je trajanja.</p>
<p style="text-align: justify"> U proširenoj verziji TTCAN potokola, NTU se dobija deljenjem vremenskog intervala trajanja sistemskog takta definisanog učestanošću oscilatornog kola konkertnog čvora sa odgovarajućim koeficijentom (time unit ratio – TUR). U tom slučaju se NTU izražava u sekundama. Koeficijent TUR nije fiksan već se neprekidno koriguje u toku rada, a sve u cilju postizanja što bolje usklađenosti između globalnog i ciklusnog vremena. Mehanizam za korekciju vrednosti TUR je relativno složen i njegovo izlaganje bi prevazišlo okvire ovog kratkog pregleda TTCAN protokola. Dovoljno je samo reći da se u tom procesu koristi informacija o vrednosti globalnog vremena koja je u proširenom TTCAN protokolu dostupna kroz polje podataka referentne poruke. Opisani postupak izračunavanja mrežne vremenske jedinice i ciklusnog vremena za slučaj proširenog TTCAN protokola je prikazan na slici br.1.</p>
<p style="text-align: center"><img loading="lazy" decoding="async" class="aligncenter size-full wp-image-8462" src="https://www.automatika.rs/wp-content/uploads/2017/05/can_protokol_ttcan_protokoli_automatika_protokoli_industrijski_protokoli_automatika.rs_.jpg" alt="" width="666" height="436" srcset="https://www.automatika.rs/wp-content/uploads/2017/05/can_protokol_ttcan_protokoli_automatika_protokoli_industrijski_protokoli_automatika.rs_.jpg 666w, https://www.automatika.rs/wp-content/uploads/2017/05/can_protokol_ttcan_protokoli_automatika_protokoli_industrijski_protokoli_automatika.rs_-300x196.jpg 300w, https://www.automatika.rs/wp-content/uploads/2017/05/can_protokol_ttcan_protokoli_automatika_protokoli_industrijski_protokoli_automatika.rs_-642x420.jpg 642w" sizes="auto, (max-width: 666px) 100vw, 666px" />Slika br.1 Generisanje NTU</p>
<h3 style="text-align: justify">Sinhronizacija rada čvorova na mreži</h3>
<p style="text-align: justify"> Sinhronizacija svih čvorova, uključujući i vremenski master, se obavlja na isti način. Međutim, sam način kako se to izvodi zavisi od toga da li je na konkretnoj mreži implementirana osnovna ili proširena verzija TTCAN protokola. Način sinhronizacije u slučaju osnovne verzije TTCAN protokola ilustrovan je na slici br.2</p>
<p style="text-align: center"><img loading="lazy" decoding="async" class="aligncenter size-full wp-image-8461" src="https://www.automatika.rs/wp-content/uploads/2017/05/3_can_protokol_ttcan_protokoli_automatika_protokoli_industrijski_protokoli_automatika.rs_.jpg" alt="" width="422" height="370" srcset="https://www.automatika.rs/wp-content/uploads/2017/05/3_can_protokol_ttcan_protokoli_automatika_protokoli_industrijski_protokoli_automatika.rs_.jpg 422w, https://www.automatika.rs/wp-content/uploads/2017/05/3_can_protokol_ttcan_protokoli_automatika_protokoli_industrijski_protokoli_automatika.rs_-300x263.jpg 300w" sizes="auto, (max-width: 422px) 100vw, 422px" />Slika br.2 Sinhronizacija ciklusnog vremena (osnovna verzija TTCAN protokola)</p>
<p style="text-align: justify"> Kao što se sa slike može videti, SOF bit svake poruke uzrokuje da se podatak o lokalnom vremenu upiše u lokalni registar svakog čvora označen na slici sa Sync_Mark. Nakon toga, svaki čvor ispituje da li se radi o refentnoj poruci. Ako je to slučaj, sadržaj Sync_Mark registra se prepiše u Ref_Mark registar, i automatski oduzme od vrednosti lokalnog vremena formirajući na taj način podatak o ciklusnom vremenu. Dakle u tom trenutku, ciklusno vreme će biti jednako vremenskom intervalu koji je protekao od trenutka detektovanje prvog bita referente poruke, i nastaviće da se menja na dalje u skladu sa lokalnim vremenom sinhronišući tako sve aktivnosti na čvoru. Tačnost sinhronizacije u ovom slučaju je zavisna od brzine prenosa na mreži i tipično je na nivou trajanja jednog bita CAN poruke.</p>
<p style="text-align: justify"> Sinhronizacija rada čvorova na mreži sa proširenim TTCAN prokolom je bazirana na tzv. globalnom vremenu (global time). Postupak proračuna globalnog vremena je ilustrovan na slici br.3, i biće u najkraćim crtama opisan u daljem tekstu.</p>
<p style="text-align: center"><img loading="lazy" decoding="async" class="aligncenter size-full wp-image-8460" src="https://www.automatika.rs/wp-content/uploads/2017/05/2_can_protokol_ttcan_protokoli_automatika_protokoli_industrijski_protokoli_automatika.rs_.jpg" alt="" width="412" height="404" srcset="https://www.automatika.rs/wp-content/uploads/2017/05/2_can_protokol_ttcan_protokoli_automatika_protokoli_industrijski_protokoli_automatika.rs_.jpg 412w, https://www.automatika.rs/wp-content/uploads/2017/05/2_can_protokol_ttcan_protokoli_automatika_protokoli_industrijski_protokoli_automatika.rs_-300x294.jpg 300w" sizes="auto, (max-width: 412px) 100vw, 412px" />Slika br.3 Računanje globalnog vremena (proširena verzija TTCAN protokola)</p>
<p style="text-align: justify"> Vremenski master u okviru polja za podatke referentne poruke šalje svoju (po definiciji ispravnu) vrednost globalnog vremena. To je najčešće vrednost vremenskog trenutka kada vremenski master odašilje prvi SOF bit svoje poruke. Svaki čvor, kada detektuje da se radi o referentnoj poruci prihata taj podatak i na osnovu njega formira tzv. lokalni offset, kao razliku globalnog vremena vremenskog mastera i vrednosti lokalnog vremena kada je prihvaćen prvi bit referentne poruke. Tokom narednog osnovnog ciklusa svaki čvor koriguje vrednost lokalnog vremena lokalnim ofsetom i tako formira svoje globalno vreme. Na ovaj način se nezavisno od brzine prenosa poruka na mreži, može postići tačnost sihronizacije od 1μs što tipično zadovoljava i najstrože zahteve proizvođača vozila. Treba konstatovati da vremeski master podatak o globalnom vremenu može dobijati i od nekog eksternog izvora, pa se u tom smislu veoma često koristi GPS sistem.</p>
<h3 style="text-align: justify">Implementacija TTCAN protokola</h3>
<p style="text-align: justify"> Nakon što je podnet predlog za standardizaciju TTCAN protokola, nekoliko proizvođača je već realizovalo čipove koji implementiraju ovaj protokol. Paralelno sa tim razvijaju se i softverski alati, koji se delom preuzimaju od osnovnog CAN sistema, a delom razvijaju specijalno za TTCAN primenu.</p>
<p style="text-align: justify"> Firma Bosch je implementirala TTCAN protokol u FPGA kolu, da bi ubrzo proizvela i stand-alone kontroler koji podržava i osnovni i prošireni TTCAN protokol, i pin kompatibilan je sa poznatijim CAN kontrolerima: Intelovim 82527 i Simensovim CC170.</p>
<p style="text-align: justify"> Ubrzo je i firma Atmel razvila svoj CAN kontoler koji u potpunosti podržava i TTCAN protokol. Razvojem i proizvodnjom sličnih čipova bave se i Motorola, NEC i drugi.</p>
<p style="text-align: justify"> Između ostаlog, prisutni su i pokušaji da se izvrši uključivanje karakteristika TTCAN protokola u trenutno znatno rasprostranjeniji CANopen protokol.</p>
<p>The post <a href="https://www.automatika.rs/baza-znanja/obrada-signala/ttcan-protokol-formiranje-cvorova-sinhoronizacija-i-implementacija.html">TTCAN protokol &#8211; Formiranje čvorova, sinhoronizacija i implementacija</a> appeared first on <a href="https://www.automatika.rs">Automatika.rs</a>.</p>
]]></content:encoded>
					
					<wfw:commentRss>https://www.automatika.rs/baza-znanja/obrada-signala/ttcan-protokol-formiranje-cvorova-sinhoronizacija-i-implementacija.html/feed</wfw:commentRss>
			<slash:comments>0</slash:comments>
		
		
			</item>
		<item>
		<title>CANopen &#8211; Viši CAN protokol</title>
		<link>https://www.automatika.rs/baza-znanja/obrada-signala/canopen-visi-can-protokol.html</link>
					<comments>https://www.automatika.rs/baza-znanja/obrada-signala/canopen-visi-can-protokol.html#respond</comments>
		
		<dc:creator><![CDATA[Marko Nikolić]]></dc:creator>
		<pubDate>Mon, 05 Dec 2016 07:22:48 +0000</pubDate>
				<category><![CDATA[Obrada signala]]></category>
		<category><![CDATA[automatika protokoli]]></category>
		<category><![CDATA[canopen]]></category>
		<category><![CDATA[canopen protokol]]></category>
		<category><![CDATA[divicenet]]></category>
		<category><![CDATA[industrijski protokoli]]></category>
		<guid isPermaLink="false">https://www.automatika.rs/?p=7384</guid>

					<description><![CDATA[<p>CANopen standard je rezultat razvojnog projekta finanasiranog od strane zemalja EU, i podržan je od strane organizacije CiA (CAN-in Automation). Iz tog razloga je ovaj standard daleko rasprostranjeniji u Evropi nego u Severnoj Americi i Aziji, gde se dominantno koristi  DeviceNet protokol.  CANopen je originalno razvijan za primenu u aplikacijama koje upravljaju kretanjem, tj. za [&#8230;]</p>
<p>The post <a href="https://www.automatika.rs/baza-znanja/obrada-signala/canopen-visi-can-protokol.html">CANopen &#8211; Viši CAN protokol</a> appeared first on <a href="https://www.automatika.rs">Automatika.rs</a>.</p>
]]></description>
										<content:encoded><![CDATA[<p style="text-align: justify"><strong>CANopen standard</strong> je rezultat razvojnog projekta finanasiranog od strane zemalja EU, i podržan je od strane organizacije CiA (CAN-in Automation). Iz tog razloga je ovaj standard daleko rasprostranjeniji u Evropi nego u Severnoj Americi i Aziji, gde se dominantno koristi  <a href="https://www.automatika.rs/baza-znanja/obrada-signala/devicenet-visi-can-protokol.html" target="_blank">DeviceNet protokol</a>.</p>
<p style="text-align: justify"> CANopen je originalno razvijan za primenu u aplikacijama koje upravljaju kretanjem, tj. za najkompleksniju oblast industrijske automatizacije. Tu su zahtevi veoma rigorozni: poruke moraju biti što kraće, sa visokim stepenom iskorišćenosti sadržaja poruke za prenos korisne informacije. Takođe, pouzdanost prenosa uz ispunjenje strogih vremenskih zahteva po pitanju odziva na zahtev za prenosom poruke, jasno su ukazivali da CAN protokol mora biti osnova na kojoj će biti razvijan ovaj viši protokol. Neke od ovih zahteva zadovoljavo je i bazični CAN protokol. Međutim, on je imao i mnogo ograničenja (npr. korisna informacija u komunikaciji između dva uređaja je limitirana na 8 bajtova), što je neizostavno zahtevalo razvoj nadređenog protokola koji koji bi u sebe uključio bazični CAN protokol.</p>
<p style="text-align: justify"> Ciljna grupa za primenu CANopen protokola su distribuirani sistemi sa lokalnom inteligencijom, dakle, ona ista oblast primene u kojoj su za sada dominantni fieldbus sistemi kao što je recimo Profibus. Međutim, prednosti CANopen protokola su jednostavnost realizacije, visoka pouzdanost i izuzetno kratko vreme reagovanja. Pored toga, CANopen ima veoma kratko vreme oporavka nakon detektovane greške u prenosu. Često se zbog toga kaže će da CANopen bazirana mreža pre detektovati grešku i ponovo poslati ispravnu poruku, nego što će TCP/IP bazirana mreža i detektovati da je nastupila greška u prenosu. CANopen protokol vrši segmentaciju velikih poruka u osmobajtne pakete i šalje ih, paket po paket, u okviru poruke dužine 111 bitova. To omogućava da poruka većeg prioriteta uvek prekine prenos velike poruke nakon što se prenos jednog paketa završi. Prenos preostalih paketa će biti nastavljen čim mreža ponovo postane slobodna. Nasuprot tome, TCP/IP protokol zahteva integritet i neprekidnost čak 1500 bajtova, što je krajnje nepovoljno za primenu u real time aplikacijama.</p>
<p style="text-align: justify"> Još jedna vrlo važnu osobina CANopen protokola, a koju poseduje i DeviceNet, je zamenljivost i međusobni rad proizvoda različitih proizvođača koji podržavaju CANopen protokol. O toj karakteristici ovog protokola će biti više reči kasnije.</p>
<p style="text-align: justify"> CANopen je otvoreni sistem, ne samo u smislu da nije vlasništvo nijednog većeg proizvo đača ili grupacije, već i u pogledu njegove fleksibilnosti. Naime, CANopen se može konfigurisati da podržava najrazličitije mrežne strukture i topologije. On čak omogućava međusobnu komunikaciju slave uređaja. Sve to je moguće zbog njegove jednostavnosti što prouzrokuje i male memorijske zahteve. Na primer, veličina koda za osmobitni mikrokontroler koji piše i čita osmobitne podatke preko CANopen mreže je manja od 5k bajtova.</p>
<p style="text-align: justify"> CANopen podržava dva puta više čvorova na mreži od DeviceNet-a, čak 127, dok je izbor mogućih brzina prenosa podataka daleko veći: 1 Mb/s, 800 kb/s, 500 kb/s, 250 kb/s, 125 kb/s, 50 kb/s, 20 kb/s i 10 kb/s.</p>
<h3 style="text-align: justify">Osnovna struktura CANopen protokola</h3>
<p style="text-align: justify"> Dva osnovna elementa u strukturi CANopen protokola su: komunikacioni profil (Communication profile) i profil uređaja (Device profile).</p>
<h3 style="text-align: justify">Profil uređaja</h3>
<p style="text-align: justify"> Koncept profila uređaja je uveden da bi bilo moguće umrežavanje uređaja različitih proizvođača bez potrebe za pisanjem specijalizovanog softvera za svaki pojedinačni uređaj. U tom cilju CiA je prezentovala precizno uputstva koja omogućavaju proizvođačima uređaja da realizuju svoje uređaje u skladu sa predefinisanim profilima. Tek za uređaje koji su u skladu sa predefinisanim profilima, CANopen može da garantuje osnovi set mrežnih funkcija. Da bi se omogućilo postizanje dodatnih funkcionalnosti, u okviru profila je određen i jedan opcioni deo u kome proizvođači mogu definisati dodatne karakteristike uređaja, opet na kontrolisan način. Kao pomoć proizvođačima, dostupan je veliki broj standardnih profila za različite tipove uređaja: I/O module, kontrolere, merne uređaje i sl.</p>
<p style="text-align: justify"> Ovi profili su implementirani u obliku standardizovane baze podataka koja se naziva rečnik objekata (object dictionary). Taj rečnik objekata je u obliku ASCII karaktera zapisan u fajl koji se najčešće susreće pod nazivom EDS (Electronic Data Shit). Uz pomoć specijalnog softverskog alata, ova baza se može konfigurisati prema željenom uređaju, nakon čega se dobija tzv. DCF (Device Configuration File). Važno je razumeti da ovaj fajl sa rečnikom objekata ne mora biti prisutan na uređaju, ali mora u procesu instalacije tog uređaja na mrežu biti dostupan master-u (aplikaciji) koji tu inicijalizaciju vrši, bilo preko CANopen mreže, bilo putem Interneta, ili na bilo koji drugi razumljiv način.</p>
<p><strong>CANopen </strong>rečnik objekata je tipično podeljen u 4 segmenta:</p>
<ul>
<li style="text-align: justify">Segment tipova podatak &#8211; u ovom segmentu je definisano koje sve tipove podataka podržava posmatrani uređaj; među njima mogu biti i tipovi podataka definisani od strane proizvođača.</li>
<li style="text-align: justify">Segment komunikacionog profila -u ovom segmenu se, pored podataka o tome koji se konkretni uređaj koristi, nalaze i neki osnovni podaci o samom uređaju; takođe, ovde je mapirano i koji je tip svake vrste poruke koju konkretni uređaj razmenjuje preko mreže.</li>
<li style="text-align: justify">Segment profila uređaja &#8211; ovaj segment predstavlja opis onih bazičnih osobina uređaja koji obezđuje da svi uređaji istog tipa, a od različitih proizvođača povezani na CANopen mrežu pokazuju isto bazično ponašanje.</li>
<li style="text-align: justify">Segment definisan od strane proizvođača &#8211; ovo je opcioni segmen u kome proizvođač može da definiše neke dodatne funkcionalnosti specifične za njegov uređaj, ali na unapred propisan način.</li>
</ul>
<h3 style="text-align: justify">Komunikacioni profil</h3>
<p style="text-align: justify"> Komunikacioni profil zahteva da na mreži mora postojati bar dva čvora od kojih u svakom trenutku bar jedan mora biti master a drugi slave. Za takvu mrežu, CANopen protokol definiše nekoliko metoda za prenos i prijem poruka preko CAN linija. Te poruke za nas predstavljaju tzv. komunikacione objekte. CANopen razlikuje sinhroni i asinhroni mehanizam prenosa podataka.</p>
<p style="text-align: justify"> Sinhroni prenos je podržan preko dva tipa poruka: predefinisanih poruka (Sync Object, Time Stamp Object i Emergency Object), kao i PDO tipa poruka. Ovaj mod omogućava uređaju na mreži da bude strogo sinhronizovan sa taktom master-a. To je izuzetno bitno u nekim primenama vezanim za kontrolu kretanja. U takvim aplikacijmama je upravljačka petlja najčešće zatvorena preko CANopen linije, što zahteva sinhronizovano uzorkovanje podataka. U ovom modu rada, na raspolaganju je nekoliko parametara koji ga mogu prilagoditi konkretnoj aplikaciji. Na primer, moguće je definisati da se odbirci nekog ulaznog signala uzimaju i proseđuju preko mreže svaki n-ti ciklus i sl.</p>
<p style="text-align: justify"> Asinhroni prenos je podržan preko tri tipa poruka: poruka za administriranje na mreži (Network administration message), SDO i PDO tipova poruka. Asinhroni prenos omogućava uređaju da automatski obavesti druge uređaje da se neki događaj ostvario, smanjujući na taj način vreme reagovanja. Ovaj mod rada omogućava redukovanje opterećenja mreže, kao i visoke performanse u komunikaciji uz relativno malu brzinu prenosa.</p>
<p style="text-align: justify"><img loading="lazy" decoding="async" class="aligncenter size-full wp-image-7388" src="https://www.automatika.rs/wp-content/uploads/2016/12/CPM-Support-Service_automatika_obrada_signala.jpg" alt="cpm-support-service_automatika_obrada_signala" width="500" height="322" srcset="https://www.automatika.rs/wp-content/uploads/2016/12/CPM-Support-Service_automatika_obrada_signala.jpg 500w, https://www.automatika.rs/wp-content/uploads/2016/12/CPM-Support-Service_automatika_obrada_signala-300x193.jpg 300w" sizes="auto, (max-width: 500px) 100vw, 500px" /></p>
<h3 style="text-align: justify">Tipovi komunikacionih objekata (tipovi poruka)</h3>
<p style="text-align: justify"> CANopen protokol pravi razliku između četiri osnovna tipa podataka (komunikacionih objekata):</p>
<ul>
<li style="text-align: justify">Poruke za administriranje na mreži (Layer Management (LM) i Network Management (NMT)) &#8211; ove poruke se koriste u svrhu kontrole uređaja na mreži; pod tim se podrazumeva dinamička distribucija identifikatora pojedinačnim uređajima, kontrolu stanja i komunikacionog moda jednog ili više čvorova na mreži, periodačan polling čvorova na mreži ne bi li se detektovao eventualni otkaz nekog od njih i sl.</li>
<li style="text-align: justify">Poruke sa servisnim podacima (Service Data Object (SDO)) &#8211; ove poruke se šalju asinhrono, i tipično se primenjuju u dva slučaja; prva primena je u procesu konfigurisanja uređaja na CANopen mrežu; pod tim se podrazumeva inicijalizacija parametara čvora, kao i učitavanje određenog programa u uređaj; druga primena SDO je za prenos poruka koje su veće od 8 bajtova u formi više CAN telegrama; zajednička osobina za obe primene SDO je da se radi o porukama relativno niskog prioriteta.</li>
<li style="text-align: justify">Poruke sa podacima procesa (Process Data Object (PDO)) &#8211; PDO se tipično koristi za poruke velike brzine i visokog prioriteta; podaci u PDO poruci su ograničeni na dužinu od 8 bajtova; format ovih poruka, kao i dužina i tip podataka koji se njima prenose se mogu konfigurisati korišćenjem SDO poruka; ovaj tip poruke se može odaslati od bilo kog čvora mreže ka jednom ili više drugih čvorova na mreži; PDO poruke se mogu prenositi i asinhronim i sinhronim mehanizmom; u slučaju asinhronog mehanizma, taj proces može biti iniciran bilo zahtevom od nekog drugog čvora (remote request), bilo određenim događajem na konkretnom uređaju.</li>
<li style="text-align: justify">Predefinisane poruke, kao što su Sync Object, Time Stamp Object i Emergency Object &#8211;  emergency message je poruka najvišeg prioriteta i rezervisana je da izvesti o havarijskom stanju na uređaju koji je odašilje; Sync Object predstavlja podršku za razvoj aplikacija u realnom vremenu.</li>
</ul>
<h3 style="text-align: justify">CANopen upravljanje mrežom – proces inicijalizacije</h3>
<p style="text-align: justify"> Za razliku od <a href="https://www.automatika.rs/baza-znanja/obrada-signala/devicenet-visi-can-protokol.html" target="_blank">DeviceNet protokola</a>, CANopen protokol ne koristi predefinisanu šemu za raspodelu identifikatora. Po priključenju na mrešu svaki uređaj dobija tzv. inicijalizacioni identifikator poruke koji je najčešće određen stanjem nekih DIP prekidača na samom uređaju. Nakon podizanja mreže, master najpre uspostavlja dijalog sa svakim pojedinačnim slave-om preko NMT servisa. Kada je veza uspostavljna, master najpre svakom od slave-ova prosleđuje identifikatore za njihove SDO-PDO poruke. Nakon toga master upisuje potrebni kod i inicijalizuje preostale parametre svakom od slave-ova. Ove operacije master realizuje preko svojih 5 različitih NMT poruka (Start_Remote_Node, Stop_Remote_Node, Enter_Pre-Operational _State, Reset_Node i Reset_Communication), a sa druge strane slave podržava preko svoje mašine stanja (state machine) sa 4 predefinisana stanja: Initialisation, Pre_Operational, Operational i Prepared.</p>
<p>The post <a href="https://www.automatika.rs/baza-znanja/obrada-signala/canopen-visi-can-protokol.html">CANopen &#8211; Viši CAN protokol</a> appeared first on <a href="https://www.automatika.rs">Automatika.rs</a>.</p>
]]></content:encoded>
					
					<wfw:commentRss>https://www.automatika.rs/baza-znanja/obrada-signala/canopen-visi-can-protokol.html/feed</wfw:commentRss>
			<slash:comments>0</slash:comments>
		
		
			</item>
		<item>
		<title>DeviceNet &#8211; Viši CAN protokol</title>
		<link>https://www.automatika.rs/baza-znanja/obrada-signala/devicenet-visi-can-protokol.html</link>
					<comments>https://www.automatika.rs/baza-znanja/obrada-signala/devicenet-visi-can-protokol.html#respond</comments>
		
		<dc:creator><![CDATA[Marko Nikolić]]></dc:creator>
		<pubDate>Tue, 18 Oct 2016 11:10:19 +0000</pubDate>
				<category><![CDATA[Obrada signala]]></category>
		<category><![CDATA[automatika protokoli]]></category>
		<category><![CDATA[can protokol]]></category>
		<category><![CDATA[cip model]]></category>
		<category><![CDATA[devicenet model]]></category>
		<category><![CDATA[industrijski protokoli]]></category>
		<guid isPermaLink="false">https://www.automatika.rs/?p=7271</guid>

					<description><![CDATA[<p>DeviceNet protokol je razvila kompanija Rockwell Automation za sopstvene potrebe. Kako se ovaj protokol pokazao veoma dobrim u praksi, posebno u oblasti industrijske automatizacije, ubrzo je formirana organizacija njegovih korisnika pod imenom Open DeviceNet Vendor Association (ODVA). Ona postaje odgovrna za specificiranje i održavanje DeviceNet standarda, kao i za njegovu svetsku promociju. To je otvoren protokol, [&#8230;]</p>
<p>The post <a href="https://www.automatika.rs/baza-znanja/obrada-signala/devicenet-visi-can-protokol.html">DeviceNet &#8211; Viši CAN protokol</a> appeared first on <a href="https://www.automatika.rs">Automatika.rs</a>.</p>
]]></description>
										<content:encoded><![CDATA[<p style="text-align: justify"><strong>DeviceNet</strong> protokol je razvila kompanija <strong>Rockwell Automation</strong> za sopstvene potrebe. Kako se ovaj protokol pokazao veoma dobrim u praksi, posebno u oblasti industrijske automatizacije, ubrzo je formirana organizacija njegovih korisnika pod imenom Open DeviceNet Vendor Association (ODVA). Ona postaje odgovrna za specificiranje i održavanje DeviceNet standarda, kao i za njegovu svetsku promociju. To je otvoren protokol, i svaki član ODVA može učestvovati u njegovom daljem razvoju u nekoj od interesnih grupa.</p>
<p style="text-align: justify"> DeviceNet je jedan od tri mrežna standarda (DeviceNet, ControlNet i Eternet/IP) koji koristi identičan aplikacijski sloj, tzv. <strong>Common Industrial Protocol (CIP)</strong>, što je prikazano na slici br.1.<img loading="lazy" decoding="async" class="aligncenter size-full wp-image-7276" src="https://www.automatika.rs/wp-content/uploads/2016/10/2_devicenet_cip_model_obrada_singala_protokoli_automatika.rs_.jpg" alt="2_devicenet_cip_model_obrada_singala_protokoli_automatika-rs" width="507" height="458" srcset="https://www.automatika.rs/wp-content/uploads/2016/10/2_devicenet_cip_model_obrada_singala_protokoli_automatika.rs_.jpg 507w, https://www.automatika.rs/wp-content/uploads/2016/10/2_devicenet_cip_model_obrada_singala_protokoli_automatika.rs_-300x271.jpg 300w, https://www.automatika.rs/wp-content/uploads/2016/10/2_devicenet_cip_model_obrada_singala_protokoli_automatika.rs_-465x420.jpg 465w" sizes="auto, (max-width: 507px) 100vw, 507px" />Slika br.1 CIP model</p>
<p style="text-align: justify"> <strong>CIP</strong> je strogo objektno orijentisan protokol. U skladu sa CIP protokolom, model jednog DeviceNet čvora je prikazan na slici br.2. Taj model uključuje nekoliko objekata. Neki od njih su zahtevani od strane DeviceNet-a, a neki od njih su definisani od strane proizvođaža DeviceNet opreme u cilju postizanja dodatnih funkcionalnosti. Svaki objekat ima svoje atribute, servise i ponašanje prema okruženju. Glavne karakteristike i namene objekata prikazanih na slici br.2 su date u Tabeli 1.</p>
<p style="text-align: center"><img loading="lazy" decoding="async" class="aligncenter size-full wp-image-7277" src="https://www.automatika.rs/wp-content/uploads/2016/10/3_devicenet_model_pic_devicenet_cip_model_obrada_singala_protokoli_automatika.rs_.gif" alt="3_devicenet_model_pic_devicenet_cip_model_obrada_singala_protokoli_automatika-rs" width="389" height="245" />Slika br.2 Modela DeviceNet objekta</p>
<p>Tabela 1: Opis funkcionalnosti objekata DeviceNet čvor</p>
<p><img loading="lazy" decoding="async" class="aligncenter size-full wp-image-7278" src="https://www.automatika.rs/wp-content/uploads/2016/10/Tabela_devicenet_cip_model_obrada_singala_protokoli_automatika.rs_.jpg" alt="tabela_devicenet_cip_model_obrada_singala_protokoli_automatika-rs" width="500" height="273" srcset="https://www.automatika.rs/wp-content/uploads/2016/10/Tabela_devicenet_cip_model_obrada_singala_protokoli_automatika.rs_.jpg 500w, https://www.automatika.rs/wp-content/uploads/2016/10/Tabela_devicenet_cip_model_obrada_singala_protokoli_automatika.rs_-300x164.jpg 300w" sizes="auto, (max-width: 500px) 100vw, 500px" /></p>
<p style="text-align: justify"> Da bi se postigao međusobni rad i zamenljivost uređaja različitih proizvođača povezanih na mrežu sa implementirani CIP protokolom, morao se definisati tzv. profil uređaja (Device profile), koji predstavlja minimalni set objekata, konfiguracionih opcija i tipova I/O poruka za konkretni tip uređaja. Treba uočiti da je pojam profila jednog DeviceNet uređaja širi od pojma modela jednog DeviceNet čvora, tj. uvek je jedan model DeviceNet čvora uključen u opis konkretnog DeviceNet profila.</p>
<p style="text-align: justify"> Na taj način se postiže da svi uređaji koji slede isti profil imaju iste tipove I/O poruka, iste konfiguracione opcije i odgovaraju na iste komande na identičan način. Neki od mnogobrojnih definisanih profila su: AC pogon, DC pogon, komunikacioni adapter, anlaser, ventil, fotoelektrični senzor, diskretni I/O uređaj opšte namene i slično. Na taj način se za svaki uređaj implementira minimalni set zajedničkih osobina, čime se postiže zajednički rad na istoj mreži uređaja različitih tipova i uređaja proizvedenih od strane različitih proizvođača.</p>
<p style="text-align: justify"> Kako pomenute tri mreže (DeviceNet, ControlNet i Eternet/IP) koriste CIP kao zajednički aplikacijski sloj, to dodatno olakšava pisanje aplikativnog softvera, jer programer koji to radi ne mora više čak ni da zna kojom od pomenutih mreža su njegovi uređaji povezani.</p>
<p style="text-align: justify"> Adresiranje objekata unutar DeviceNet čvora je bazirano na hijerarhijskoj šemi koja se sastoji od 4 identifikatora: MAC-ID (Medium Access Control Identifier), ClassID, InstanceID i AttributeID. Zadatak MAC-ID je da identifikuje konkretni čvor među ostalim čvorovima na liniji. Zadatak ClassID je da u datom čvoru identifikuje klasu objekata da bi u njoj InstanceID mogao da identifikuje odgovarajući primerak te klase. Konačno, AttributID omogućava pristup odgovarajućem atributu identifikovanog primerka.</p>
<h3 style="text-align: justify"> Fizički sloj DeviceNet protokola</h3>
<p style="text-align: justify"> DeviceNet poseduje jedinstvenu karakteristiku da mu je napajanje prisutno na mreži. To omogućava da uređaj adekvatne snage bude napajan direktno sa mreže, čime se smanjuje broj njegovih priključaka, kao i fizičke dimenzije uređaja. Zavisno od primenjenog kabla nominalna struja na linijama za napajanje može da dostigne vrednost i do 8A.</p>
<p style="text-align: justify"> Jedinstvena karakteristika DeviceNet-a je i mogućnost da se napajanje može uvesti na proizvoljnom mestu u mreži. To omogućava da se u aplikacijama gde je pouzdanost veoma bitna ostvari redundantni sistem napajanja.</p>
<p style="text-align: justify"> Ovaj protokol podržava brzine prenosa od 125 kb/s, 250kb/s i 500 kb/s. Brzina od 1Mb/s, koju podržavaju neki drugi protokoli (npr. CANopen) nije podržana od strane DeviceNet protokola. Razlog leži u činjenici da maksimalna dužina komunikacione linije veoma brzo opada sa porastom brzine prenosa (npr. za brzine prenosa od 125 kb/s ona iznosi 500 m, dok za brzine od 500 kb/s ona iznosi samo 100 m), tako da bi za brzine prenosa od 1 Mb/s ta dužina bila neprihvatljivo mala.</p>
<p style="text-align: justify"> <strong>DeviceNet</strong> dozvoljava najviše 64 aktivna čvora na mreži, pa je i po tom kriterijumu jedan od najrestriktivnih viših CAN protokola. Takođe, DeviceNet postavlja i strože zahteve po pitanju karakteristika linijskih primopredajnika (bus transceiver-a), tako da ako neki primopredajnik zadovoljava specifikacije iz <strong>ISO 11898 standarda</strong>, ne znači da će uspešno funkcionisati primenjen na DeviceNet mreži.</p>
<p style="text-align: justify"> Ovaj protokol podržava i izolovani i neizolovani dizajn komunikacione linije. Izbor konketnog rešenja dominantno zavisi od tipa uređaja. Ako uređaj nije električno povezan sa okruženjem i napaja se preko DeviceNet mreže (što je recimo slučaj sa većinom senzora), onda se on tipično ne izoluje od mreže. Sa druge strane, uređaji koji poseduju eksternu električnu vezu skoro isključivo pristupaju mreži preko jednog izolacionog segmenta. Ako se za izolaciju koristi neki optički sistem, mora se voditi računa i o njegovoj brzini, jer se njegovo kašnjenje superponira na kašnjenje linijskog primopredajnika.</p>
<p>The post <a href="https://www.automatika.rs/baza-znanja/obrada-signala/devicenet-visi-can-protokol.html">DeviceNet &#8211; Viši CAN protokol</a> appeared first on <a href="https://www.automatika.rs">Automatika.rs</a>.</p>
]]></content:encoded>
					
					<wfw:commentRss>https://www.automatika.rs/baza-znanja/obrada-signala/devicenet-visi-can-protokol.html/feed</wfw:commentRss>
			<slash:comments>0</slash:comments>
		
		
			</item>
	</channel>
</rss>
