Tento materiál je vypracován jako kombinace volného překladu různých materiálů dostupných na internetu a vlastních praktických zkušeností. |
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-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 DSP-420-1: CANopen Profiles for Extruder Downstream Devices
- CiA DSP-401: Device profile for I/O modules
- CiA DSP-402: Device profile for drives and motion control
- CiA WDP-403: Device profile for human machine interfaces
- CiA WD-404: Device profile for measuring devices and closed-loop controllers
- CiA WD-405: Device profile for IEC-1131Interfaces
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:
CAN Identifikátor | Kód | Účel |
0 | 0000b | NMT Services |
1-127 | - | free |
128 | 0001b | Sync Message |
129-255 | 0001b | Emergency Messages |
256 | 0010b | Time-Stamp Message |
257-384 | - | free |
385-511 | 0011b | Transmit Process Data Objects 1(PDO1) |
512 | - | free |
513-639 | 0100b | Receive Process data Objects 1 (PDO1) |
640 | - | free |
641-767 | 0101b | Transmit Process Data Objects 2 (PDO2) |
768 | - | free |
769 - 895 | 0110b | Receive Process data Objects 2 (PDO2) |
896-1404 | - | free |
1405-1535 | 1011b | Service Data Objects |
1536 | - | free |
1537-1663 | 1100b | Service Data Objects |
1664-1792 | - | free |
1793-1919 | 1110b | Node Guarding (Boot-Up) Messages |
1920-2015 | - | free |
2015-2031 | - | Reserved for NMT, LMT and DBT Services |
Vlastní identifikátor (COB-ID, Communication Object ID) má tedy následující strukturu:
10 | 9 | 8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
Kód | ID modulu (node ID) |
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:
Funkce | CS |
Start Remote Node | 1 |
Stop Remote Node | 2 |
Enter Pre-Operational State | 128 |
Reset Node | 129 |
Reset Communication | 130 |
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 disabovana, 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:
EEC | ER | MEF |
2 bajty | 1 bajt | 5 bajtů |
EEC - Emergency Error Code
ER - Error Register
MEF - Manufacturer-specific Error Field
Bity error registru mají tento význam
Bit |
Význam |
0 |
Generic Error |
1 |
Current |
2 |
Voltage |
3 |
Temperature |
4 |
Communication |
5 |
Device profile specific |
6 |
Reserved |
7 |
Manufacturer specific |
Hodnoty v poli Emergency Error Code mají tyto významy:
Hodnota (hex) |
Význam |
00xx | Error Reset or No Error |
10xx | Generic Error |
20xx | Current |
21xx | Current, device input side |
22xx | Current inside the device |
23xx | Current, device output side |
30xx | Voltage |
31xx | Mains Voltage |
32xx | Voltage inside the device |
33xx | Output voltage |
40xx | Temperature |
41xx | Ambient Temperature |
42xx | Device Temperature |
50xx | Device Hardware |
60xx | Device Software |
61xx | Internal Software |
62xx | User Software |
63xx | Data Set |
70xx | Additional Modules |
80xx | Monitoring |
81xx | Communication |
90xx | External Error |
F0xx | Additional Functions |
FFxx | Device specific |
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žity
- 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 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.
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. 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ů
Identifikátor | DB0 | DB1 | DB2 | DB3 | DB4 | DB5 | DB6 | DB7 |
110 0iii iiii (1536 + node ID) |
Command | Object Index | Sub-index | Reserved (0-0-0-0) |
Bajt Command má tvar 010000000b.
Command: aaabbbbb | CAL Multiplexed Domain Transfer Protocol |
aaa | 010 (scs = 2: initiate upload response) |
bbbbb | 00000 (not used) |
Slave vrací požadovaná data:
Identifikátor | DB0 | DB1 | DB2 | DB3 | DB4 | DB5 | DB6 | DB7 |
101 1iii iiii (1408 + node ID) |
Reply | Object Index | Sub-index | Data |
Bajt Reply má tuto strukturu:
Reply: aaabcces | CAL Multiplexed Domain Transfer Protocol |
aaa | 010 (scs = 2: initiate upload response) |
b | 0 (not used) |
cc | (number of data bytes ([9-n to 8]) that do NOT contain data) |
e | 1 (e=1: expedited transfer) |
s | 1 (s = 1: data set size is indicated) |
V případě že objekt obsahuje více než 4 bajty, musí být rozsegmentována do více zpráv. Po inicializační požadavku, který se skládá ze dvou zpráv jsou čteny 7 bajtové segmenty data. Na každý segment připadají 2 zprávy.
Master požaduje objekt z jednotky slave takto:
Identifikátor | DB0 | DB1 | DB2 | DB3 | DB4 | DB5 | DB6 | DB7 |
110 0iii iiii (1536 + node ID) |
Command | Object Index | Sub-index | Reserved (0-0-0-0) |
Slave vrací:
Identifikátor | DB0 | DB1 | DB2 | DB3 | DB4 | DB5 | DB6 | DB7 |
101 1iii iiii (1408 + node ID) |
Reply | Object Index | Sub-index | Length |
Reply: aaabcces | CAL Multiplexed Domain Transfer Protocol |
aaa | 010 (scs = 2: initiate upload response) |
b | 0 (not used) |
cc | 00 (not valid) |
e | 0 (e = 0: normal transfer) |
s | 1 (s = 1: data set size is indicated) |
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:
Identifikátor | DB0 | DB1 | DB2 | DB3 | DB4 | DB5 | DB6 | DB7 |
110 0iii iiii (1536 + node ID) |
Command | Object Index | Sub-index | Reserved (0-0-0-0) |
DB0 - command má následující tvar:
Command: aaabcccc | CAL Multiplexed Domain Transfer Protocol |
aaa | 011 (scs = 3: upload segment request) |
b | 1/0 (toggle bit), bit se mění v každém segmentu dat, první požadavek má tento bit nastaven na 0, odpověď generovaná slave jednotkou zkopíruje do odpovědi hodnotu bitu z požadavku |
cccc | 0000 (not used) |
Slave pak zasílá příslušný segment data:
Identifikátor | DB0 | DB1 | DB2 | DB3 | DB4 | DB5 | DB6 | DB7 |
101 1iii iiii (1408 + node ID) |
Reply | Data |
Reply: aaabcccs | CAL Multiplexed Domain Transfer Protocol |
aaa | 000 (scs = 0: upload segment respond) |
b | 1/0 (toggle bit) |
ccc | (number of data bytes ([9-n to 8]) that do NOT contain data) |
e | = 1 pokud se jedná o poslední segment |
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:
Identifikátor | DB0 | DB1 | DB2 | DB3 | DB4 | DB5 | DB6 | DB7 |
110 0iii iiii (1536 + node ID) |
Command | Object Index | Sub-index | Data |
Kde Command má tuto strukturu:
Command: aaabcces | CAL Multiplexed Domain Transfer Protocol |
aaa | 001 (scs = 1: initiate download request) |
b | 0 (not used) |
cc | (number of data bytes ([9-n to 8]) that do NOT contain data) |
e | 1 (e=1: expedited transfer) |
s | 1 (s = 1: data set size is indicated) |
Slave pak odpovídá takto:
Identifikátor | DB0 | DB1 | DB2 | DB3 | DB4 | DB5 | DB6 | DB7 |
101 1iii iiii (1408 + node ID) |
Reply | Object Index | Sub-index | Reserved (0-0-0-0) |
Reply: aaabbbbb | CAL Multiplexed Domain Transfer Protocol |
aaa | 011 (scs = 3: initiate download response) |
bbbbb | 00000 (not used) |
Pokud data objektu obsahují více než 4 bajty, je použit opět přenos po segmentech. Master nejprve inicializuje zápis takto:
Identifikátor | DB0 | DB1 | DB2 | DB3 | DB4 | DB5 | DB6 | DB7 |
110 0iii iiii (1536 + node ID) |
Command | Object Index | Sub-index | Length |
Command: aaabcces | CAL Multiplexed Domain Transfer Protocol |
aaa | 001 (scs = 1: initiate upload response) |
b | 0 (not used) |
cc | (not valid) |
e | 1 (e=0: normal transfer) |
s | 1 (s = 1: data set size is indicated) |
Následně slave potvrdí požadavek takto:
Identifikátor | DB0 | DB1 | DB2 | DB3 | DB4 | DB5 | DB6 | DB7 |
101 1iii iiii (1408 + node ID) |
Reply | Object Index | Sub-index | Reserved (0-0-0-0) |
Reply: aaabbbbb | CAL Multiplexed Domain Transfer Protocol |
aaa | 011 (scs = 3: initiate download response) |
bbbbb | 00000 (not used) |
Dále pak master generuje jednotlivé segmenty dat:
Identifikátor | DB0 | DB1 | DB2 | DB3 | DB4 | DB5 | DB6 | DB7 |
110 0iii iiii (1536 + node ID) |
Command | Data |
Command: aaabcccs | CAL Multiplexed Domain Transfer Protocol |
aaa | 000 (scs = 0: download segment request) |
b | 1/0 (toggle bit) |
ccc | (number of data bytes ([9-n to 8]) that do NOT contain data) |
e | = 1 pokud se jedná o poslední segment |
Každý segment je potvrzen slave jednotkou:
Identifikátor | DB0 | DB1 | DB2 | DB3 | DB4 | DB5 | DB6 | DB7 |
101 1iii iiii (1408 + node ID) |
Reply | Reserved (0-0-0-0-0-0-0) |
Reply: aaabcccc | CAL Multiplexed Domain Transfer Protocol |
aaa | 001 (scs = 1: download segment response) |
b | 1/0 (toggle bit) |
cccc | 0000 (not used) |
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:
Identifikátor | DB0 | DB1 | DB2 | DB3 | DB4 | DB5 | DB6 | DB7 |
110 0iii iiii (1536 + node ID) master to slave |
Command | Object Index | Sub-index | Additional Code | Error Code | Error Class | ||
101 1iii iiii (1408 + node ID) slave to master |
Command: aaabbbbb | CAL Multiplexed Domain Transfer Protocol |
aaa | 100 (scs/ccs = 4: abort domain transfer) |
bbbbb | 1/0 (toggle bit) |
Chyba je dána hodnotou Error Code (DB6) a Error Class (DB7), některé chyby jsou pak rozvinuty hodnotou v poli Additional Code.
Description | Error Class | Error Code | Additional Code |
Toggle bit not alternated (not in LMB) | 5 Service Error | 3 Parameter Inconsistent | 0 |
Command specifier not valid | 5 Service Error | 4 Illegal Parameter | 0 |
Object does not exist | 6 Access Error | 2 Object non-existent | 0 |
Attempt to read a write only Object | 6 Access Error | 1 Object access unsupported | 0 |
Attempt to write a read only Object | 6 Access Error | 1 Object access unsupported | 0 |
Index value is reserved for further use (00A0h-0FFFh and A000h-FFFFh) | 6 Access Error | 4 Invalid address | 0 |
Access failed due to hardware | 6 Access Error | 6 Hardware fault | 0 |
Sub-index does not exist | 6 Access Error | 9 Object attribute inconsistent | 11h |
Object length too high | 6 Access Error | 7 Type conflict | 12h |
Object length too low | 6 Access Error | 7 Type conflict | 13h |
Data cannot be transferred / Invalid signature | 8 Other Error | 0 | 20h |
Parameter value out of range | 6 Access Error | 9 Object attribute inconsistent | 30h |
Sub-parameter value out of range | 6 Access Error | 9 Object attribute inconsistent | 33h |
Maximum value < Minimum value | 6 Access Error | 9 Object attribute inconsistent | 36h |
Object cannot be mapped to PDO | 6 Access Error | 4 Invalid address | 41h |
PDO length exceeded | 6 Access Error | 4 Invalid address | 42h |
General internal incomptibility | 6 Access Error | 4 Invalid address | 44h |
Dokumentace k servozesilovači Servostar nerozlišuje skupiny Additional Code-Error Code-Error Class, uvádí chyby jako 32 bitové slovo takto:
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é objkty 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ů.