# Komunikujeme s měniči SERVOSTAR 400/600

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 (C OB-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

C AN 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ů.

David

Zpět na hlavní stránku