Díl 1 - Čtení dlouhého SDO, vyžadování jednotlivých segmentů
Díl 2 - Mapování objektů do PDO
Díl 7 - Nodeguarding a Heartbeat
V předchozím dílu jsme si ukázali mapování dat - objektů do TPDO a ukázali jsme si generování TPDO na základě příjmu zprávy SYNC. V tomto díle se budeme věnovat hlavně teorii.
Nejdříve se ještě vrátíme k mapování a konfiguraci PDO. Obvykle CANopen síť zařízení pracuje tak, že je na CAN sběrnici master a několik slave nodů. Master generuje dle potřeby zprávy NMT, SYNC, zpracovává chyby a provádí distribuci dat. V tomto případě tedy veškerá data jsou mezi CANopen nody distribuována jeho prostřednictvím. Tedy master odesílá například SYNC zprávu. Jednotlivé nody odesílají svoje TPDO, master je čte a provádí distribuování dále. Nody je přijímají jako RPDO.
Předností tohoto řešení je snadná konfigurace, vše máme pod kontrolou na jednom místě. Obvykle můžeme využít výchozího mapování objektů (dat) do PDO. Celá konfigurace je tak značně zjednodušena. Negativem ovšem je zpoždění dat.
Druhá varianta předpokládá, že data si mezi sebou posílají přímo jednotlivé nody. To vyžaduje změnu výchozího nastavení CAN identifikátoru, pod kterým jsou data odesílána jako TPDO nebo přijímána jako RPDO. Může se stát, že přijdeme k systému, který navrhoval někdo jiný a budeme v něm hledat chybu. Pokud jsou v něm přemapována COB-ID jak pro RPDO tak pro TPDO, nepoznáme z CAN identifikátoru na první pohled kdo je zdrojem dat. Proto je vhodné se držet jednoduchého pravidla a upravovat pouze COB-ID u RPDO. Protože nastavení TPDO zůstane ve výchozím stavu, stále z identifikátoru poznáme my a nebo někdo jiný po nás kdo je zdrojem zprávy.
Výhodou tohoto řešení je také to, že snižujeme zatížení CAN sběrnice a zpoždění (latence) dat. Není třeba zpráva mezi nodem a masterem a druhá mezi masterem a nodem ale vystačíme s jednou zprávou která jde přímo. V případě, že jedna data mají číst 2 nody, je možné COB ID RPDO u dvou nodů nastavit na stejný identifikátor. Obě zařízení tak budou číst data v jeden okamžik z jednoho zdroje. Toto také dále snižuje zatížení sběrnice.
Během návrhu je taktéž vhodné dbát na prioritu CAN zpráv. Budeme li na CAN sběrnici přenášet například polohu, požadované otáčky, teplotu motoru a koncové spínače, je dobré systém navrhnout tak, aby CAN zprávy s koncovými spínači měla maximální prioritu. Naopak teplota motoru je děj, který se mění relativně pomalu, identifikátory tak mohou mít malou prioritu. Údaje o poloze či otáčkách pak budou mít prioritu uprostřed. Jen pro připomenutí, pro CAN bus platí, že větší prioritu mají zprávy s menší hodnotou identifikátoru. I proto má největší prioritu NMT, následuje SYNC, potom PDO a až po něm SDO (konfigurace).
Tuto prioritu lze ovlivnit 2 způsoby, změnou Node ID nebo úpravou COB ID jednotlivých PDO.
TPDO Transmission type
Tímto parametrem pro každé TPDO se nastavuje podmínka, kdy jsou data generovány na CAN sběrnici. Existují 3 základní podmínky:
- událost, tedy změna stavu, hodnoty, časovač
- požadavek na data - RTR zpráva
- zpráva SYNC
| Hodnota | Popis | |
|---|---|---|
| 00h | 0d | Acyklický (necyklický) synchronnní, TPDO se odešle po příchodu zprávy SYNC pokud došlo ke změně některé namapované hodnoty od předchozího odeslání |
| 01h-F0h | 1d-240d | Cyklický synchronní, TPDO se odešle po přijetí N-té zprávy SYNC. Tedy je li nastavena hodnota 1, je TPDO odesláno s každou přijatou zprávou SYNC. Pokud je nastavena hodnota 2, je TPDO odesláno po přijetí každé druhé zprávy SYNC a tak dále až do hodnoty 240. |
| F1h-FBh | 241d-251d | Nevzužito |
| FCh | 252d | Synchronní RTR - měřená hodnota se sampluje s příchodem SYNC, odešle se po příchodu RTR. |
| FDh | 253d | Asynchronní RTR - hodnota je změřena a odeslána při příchodu RTR. |
| FEh | 254d | Asynchronní: Odesláno při změně stavu, uplynutí času. Událost která vyvolá odeslání specifikuje výrobce zařízení. |
| FFh | 255d | Asynchronní: Odesláno při změně stavu, uplynutí času. Událost která vyvolá odeslání je specifikována profilem zařízení. |
Je třeba tu poznamenat že například při nastavení 0, 1-240, 254 a 255 může být TPDO odesláno také při příchodu RTR ale záleží na konkrétní implementaci. Mohou existovat zařízení, která RTR vůbec nepodporují a pak nepodporují vůbec nastavení 252 a 253. Nový protokol CAN FD ani zprávy RTR nepodporuje. Taktéž je tu třeba poznamenat že mohou existovat zařízení které změnu nastavení Transmission type vůbec nepodporují.
Ač se již obecně používaní zpráv RTR nedoporučuje, při vývoji vlastního zařízení mohou být v kombinaci s vhodným CAN bus řadičem dobře využita ke snížení zátěže MCU. Mnoho řadičů typu FullCAN podporuje funkci kdy do příslušného transmit bufferu nastavíme data - tedy updatujeme například měřené veličiny a zpráva z bufferu je automaticky odeslána na CAN jakmile dorazí po CAN sběrnici RTR zpráva se stejným identifikátorem. Naše aplikace v MCU se tak vůbec nemusí starat o odeslání dat a při vhodném nastavení masek a filtrů tuto zprávu nemusí naše aplikace zpracovávat čímž šetří svůj strojový čas.
Budeme li pracovat s CANopen zařízením generování zprávy SYNC zajistíme v SW PP2CAN v nástroji CANopen snadno na kartě SYNC.
