Komunikujeme s měniči SERVOSTAR 400/600

 

Díl první: Úvod

    Servostar 600/400 jsou univerzální servozesilovače pro řízení servopohonů od firmy Kollmorgen Seidel GmbH & Co. Jejich distributorem je například firma TGdrives. Pro komunikaci s tímto zařízením lze využít sběrnice CAN nebo PROFIBUS. My se samozřejmě budeme zabývat rozhraním CAN. Zařízení pracuje podle standardu CANopen CiA301 (Communication profile for Industrial Systems ). V prvních částech tohoto seriálu se tedy budeme seznamovat s implementací tohoto komunikačního standardu.

    Specifikace sběrnice CAN prvních dvou vrstev modelu ISO OSI, tj. vrstvy fyzické a linkové. Aby byla usnadněna vzájemná interoperabilita zařízení různých výrobců, vznikly různé high-level protokoly, které přesně definují způsob komunikace zařízení dané kategorie a definují tak aplikační vrstvu dle ISO OSI. CANopen rozšiřuje definici CAL o další služby a definuje komunikační profily pro často užívaná zařízení v průmyslové automatizaci. Pro zájemce o hlubší prostudování doporučuji tyto dokumenty:

        - CiA DS-102: CAN Physical Layer for Industrial Applications

        - CiA DS-301: CAL-based communication profile for industrial systems

        - CiA DSP-302: Framework for programmable CANopen devices

        - CiA DR-303-2:  Representation of SI units and prefixes

        - CiA DR-303-3: Indicator Specification

        - CiA DR-303-4: LSS - Layer Setting Services and Protocol

        - CiA DSP-305: CANopen LSS Services and Protocol

        - CiA DSP-306: Electronic Data Sheet (EDS) Specification for CANopen

        - CiA DS-307: Framework Maritime Electronics¨

        - CiA DSP-420-1:  CANopen Profiles for Extruder Downstream Devices

        - CiA DS-401: Device profile for I/O modules

        - CiA DS-402: Device profile for drives and motion control

        - CiA DS-403: Device profile for human machine interfaces

        - CiA DS-404: Device profile for measuring devices and closed-loop controllers

        - CiA DS-405: Interface and Device Profile for IEC 61131-3 Programmable Devices

        - CiA DS-406: Device profile for encoders

        - CiA DS-407: Public transportation - Passenger Information Systems

        - CiA DS-408: Device profile fluid power technology proportional valves and hydrostatic transmissions

        - CiA DS-409: Vehicle door control

        - CiA DS-410: Device profile for inclinometer

        - CiA DS-412: Medical Devices

        - CiA DS-413: Truck Gateways

        - CiA DS-414: Weaving Machines

        - CiA DS-415: Device profile for road construction machinery

        - CiA DS-416: Building Door Control

        - CiA DS-417: Lift Control Systems

        - CiA DS-418: Device profile for battery modules

        - CiA DS-419: Device profile for battery chargers

        - CiA DS-420: Profiles for extruder downstream devices

        - CiA AN-801: Automatic bit-rate detection

        - atd.

    Popis funkcí a parametru zařízení se nachází v adresáři objektu (object dictionary), který obsahuje část s obecnou specifikací zařízení, jako jeho název, výrobce, komunikační parametry atd., a potom část, která obsahuje určitou funkčnost zařízení, parametry a data. Každá položka v adresáři se nazývá objekt a je určena 16-bitovým indexem a 8-bitovým subindexem.

    Rozlišují se dva základní mechanismy přenášení zpráv na CANopen. Procesní data určená pro časově kritickou výměnu, nazývaná Process Data Objects (PDO) a služební zprávy, jejichž doručení není časově kritické, nazývané Service Data Objects SDO. SDO se používají především pro přenášení a nastavení parametru při konfiguraci zařízení nebo pro přenášení delších zpráv. Zpráva na CANu muže obsahovat maximálne 8 bytu dat. V případě že není možné přenést data v jedné zprávě, musí být zpráva rozsegmentována do několika zpráv. Maximální délka dat není omezena.

    Procesní data se přenášejí bud cyklicky, při změně nebo na vyžádání jako broadcastové zprávy  Rozmístění aplikačních objektu (položek z adresáre objektu) do přenášeného objektu PDO je určeno pomocí tzv. mapování PDO – tato informace je uložena v adresáři objektu a muže být změněna podle požadavku aplikace.

    CANopen využívá standardních 11-bitových identifikátorů. Identifikátory jsou rozděleny do několika skupin dle následující tabulky:

    Vlastní identifikátor (COB-ID, Communication Object ID) má tedy následující strukturu:

 

    Priorita zprávy je dána hodnotou identifikátoru. Platí že zprávy s nižším COB-ID mají vyšší prioritu. Priorita se uplatňuje při kolizi přenášených dat na sběrnici, kdy dojde k přerušení odesílání zprávy s nižší prioritou. Zprávy NMT, SYNC a Time-Stamp jsou typu broadcast.

NMT

(Network Management)

    Zpráva se skládá z identifikátoru a dvou datových bytů. Identifikátor má hodnotu 0. První byte je označován jako CS (Command Specifier), druhý byte obsahuje identifikátor node ID. Node ID bývá definován HW přepínačem. Může obsahovat hodnoty 1-127. Pak je zpráva určena právě jednomu nodu. Je-li node ID rovno 0, je zpráva určen všem jednotkám. 

    Command Specifier může nabývat těchto významů a hodnot:

    Příště budeme pokračovat popisem NMT a probereme i další skupiny zpráv.

Díl druhý: Popis CANOpen

    CAN open slave zařízení se může nacházet v jednom ze tří stavů:

            - Pre-Operational State (jen SDO*, konfigurace PDO*)

            - Operational_State (SDO* i  PDO*)

            - Prepared_State (jednotka disablována, není možná komunikace SDO/PDO/emergency*)

    (* vysvětleno později)

    Po připojení zařízení (CANopen slave) k napájení přejde zařízení do stavu Pre-Operational.

    Je-li jednotka ve stavu Pre-Operational je možno ji přepnout do stavu:

            - Operational příkazem Start Remote Node

            - Prepared State příkazem Stop Remote Node

            - Resetovat příkazem Reset Node nebo Reset Communication

    Ve stavu Operational je možno přepnou do stavu:

            - Prepared State příkazem Stop Remote Node

            - Pre-Operational State příkazem Enter Pre-Operational State

            - Resetovat příkazem Reset Node nebo Reset Communication

    Ve stavu Prepared je možno ji přepnout do stavu:

            - Pre-Operational State příkazem Enter Pre-Operational State

            - Operational příkazem Start Remote Node

            - Resetovat příkazem Reset Node nebo Reset Communication

 

SYNC

    PDO zprávy které mohou obsahovat různé měřené veličiny - stavy mohou být konfigurovány tak aby se odesílaly synchronně při obdržení zprávy SYNC. Tato zpráva má hodnotu identifikátoru 128 a neobsahuje žádná data (počet datových bytů je nulový).

EMERGENCY

    Tyto zprávy jsou generovány zařízením, dojde-li k závažné chybě. Zpráva je při vzniku chyby generována pouze jednou při vyniku této události. Chyba je uložena v Error registru, objekt 1001h. Identifikátor zprávy má rozsah 129-255d (kód 0001b+module ID). Datová část zprávy má následující strukturu:

  Time-Stamp

    Time Stamp message (ID 256) má délku 6 bajtů a obsahuje počet milisekund od půlnoci a počet dnů od 1. ledna 1984. Toto 48 bitové pole v datové části zprávy má následující strukturu:

        - unsigned28 ms od půlnoci

        - 4 bity nevyužit

        - unsigned16 dny od 1. ledna 1984

    Tato zpráva není servozesilovačem SERVOSTAR 600 podporována.

Díl třetí: SDO - Service Data Objects

    SDO zprávy jsou určeny pro přístup k adresáři aplikačních objektů. Zpráva má vždy délku 8 bajtů. Vlastní data mají délku 4 bajtů. Jsou-li data delší než 4 bajty je zpráva rozdělena do několika 7 bajtových segmentů. Pro n segmentů je třeba (n+1)*2 zpráv. Na každou zprávu master command odpovídá jednotka slave zprávou reponse. Data jsou uložena ve formátu little endian (intelovský formát).

    Adresář objektů (Object Dictionary) obsahuje objekty, které jsou nezbytné pro zobrazení všech vlastností a parametru zařízení, pokud tyto vlastnosti a parametry mají být přístupné prostřednictvím sběrnice CAN. Jestliže objekt s určitým indexem obsahuje několik dalších položek označených příslušnými sub-indexy, pak je hodnota nejvyššího využitého sub-indexu uložena v položce se sub-indexem 0. Indexy se používají pro takzvané profily zařízení. Standardní profily jsou definovány v rozmezí indexu 0x6000 – 0x9FFF. Pro funkce specifikované určitým výrobcem je vymezeno rozmezí indexu 0x2000 – 0x5fff. Hrubou mapu objektů zobrazuje následující obrázek.

    Čtení objektu z adresáře: master požaduje data z adresáře objektů, délka dat je do 4 bajtů

     Bajt Command má tvar 010000000b.

    Slave vrací požadovaná data:

  

     Celkový počet bajtů v následujícím přenosu je uložen v poli Length v odpovědí kterou zasílá slave jednotka. DB4 obsahuje LSB, DB7 pak MSB. Následně  jsou segmenty zasílány z jednotky slave po požadavku mastera:

DB0 - command má následující tvar:

Slave pak zasílá příslušný segment data:

    

---

Stejné mechanismy jako pro čtení dat z adresáře objektů existují i pro zápis data. Následuje tedy popis struktury zpráv při zápisu.

V případě že data která budeme do objektu zapisovat obsahují 4 a méně bajtů, jsou potřeba 2 zprávy. První je zpráva od mastera se zapisovanými daty, druhou pak potvrzení od slave jednotky. Master tedy zasílá zprávu tohoto tvaru:

Kde Command má tuto strukturu:

Slave pak odpovídá takto:

 

---

Pokud data objektu obsahují více než 4 bajty, je použit opět přenos po segmentech. Master nejprve inicializuje zápis takto:

 

Následně slave potvrdí požadavek takto:

 

Dále pak master generuje jednotlivé segmenty dat:

 

Každý segment je potvrzen slave jednotkou:

 

    V dalším díle budeme pokračovat v popisu SDO, popíšeme si chyby, které mohou vzniknout při čtení/zápisu do adresáře objektů. Nudnou teorii pak doplníme předvedením praktické komunikace se servozesilovačem Servostar 600.

Díl čtvrtý: SDO - Service Data Objects: od teorie k praxi

    Dojde li během čtení nebo zápisu k výskytu chyby, odešle slave místo normální odpovědi chybovou zprávu. Obdobně master muže také přerušit komunikaci zasláním chybové zprávy (Abort Transfer). Tato zpráva má následující tvar:

 

  

     Chyba je dána hodnotou Error Code (DB6) a Error Class (DB7), některé chyby jsou pak rozvinuty hodnotou v poli Additional Code.

     Nyní tedy něco praktického, budeme požadovat zjistit informace o tom, co máme vlastně připojeno za zařízení na sběrnici. K tomu můžeme použít objekt 1018h. Každý výrobce a jeho produkt má přiděleno identifikační číslo kterým jej můžeme identifikovat, takzvané Vendor ID a Product Code. Jednotlivé položky tohoto objektu vidíme na následujícím obrázku. Tento popis také představuje standardní formu, jak jsou v dokumentaci jednotlivé aplikační objekty popisovány.

   

    První položka objektu Identity Object s indexem 1018h, subindex 0 se jmenuje "Number of entries" udává počet podobjektů (subindexů) objektu. Rozsah hodnot subindexu pro podobjekty je 1..4. Na subindexu 1 je uloženo Vendor ID, dále pak subindex 2 obsahuje Product Code, subindex 3 obsahuje Revision Number a obsahem posledního subindexu 4 je Serial Number. 

    V případě že budeme testovat zařízení s Node ID 1 a budeme používat program PP2CAN, bude zpráva kterou vyplníme vypadat takto:

    Zpráva bude mít identifikátor ve standardním formátu, jelikož se jedná o zprávu SDO zasílanou masterem jednotce slave s node ID 1, bude identifikátor mít hodnotu 1537d  (601h). Délka SDO zpráv je vždy 8. DB0 - command bude mít hodnotu 64d tj. 40h. V DB1 a DB2 zadáváme index objektu 1018h, v DB1 je dolní bajt, zapsán dekadicky tj. 24d (18h), v DB2 pak horní bajt 16d (10h). Protože zjišťujeme Vendor ID, bude mít subindex hodnotu 01. Data budou nulová.

Odpověď kterou nám jednotka zašle si popíšeme v dalším pokračování. Dále si rozebereme zaslání dalších dotazů a povelů.

Díl pátý: Komunikujeme

    Minulou kapitolu jsme ukončili odesláním SDO zprávy, která nám měla vrátit Vendor ID. V dokumentaci od Servostaru 600 se dočteme, že hodnota Vendor ID je typu UNSIGNED32 a jeho hodnota je v hexadecimálním formátu 00 00 00 6Ah, tzn. Kollmorgen - Seidel GmbH & Co. KG. Nejnižší bajt s hodnotou 6Ah je dekadicky 106, ostatní bajty jsou nulové. To koresponduje s odpovědí, kterou obdržíme zpět a kterou vidíme na následujícím obrázku.

    Při našich dalších pokusech s tímto zařízením budeme předpokládat, že měnič má přednastavené motion tasky, které budeme chtít prostřednictvím CAN sběrnice spouštět. Vlastní nastavení motion tasku prostřednictvím protokolu CANopen bude obsahem některé z dalších kapitol. Nastavení těchto tasků můžeme prozatím provést prostřednictvím RS232 a dodávaného konfiguračního SW, který je pro tyto účely daleko přehlednější. Naším cílem tedy bude namapovat několik PDO objektů pro příjem dat, provést inicializaci najetím na referenční bod (homing) a spouštět naše přednastavené motion tasky. Pro zjednodušení práce jsem připravil databázi předdefinovaných zpráv pro diagnostický SW PP2CAN. Tu můžete stáhnout zde. Pro seznámení s tímto programem a různé off-line analýzy si můžete stáhnout i demo verzi tohoto SW, která je omezena na použití pouze virtuálního CAN portu. Stáhnout můžete zde.

    Nejprve provedeme reset nodu příkazem Reset node. Jedná se o zprávu NMT, tato zpráva má tvar:

Description	Id	Length	DB0	DB1	DB2	DB3	DB4	DB5	DB6	DB7
Reset node	0	2	129	1	-	-	-	-	-	-
	00h	02h	81h	01h	-	-	-	-	-	-

    Dokumentace k Servostaru 600 i specifikace CANOpen využívá hojně zápis hodnot identifikátorů a datových bajtů v hexadecimálním tvaru. SW PP2CAN je orientován především na dekadický zápis, proto budou u zpráv uváděny oba tvary.

    Jen pro zopakování, zprávy NMT mají vždy identifikátor 0 a délku 2. DB2 je nazýván Command Specifier a hodnota 129 znamená příkaz Reset Node. V DB1 je pak uvedeno Node ID. Tento identifikátor může obsahovat hodnoty adres jednotek 1-127. Hodnota 0 pak znamená že příkaz je určen všem jednotkám.

    Servostar 600 po obdržení tohoto příkazu provede svůj reset. Průběh resetu můžeme sledovat i na displeji měniče. Zde se v průběhu resetu zobrazuje číslo verze firmware. Vlastní reset trvá u tohoto měniče přibližně 13 sekund. Po ukončení resetu obdržím z měniče tuto zprávu:

Description	Id	Length	DB0	DB1	DB2	DB3	DB4	DB5	DB6	DB7
Reset node - Answer	129	8	0	0	0	0	0	0	0	0
	81h	08h	00h	00h	00h	00h	00h	00h	00h	00h

    Identifikátor 129 této zprávy nám napovídá, že se jedná o zprávu  Emergency. Nulová data pak říkají, že nedošlo k žádné chybě. V dalším kroku budeme provádět namapování několika objektů. Nejprve odešleme zprávu s tímto tvarem:

Description	Id	Length	DB0	DB1	DB2	DB3	DB4	DB5	DB6	DB7
1st  transmit-PDO select	1537	8	47	0	42	0	1	0	0	0
	601h	08h	2Fh	00h	2Ah	00h	01h	00h	00h	00h

    Jedná se o zprávu SDO. Hodnota 16-bitového indexu v hexadecimálním vyjádření je 2A00h, subindex má hodnotu 0. Pokud vyhledáme význam indexu 2A00h v dokumentaci (tu si můžete stáhnout zabalenou ve formátu pdf zde), zjistíme pro tento index název objektu: "1st  transmit-PDO select". V tomto okamžiku se dostáváme k procesu který se nazývá mapování PDO. Objekt s indexem 2A00h slouží k výběru předdefinovaného TPDO objektu. V našem případě se jedná o TPDO s indexem 1. V případě servozesilovače Servostar pro který platí profil DSP-402 (Device profile for drives and motion control) jde o stavové slovo. (index 6041h). V čem spočívá mapování znázorňuje následující obrázek. Ten pochází z jakéhosi českého materiálu, který jsem stáhnul na internetu, link si bohužel už nepamatuji. Chtěl bych poděkovat autorovi, škoda že se pod něj nikdo nepodepsal.

    Aplikační objekty, které jsou určeny indexem a subindexem jsou mapovány do zprávy PDO. Můžeme do této zprávy namapovat statusy zařízení, různé parametry a stavy jako například stavy I/O, polohy, rychlosti u pohonů atd.

    Na zaslání zprávy "1st  transmit-PDO select" reaguje servozesilovač touto zprávou:

Description	Id	Length	DB0	DB1	DB2	DB3	DB4	DB5	DB6	DB7
1st  transmit-PDO select	1409	8	96	0	42	0	0	0	0	0
Answer	581h	08h	60h	00h	2Ah	00h	00h	00h	00h	00h

     V případě že by došlo k chybě (například neexistující objekt), obdrželi bychom odpověď jak je popsáno ve  čtvrtém dílu. V našem případě však k žádné chybě nedošlo.

Díl šestý: Komunikujeme II

    Následující tabulka je převzata z dokumentace k měniči Servostar a představuje definované Tx PDO objekty. Přednastavené mapování nelze měnit. Pro uživatelské mapování jsou k dispozici objekty 37-40. Pokud chcete používat tyto uživatelsky konfigurovatelné objekty, je třeba provést jejich konfiguraci prostřednictvím SDO 1A00h - 1A03h.

    Naším úkolem tedy je spouštět prostřednictvím CANu motion tasky. Provedeme tedy konfiguraci měniče tak, aby jako reakci na zprávy SYNC odesílal zpět do PC status, manufacturer status, rychlost a polohu. K tomu bude třeba nakonfigurovat TPDO. PDO 22 objekt obsahuje status registr, polohu a rychlost, PDO objekt 23 pak obsahuje manufacturer status, což je status registr výrobce zařízení. Motion tasky budeme chtít spouštět prostřednictvím RPDO. V tabulce, která následuje, je uveden přehled předdefinovaných Rx PDO. Z tabulky je vidět, že pro spouštění motion tasku je možno použít předdefinovaný PDO 35.

    Nejprve je však třeba provést najetí pohonu, který je prostřednictvím měniče Servostar řízen na referenční bod. Tento proces se nazývá homing a slouží k inicializaci odměřování pohonu. Parametry homingu je taktéž možno konfiguravat prostřednictvím CANu, nicméně budeme předpokládat že jsou již nastaveny prostřednictvím RS232 a dodávaného konfiguračního SW od firmy TGdrives.  K detekci ukončení procesu homing využijeme bitu 17 v manufacturer status registru. Pokud je tento bit nastaven na 1, je referenční bod nastaven. Vlastní konfigurace tedy proběhne prostřednictvím sekvence těchto zpráv:

---

Description	Id	Length	DB0	DB1	DB2	DB3	DB4	DB5	DB6	DB7
1st  transmit-PDO select	1537	8	47	0	42	0	23	0	0	0
	601h	08h	2Fh	00h	2Ah	00h	17h	00h	00h	00h

    Vybereme PDO23 jako první TPDO. PDO obsahuje status a manufacturer-specific status. SDO 2A00 slouží k výběru předdefinovaného Tx PDO.

---

Description	Id	Length	DB0	DB1	DB2	DB3	DB4	DB5	DB6	DB7
1st TPDO reaction to every SYNC	1537	8	34	0	24	2	1	0	0	0
	601h	08h	22h	00h	18h	02h	01h	00h	00h	00h

    Nastavujeme, že chceme aby Servostar odesílal TPDO 1 po obdržení zprávy SYNC. SDO 1800 slouží k nastavení TPDO komunikačních parametrů. Subindex 02 nastavuje parametr transmission type, hodnota 1 pak znamená, že má být zpráva odeslána při každém obdržení zprávy SYNC.

---

    Pomocí SDO 2A01 a 1801 nastavíme TPDO2 tak , aby po každé obdržené SYNC zprávě zaslal PDO 22.

 

Description	Id	Length	DB0	DB1	DB2	DB3	DB4	DB5	DB6	DB7
2nd  transmit-PDO select	1537	8	47	1	42	0	22	0	0	0
	601h	08h	2Fh	01h	2Ah	00h	16h	00h	00h	00h

 

Description	Id	Length	DB0	DB1	DB2	DB3	DB4	DB5	DB6	DB7
2nd TPDO reaction to every SYNC	1537	8	34	1	24	2	1	0	0	0
	601h	08h	22h	01h	18h	02h	01h	00h	00h	00h

---

Description	Id	Length	DB0	DB1	DB2	DB3	DB4	DB5	DB6	DB7
1st RPDO - Motion task	1537	8	43	0	38	0	35	0	0	0
	601h	08h	2Bh	00h	26h	00h	23h	00h	00h	00h

     Prostřednictvím SDO 2600 vybereme PDO 35. Prostřednictvím RPDO 1 pak bude Servostar přijímat příkazy pro spuštění jednotlivých motion tasku. 

---

Description	Id	Length	DB0	DB1	DB2	DB3	DB4	DB5	DB6	DB7
Enable	1537	8	43	64	96	0	15	0	0	0
	601h	08h	2Bh	40h	60h	00h	0Fh	00h	00h	00h

    Tímto příkazem provedeme prostřednictvím SDO 6040 Enable pohonu. SDO 6040 je řídící slovo (Control word). Má 16 bitů a význam jednotlivých bitů zobrazuje následující tabulka:

 

 

    Další tabulka zobrazuje nastavení bitů pro jednotlivé příkazy zadávané prostřednictvím tohoto slova. Obě tabulky jsou převzaty z dokumentace k tomuto měniči. Definice je však součástí předpisu CiA DS-402: Device profile for drives and motion control. V našem případě zadáváme hodnotu řídícího slova 000Fh, což odpovídá příkazu Enable Operation.

 

---

    Pokud v tomto okamžiku zašleme příkaz NMT Start Remote Node a začneme taktéž generovat zprávy SYNC, budeme do PC dostávat data z TPDO1 A TPDO2. To je výhodné, neboť z manufacturer status registru a již zmíněného bitu 17 se dozvíme, o nalezení referenčního bodu a tedy o ukončení homingu, jehož spuštění bude následovat.

---

Description	Id	Length	DB0	DB1	DB2	DB3	DB4	DB5	DB6	DB7
Homing mode	1537	8	47	96	96	0	249	0	0	0
	601h	08h	2Fh	60h	60h	00h	F9h	00h	00h	00h

Aktivaci módu Homing provádíme rostřednictvím SDO 6060 - Modes of operation. Následně nastavíme řídící slovo prostřednictvím SDO 6040 na Start homing. V modu Homing má bit 4 tohoto řídícího slova význam Start homing.

Description	Id	Length	DB0	DB1	DB2	DB3	DB4	DB5	DB6	DB7
Start homing	1537	8	43	64	96	0	31	0	0	0
	601h	08h	2Bh	40h	60h	00h	1Fh	00h	00h	00h

---

V okamžiku kdy je homing dokončen, můžeme začít spouštět jednotlivé motion tasky prostřednictvím RPDO1. Pokud máme nakonfigurován motion task 1 například na najetí na nějakou středovou hodnotu rozsahu posuvu pohonu jako v mém případě, je možno tento motion task spustit zasláním následujícího příkazu.

Description	Id	Length	DB0	DB1	DB2	DB3	DB4	DB5	DB6	DB7
Motion task 1	513	1	1	-	-	-	-	-	-	-
	201h	01h	01h	-	-	-	-	-	-	-

---

  Tuto uvedenou sekvenci zpráv je možno načíst do diagnostického SW PP2CAN prostřednictvím databáze předdefinovaných zpráv, která je k dispozici ke stažení zde. Tato databáze je určena pro zařízení s adresou 1 tak jako i zprávy uvedené v textu. Obsahuje také zprávy, které odesílá Servostar zpět jako odpovědi na jednotlivé příkazy SDO.

---

Seriál CANopen a PP2CAN

Díl 1 - Čtení segmentovaného SDO

Díl 2 - Mapování objektů do PDO

Díl 3 - Odesílání TPDO

Díl 4 - Nástroj PDO mapping

Díl 5 - CANopen FD USDO

Díl 6 - CANopen Safety: SRDO

Díl 7 - Nodeguarding a Heartbeat

Díl 8 - Objekt 1010h - save