CANopen Master szoftveres implementálása

A részleges implementáláshoz szükséges információkat gyűjtöm itt össze. Nem célom a témát a teljes mélységéig feltárni, inkább csak az, hogy legyen egy áttekintés a főbb funkciókról.

A CANopen az OSI rendszerben a 7-ik rétegen, az alkalmazások rétegén helyezkedik el. Tehát a lényegi megvalósítás szoftveres. A protokoll fizikai megvalósulását (1..3 réteg) a CAN busz specifikálja.

A specifikáicó az eszközökben levő információk rendszerét adja meg mind az elérés, mind a tárolás szempontjából. Objektumokat, könyvtárakat és alkönyvtárakat definiál, amiket azok számával érhetünk el.

Az adatáramlás többféle lehet. Három fő kommunikáció objektumot különboztet meg:

1. Adminisztratív üzenetek: ilyenek például a hálüzat kezelési üzenetek (NMT).
2. Szerviz adat objektumok (SDO - Service Data Objects): nem real time adatok írására/olvasására. A kiolvasható adat hossza nem kötött, de 4 byte-on felül tördelni kell. Mindig on request és master-slave.
   
3. Folyamat adat objektumok (PDO - Process Data Objects): real-time adadtok forgalmazásához.
   

Az üzenetek felépítése:
Az üzeneteket framekbe (keretekbe) foglaljuk. Ennek egy részét a CAN vezérlő és driverei oldják meg, nekünk csak a CANopen által elvárt protokolláris bájtokkal kell foglalkozni. Egy üzenet a COB-ID-del (Communication Object ID - Kommunikációs objektum ID) kezdődik. A csomagolást a CAN driver végzi. A COB-ID két részből áll + 1 bit a CAN protokollból, a többit nem tárgyalom itt:

• 4 bit a kívánt funkció kódja (nmt, pdo, sdo írás/olvasás, vész üzenet, boot-up üzenet stb),
• 7 bit a node sorszáma (eszköz sorszáma)
• 1 bit a RTF: RemoTe Frame - Távoli Keret. Ez használjuk akkor, ha információt kérünk a távoli eszköztől. Ilyen esetben nincs adat a keretben.

A CAN buszon a logikai 0 (nulla) domináns, ami azt jelenti, hogy ha egy eszköz épp nullát ír a buszra, nem számít, hogy hány másik eszköz akar 1-est írni. Ebből fakadóan a buszon végezhető funkciók és az eszközök sorszáma (node id) is egyben prioritási rendszert adnak meg. (Alacsonyabb számnak magasabb a prioritása.)

A COB-ID tehát a kívánt funkció és a node id összege. Eztán 8 byte adat következhet. Ezt kell nekünk a CANopen szabvány által megformálni.

A CAN és a CANopen lehetőséget ad Broadcast üzenet küldésre is. Ennek három speicális fajtája van:

• Modul Control COB-ID: 0x000. Ezt használjuk az eszközök protokoll szintű vezérlésére (elindítás, leállítás, reset stb).
• SYNC COB-ID: 0x080. Szinkronizálás parancs.
• Time Stamp: 0x100. Idő béjeg.
  

Az eszközök feléledés után (Boot-up) egy feléledési üzenetet küldenek. Ez az üzenet 0x700+Node Id COB-ID-t és egy byte adotot tartalmaz, ahol az adat 0.
Alap esetben az eszköz Pre-Operational (működés előtt) állapotban ébred, ahonnan a Master a Start Remote Node modul control paranccsal tudja átbillenteni működési állapotba.


Mik az objektum könyvátrak (OB-k)?
Ezek a CANopenes elnevezései az egymással összefüggésben levő "regisztereknek". Tehát az elv hasonló a regiszteres megoldásokhoz, de itt az adott regiszternek megszabott tartalma van és az alknyvtár számozással összefüggésben van a könyvtárral. Például:
Objects and Data for the 1^st RxPDO

Ind.	Sub- index	Name	Type	Attr.	Map ping	Default value	Meaning
0x1400	0	Number of elements	Unsigned8	ro	N	5	Communication parameters for the first receive PDO. Sub-index 0: number of following parameters
	1	COB-ID	Unsigned32	rw	N	0x000002xy, xy=Node-ID	COB-ID (Communication Object Identifier) RxPDO1
	2	Transmission Type	Unsigned8	rw	N	255	Transmission type of the PDO
	3	Inhibit Time	Unsigned16	rw	N	0	Present for reasons of backwards compatibility, but not used in the RxPDO.
	4	CMS Priority Group	Unsigned8	rw	N	-	Present for reasons of backwards compatibility, but not used.
	5	Event Timer	Unsigned16	rw	N	0	Event-Timer. Watchdog time defined for monitoring reception of the PDO.

Az index adja meg a könyvtárat, míg a sub index az alá ágazó paramétereket. A feljebb látható könyvtár egy PDO adatait tartalmazza.

Az NMT üzenetek:
Ezek a legyegyszerűbb üzenetek és a hálózat kezelésére vannak. Felépítésük szerint.

COB-ID Byte0 Byte1

ahol:

• COB-ID = 0x00
• Byte0: CS (Command Specifier) maga a kívánt parancs.
• Byte1: az eszköz node id-je, amelynek az üzenet szól.

A CS, tehát a parancs a következők egyike lehet:

• 0x01: Start Remote Node : távoli eszköz elindítása
• 0x02: Stop Remote Node: leállítása
• 0x80: Enter Pre op. mode: távoli eszköz működés előtt módba léptetése
• 0x81: Reset Node: távoli eszköz újraindítása
• 0x82: Reset Communication: a távoli eszközzel való kommunikáció újraindítása

A CANopen lehetőséget ad Node Guardingra (Node felügyelet), de ezt most nem tárgyaljuk.

A PDO-k:
Fogadásuk lehet szinkron, asszinkron és esemény vezérelt vagy ezek kombinációja. Max. 8 bájtot forgalmaz. 512 db tx és rx lehet. A Tx PDO-k a 0x181 memória területtől kezdődnek, míg az RX PDO-k a 0x201-estől. Alap esetben a CANopen szabvány minimum 2 RX és 4TX PDO definiálását írja elő.

A PDOk paramétereit a feljebb látható módon adhatjuk meg a megfelelő könyvtárak használatával, míg a PDO csomagok adat tartalmát a 0x1A00 könyvártól felfelé adhajuk meg, természetesen az adott eszköznek megfelelően. Ezek a Mapping paraméterek. A sub index 0 adja meg, hogy az adott PDO hány bájtot forgalmaz és a továbbiak a forgalmazni kívánt bájtok helyét és azt, hogy hány bitet az adott bájtból. Így a sub index felépítése:
Index SubInd Szélesség.

Így pl, ha az adott PDO a 0x600-as könyvtár 0x02-es alkönyvtárának 8 bitjét forgalmazza, akkor az adott deklaráció így néz ki: 0x06000208.

Fontos, hogy a CANopen little endian adat továbbítást alkalmaz, ami azt jelenti, hogy a több bájt hosszú adatoknak mindig az LSB, tehát kisebb helyiértékű része kerül előre. Tehát, ha a megadott indexű könyvtár pl egy 16 bites adatot tartalmaz, akkor a válasz így fog kinézni:
[0x280+Node id] [a 16 bit adat LSB-je] [a 16 bit adat MSB-je]

Ha egy mapping könvtár 0 sub indexe nulla és a hozzá tartozó communicaton object 1 szubindexének 31. bitje egy, akkor az adott SDO ki van kapcsolva.

Az SDOk:
Ezeket az objektumokat a nem valós idejűséget igénylő, sokszor nagy mennyiségű, adatok mozgatásához használjuk. Az továbbított adat hossza szerint lehet expedited vagy segmented adatátvitel.
A CAN által engedett 8 byte-ból a nulladik bájt mindig az SDO Command Specifier (SDO parancs megadó), ami a következőket tartalmazza:

• letöltés / feltöltés
• kérelem / válasz
• szegmentált / egyben küldött adat
• hány adatbájtot hordoz ez a keret
• alternáló bit, amely minden szegmensnél vált.

Létezik még egy úgynevezett Blokk adatátvitel, de ezt most nem tárgyalom.

A letöltés mindig azt jelenti, hogy az ezsköz BE írunk, míg feltöltéskor az eszközTŐL várunk adatot. Így a távoli eszköz lesz az adatátvitel szempontjából a szerver.

Most csak a három legáltalánosabb parancsot ismertetem.
A "-" helyén álló bitek nem számítanak bele a parancsba, de hagyjuk őket nullának!

1. Letöltés kezdeményezése:

Bit	7	6	5	4	3	2	1	0
From Client	0	0	1	-	n		e	s
From Server	0	1	1	-	-	-	-	-

Ahol:

• n: csak akkor értelmezhető, ha e=1 és s=1, egyébként nulla. Azt mutatja, hogy az adat mezőből hány byte nem adat. (A negyedig bytetól 8-n ig adat bytok vannak.)
• e: normál átvtel, 1= expedited átvitel
  
• s: hossz indikátor, 0= nincs megadva, 1= megadva
• e=0, s=0: az adatájtokat későbbi használatra tarja fenn a CiA
• e=0, s=1: az adatbájtok byte számlálók. (LSB elől.)
• e=1: az adatbájtok a letöltendő adatot tartalmazzák.

2. Felöltés kezdeményezése:

Bit	7	6	5	4	3	2	1	0
From Client	0	1	0	-	-	-	-	-
From Server	0	1	0	-	n		e	s

A jelölések megegyeznek a letöltésben levőkkel.

3. Átvitel megszakítása:

Bit	7	6	5	4	3	2	1	0
From Client	1	0	0	-	-	-	-	-

Megszakításkor a 0 és 1 adatbájt az objektum indexét, a 2-es byte az alindexet és a maradék 4 byte a 32bites hibakódot, a megszakítás okát tartlamazza.

Egy példa
A 0x3FE érték letöltése a letöltése a 2-es nodban levő 0x1801 sub 0x3 ba:

Cob-ID	byte
	0	1	2	3	4	5	6	7
0x602	0010 1011 (0x2B)	0x01	0x18	0x03	0xFE	0x03	-	-

A válasz:

0x582	0110 0000 (0x60)	0x01	0x18	0x03	-	-	-	-

A hiba objektum:
A CANopen definiál egy hiba objektumot is. A 0x080+node id Command specifier kóddal tudunk hibaüzit küldeni az adott node-nak.
És van egy error regiszterünk is az index 0x1001 könyvtárban.
A hibakódokat nem másolom ide.

Ennyit kell tudni dióhéjban a CANopenről ahhoz, hogy meg lehessen kezdeni az implementálást.