CANopen - CANopen - Wikipedia
CANopen je komunikace protokol a specifikace profilu zařízení pro vestavěné systémy použito v automatizace. Z hlediska OSI model CANopen implementuje výše uvedené vrstvy a včetně síťová vrstva. Standard CANopen se skládá ze schématu adresování, několika malých komunikačních protokolů a protokolu aplikační vrstva definované profilem zařízení. Komunikační protokoly mají podporu pro správu sítě, monitorování zařízení a komunikaci mezi uzly, včetně jednoduché transportní vrstva pro segmentaci / desegmentaci zpráv. Protokol nižší úrovně implementující datové spojení a fyzické vrstvy je obvykle Controller Area Network (CAN), i když zařízení využívající jiné komunikační prostředky (např Ethernet Powerlink, EtherCAT ) lze také implementovat profil zařízení CANopen.
Základní zařízení a komunikační profily CANopen jsou uvedeny ve specifikaci CiA 301 vydané společností CAN v automatizaci.[1] Profily pro více specializovaná zařízení jsou postaveny na vrcholu tohoto základního profilu a jsou specifikovány v mnoha dalších standardech vydaných CAN in Automation, jako je CiA 401[2] pro I / O moduly a CiA 402[3] pro ovládání pohybu.
Model zařízení
Každé zařízení CANopen musí do svého řídicího softwaru implementovat určité standardní funkce.
- A komunikační jednotka implementuje protokoly pro zasílání zpráv s ostatními uzly v síti.
- Spouštění a resetování zařízení se ovládá pomocí a státní stroj. Musí obsahovat stavy Inicializace, Předprovozní, Provozní a Zastaveno. Přechody mezi stavy se provádějí vydáním komunikačního objektu správy sítě (NMT) zařízení.
- The slovník objektů je pole proměnných s 16bitovým indexem. Každá proměnná může mít navíc 8bitový subindex. Proměnné lze použít ke konfiguraci zařízení a odrážení jeho prostředí, tj. Obsahují data měření.
- The aplikace část zařízení ve skutečnosti vykonává požadovanou funkci zařízení poté, co je stavový stroj nastaven do provozního stavu. Aplikace je konfigurována proměnnými ve slovníku objektů a data jsou odesílána a přijímána prostřednictvím komunikační vrstvy.
Slovník objektů
Zařízení CANopen musí mít slovník objektů, který se používá pro konfiguraci a komunikaci se zařízením. Položka ve slovníku objektů je definována:
- Index, 16bitová adresa objektu ve slovníku
- Název objektu (Typ / velikost objektu), symbolický typ objektu v položce, například pole, záznam nebo jednoduchá proměnná
- název, řetězec popisující záznam
- Typ, dává datový typ proměnné (nebo datový typ všech proměnných pole)
- Atribut, který poskytuje informace o přístupových právech k této položce, může to být čtení / zápis, jen pro čtení nebo jen pro zápis
- The Povinné / nepovinné pole (M / O) definuje, zda zařízení splňující specifikaci zařízení musí tento objekt implementovat nebo ne
Základní typy dat pro hodnoty slovníku objektů, například booleovi, celá čísla a plováky jsou definovány ve standardu (jejich velikost v bitech je volitelně uložena v definici souvisejícího typu, rozsah indexu 0x0001–0x001F), stejně jako složené datové typy, jako jsou řetězce, pole a záznamy (definované v rozsahu indexu 0x0040–0x025F). Složené datové typy lze subindexovat pomocí 8bitového indexu; hodnota v subindexu 0 pole nebo záznamu označuje počet prvků v datové struktuře a je typu UNSIGNED8.
Například komunikační parametry zařízení standardizované v základním profilu zařízení CiA 301[4] jsou mapovány v rozsahu indexů 0x1000–0x1FFF („oblast komunikačního profilu“). Prvních několik záznamů v této oblasti je následující:
Index | Název objektu | název | Typ | Atribut | M / O |
---|---|---|---|---|---|
0x1000 | VAR | typ zařízení | 32 | ro | M |
0x1001 | VAR | registr chyb | 8. BEZPLATNÉ | ro | M |
... | |||||
0x1008 | VAR | název zařízení výrobce | Vis-String | konst | Ó |
... |
Díky vhodným nástrojům lze obsah slovníku objektů zařízení na základě elektronického datového listu (EDS) přizpůsobit konfiguračnímu souboru zařízení (DCF), aby bylo možné zařízení integrovat do konkrétní sítě CANopen. Podle CiA 306[5], formát souboru EDS je Soubor INI formát. Existuje připravovaný formát ve stylu XML, který je popsán v CiA 311[6].
Sdělení
Komunikační objekty
Sběrnice CAN, vrstva datového spojení CANopen, může přenášet pouze krátké balíčky skládající se z 11bitového ID, bitu požadavku na vzdálený přenos (RTR) a 0 až 8 bajtů dat. Standard CANopen rozděluje 11bitové ID rámce CAN na 4bitový funkční kód a 7bitové ID uzlu CANopen. To omezuje počet zařízení v síti CANopen na 127 (0 je vyhrazeno pro vysílání). Rozšíření standardu sběrnice CAN (CAN 2.0 B) umožňuje rozšířená ID rámců o 29 bitů, ale v praxi jsou sítě CANopen dostatečně velké, aby potřebovaly rozšířený rozsah ID, vidět jen zřídka.
V CANopen je 11bitové ID rámce CAN známé jako identifikátor komunikačního objektu nebo COB-ID. V případě kolize přenosu umožňuje arbitrace sběrnice použitá na sběrnici CAN jako první a bez zpoždění přenos rámce s nejmenším ID. Použití nízkého číselného čísla pro časově kritické funkce zajišťuje nejnižší možné zpoždění.
Obsah rámu CANopen:
CAN-ID | RTR | Délka dat | Data | |
---|---|---|---|---|
Délka | 11 bitů | 1 bit | 4 bity | 0-8 bajtů |
Datový rámec s 11bitovým identifikátorem se také nazývá „formát základního rámce“.
Výchozí mapování CAN-ID třídí rámce přiřazením funkčního kódu (NMT, SYNC, EMCY, PDO, SDO ...) prvním 4 bitům, takže prioritu mají kritické funkce. Toto mapování však lze přizpůsobit pro speciální účely (kromě NMT a SDO, které je vyžadováno pro základní komunikaci).
Kód funkce | ID uzlu | |
---|---|---|
Délka | 4 bity | 7 bitů |
Standard vyhrazuje určité CAN-ID pro správu sítě a převody SDO. Některé funkční kódy a CAN-ID je třeba po inicializaci zařízení namapovat na standardní funkce, ale později je lze nakonfigurovat pro další použití.
Předdefinovaná sada připojení[7]
Pro jednoduché síťové struktury podporuje CANopen předdefinované přidělení identifikátorů zpráv.
Komunikační objekt | COB-ID hex | Slave uzly | Specifikace |
---|---|---|---|
Řízení uzlu NMT | 000 | Pouze přijímat | CiA 301 |
Globální zabezpečený příkaz | 001 | ? | CiA 304 |
Sync | 080 | Pouze přijímat | CiA 301 |
Nouzový | 080 + NodeID | Vysílat | CiA 301 |
Časové razítko | 100 | Pouze přijímat | CiA 301 |
CHOP | 180 + NodeID 200 + NodeID 280 + NodeID 300 + NodeID 380 + NodeID 400 + NodeID 480 + NodeID 500 + NodeID | 1. Vysílejte CHOP 1. Získejte CHOP 2. Vysílejte CHOP 2. Získejte CHOP 3. Vysílejte CHOP 3. Získejte CHOP 4. Předejte CHOP 4. Získejte CHOP | CiA 301 |
SDO | 580 + NodeID 600 + NodeID | Vysílat Dostávat | CiA 301 |
Monitorování uzlů NMT (hlídání uzlů / tlukot srdce) | 700 + NodeID | Vysílat | CiA 301 |
LSS | 7E4 7E5 | Vysílat Dostávat | CiA 305 |
Komunikační modely
Ve zprávách mezi uzly CANopen se používají různé druhy komunikačních modelů.
V otrokář vztahu je jeden uzel CANopen označen jako hlavní, který odesílá nebo požaduje data od podřízených. Protokol NMT je příkladem komunikačního modelu master / slave.
A klient-server vztah je implementován v protokolu SDO, kde klient SDO odesílá data (index slovníku objektů a subindex) na server SDO, který odpovídá jedním nebo více balíčky SDO obsahujícími požadovaná data (obsah slovníku objektů v daném indexu ).
A výrobce / spotřebitel model se používá v protokolech Heartbeat a Node Guarding. V push-model výrobce / spotřebitele odesílá výrobce údaje spotřebiteli bez konkrétního požadavku, zatímco v EU tažný model, musí spotřebitel požadovat údaje od výrobce.
Protokoly
Protokoly pro správu sítě (NMT)
Protokoly NMT se používají k vydávání příkazů ke změně stavového stroje (např. Ke spuštění a zastavení zařízení), k detekci spuštění vzdáleného zařízení a chybových stavů.
The Řídicí protokol modulu je používán NMT masterem ke změně stavu zařízení. CAN-frame COB-ID tohoto protokolu je vždy 0, což znamená, že má funkční kód 0 a ID uzlu 0, což znamená, že každý uzel v síti tuto zprávu zpracuje. Skutečné ID uzlu, ke kterému je příkaz určen, je uvedeno v datové části zprávy (na druhém bajtu). Může to být také 0, což znamená, že všechna zařízení na sběrnici by měla přejít do indikovaného stavu.
COB-ID | Datový bajt 0 | Datový bajt 1 |
---|---|---|
0x000 | Požadovaný stav | Adresovaný uzel |
Příkazový kód NMT | Význam |
---|---|
0x01 | Přejít na „funkční“ |
0x02 | Přejít na „zastaveno“ |
0x80 | Přejít na „předprovozní“ |
0x81 | Přejít na 'resetovat uzel' |
0x82 | Přejít na ‚resetovat komunikaci ' |
The Prezenční signál se používá k monitorování uzlů v síti a k ověření, že jsou naživu. Producent prezenčního signálu (obvykle podřízené zařízení) pravidelně zasílá zprávu s binárním funkčním kódem 1110 a jeho ID uzlu (COB-ID = 0x700 + ID uzlu). Datová část rámce obsahuje bajt označující stav uzlu. Zákazník prezenčního signálu čte tyto zprávy. Pokud zprávy nedorazí v určitém časovém limitu (definovaném ve slovníku objektů zařízení), může spotřebitel provést akci, například resetovat zařízení nebo označit chybu. Formát rámečku je:
COB-ID | Datový bajt 0 |
---|---|
0x700 + ID uzlu | Stát |
Stavový kód NMT | Zastoupený stát |
---|---|
0x00 | Spuštění (inicializace) |
0x04 | Zastavil |
0x05 | Provozní |
0x7f | Předprovozní |
Zařízení CANopen jsou povinna provést přechod ze stavu Inicializace do Předprovozní automaticky během bootování. Když je tento přechod proveden, je na sběrnici odeslána jedna prezenční signál. To je bootovací protokol.
Pro monitorování slave existuje protokol typu odpověď / odpověď (pull model), který se nazývá hlídání uzlů.
Protokol servisních datových objektů (SDO)
Protokol SDO se používá pro nastavení a pro čtení hodnot ze slovníku objektů vzdáleného zařízení. Zařízení, jehož objektový slovník je přístupný, je server SDO a zařízení přistupující ke vzdálenému zařízení je klient SDO. Komunikace je vždy iniciována klientem SDO. V terminologii CANopen se komunikace zobrazuje ze serveru SDO, takže čtení ze slovníku objektů má za následek upload SDO a zápis do slovníku je stahování SDO.
Protože hodnoty slovníku objektů mohou být větší než limit osmi bajtů rámce CAN, protokol SDO implementuje segmentaci a desegmentaci delších zpráv. Ve skutečnosti existují dva z těchto protokolů: SDO download / upload a SDO Block download / upload. Přenos bloku SDO je novějším doplňkem standardu, který umožňuje přenos velkého množství dat s mírně menší režií protokolu.
COB-ID příslušných SDO přenášejících zprávy z klienta na server a ze serveru na klienta lze nastavit ve slovníku objektů. Ve slovníku objektů lze nastavit až 128 serverů SDO na adresách 0x1200 - 0x127F. Podobně lze klientské připojení SDO zařízení konfigurovat s proměnnými na 0x1280 - 0x12FF. Nicméně předdefinovaná sada připojení definuje kanál SDO, který lze použít i po spuštění (ve stavu před spuštěním) ke konfiguraci zařízení. COB-ID tohoto kanálu jsou 0x600 + ID uzlu pro příjem a 0x580 + ID uzlu pro vysílání.
Pro zahájení stahování odešle klient SDO následující data ve zprávě CAN s „přijetím“ COB-ID kanálu SDO.
Byte Nr: | Bajt 1 | Byte 2-3 | Bajt 4 | Byte 5-8 | ||||
---|---|---|---|---|---|---|---|---|
Délka: | 3 bity | 1 bit | 2 bity | 1 bit | 1 bit | 2 bajty | 1 bajt | 4 byty |
Význam: | ccs = 1 | rezervováno (= 0) | n | E | s | index | subindex | data |
- ccs je specifikátor příkazu klienta pro přenos SDO, toto je 0 pro stahování segmentu SDO, 1 pro zahájení stahování, 2 pro zahájení nahrávání, 3 pro nahrávání segmentu SDO, 4 pro zrušení přenosu SDO, 5 pro nahrávání SDO bloku a 6 pro SDO blokovat stahování
- n je počet bytů v datové části zprávy, které neobsahují data, platí pouze v případě, že jsou nastaveny e a s
- E, pokud je nastaveno, označuje zrychlený přenos, tj. všechna vyměněná data jsou obsažena ve zprávě. Pokud je tento bit vymazán, pak je zprávou segmentovaný přenos, kde se data nevejdou do jedné zprávy a použije se více zpráv.
- s, pokud je nastaveno, označuje, že velikost dat je specifikována v n (pokud je nastaveno e) nebo v datové části zprávy
- index je index slovníku objektů dat, která mají být zpřístupněna
- subindex je subindex proměnné slovníku objektů
- data obsahuje data, která se mají nahrát v případě zrychleného přenosu (nastaví se e), nebo velikost dat, která se mají nahrát (nastaví se s, nastaví se e)
Zpracovat protokol PDO (Data Data Object)
Protokol Process Data Object se používá ke zpracování dat v reálném čase mezi různými uzly. Můžete přenášet až 8 bajtů (64 bitů) dat na jeden CHOP buď ze zařízení, nebo do zařízení. Jeden PDO může obsahovat více záznamů slovníku objektů a objekty v jednom PDO lze konfigurovat pomocí záznamů slovníku mapování a parametrů.
Existují dva druhy PDO: vysílací a přijímací PDO (TPDO a RPDO). První je pro data pocházející ze zařízení (zařízení je producentem dat) a druhá pro data směřující do zařízení (zařízení je spotřebitel dat); to znamená, že s RPDO můžete odesílat data do zařízení a s TPDO můžete číst data ze zařízení. V předdefinované sadě připojení jsou k dispozici identifikátory pro čtyři (4) TPDO a čtyři (4) RPDO. S konfigurací je možné 512 PDO.
PDO lze odesílat synchronně nebo asynchronně. Synchronní PDO se odesílají po zprávě SYNC, zatímco asynchronní zprávy se odesílají po interním nebo externím spuštění. Například můžete požádat zařízení o přenos TPDO, který obsahuje data, která potřebujete, odesláním prázdného TPDO s příznakem RTR (pokud je zařízení nakonfigurováno tak, aby přijímalo požadavky TPDO).
S RPDO můžete například spustit dvě zařízení současně. Musíte pouze namapovat stejné RPDO na dvě nebo více různých zařízení a ujistit se, že tyto RPDO jsou mapovány se stejným COB-ID.
Protokol Synchronization Object (SYNC)
Sync-Producer poskytuje synchronizační signál pro Sync-Consumer. Když Sync-Consumer obdrží signál, začne vykonávat své synchronní úkoly.
Obecně platí, že stanovení doby přenosu synchronních zpráv PDO ve spojení s periodicitou přenosu synchronizačního objektu zaručuje, že senzorová zařízení mohou uspořádat vzorkování procesních proměnných a že akční zařízení mohou aktivovat svoji aktivaci koordinovaně.
Identifikátor synchronizačního objektu je k dispozici na indexu 1005h.
Protokol Time Stamp Object (TIME)
Objekt Time-Stamp obvykle představuje čas jako 6bajtové pole: počet milisekund po půlnoci (maximálně 27 bitů uložených v 32bitovém poli) a nepodepsaný 16bitový počet dní od 1. ledna, 1984. (To přeteče 7. června 2163.)
Některé časově kritické aplikace, zejména ve velkých sítích se sníženými přenosovými rychlostmi, vyžadují velmi přesnou synchronizaci; může být nutné synchronizovat místní hodiny s přesností v řádu mikrosekund. Toho je dosaženo použitím volitelného synchronizačního protokolu s vysokým rozlišením, který využívá speciální formu zprávy s časovým razítkem k úpravě nevyhnutelného posunu místních hodin.
Časové razítko s vysokým rozlišením je kódováno jako unsigned32 s rozlišením 1 mikrosekundu, což znamená, že se počítadlo času restartuje každých 72 minut. Konfiguruje se mapováním časového razítka s vysokým rozlišením (objekt 1013h) na PDO.
Protokol nouzového objektu (EMCY)
Nouzové zprávy jsou spouštěny výskytem závažné interní chybové situace zařízení a jsou přenášeny z příslušného aplikačního zařízení do ostatních zařízení s vysokou prioritou. Díky tomu jsou vhodné pro upozornění na chyby typu přerušení. Nouzový telegram lze odeslat pouze jednou za „chybovou událost“, tj. Nouzové zprávy se nesmí opakovat. Dokud na zařízení nedojde k žádným novým chybám, není nutné zasílat žádné další nouzové zprávy. Prostřednictvím nouzových chybových kódů definovaných komunikačním profilem CANopen jsou v profilech zařízení specifikovány registr chyb a další specifické informace o zařízení.
Inicializace
Ukázka trasování komunikace mezi nadřízeným a dvěma podřízenými převodníky tlaku nakonfigurovanými pro ID 1 a ID uzlu 2.
CAN ID | DÉLKA DAT | DATA | Popis |
---|---|---|---|
0x0 | 2 | 01 00 | Master uvede všechna zařízení na sběrnici do provozního režimu |
0x80 | 0 | Master odešle zprávu SYNC, která aktivuje zařízení k odesílání dat | |
0x181 | 4 | CD 82 01 00 | Uzel na ID 1 (CID-0x180), snímací tlak 0x0182CD (99021) pascaly |
0x182 | 4 | E5 83 01 00 | Uzel na ID 2 (CID-0x180), čtecí tlak 0x0183E5 (99301) pascalů |
Elektronický datový list
Electronic Data Sheet (EDS) je formát souboru definovaný v CiA306, který popisuje chování komunikace a položky slovníku objektů zařízení. To umožňuje nástrojům, jako jsou servisní nástroje, konfigurační nástroje, vývojové nástroje a další, se zařízeními správně zacházet.
Tyto soubory EDS jsou povinné pro absolvování testu shody CiA CANopen.
Od konce roku 2007 nový XML formát založený na XDD je definován v CiA311. XDD odpovídá ISO standardní 15745.
Glosář pojmů CANopen
- CHOP: Zpracovat datový objekt - vstupy a výstupy. Hodnoty typu rotační rychlosti, napětí, frekvence, elektrického proudu atd.
- SDO: Servisní datový objekt - nastavení konfigurace, případně ID uzlu, přenosová rychlost, offset, zisk atd.
- COB-ID: Identifikátor komunikačního objektu
- CAN ID: Identifikátor CAN. Toto je 11bitový identifikátor zprávy CAN, který je na začátku každé zprávy CAN na sběrnici.
- EDS: Elektronický datový list. Toto je soubor ve formátu INI nebo XML.
- DCF: Konfigurační soubor zařízení. Toto je upravený soubor EDS s nastavením ID uzlu a přenosové rychlosti.
Viz také
- Řídicí síť je článek o sběrnici CAN.
- J1939
- DeviceNet
- IEEE 1451
- TransducerML
Reference
- ^ Specifikace aplikační vrstvy CiA 301 CANopen, ke stažení zdarma z CAN v automatizaci
- ^ Specifikace elektronického datového listu (EDS) CiA 306 CANopen
- ^ Specifikace CiA 311 CANopen XML-EDS
- ^ Předdefinovaná sada připojení ze základů CANopen [8]
- ^ Specifikace profilu zařízení CiA 401 CANopen pro obecné I / O moduly, volně ke stažení z CAN v automatizaci
- ^ Profil zařízení CiA 402 CANopen pro pohybové ovladače a pohony (stejné jako IEC 61800-7-201 / 301)
externí odkazy
- CANopen Origins - projekt Esprit ASPIC 1993 (Bosch, Newcastle University, University of Applied Science v Reutlingenu)
- O CANopen (canopensolutions.com)
- Použití identifikátoru v sítích CANopen
- CanFestival - Open source CANopen multiplatformní framework
- CanOpenNode - Open source CANopen framework pro mikrokontroléry a Linux
- Lely CANopen - An open source CANopen knihovna pro pány a otroky
- openCANopen - otevřený zdroj CANopen master
- Projekt CANopen Stack - flexibilní open source zásobník CANopen pro mikrokontrolér
- CANopen pro Python
- CANnewsletter - informace o CAN, CANopen a J1939
- Vzdělávací stránky CANopen
- Úvod do CANopen Fundamentals (na www.canopen-solutions.com)
- Wiki komunity CANopen-Lift
- CANeds: Zdarma editor EDA a XDD soubory
- Informace CAN pro průmysl
- Online portál CAN v automatizaci
- CANopen - aplikační vrstva a obecný komunikační profil
- CANopen - jednoduché intro (včetně převaděče COB ID)