Slika br.1 Blok dijagram TMS320x240x CAN modula

 CAN modul ostvaruje dvožičnu komunikaciju sa CAN transceiver-om preko pinova CANTX i CANRX sa jedne strane. Sa druge strane CPU ostvaruje pristup kontrolnim i statusnim registrima, kao i specifičnom memorijskom prostoru (tzv. Mailbox RAM) CAN modula.

 Mailbox-ovi su locirani u delu RAM-a veličine 48 memorijskih reči. U Mailbox RAM-u se nalaze poruke koje su upravo primljene, odnosno upisuju se poruke namenjene za slanje. Mailbox-ovi 0 i 1 su prijemni, dok su 4 i 5 predajni; mailbox-ovi 2 i 3 su konfigurabilni i mogu poslužiti za slanje ili za prijem.

 Svaki od šest mailbox-ova sadrži po četiri 16-bitna registra u kojima može da se smesti maksimalno 8 bajtova podataka, dva 16-bitna registra za identifikator i nekoliko kontrolnih registara. U okviru dva registra za identifikator, pored samog 29-bitnog identifikatora, se nalaze i tri bita kojima se definiše dužina identifikatora, upotreba lokalne maske i auto-answer mod (AAM bit) potreban za automatski odgovor na zahtev za podacima.

 CAN modul šalje ili prima podatke koristeći tip poruke sa podacima čiji je format prikazan na slici br.2. Po prijemu nove poruke se najpre identifikator same poruke upoređuje sa identifikatorima prijemnih mailbox-ova, i ukoliko se ovi poklope poruka se prihvata. Postavljanje lokalne maske omogućava da se određeni bitovi identifikatora mailbox-a maskiraju i ne učestvuju u upoređivanju sa odgovarajućim bitovima identifikatora pristigle poruke. Naravno, lokalnu masku je moguće postaviti samo za prijemne mailbox-ove.

Slika br.2 Format poruke sa podacima

 Prijem poruka sa zahtevom za podacima se može ostvariti samo preko mailbox-ova 0, 1, 2 i 3. Ukoliko stigne poruka u kojoj je setovan RTR bit, CAN modul upoređuje identifikatore ovih mailbox-ova sa identifikatorom pristigle poruke. Identifikatori mailbox-ova se porede počev od mailbox-a broj 3 naniže. Za slučaj kada se identifikatori poklope dalja pretraga se završava. Zavisno od toga da li je identifikaovani mailbox prijemni ili predajni, kao i da li je setovan AAM bit, moguće su sledeće situacije:

 1. Ukoliko je prozvani mailbox konfigurisan za slanje (uočiti da to mogu biti samo konfigurabilni mailbox – ovi 2 i 3), a AAM fleg je setovan, dolazi do automatskog slanja trenutnog sadržaja tog mailbox-a.

 2.Ukoliko je prozvani mailbox konfigurisan kao predajni, a AAM bit nije setovan, prihvaćena poruka sa zahtevom za podacima će biti ignorisana, tj neće biti nikakvog odziva na poruku, kao ni bilo kakve signalizacije ka CPU da je ovakva potuka primljena.

 3. Ukoliko je prozvani mailbox konfigurisan kao prijemni, on poruku prihvata i signilizira CPU preko bita RCR iz prijemnog kontrolnog registra. Odgovor na ovaj zahtev za podacima sada u potpunosti zavisi od odluke CPU.

 Kada CPU želi da pošalje zahtev za podacima, to se ostvaruje sa konfigurabilnim mailbox-ovima 2 i 3. Naime, jedan od njih se najpre konfiguriše kao prijemni mailbox. Tako konfigurisan mailbox je u stanju da pošalje poruku sa zahtevom za podacima. Prijem očekivanih podataka se ostvaruje u istom mailbox-u.

 Dva statusna registra daju informacije o funkcionisanju cele periferije (Global Status Register (GSR)), odnosno o tipu greške koja je nastupila (Error Status Register (ESR)). ESR prikazuje samo prvu grešku koja je nastupila, to jest naredne greške ne menjaju njegov sadržaj. CAN modul ima dva brojača grešaka, po jedan za režim slanja i režim prijema čiji sadržaji su dostupni CPU.

 Kontrolni registri CAN modula omogućavaju konfigurisanje mailbox-ova pomoću kojih se oni uključuju ili isključuju, kontrolišu predajne ili prijemne funkcije, određuju brzinu prenosa i upravljaju prekidima. Postoje dva tipa prekidih zahteva između CAN modula i PIE kontrolera: jedan je iniciran promenom stanja nekog mailbox-a, a drugi usled uočene greške. Oba tipa mogu koristiti visoki i niski nivo prioriteta. Sledeće aktivnosti iniciraju prekid:

• poruka je uspešno primljena ili poslata;
• slanje poruke je prekinuto;
• CPU nije uspeo da upiše poruku za slanje;
• wake-up stanje;
• stara poruka je prebrisana od strane nove poruke;
• CAN modul je onemoguđen da šalje poruke (Bus-off stanje);
• CAN modul je pasivan (Error Passive);
• jedan ili oba brojača grešaka ima vrednost koja je jednaka ili veća od 96;

Maxim MAX3225cpp

 Maxim MAX3225cpp predstavlja RS-232 drajver [12] zadužen za asinhronu serijsku vezu sistema sa periferijama. Maksimalna brzina komunikacije je 1 Mb/s. Podizanje signala na RS-232 nivo se ostvaruje takozvanom naponskom pumpom koja je realizovana u vidu četiri kondenzatora reda veličine 0,1µF. Kolo automatski prelazi u stanje niske potrošnje kada je RS-232 kabl otkačen ili u slučaju da su transmisiona kola zakačene periferije neaktivna, odnosno ukoliko je UART koji pogoni transmitere neaktivan više od 30 sekundi koristeći AutoShutdown Plus aplikaciju. Kolo se ponovo aktivira pri novoj validnoj tranziciji na bilo kom transmiter-skom ili receiver-skom ulazu. Kolo je smešteno u standardnom DIP 20 kućištu.

Philips PCA82C250

 PCA82C250 je interfejs između CAN kontrolera i fizičke magistrale. Primarna upotreba je u industrijskim aplikacijama koje koriste brzine od 40 kb/s do 1 Mb/s. Poseduje zaštite od kratkog spoja ka pozitivnom i negativnom naponu, zaštitu od termalnog preopterećenja koja kontroliše da temperatura spoja ne pređe 165ºC. Kolo zahteva 5V napajanje, i njegovo ulazno kolo za prijem podataka od CAN kontrolera (pin TXD) očekuje za logičku jedinicu napon od 5V, dok njegovo izlazno kolo za slanje podatka ka CAN kontroleru daje napon od 5V za logičku jedinicu. U oba slučaja, logičkoj nuli odgovara naponski nivo od 0V.

 PCA82C250 je spakovan u veoma malo osmopinsko SMD kućište sa oznakom SO-8 (Small Outline package). Dimenzije su mu 4x5mm.

The post Karakteristike i blok dijagram CAN modula jednog digitalnog signalnog procesora appeared first on Automatika.rs.

Formiranje osnovne jedinice za merenje vremena na TTCAN mreži

 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.

 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.

Slika br.1 Generisanje NTU

Sinhronizacija rada čvorova na mreži

 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

Slika br.2 Sinhronizacija ciklusnog vremena (osnovna verzija TTCAN protokola)

 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.

 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.

Slika br.3 Računanje globalnog vremena (proširena verzija TTCAN protokola)

 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.

Implementacija TTCAN protokola

 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.

 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.

 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.

 Između ostаlog, prisutni su i pokušaji da se izvrši uključivanje karakteristika TTCAN protokola u trenutno znatno rasprostranjeniji CANopen protokol.

The post TTCAN protokol – Formiranje čvorova, sinhoronizacija i implementacija appeared first on Automatika.rs.

 Oba imaju zadatak da preko DeviceNet mreže uspostave tzv. Explicit Message Connection koji ne predstavlja ništa drugo do sposobnost novopriključenog, nekonfigurisanog porta da prihvata poruke sa mreže sa unapred predifinisanim identifikatorima. Preko tog “kanala” od strane nekog drugog čvora na mreži šalju se takozvane eksplicitne poruke. Eksplicitna poruka predstavlja 8-bitnu informaciju neophodnu za konfiguraciju novopriključenog čvora i locirane su u polju podataka standardne poruke sa podacima CAN protokola. Kao identifikator u CAN poruci koriste se dva specijalno rezervisana identifikatora, tako da ostali čvorovi na mreži neće reagovati na ove poruke.

 Po završetku konfigurisanja zatvara se komunikacioni “kanal“, nakon čega se konfigurisani čvor ponaša kao standardni DeviceNet čvor sa pridruženim setom identifikatora. U toku procesa konfiguracije čvor koji se konfiguriše pošalje 27 i primi 1701 eksplicitnu poruku.

Raspodela indentifikatora poruka unutar DeviceNet mreže

 Metode za raspodelu identifikatora poruka predstavljaju jedan od najznačajnijih segmenata sistema baziranih na CAN protokolu. Od raspodele identifikatora u velikoj meri zavisi efikasnost sistema, sposobnost filtriranja poruka i opterećenost mreže. Posmatrajući ovaj segment viših CAN protokola, može se konstatovati da DeviceNet i CANopen po ovom pitanju imaju sasvim različit pristup. Naime, izuzimajući određeni broj identifikatora rezervisanih u svrhu upravljanja mrežom, CANopen protokol ne koristi nikakvu predefinisanu šemu za dodelu identifikatora. Nasuprot tome, DeviceNet protokol koristi predefinisane identifikatore.

 DeviceNet mreža postavlja specifične zahteve po pitanju dužine identifikatora poruka. Naime, upotreba 29–bitnog identifikatora ne samo da se ne zahteva, već nije ni dozvoljena. Ovaj protokol definiše podelu 11-bitnog identifikatora u 3 različite grupe. Svakom od maksimalno 64 čvora pripada set identifikatora iz svake od grupa, pri čemu su ovi raspodeljeni ravnomerno na svaki od čvorova. Rezervacija maksimalnog broja identifikatora za maksimalni broj čvorova na mreži implicira da za mrežu sa manje od 64 čvora identifikatora nepostojećih čvorova neće biti dostupni za ostatak sistema. Identifikatori prve grupe se koriste za poruke visokog prioriteta. Svakom čvoru pripada po 16 identifikatora iz ove grupe. Identifikatori treće grupe su namenjeni za poruke niskog prioriteta i u ovom slučaju svakom čvoru pripada po pet. Druga grupa identifikatora je namenjena kao podrška za starije uređaje sa smanjenim mogućnostima filtracije identifikatora. To su tzv. osnovni CAN kontroleri (Basic CAN Type Controllers) koji imaju mogućnost filtriranja samo osam najznačajnijih bitova identifikatora.

Implementacija master-slave komunikacije na DiviceNet mreži

 Iako je osnovna namena DeviceNet protokola tzv. Peer-to-peer ili Multi-Master komunikacija, on implementira i uprošćenu komunikacionu šemu baziranu na master-slave relacijama. Ova predefinisana šema se naziva set predefinisanih master-slave veza (Predefined Master-Slave Connection Set). Ovaj uprošćeni model povezivanja pojednostavljuje prenos I/O poruka koje se i najčešće koriste u upravljačkim aplikacijama. Naime, mnogi senzori i aktuatori su dizajnirani tako da izvršavaju neke predefinisane funkcije u kojima je tip i količina podataka koje uređaj proizvodi i/ili koristi poznat odmah po uključenju. Takvi uređaji poseduju objekte za konekciju na mrežu koji su, zbog jednostavnosti postavljenog zadatka, skoro u potpunosti konfigurisani samim ukuljučenjem uređaja. Po priključenju na mrežu takvog uređaja master-u preostaje da jedino interno označi “vlasništvo” nad novouvedeni slave-om, nakon čega može odmah da se započne sa prenosom podataka.

 Slave može generisati podatke koristeći jedan od više unapred definisanih tipova, kao i koristiti specifične, aplikacijski definisane, tipove podataka. On može primati poruke metodom prozivanja (polling). Slave-ovi konfigurisani za ovaj mod komunikacije primaju poruke od master-a na sekvencijalan način, po redosledu definisanom u internoj listi master-a. Učestanost sa kojom se određeni slave proziva zavisi od broja čvorova u internoj listi master-a, realizovane brzine prenosa DeviceNet mreže, veličine poruka koja se predaje pojedinačnom čvoru, ali i od internog vremenskog rasporeda master-a. Podaci koje generiše master mogu biti Unicast ili Multicast tipa. Metod master-slave komunikacije se odlikuje najvećim stepenom determinističkog ponašanja DeviceNet mreže.

 Slave može biti konfigurisan da ciklično, na precizno definisane vremenske intervale generiše poruke master-u. Ovaj tip komunikacije omogućava da se učestanost prenosa podataka prilagodi zahtevima aplikacije. To opet, zavisno od same aplikacije, može značajno redukovati protok informacije po mreži, i omogućiti bolje iskorišćenje raspoloživog propusnog opsega. Detaljnija analiza ovog metoda razmene poruka je data u poglavlju koje se bavi TTCAN protokolom.

 Konačno, slave uređaj može biti konfigurisan tako da poruke generiše na promenu nekog od svojih stanja (Change of State (COS) Message). Za ovaj mod rad vezana su dva dodatna konfiguraciona parametra. Prvi od njih definiše vremenski interval nakon koga slave mora da pošalje unapred definisanu poruku (tzv. Heartbeat Message) u slučaju da se u toku tog intervala ne desi promena nijednog od analiziranih stanja. Ovim se obezbeđuje da se master obavesti da je slave “živ” i aktivan bez obzira što ne šalje očekivane I/O poruke. Drugi, korisnički podesivi parametar, je tzv. Production Inhibit Time parametar, čiji je zadatak da ograniči frekvenciju pojavljivanja COS poruke i tako spreči da posmatrani čvor zaguši komunikacionu liniju. Ova dva parametra pružaju dizajneru mreže moćno sredstvo da optimalno prilagodi karakteristike aplikacije propusnom opsegu mreže.

Više o DeviceNet protokolu pronađite OVDE.

 Naponema: Dalja objašnjenja pojmova korišćenih u ovom tekstu možete naći u  radu Implementacija CAN protokola. Autori: Željko Pantić, Igor Stamenković

The post Konfiguracija uređaja na DeviceNet mreži appeared first on Automatika.rs.

 DeviceNet je jedan od tri mrežna standarda (DeviceNet, ControlNet i Eternet/IP) koji koristi identičan aplikacijski sloj, tzv. Common Industrial Protocol (CIP), što je prikazano na slici br.1.Slika br.1 CIP model

 CIP 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.

Slika br.2 Modela DeviceNet objekta

Tabela 1: Opis funkcionalnosti objekata DeviceNet čvor

 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.

 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.

 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.

 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.

 Fizički sloj DeviceNet protokola

 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.

 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.

 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.

 DeviceNet 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 ISO 11898 standarda, ne znači da će uspešno funkcionisati primenjen na DeviceNet mreži.

 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.

The post DeviceNet – Viši CAN protokol appeared first on Automatika.rs.