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 (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.

CANopen Object Dictionary

    Č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:

Servostar 600 - CANopen Abort Codes

     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.

CANopen SDO 1018   

    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