CANopen
CANopen je komunikační protokol založený na CAN, který se používá hlavně v automatizační technologii a pro vytváření sítí v komplexních zařízeních.
Hlavní distribuční oblastí CANopen je Evropa. Počet uživatelů se však zvyšuje jak v Severní Americe, tak v Asii. Byl iniciován především německými středními společnostmi a vyvíjen jako prototyp v letech 1993 až 1995 v rámci projektu ESPRIT ASPIC pod vedením společnosti Bosch . Je udržován organizací CAN in Automation (CiA) od roku 1995 a je standardizován jako evropská norma EN 50325-4.
Základní služby CANopen
V CANopen je definováno několik základních služeb (primitiv služby). Jedná se o tyto základní služby:
- Žádost
- Žádost o službu CANopen aplikací
- Indikace
- Oznámení aplikaci, že existuje výsledek nebo konkrétní zpráva
- Odezva
- Reakce aplikace na indikaci
- potvrzení
- Potvrzení žádosti, že byla provedena služba CANopen
Kromě těchto služeb klient-server se v CANopen používají také další komunikační koncepty, jako je koncept producent-spotřebitel . To ukazuje, že CANopen není klasický systém typu master-slave. CANopen původně kryl aplikační vrstvu (vrstvu 7) v modelu OSI a používá CAN jako transportní médium vrstvy 2. Síťované sítě s možnostmi směrování jsou však od roku 2006 také standardizovány.
Komunikační objekty
Komunikační objekty lze rozdělit na
- Servisní datové objekty (SDO) pro parametrizaci položek adresáře objektů,
- Zpracovat datové objekty (PDO) pro přenos dat v reálném čase,
- Objekty správy sítě (NMT) pro řízení stavového zařízení zařízení CANopen a pro monitorování uzlů,
- další objekty, jako je synchronizační objekt (SYNC), časové razítko a chybové zprávy (EMCY).
Adresář objektů
Všechny komunikační objekty a všechny uživatelské objekty jsou shrnuty v Object Dictionary (OD). V modelu zařízení CANopen je OV spojení mezi aplikací a komunikační jednotkou CANopen. Každá položka ve slovníku objektů znamená objekt a je identifikována 16bitovým indexem. Index může zase obsahovat až 255 dílčích indexů. To znamená, že lze odlišit až 65536 × 254 prvků nezávisle na „11bitových identifikátorech“. (Podindexy 0 a 255 nelze volně používat.) V profilech je přesně definováno přiřazení objektů komunikace a profilů zařízení k příslušnému indexu; je tedy definováno jasné rozhraní mezi aplikací a externí komunikací s adresářem objektů. Například každý uzel CANopen v síti ví, že interval prezenčního signálu lze najít na indexu 1017h a každý uzel nebo každý konfigurační program jej může číst nebo zapisovat.
| Oblast indexu | použití |
|---|---|
| 0000 | nepoužívá |
| 0001-009F | Datové typy (zvláštní případ) |
| 00A0-0FFF | Rezervováno |
| 1000-1FFF | Komunikační profil |
| 2000-5FFF | oblast specifická pro výrobce |
| 6000-9FFF | až 8 standardizovaných profilů zařízení |
| A000-AFFF | Zpracovávejte obrázky zařízení IEC61131 |
| B000-BFFF | Zpracovávejte obrazy bran CANopen podle CiA 302-7 |
| C000-FFFF | Rezervováno |
Pro každý komunikační objekt je v síti jedinečný COB-ID (identifikátor komunikačního objektu). COB-ID se skládá z 32bitových hodnot, přičemž první dva bity mají význam specifický pro daný objekt. V 11bitové síti CAN má následujících 19 bitů (29 až 11) hodnotu 0 a poslední bity (10 až 0) odpovídají identifikátoru CAN.
Servisní datové objekty poskytují službu pro přístup do slovníku objektů. Každé zařízení CANopen vyžaduje alespoň jeden server SDO, který přijímá a zpracovává požadavky SDO z jiných zařízení. Ve výchozím nastavení zprávy na server SDO zařízení používají číslo uzlu příjemce + 1536 (0x600) jako COB ID nebo jako „identifikátor“ zprávy CAN. Číslo uzlu odesílatele +1408 (0x580) se používá jako „identifikátor“ pro odpověď ze serveru SDO. Záznamy v OV jsou přenášeny s těmito relativně vysokými, a tedy i nízko prioritními ID. Pro tento přenos SDO existuje protokol, který vyžaduje 4 bajty pro kódování směru přenosu, indexu a subindexu. To ponechá pouze 4 bajty z 8 bajtů datového pole CAN pro datový obsah. Pro objekty, jejichž datový obsah je větší než 4 bajty, existují dva další protokoly pro fragmentovaný přenos SDO.
Na rozdíl od přenosu SDO s nízkou prioritou, který je přetížen daty protokolu, poskytují objekty procesních dat rychlejší způsob přenosu dat procesu. "Identifikátory" používané pro přenos PDO jsou s výchozím nastavením v rozsahu COB ID od 385 (0x181) do 1407 (0x57F), a proto mají vyšší prioritu než zprávy SDO. Dále obsahují pouze uživatelská data, takže je k dispozici 8 bajtů. Obsah uživatelských dat se určuje pomocí položek mapování PDO. Jedná se o objekty v OD, které stejně jako tabulka přiřazení určují, která data jsou přenášena prostřednictvím CHOP. Tato data jsou zase obsahem dalších objektů v OV. Hodnoty několika objektů lze také přenášet v PDO a přijímače PDO mohou používat pouze části dat podle svých položek mapování PDO. Když je přijat PDO, data jsou znovu přenesena do dalších objektů OV, např. B. v digitálním výstupním objektu zapsáno. Přenos PDO může probíhat cyklicky, orientovaný na událost, dotazovaný nebo synchronizovaný.
Objekty správy sítě se používají ke správě sítě. Takže existují i mezi ostatními. Zprávy, které způsobí změnu stavu v zařízení nebo rozšíří globální chybové zprávy.
Synchronní objekt odesílá nebo přijímá například zprávu SYNC s vysokou prioritou, která se používá k synchronizaci uzlů v síti a s objektem časového razítka zajišťuje jednotný čas v síti. Kromě toho existuje v komunikačním profilu a zejména v profilech zařízení řada dalších objektů.
Profily zařízení
Profily zařízení CANopen byly definovány pro řadu tříd zařízení. Tyto profily zařízení definují funkčnost a strukturu adresáře objektů pro příslušná zařízení. Použitím zařízení CANopen, která odpovídají určitému profilu, je dosaženo větší nezávislosti na výrobcích zařízení.
Některé z profilů zařízení jsou:
| výchozí | Třída zařízení |
|---|---|
| CiA 401 | Vstupní / výstupní moduly |
| CiA 402 | elektromotory |
| CiA 404 | Senzory a ovladače |
| CiA 406 | Lineární a rotační enkodéry |
| CiA 408 | hydraulické ventily a pohony |
Profily aplikací
Na rozdíl od profilů zařízení profily aplikace nepopisují funkčnost skupiny zařízení (disky, kodéry, vstupy / výstupy), ale funkce aplikace. Takže existuje z. B. Aplikační profily pro výtahové systémy (CiA 417), kolejová vozidla (CiA 421), popelářské vozy (CiA 422) nebo elektrická lehká vozidla, jako jsou elektrická kola (CiA 454 EnergyBus ).
Nejdůležitější aplikační profily jsou:
| výchozí | aplikace |
|---|---|
| CiA 410 | Sklonoměr |
| CiA 412 | Lékařské vybavení |
| CiA 413 | Brány do nástavby nákladních vozidel |
| CiA 415 | Senzory pro silniční stavební stroje |
| CiA 416 | Ovládání dveří |
| CiA 417 | Ovládací prvky výtahu |
| CiA 418/9 | Baterie a nabíječky |
| CiA 420 | Následná zařízení extruderu |
| CiA 421 | Kolejová vozidla |
| CiA 422 | Popelářské vozy |
| CiA 444 | Jeřáby / rozmetadla |
| CiA 454 | Lehká elektrická vozidla |
Elektronické datové listy
Pro použití zařízení CANopen jsou stále zapotřebí elektronické datové listy, takzvané soubory EDS. Tyto soubory ve standardizovaném textovém formátu popisují jak nejdůležitější parametry objektů v adresářích zařízení zařízení, tak fyzické parametry, jako například B. podporované přenosové rychlosti. Konfigurační nástroje mohou číst soubory EDS a s jejich pomocí komunikovat s příslušným zařízením a v případě potřeby jej parametrizovat. Bezplatný nástroj CANchkEDS se používá ke kontrole syntaktické správnosti EDS.
Příklad: Výpis ze souboru EDS
[FileInfo] FileName=newProject_line0.eds FileVersion=1 FileRevision=0 EDSVersion=4.0 Description=xxx CreationTime=10:15AM CreationDate=03-06-2005 CreatedBy=me ModificationTime=10:15AM ModificationDate=03-06-2005 ModifiedBy=me
[DeviceInfo] VendorName=xxx VendorNumber=0x0 ProductName=test ProductNumber=0x0 RevisionNumber=0x0 OrderCode= BaudRate_10=0 BaudRate_20=0 BaudRate_50=1 BaudRate_125=1 BaudRate_250=1 BaudRate_500=0 BaudRate_800=0 BaudRate_1000=0 DynamicChannelsSupported=0 GroupMessaging=0 LSS_Supported=0 Granularity=0 SimpleBootUpSlave=1 SimpleBootUpMaster=0 NrOfRXPDO=0 NrOfTXPDO=0
[MandatoryObjects] SupportedObjects=3 1=0x1000 2=0x1001 3=0x1018
[1000] ParameterName=Device Type ObjectType=0x07 DataType=0x0007 AccessType=const DefaultValue=0x00000000 PDOMapping=0
[1001] ParameterName=Error Register ObjectType=0x07 DataType=0x0005 AccessType=ro DefaultValue=0x00 PDOMapping=0
Formát popisu XDD založený na XML byl standardizován od začátku roku 2007 . Tento formát je založen na normě ISO 15745 a umožňuje podrobný popis funkcí zařízení. Aplikace je popsána nezávisle na CANopen a parametry aplikace jsou přiřazeny objektům CANopen.
K dispozici je bezplatný editor s názvem CANeds pro tento nový formát založený na XML i pro formát EDS, který byl platný dříve.
Individuální důkazy
- ↑ http://www.can-cia.org/can-knowledge/canopen/canopen/
- ↑ Některé z profilů zařízení lze zdarma stáhnout z webových stránek CiA.
- ↑ http://www.embedded-communication.com/canopen/energybus-the-canopen-based-communication-standard-for-levs-and-e-bikes/
- ↑ zdroj pro stahování volných EDS-checker CANchkEDS ( Memento na originálu z 28. ledna 2011 v Internet Archive ) Info: archiv odkaz se automaticky vloží a dosud nebyl zkontrolován. Zkontrolujte prosím původní a archivovaný odkaz podle pokynů a poté toto oznámení odstraňte.
- ↑ Zdroj pro stažení bezplatného editoru CANED
