Fagor CANopen protocol (MCP-MCPi) Manuale utente
- Tipo
- Manuale utente
FAGOR AUTOMATION S.COOP.
MCP/MCPi
~ Protocollo CANopen ~
Ref. 0612
2/40 - Protocollo CANopen MCP/MCPi - Ref. 0612
Titolo MCP/MCPi. Protocollo CANopen.
Tipo di documentazione Architettura, topologia e comunicazione in reti CANopen.
Denominazione MAN_ MCP/MCPi_CANopen (ita.).
Riferimento Ref. 0612
Software V01.05 (MCP), V01.01 (MCPi)
WinDDSSetup A partire dalla versione V0612
Documento elettronico MAN_MCP&MCPi_CANopen.pdf
Headquarters FAGOR AUTOMATION S.COOP.
Bº San Andrés 19, Apdo. 144
E20500 ARRASATE-MONDRAGÓN
www.fagorautomation.com
info@fagorautomation.es
Telefono: 34-943-719200
Fax: 34-943-771118 (Servizio Assistenza Tecnica)
L'informazione di cui al presente manuale può essere soggetta a variazioni dovute
a eventuali modifiche tecniche. FAGOR AUTOMATION, S. Coop. si riserva il diritto
di modificare il contenuto del manuale, non essendo tenuta a notificare tali
variazioni.
È stato verificato i contenuti del presente manuale e la sua coincidenza per il
prodotto descritto. Ciononostante, è possibile che sia stato commesso un errore
involontario e perciò non si garantisce una coincidenza assoluta. In ogni caso, si
verifica regolarmente l’informazione contenuta nel documento e si provvede a
eseguire le correzioni necessarie che saranno incluse in una successiva
editazione.
Tutti i diritti sono riservati. La presente documentazione, interamente o in parte, non
può essere riprodotta, trasmessa, trascritta, memorizzata in un sistema di
registrazione dati o tradotta in nessuna lingua, senza autorizzazione espressa di
Fagor Automation. Coop.
MCP/MCPi - Ref. 0612 Protocollo CANopen - 3/40
GARANZIA
GARANZIA INIZIALE:
Ogni prodotto fabbricato o commercializzato da FAGOR ha una garanzia di 12 mesi per
l'utente finale.
Affinché il tempo dall'uscita di un prodotto dai nostri magazzini all'arrivo presso l'utente finale
non venga sottratto da questi 12 mesi di garanzia, il costruttore o l'intermediario deve
comunicare a FAGOR la destinazione, l'identificazione e la data di installazione della macchina
tramite il Foglio di Garanzia che accompagna ogni prodotto.
La data di inizio della garanzia per l'utente sarà quella indicata come data di installazione
della macchina sul Foglio di Garanzia.
Questo sistema ci consente di assicurare all'utente i 12 mesi di garanzia.
FAGOR dà un termine di 12 mesi al costruttore o all'intermediario per l'installazione e la vendita
del prodotto, in modo che la data di inizio della garanzia può essere fino a un anno posteriore
all'uscita del prodotto dai nostri magazzini, purché sia stato rimesso il foglio di garanzia. Ciò
significa in pratica l'estensione della garanzia a due anni dall'uscita del prodotto dai magazzini
Fagor. Nel caso in cui non sia stato inviato il citato foglio, il periodo di garanzia concluderà dopo
15 mesi dall'uscita del prodotto dai nostri magazzini.
FAGOR si impegna alla riparazione o alla sostituzione di un prodotto a partire dal suo lancio
sul mercato e fino a 8 anni dopo la data di eliminazione dal catalogo.
Spetta esclusivamente a FAGOR determinare se la riparazione entra nell'ambito definito come
garanzia.
CLAUSOLE DI ESCLUSIONE:
La riparazione sarà effettuata presso i nostri impianti. Sono pertanto fuori garanzia le spese
di trasporto o quelle derivanti dagli spostamenti del proprio personale tecnico per realizzare
la riparazione di un'attrezzatura, anche se entro il succitato periodo di garanzia.
La citata garanzia sarà applicata purché le apparecchiature siano state disinstallate in base
alle istruzioni, non siano state maltrattate o non abbiano subito danni causati da incidenti o
negligenza e purché non siano state effettuate da personale non autorizzato da FAGOR.
Se, una volta effettuato l'intervento o la riparazione, la causa del guasto non è imputabile al
nostro prodotto, il cliente è tenuto a coprire tutte le spese derivanti, in base alle tariffe vigenti.
Non sono coperte altre garanzie implicite o esplicite e la FAGOR AUTOMATION non si rende
comunque responsabile di altri danni o pregiudizi eventualmente verificatisi.
CONTRATTI DI ASSISTENZA TECNICA:
Sono a disposizione del cliente Contratti di Assistenza e Manutenzione sia per il periodo di
garanzia sia fuori dallo stesso.
4/40 - Protocollo CANopen MCP/MCPi - Ref. 0612
DICHIARAZIONE DI CONFORMITÀ
Costruttore: Fagor Automation, S. Coop.
Barrio de San Andrés s/n, C.P. 20500, Mondragón -Guipúzcoa-
(SPAGNA).
Dichiariamo, sotto la nostra esclusiva responsabilità, la conformità del prodotto:
Sistema di regolazione AC Brushless Fagor
composto dai seguenti moduli e motori:
Moduli regolatori: Serie MCP e MCPi
Motori AC: Serie FXM, FKM, FSA e FSP
cui si riferisce la presente dichiarazione,
ai requisiti base delle Direttive Europee 73/23/CE di Bassa Tensione [Norma Base
di Sicurezza; Apparecchiatura Elettrica delle Macchine EN60204-1:95] e
92/31/CE di Compatibilità Elettromagnetica [EN 61800-3:1996, Norma specifica di
Compatibilità Elettromagnetica per Sistemi di Regolazione].
In Mondragón, li 15.09.06
PRESENTAZIONE
Questo manuale offre informazioni descrittive e dettagliate del protocollo CANopen
sulla scheda CAN dei regolatori MCP e MCPi, sull’architettura, topologia e
comunicazione CANopen nella rete e sull’avvio dell’apparecchiatura.
Se è la prima volta che si esegue l'installazione, è consigliabile leggere l'intero
documento.
In caso di eventuali dubbi o necessità, si prega di rivolgersi ai nostri tecnici presso uno
qualsiasi degli uffici sussidiari.
Grazie per aver scelto Fagor.
MCP/MCPi - Ref.0612 Protocollo CANopen - 5/40
INDICE GENERALE
PROTOCOLLO CANopen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7
Introduzione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7
Architettura di rete. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7
Topologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7
Cavo di connessione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8
Lunghezza massima . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8
Comunicazione in rete . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9
Frame CAN standard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9
Connessione predefinita CANopen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9
NMT, Network Management. Procedura di avvio e controllo di rete . . . . . . . . . . .11
PDO, Oggetto di Dati di Procedura. Canale rapido . . . . . . . . . . . . . . . . . . . . . . .14
SDO, Oggetto di Dati di Servizio. Canale lento . . . . . . . . . . . . . . . . . . . . . . . . . .17
Oggetto di emergenza . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20
Descrizione del dizionario di oggetti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .22
Descrizione dei PDO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27
Avvio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .34
Descrizione della scheda CAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .34
Selezione della velocità di comunicazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .34
Determinazione del nº di nodo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .36
Indicatori di stato . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .36
6/40 - Protocollo CANopen MCP/MCPi - Ref.0612
PAGINA IN BIANCO
MCP/MCPi - Ref.0612 Protocollo CANopen - 7/40
PROTOCOLLO CANopen
Introduzione
CANopen è un protocollo di comunicazione di rete basato sul sistema di Bus CAN
(sviluppato da BOSCH verso la metà degli ‘80 e destinato al settore automezzi).
CANopen è definito come uno strato di applicazione uniforme nella specifica
DS301 edita dall’ente regolatore della specifica SOCIETÀ (Can In Automation).
CAN è un sistema di Bus Multimaster che si differenzia da altri sistemi di Bus per
il fatto che i moduli collegati allo stesso non sono direzionati dagli identificatori dei
messaggi. In questo modo, i nodi potranno lasciare via i messaggi nel Bus purché
esso sia libero da traffico. I conflitti nel bus sono risolti in base a una determinata
priorità assegnata ai messaggi, stabilita nello stesso COB ID (Communication
Object Identifier) e chiaramente assegnata agli oggetti di comunicazione. Il COB ID
contenente il minor valore identifica il messaggio di maggior priorità. Questa
caratteristica fornisce un’autoregolazione di priorità nel Bus senza la gestione di
nessun elemento maestro (master).
Architettura di rete.
Topologia
Per costruire una rete CAN semplice, in cui la comunicazione sarà stabilita con
protocollo CANopen, sarà necessario almeno un elemento slave, un elemento
maestro (p. es. un PC con scheda di bus di campo CAN) e un cavo di connessione
come quello illustrato nella
FIGURA 1.
Potranno avere fino a 127 elementi slave indipendenti. Questi potranno adottare
numeri di nodo compresi fra 1 e 127.
Nella rete dovranno essere connesse fra loro tutte le linee CAN_H, CAN_L e
CAN_SHLD.
Si ricorda che il nodo 0 non esiste come tale ed è riservato a certi messaggi
generici utilizzati dall’elemento maestro.
FIGURA 1.
Topologia di una rete CAN.
CANopen
MASTER
CANopen
connector
of the PC
5
4
3
2
1
120 Ω
CANopen
connector
DRIVE 3
4
3
2
CANopen
connector
DRIVE 2
4
3
2
CANopen
connector
DRIVE 1
7
2
5
120 Ω
White
Shield
Brown
CAN_H
CAN_SHLD
CAN_L
CAN_SHLD
CAN_L
CAN_H
Nota: Una resistenza terminatrice da 120 Ω sarà montata dall’installatore della rete su ogni
modulo estremità del bus CANopen. Nella rete della figura sono state installate sul PC e sul
DRIVE3 che sono i moduli estremità del bus. Se p. es. invece del PC fosse stato posto un
DRIVE in tale posizione, allora esso sarebbe un’estremità del bus e occorrerebbe installare la
resistenza terminatrice di 120 Ω in tale DRIVE e non nel PC. Il resto dei moduli che fanno parte
del bus non sarà situato alle estremità dello stesso e, pertanto, non si installerà in essi nessuna
resistenza. Vedi figura.
8/40 - Protocollo CANopen MCP/MCPi - Ref.0612
Cavo di connessione
Per realizzare la connessione della scheda CAN, installata in un regolatore, a una
rete CANopen, sarà necessario disporre di un cavo CAN formato da un tubo flessibile
di 2 fili con schermatura esterna. In una delle estremità del tubo flessibile è inserito
un connettore “Open Style” collegabile a 5 vie e passo 5 mm. La maglia andrà
collegata al pin 3 di questo connettore. Per ulteriori dettagli, vedi
FIGURA 2.
Tutte le linee CAN_H, CAN_L e la maglia di ognuno dei moduli che conformano la
rete dovranno essere collegate fra loro.
In ognuno dei due moduli estremità del bus CAN (e solo in essi) dovranno essere
installate esternamente dall’utente (fra i pin 2 e 4 del connettore Open Style se
il modulo estremità è un regolatore, o 2 e 7 del connettore Sub-D, M9 se il modulo
estremità è il PC) una resistenza terminatrice di linea da 120 Ω allo scopo di evitare
riflessi (rimbalzi), cioè problemi di trasmissione.
Lunghezza massima
Nella seguente tabella vengono riportate le lunghezze massime della rete in
funzione delle diverse velocità di trasmissione:
FIGURA 2.
Cavi di collegamento fra moduli collegati a una rete CAN.
TABELLA 1. Lunghezza massima di una rete CAN a seconda della velocità di trasmissione.
Velocità di
trasmissione
Lunghezza
di rete
Velocità di
trasmissione
Lunghezza
di rete
1000 kbit/s 30 metri 250 kbit/s 250 metri
800 kbit/s 50 metri 125 kbit/s 500 metri
500 kbit/s 100 metri ≤ 50 kbit/s 1000 metri
CAN H
SHIELD
CAN L
SHIELD
ISO GND
5
4
3
2
1
Pin
5
4
3
2
1
Pin
5
4
3
2
1
Pin
7
25
C
A
N
o
p
e
n
Vista frontale del connettore Sub-D, F9
dell’estremità del cavo CAN
Cavo CAN fra
PC e DRIVE1
Cavo CAN fra
DRIVE1 e DRIVE2
Cavo CAN fra
DRIVE2 e DRIVE3
5
4
3
2
1
Pin Segnale Colore del filo
5 N.C. ----
4 CAN_H Bianco
3 CAN_SHLD Griglia
2 CAN_L Marrone
1 N.C. ----
MCP/MCPi - Ref.0612 Protocollo CANopen - 9/40
Comunicazione in rete
Frame CAN standard
I frame standard di CAN contengono da 44 a 108 bit utili. Inoltre, in funzione dei dati
inviati, si possono inserire nel frame dai driver di CAN fino a 23 bit “di ripieno” in modo
che il massimo nº di bit che si raggiunge nell’invio di un frame è di 131.
L’identificazione dei campi di bit nel frame CAN è:
<Start bit>: Inizio del frame.
<Arbitraggio>: Campo di arbitraggio contenente l’identificatore e il tipo di
messaggio che sarà inviato.
<Controllo bits>: Campo di controllo contenente il nº di byte di dati.
<Data field>: Byte di dati (di 0 a 8 byte).
<CRC>: Caratteri di verifica di ridondanza ciclica come da algoritmo CRC-16.
<Acknowledge>: Riconoscimento di frame.
<End>: Bits finale frame.
Connessione predefinita CANopen
Con CANopen la trasmissione dati, lo scatto eventi, la segnalazione di stati di errore,
ecc.. è realizzata mediante oggetti di comunicazione. A tale scopo, ogni oggetto di
comunicazione ha assegnato un COB ID nella rete.
Gli oggetti più importanti in CANopen sono:
<NMT>: Oggetti di trattamento della rete.
<SYNC>: Oggetti di sincronizzazione.
<EMCY>: Oggetti di messaggio di errore.
<PDO>: Oggetti di procedura.
<SDO>: Oggetti di servizio.
Allo scopo di facilitare l’impostazione di reti CAN semplici, esiste un set di COB ID
già predefiniti.
FIGURA 3.
Frame CAN standard.
1
12
6
0-8 bytes 16
27
Start bit
A
rbitration
Control bits
Data field
CRC
Acknowledge
End
Bit Length
10/40 - Protocollo CANopen MCP/MCPi - Ref.0612
COB ID
Identificatore del messaggio immesso nella rete implementato negli 11 bit
dell’identificatore nel frame di CAN. La sua struttura è:
Con il codice di funzione 1 (oggetto di emergenza) si possono generare fino a 128
oggetti diversi, a seconda del nº di nodo disponibile nel messaggio. Gli oggetti con
identificatore da 0x81 a 0xFF sono oggetti di emergenza emessi dal nodo il cui
numero è implicito nell’identificatore. Lo 0x80 è un oggetto diverso emesso
dall’elemento maestro (senza nº di nodo assegnato) di più alta priorità dei messaggi
di emergenza e che serve da sincronismo per il bus di comunicazioni.
A seconda se il nº di nodo appare o meno nell’intestazione del messaggio, si
stabiliscono gli oggetti Broadcast (nodo 0) e Per to Per (nodo>0). Gli oggetti
“Broadcast” sono interpretati da tutti i nodi del bus e gli oggetti “Per to Per” consentono
di stabilire conversazioni fra due elementi della rete.
- Oggetti “Broadcast”
Il COB ID degli oggetti Broadcast è unico, dato che non ha assegnato nessun numero
di nodo. Sarà interpretato da tutti i nodi presenti nella rete CANopen.
FIGURA 4.
Struttura del COB ID.
TABELLA 2. Oggetti Broadcast.
Oggetto Bits di codice
di funzione
COB ID Parametri di
comunicazione
NMT Module Control 0000 000h ---------
SYNC 0001 080h 1005h, 1006h, 1007h
TIME STAMP 0010 100h 1012h, 1013h
10 9 8765 4 3 2 1 0
Function Code Node number: 0 - 127
MCP/MCPi - Ref.0612 Protocollo CANopen - 11/40
- Oggetti “Per to Per”
Gli oggetti Per to Per comportano di stabilire una comunicazione fra due nodi in
particolare. Questo obbliga i COB ID ad includere (a seconda dell’oggetto in
questione) il nº di nodo al quale sono destinati o il nº di nodo dal quale sono emessi
(0-127 in entrambi i casi). Da qui l'intervallo specificato nella
TABELLA 3.
In “parametri di comunicazione” è l’oggetto di comunicazioni in cui sono impostati
diversi aspetti relativi a tale oggetto.
In “parametri di mappatura del PDO” è l’oggetto di mappatura in cui sono impostati
i diversi oggetti mappati per il rispettivo PDO.
NMT, Network Management. Procedura di avvio e controllo di rete
Una volta applicata la tensione a un nodo CANopen si stabilisce la procedura di
avvio (start-up) inizializzandone le variabili, realizzandone l’auto-verifica, ecc.. Una
volta effettuata questa procedura, ogni nodo invia un messaggio di “Boot-Up”
(avvio) attraverso il bus per fare sapere all’elemento maestro che un nuovo nodo è
stato incorporato alla rete CANopen.
(Boot-Up) NMT - maestro
Í NMT - slave.
Una volta eseguita correttamente questa procedura, il nodo passa automaticamente
in uno stato pre-operazionale restando così finché l’elemento maestro, mediante
un messaggio di controllo rete (NMT), non gli richiederà di passare in un altrostato
operazionale:
TABELLA 3. Oggetti Per to Per.
Oggetto Bits di codice
di funzione
COB ID Parametri di
mappatura del PDO
Parametri di
comunicazione
EMERGENCY 0001 081h-0FFh 1024h, 1015h
PDO1 tx 0011 181h-1FFh 1A00h 1800h
PDO1 rx 0100 201h-27Fh 1600h 1400h
PDO2 tx 0101 281h-2FFh 1A01h 1801h
PDO2 rx 0110 301h-37Fh 1601h 1401h
PDO3 tx 0111 381h-3FFh 1A02h 1802h
PDO3 rx 1000 401h-47Fh 1602h 1402h
PDO4 tx 1001 481h-4FFh 1A03h 1803h
PDO4 rx 1010 501h-57Fh 1603h 1403h
SDO tx 1011 581h-5FFh 1200h
SDO rx 1100 601h-67Fh 1200h
NMT Error Control 1110 701h-77Fh 1016h-1017h
Nota: Il concetto dei termini rx e tx va inteso dal punto di vista del bus.
COB ID Byte 0
0x700 + ID di nodo 0
12/40 - Protocollo CANopen MCP/MCPi - Ref.0612
(Controllo del modulo) NMT- maestro Î NMT- slave.
Questa azione può essere definita o no come “Broadcast” a seconda del valore
indicato nel byte 1 del campo dati. Quindi se il valore del byte 1 è zero, l’azione si
definisce come “Broadcast”. Se è diverso da zero e minore di 128, il suo valore
indicherà il nodo al quale è diretto l’ordine.
Il valore indicato nel byte 0 del campo dati del messaggio CAN stabilisce l’ordine da
eseguire. Vedi tabella sotto.
CS.
A seconda del valore specificato in questi byte del campo dati si può modificare lo
stato in cui si trovano uno o tutti i nodi presenti in rete.
Dopo un avvio soddisfacente della rete, l’elemento maestro ha l’opzione di controllare
ciclicamente che tutti i nodi siano attivi all’interno della stessa.
Con - Node Guarding - l’elemento maestro invia ciclicamente (in base a dei tempi
prestabiliti in precedenza e verificati) un messaggio “broadcast” senza nessun dato
e al quale rispondono tutti i nodi e in cui si include lo stato in cui si trova ognuno di
essi. Questi messaggi sono:
(Node Guarding) NMT- maestro
Î NMT- slave.
NMT- maestro
Í NMT- slave.
COB ID Byte 0 Byte 1
0x000 CS ID di nodo
TABELLA 4. Byte 0 del campo di dati del messaggio CAN. Ordine da eseguire.
Specificatore di
comando (byte 0)
Servizio di NTM
(controllo del modulo)
1
Avviare il nodo remoto – passaggio a operazionale -
2
Arrestare il nodo remoto – passaggio a stop -
128
Immettere lo stato preoperazionale - passaggio a preoperazionale -
129
Inizializzare il nodo - reset del / dei nodi selezionati -
130
Inizializzare la comunicazione - reset della procedura di
comunicazione nel nodo o dei nodi indicati -
COB ID
0x700 + ID di nodo
COB ID Byte 0
0x700 + ID di nodo Bit 7 - Toggle bit - Bits 6-0 - Stato
MCP/MCPi - Ref.0612 Protocollo CANopen - 13/40
Stato.
Oggetti legati.
Alternativamente, un nodo può essere impostato allo scopo di generare un
messaggio periodico denominato “Heartbeat”.
(Heartbeat) Produttore
Î Consumatore / es.
Stato.
Il consumatore di “Heartbeat” normalmente è l’elemento maestro che verifica l’invio
da parte di ognuno dei nodi del messaggio di “Heartbeat” con una periodicità
prestabilita entro determinati margini e che agirà di conseguenza ogni volta che ciò
non si verifica in uno dei nodi.
TABELLA 5. Node Guarding. Stati.
Valore Stato
0 Inizializzazione
1 In disconnessione *
2 In connessione *
3 In preparazione *
4Fermo
5 In funzionamento
127 In fase precedente al funzionamento normale
* Questi stati esistono solo se il dispositivo supporta “extended boot-up”.
Attenzione: La scheda CAN dei regolatori MCP e MCPi non supporta tale
caratteristica.
100Ch Guard Time
100Dh Life Time
100Eh Node Guarding Identifier ( di default: 700 + ID di nodo )
COB ID Byte 0
0x700 + ID di nodo Stato
TABELLA 6. Heartbeat. Stati.
Stato Significato
0 Boot-up
4 Fermo
5 In funzionamento
127 In fase precedente al funzionamento normale
Attenzione: Un nodo non può supportare “Heartbeat” e “Node Guarding”
simultaneamente.
14/40 - Protocollo CANopen MCP/MCPi - Ref.0612
(Sync) Produttore Î Consumatore/ è.
Oggetto che ha il compito di sincronizzare il bus. È ciclico, “Broadcast” e ha massima
priorità nel bus dopo il NMT. È direttamente legato al trattamento dei PDO.
Oggetti legati.
PDO, Oggetto di Dati di Procedura. Canale rapido
Gli oggetti di dati di procedure (PDO) consentono di eseguire la trasmissione dati
in tempo reale e con identificatori di alta priorità. I telegrammi di dati possono disporre
di un massimo di 8 Byte. Lo scambio di dati si può effettuare mediante eventi o in
modo sincrono, a richiesta. Lo scambio di messaggi mediante eventi consente di
ridurre drasticamente il caricamento nel bus rispetto alla modalità sincrona.
Protocollo PDO
Questo protocollo se utilizza per trasmettere i dati al/dal bus evitando di
sovraccaricarlo con informazione ridondante.
Nei messaggi PDO (nei byte di dati) si trasmettono solo ed esclusivamente i valori
di variabili di diversi nodi, e sarà eliminato l’invio dei relativi identificatori. Per
poterlo fare senza nessun tipo di errore, gli elementi maestro e slave hanno
stabilito in precedenza che variabili saranno inviate all’interno di ogni PDO
(mappatura). Questa assegnazione si definisce mediante gli oggetti “PDO
Mapping Parameter”. Il tipo di comunicazione che si stabilisce per ogni PDO
(sincronizzata o per evento) sarà determinato dagli oggetti “Communication
Parameter”.
In funzione di chi emette il messaggio PDO si parlerà di PDO di trasmissione
(dall’elemento slave al maestro) o di PDO di ricezione (dall’elemento maestro allo
slave).
COB ID
0x080
1005 h COB-ID del messaggio di sincronismo
1006 h Periodo del ciclo di comunicazione
1007 h Lunghezza della finestra sincrona
Nota: Lo Standard DS301 stabilisce quattro PDO di trasmissione ed altri 4 di
ricezione per ogni elemento slave. Non è obbligatorio implementarli tutti per
l’osservanza della norma.
MCP/MCPi - Ref.0612 Protocollo CANopen - 15/40
Mappatura e tipo di comunicazioni
Si ipotizza che nell’oggetto di mappatura del secondo PDO di trasmissione siano
disponibili i seguenti valori:.
Valore Dword (32 bit)
Si ipotizza che nell’oggetto di comunicazioni del secondo PDO di trasmissione sia
disponibili i seguenti valori:
Valore del subindice 1 (COB ID)
TABELLA 7. Mappatura e tipo di comunicazioni
Oggetto 0x1A01
Subindice Valore Significato
0 2 Mappatura di due oggetti in questo PDO
1 0x60000208
Oggetto: 0x6000 (*)
Subindice: 0x02
Dato: 8 bit
2 0x64010110
Oggetto: 0x6401 (*)
Subindice: 0x01
Dato: 16 bit
* La sua descrizione viene data nella seguente tabella.
TABELLA 8. Descrizione.
Bits 31-16 Bits 15-8 Bits 14-0
Indice Subindice Nº di bit di dati dell’oggetto
TABELLA 9. Es. di oggetto del secondo PDO.
Oggetto 0x1801
Subindice Valore Significato
0 5 L’oggetto 0x1801 è composto da 5 subindici
1 0x00000280
PDO esiste, RTR non consentito, 11 bits ID, COB
20xBC
La trasmissione del PDO sarà ciclica e attraverso il bus
dopo aver ricevuto 188 messaggi di sincronismo.
3 0x000A
Il tempo di “inhibit time” fra PDOs è di:
10 x 100 µs = 1 ms.
4 ---------- Riservato.
5 0x0000 Intervallo del “event timer” 0.
TABELLA 10. Valore del subindice 1 (COB ID)
Bit 31 Bit 30 Bit 29 Bits 28-11 Bits 10-0
0
ÎPDO esiste
1
ÎPDO non
esiste
0
ÎRTR consentito
1
ÎRTR non
consentito
0
ÎCAN ID 11 bits
1
ÎCAN ID 29 bits
Parte alta
del COB ID
(se CAN ID
è di 29 bits)
.
Parte bassa
del COB ID
(se CAN ID
è di 29 bits).
COB ID
(se CAN ID è
di 11 bits)
.
16/40 - Protocollo CANopen MCP/MCPi - Ref.0612
Valore del subindice 2 (Tipo di trasmissione)
dove:
<SYNC> significa che la trasmissione del PDO è legata al ricevimento del
messaggio di sincronismo.
<ASYNC> significa che la trasmissione del PDO non è legata al ricevimento del
messaggio di sincronismo.
Tipo di trasmissione = 0. Sincrona e aciclica. I messaggi sono inviati solo se si
verifica un evento, e in tal caso il messaggio è inviato sincronicamente con il seguente
messaggio di sincronismo.
Tipo di trasmissione = 1 a 240. Il PDO è trasmesso dopo aver ricevuto il nº di
messaggi di sincronismo specificati nel tipo di trasmissione.
Tipo di trasmissione = 252 a 253. Valori possibili solo nei PDO di trasmissione. In
entrambi i casi, il PDO è inviato come risposta a un frame RTR dell’elemento
maestro. La differenza sta nel fatto che il tipo di trasmissione = 252 aggiorna le
variabili con l’arrivo dei sincronismi e il tipo di trasmissione = 253 aggiorna le
variabili e le invia con la ricezione del frame RTR.
Tipo di trasmissione = 254. Il PDO si trasmette quando si verifica un evento
specifico del costruttore.
Tipo di trasmissione = 255. Il PDO si trasmette quando si verifica un evento
specifico del profilo di dispositivo.
TABELLA 11. Valore del subindice 2 (tipo di trasmissione).
Tipo di
trasmissione
Condizione di scatto del PDO
( B = sono necessari entrambi, O = uno o
Trasmissione del
PDO
SYNC
Oggetto
SYNC
ricevuto
RTR
Ricevuta
richiesta di
trasmissione
remota
Evento
Cambio di valore
dell'interruzione
del temporizzatore
0 B B Sincrona (SYNC), aciclica
1-240 O Sincrona (SYNC), ciclica
241-251 Riservato
252 B B Sincrona (SYNC) dopo RTR
253 O Asincrona (ASYNC) dopo RTR
254 O O
Asincrona (ASYNC), evento
specifico del costruttore
255 O O
Asincrona (ASYNC), evento
specifico del profilo di dispositivo.
Si intende conevento un cambiamento nel valore della variabile o (se è supportato
dall’apparecchiatura, oggetti di comunicazioni con subindice 5) un determinato
tempo trascorso.
MCP/MCPi - Ref.0612 Protocollo CANopen - 17/40
Valore del subindice 3 (tempo di inibizione o disabilitazione)
Specifica il minimo intervallo di tempo (in incrementi di 100 µs) che trascorre fra un
PDO e l’altro. Questo intervallo di tempo non può essere modificato finché il valore
del bit 31 del subindice 1 (COB ID) è 0 (il PDO esiste).
Valore del subindice 5 (temporizzatore di eventi)
Specifica il valore del timer di eventi (in incrementi di 1ms) quando il tipo di
trasmissione è 254 o 255.
Esempio esplicativo del senso del “tempo di inibizione” e del “timer eventi”.”
Quando si programma un PDO di trasmissione di tipo 254 nel cui si include una
variabile di posizione si presentano due situazioni diverse. Mentre l’elemento che
emette il PDO è arrestato (senza variazione nella sua posizione) non sarà necessario
nessun invio. Se si programma un timer di eventi (event timer) di 10 ms, anche se
l’elemento non varia la sua posizione (non si sposta) invierà i PDO ogni 10 ms
indicandone la posizione. Nell’iniziare lo spostamento cercherà di inviare PDO
costantemente, occupando così tutto il bus con tale informazione. Allo scopo di
evitare questa situazione, è possibile programmare un tempo di inibizione (inhibit
time) 2, in modo che mentre è in movimento invia PDO solo ogni 2 ms.
Il messaggio
In base alla configurazione descritta nelle tabelle di cui sopra, il messaggio PDO (con
i byte di cui è formato) diventa come segue:
La trasmissione del PDO sarà ciclica ed è erogata al bus dopo aver ricevuto 188
messaggi di sincronismo.
Oggetti legati
SDO, Oggetto di Dati di Servizio. Canale lento
Gli oggetti di dati di servizio (SDOs) consentono di eseguire la lettura e scrittura degli
ingressi del dizionario di oggetti (parametri, variabili, comandi, ...). In questo modo,
utilizzando SDO, qualsiasi nodo può essere impostato dall’elemento maestro. Il
messaggio SDO, di default, ha preventivamente assegnato un identificatore di bassa
priorità. I dati trasmessi superiori a 4 Byte possono essere frammentati e perciò vi
sono due meccanismi di trasferimento di un'SDO:
<Trasferimento inoltrato > utilizzato per definire un trasferimento di oggetti di non
più di 4 Byte.
<Trasferimento segmentato> utilizzato per definire un trasferimento di oggetti di
più di 4 Byte.
TABELLA 12. Messaggio PDO.
COB ID Byte 0 Byte 1 Byte 2
0x280
+ ID del nodo
8 bit di dati
dell’oggetto
Parte bassa dei 16 bit di
dati dell’oggetto 0x6000
Parte alta dei 16 bit di dati
dell’oggetto 0x6401
1004 h Nº di PDO supportati
18/40 - Protocollo CANopen MCP/MCPi - Ref.0612
Strutture di base di un SDO
Le strutture di base di un SDO sono:
Cliente Î Server/ Server Î Cliente
oppure Cliente
Î Server / Server Î Cliente
Esistono cinque protocolli di richiesta / risposta implementati negli SDO. Questi sono:
Iniziare lo scarico del dominio (Initiate Domain Download)
Scaricare il segmento di dominio (Download Domain Segment)
Iniziare il caricamento del dominio (Initiate Domain Upload)
Caricare il segmento di dominio (Upload Domain Segment)
Annullare il trasferimento di dominio (Abort Domain Transfer)
Indicatori di comando di SDO per i diversi protocolli
dove:
n
Î Indicatore del nº di byte che non contengono dati e è valido se e=1 e s=1.
e
Î Indicatore di trasferimento normale (e=0) o trasferimento inoltrato (e=1).
s
Î Indicazione o meno delle dimensioni dei dati. Se si indica (s=0) e se non si indica
(s=1).
e = 0 y s = 0
Î Byte di dati riservati da CiA per il futuro.
e = 0 y s = 1
Î Il contatore di Byte è nei Byte di dati (a byte 4 LSB a byte 7 MSB).
e = 1
Î I Byte di dati contengono i dati per scaricare (download).
TABELLA 13. Struttura SDO. Cliente Î Server / Server Î Cliente
Byte 0 Byte 1 Byte 2 Byte 3 Byte 4 Byte 5 Byte 6 Byte 7
Indicatore del
comando
SDO
Indice
di
oggetti
Subindice
di
oggetti
Fino a 4 Byte di dati in trasferimento
inoltrato o 4 Bytes del contatore in
trasferimento segmentato.
TABELLA 14. Struttura SDO. Cliente Î Server / Server Î Cliente
Byte 0 Byte 1 Byte 2 Byte 3 Byte 4 Byte 5 Byte 6 Byte 7
Indicatore del
comando SDO
Fino a 7 Byte di dati in trasferimento
segmentato
Con scaricare (download) si intende scrivere nel dizionario di oggetti e
concaricare (upload) leggere dal dizionario di oggetti.
TABELLA 15. Inizio del download di dominio.
Iniziare lo scarico del dominio
bit
76543210
Cliente
Î 001- n es
Server
Í 011- - - - -
MCP/MCPi - Ref.0612 Protocollo CANopen - 19/40
dove:
n
Î Indicatore del nº di byte che non contengono dati ed è zero se le dimensioni del
segmento non sono indicate.
c
Î Indicatore dei segmenti da scaricare. Se vi sono più segmenti da scaricare (c=0)
e se è l’ultimo segmento (c=1).
t
Î Bit di toggle che va alternato con ogni segmento consecutivo. La prima volta è
(t=0).
Un messaggio può essere annullato sia dal cliente che dal server. Deve essere
indicato con il seguente indicatore di comando:
Nell’annullare il trasferimento di dominio i byte di dati 0 e 1 contengono l’indice
dell’oggetto, il byte 2, il subindice dell’oggetto e i byte 4-7 contengono il codice di
annullamento (abort) che descrive la causa.
TABELLA 16. Scarico del segmento di dominio.
Scaricare il segmento di dominio
bit 76543210
Cliente
Î 000t n c
Server
Í 000t - - - -
TABELLA 17. Inizio del caricamento del dominio.
Iniziare il caricamento del dominio
bit 76543210
Cliente
Î 010- - - - -
Server
Í 010- n es
TABELLA 18. Caricamento del segmento di dominio.
Caricare il segmento di dominio
bit 76543210
Cliente
Î 011t - - - -
Server
Í 000t n c
TABELLA 19. Annullato il trasferimento di dominio.
Annullare il trasferimento di dominio.
bit 76543210
Cliente
Î / Í Server100- - - - -
20/40 - Protocollo CANopen MCP/MCPi - Ref.0612
Codici che descrivono la possibile ragione di annullamento SDO
Oggetto di emergenza
Un messaggio di emergenza è composto da 8 byte e dispone del seguente formato:
TABELLA 20. Descrizione dei possibili codici di annullamento dell’SDO.
Codice di annullamento Descrizione
byte 7 byte 6 byte 5 byte 4
05 03 00 00
Il bit ribaltabile non è ribaltabile
05 04 00 00
TimeOut per il protocollo SDO
05 04 00 01
Comando Client/Server non valido o identificatore
sconosciuto
05 04 00 02
Dimensioni di blocco non riconosciute (solo modalità
05 04 00 03 Numero di blocco non riconosciuto (solo modalità blocco)
05 04 00 04
Errore CRC (solo modalità blocco)
05 04 00 05
Memoria insufficente
06 01 00 00
Accesso non supportato a tale scopo
06 01 00 01
Si è cercato di leggere un oggetto di sola scrittura
06 01 00 02
Si è cercato di scrivere un oggetto di sola lettura
06 02 00 00
L’oggetto non esiste nel dizionario di oggetti
06 04 00 41
L’oggetto non può essere mappato in un PDO
06 04 00 42
Le dimensioni e il numero di oggetti mappati superano la
lunghezza del PDO
06 04 00 43
Incompatibilità generale di parametri
06 04 00 47
Incompatibilità generale dei dispositivi
06 06 00 00
Accesso interrotto a causa di errore di hardware
06 07 00 10
Tipo di dato incompatibile, la lunghezza del parametro di
servizio è incompatibile
06 07 00 12
Tipo di dato incompatibile, il parametro di servizio è troppo
lungo
06 07 00 13
Tipo di dato incompatibile, il parametro di servizio è troppo
corto
06 09 00 11
Non esiste il subindice
06 09 00 30 Intervallo di valori esterno (solo per acceso scrittura)
06 09 00 31
Valore di parametro troppo alto
06 09 00 32
Valore di parametro troppo basso
06 09 00 36 Il valore massimo è inferiore al valore minimo
08 00 00 00
Errore / errore generale
08 00 00 20
I dati non possono essere trasmessi né salvati
08 00 00 21
I dati non possono essere trasmessi né salvati perché il
dispositivo è sotto controllo locale
08 00 00 22
I dati non possono essere trasmessi né salvati a causa
dello stato del dispositivo
08 00 00 23
Non è possibile generare dinamicamente il dizionario di
oggetti
TABELLA 21. Messaggio di emergenza.
COB ID Byte 0 -1 Byte 2 Byte 3 -7
0x080
+ ID del nodo
Codici di errore di
emergenza
Registro di errore
(Oggetto 0x1001)
Campo di errore specificato
dal costruttore
La pagina sta caricando ...
La pagina sta caricando ...
La pagina sta caricando ...
La pagina sta caricando ...
La pagina sta caricando ...
La pagina sta caricando ...
La pagina sta caricando ...
La pagina sta caricando ...
La pagina sta caricando ...
La pagina sta caricando ...
La pagina sta caricando ...
La pagina sta caricando ...
La pagina sta caricando ...
La pagina sta caricando ...
La pagina sta caricando ...
La pagina sta caricando ...
La pagina sta caricando ...
La pagina sta caricando ...
La pagina sta caricando ...
La pagina sta caricando ...
-
1
-
2
-
3
-
4
-
5
-
6
-
7
-
8
-
9
-
10
-
11
-
12
-
13
-
14
-
15
-
16
-
17
-
18
-
19
-
20
-
21
-
22
-
23
-
24
-
25
-
26
-
27
-
28
-
29
-
30
-
31
-
32
-
33
-
34
-
35
-
36
-
37
-
38
-
39
-
40
