Il CANOpen
Il modello di riferimento di
CANopen
CIA – DS2xx, DS3xx, DS4xx
Cenelec, EN50325-4, "Industrial
Communications Subsystem based
on ISO 11898 (CAN) for Controllerdevice
Interfaces.
Part
4:
CANOpen", 2001.
ISO, IS-11898, "Road Vehicle Interchange of Digital Information Controller Area Network (CAN) for
High Speed Communication", 1993.
Il modello di riferimento di
CANopen


“Application Layer” e il “Communication Profile” definiscono i
servizi per ricevere e trasmettere gli oggetti sul bus
"Frameworks" rappresenta un livello aggiuntivo specifico ad
esempio per dispositivi programmabili:


nei dispositivi PLC gli oggetti standard previsti non sono sufficienti per
gestire i processi di configurazione e salvataggio delle impostazioni;
Tutti i "Profile" descrivono le caratteristiche e le funzionalità
opzionali del dispositivo. Esistono Profile già definiti per:







moduli di I/O (DS-401)
misurazione e controllo temperatura e pressione (DS-404)
gestione encoder (DS-406)
controllo trasmissione idrostatica (DS-408)
controllo posizione (DSP-402)
controllo porte automatiche (DSP-416)
controllo ascensori (DSP-417) ecc.
Obiettivi del CanOpen

Lo sviluppo del CanOpen prese avvio con questi
obiettivi:






Creare una specifica chiara e concisa per facilitare
l'implementazione e la manutenzione.
Utilizzare per quanto più è possibile standard internazionali
esistenti.
Impiegare il minimo numero possibile di Oggetti di comunicazione communication objects (identificatori CAN)
Riuscire a coprire l'ampia gamma di dispositivi utilizzati
nell'automazione delle macchine.
Assicurare un comportamento affidabile e preciso della rete
Con questi obiettivi, CANopen fu sviluppato usando
solo un esiguo numero di funzioni di comunicazione
per l'automazione delle macchine, con il conseguente
ridotto fabbisogno di processori e di memorie
Le interazioni tra gli strati del
protocollo



Nell’ Application Layer i
dispositivi si scambiano
Communication and
Application Objects (COB)
I COB permettono l’accesso
ad oggetti tramite un indice
a 16 bit ed un sub-indice ad
8 bit.
I COB sono inseriti in una o
più sequenze CAN con
identificatori predefiniti od
appositamente configurati.
Il modello del dispositivo
CANOpen
Un CANOpen device è composto da:

L'interfaccia di comunicazione
definisce oggetti di comunicazione e
fornisce i servizi per trasmettere e
ricevere nel bus gli oggetti di
comunicazione.


Il Dizionario degli oggetti descrive
tutti i Tipi di dato e gli Oggetti (COB)
accessibili dalla rete.
Il programma dell'applicazione
fornisce le funzioni di governo dei
meccanismi interni e di connessione
alle interfacce hardware del
processo.
COB
Oggetti di comunicazione

Il CANopen definisce quattro tipi di messaggi (Oggetti
di comunicazione):
 Messaggi di Gestione di rete (Network
Management - NMT)
 Oggetti di servizio (Service Data Objects - SDO)
 Oggetti di processo (Process Data Objects - PDO)
 Messaggi predefiniti, come:
 gli Oggetti Sync (Sync Objects)
 gli Oggetti Marcatempo (Time Stamp Objects)
 gli Oggetti Emergenza (Emergency Object).
Servizi di Comunicazione

Il protocollo CANopen definisce diversi metodi per
trasmettere e ricevere COB:





I trasferimenti sincroni di dati permettono alla rete di
acquisire ed elaborare grandi quantità di dati coordinati.
Messaggi asincroni o su evento possono esser inviati in
qualsiasi momento e permettono ad un dispositivo di
informare immediatamente un altro senza attendere che
abbia luogo una trasmissione sincrona.
Trasferimenti senza time constraints
Generalmente la trasmissione sincrona/asincrona/ad
eventi è limitata a 8 bytes
Si possono trasferire informazioni più lunghe di 8
bytes, ma senza avere meccanismi di gestione delle
esigenze temporali.
L’Object Dictionary
 L’ object dictionary è una
raccolta di oggetti accessibili
dalla rete
 Ogni oggetto è indirizzato
usando un 16-bit index e un
8-bit sub-index.
 L’accesso all’object dictionary
avviene tramite gli oggetti di
comunicazione e i relativi
servizi
L’Object Dictionary
 L’ object dictionary definisce
gli Static Data Types
 Sono i principali data types
utilizzati
L’Object Dictionary
 L’ object dictionary definisce
anche alcuni tipi di dati
complessi predefiniti
(Complex Data Type)
 Vengono utilizzati per alcuni
parametri di SDO e PDO
 Viene riservato spazio per
standard e complex data
types specifici del device
(Manifacturer Specific
Complex Data Types)
L’Object Dictionary
 Esempio di utilizzo
di Indici e subIndici per accedere
a ciascun oggetto
contenuto nell’
object dictionary
Meccanismi di trasferimento
dei dati

CANopen definisce due meccanismi di
trasferimento di dati:


Basata sull’uso di Service Data Object
“SDO”
Basata sull’uso di Process Data Object
“PDO”
Meccanismi di trasferimento
dei dati: SDO





La trasmissione non è caratterizzata da particolari
vincoli temporali
E’ usata generalmente per configurare dispositivi in
rete CAN, con messaggi a bassa priorità.
E’ possibile accedere direttamente all’Object
Dictionary grazie all’indice a 16 bit ed un sub-indice
di 8 bit.
Con questa modalità, è possibile realizzare
trasferimenti di dati per più di 8 byte, che si fanno
utilizzando telegrammi CAN multipli.
Viene utilizzato un modello Client/Server
Meccanismi di trasferimento
dei dati: SDO
 Solo per questo modello, è possibile trasmettere più di 8
byte, tramite segmentazione
Meccanismi di trasferimento
dei dati: SDO
Meccanismi di trasferimento
dei dati:SDO
 Accesso diretto agli oggetti del dizionario
Meccanismi di trasferimento
dei dati: PDO



La trasmissione degli Oggetti di processo è
normalmente usata per trasferire dati ad alta
velocità e con alta priorità.
In un telegramma PDO i dati sono limitati ad
8 byte.
Gli oggetti PDO vengono mappati
(preconfigurazione o manuale) sull’Object
Dictionary
PDO Mapping
 E’ possibile
definire fino a
512 PDO per la
trasmissione
(TPDO) e 512
PDO per la
ricezione (RPDO)
Meccanismi di trasferimento
dei dati: PDO



Push: I dati di processo
vengono inviati da un
"produttore" ad uno o più
“consumatori”
(multicast/broadcast)
Pull: I dati possono essere
richiesti dal/dai consumatori
(CAN Remote Frame)
I PDO sono trasmessi nella
forma "senza conferma".
Meccanismi di trasferimento
dei dati: PDO

Il Master è l’unica
entità autorizzata
all’attivazione della
comunicazione
Trasmissione su EVENTI
Meccanismi di trasferimento
dei dati: PDO

Il CANOpen prevede diversi modi per trasferire dati in tempo reale.

Un modo è di inviare semplicemente un messaggio PDO al manifestarsi
d'un evento.

Ad esempio, una porta I/O digitale trasmette lo stato delle sue linee in
entrata quando esse cambiano di stato


Questa forma di trasferimento permette di ridurre al minimo il carico
sul bus e di ottenere alte prestazioni nella comunicazione con cadenze
di bit (bit rate) relativamente basse.
Ciò permette inoltre di avere un tempo di reazione alle variazioni dei
dati, fattore critico in molte applicazioni, molto breve.
Trasmissione SINCRONA
Meccanismi di trasferimento
dei dati: PDO

La forma di trasmissione sincronizzata permette ai dispositivi in
rete di essere rigidamente sincronizzati su di un orologio pilota
(SYNC):


La sincronizzazione si riferisce alla trasmissione o alla produzione
Questa condizione è essenziale in alcune applicazioni per
controllo di posizione od in applicazioni dove si debbano leggere
o scrivere simultaneamente dati in entrate ed uscite remote.

Il protocollo permette di cambiare il periodo del ciclo

Messaggi sincroni e messaggi su evento possono essere
liberamente mescolati nella rete.
Meccanismi di trasferimento
dei dati: PDO
RICHIESTA REMOTA
Trasmissione su


Il trasferimento dati può anche
essere sollecitato da una richiesta
remota.
Un PDO può essere inviato quando
viene ricevuta una richiesta remota
(RTR)
Meccanismi di trasferimento
dei dati: PDO
Meccanismi di trasferimento
dei dati: PDO
Meccanismi di trasferimento
dei dati: PDO


Trasmissione Ciclica: la
PDO viene trasmessa
ento la finestra del
Sync periodicamente
(ogni n Sync Object)
Tasmissione Aciclica: la
PDO viene trasmessa
entro la finestra Sync,
ma non
periodicamente. Ci
deve essere un evento
specifico legato
all’applicazione che
provoca l’invio della
PDO
Synchronous Cyclic and Acyclic PDOs
Ad esempio: solo
se il valore è
cambiato
dall’ultima volta
Meccanismi di trasferimento
dei dati: PDO
 Combinando tutte le precedenti modalità trasmissive, sono
possibili diversi modelli di comunicazione impostabili per ogni
PDO:
• Syncronous Cyclic
• Synchronous Acyclic
• Synchronous Remote (Sync RTR)
• Asynchronous Remote (Async RTR)
• Asynchronous Manufacturer Profile
• Asynchronous Device Profile
Meccanismi di trasferimento
dei dati: PDO

Synchronous Cyclic :




Il valore del PDO è inviato alla ricezione dell’oggetto Sync.
E’ possibile settare il periodo (numero di oggetti Sync ricevuti)
Questa modalità ottimizza il flusso di dati, garantendo le esigenze
real-time.
Synchronous Acyclic:



Questa modalità permetta la sincronizzazione con l’oggetto Sync,
come nel modo cyclic, ma non viene trasmesso in modo periodico;
Comunque, il valore del PDO è inviato solo in dipendenza di eventi
interni all’applicazione (ad esempio se è cambiato rispetto l’ultima
trasmissione);
E’ la modalità più “economica” in termini di uso di larghezza di
banda, ma è sensibile ad errori di trasmissione (se un valore non
viene trasmesso, esso non verrà più ritrasmesso)
Meccanismi di trasferimento
dei dati: PDO

Synchronous Remote (Sync RTR):





E’ usata per realizzare trasmissioni sincrone basate su
Remote Frame.
Il device invia il valore del PDO dopo aver ricevuto la "RTR"
frame.
I dati sono aggiornati solo alla ricezione di un SYNC object.
SYNC object può essere inviato manualmente o ciclicamente
(automatico).
Asynchronous Remote (Async RTR):

Il device aggiorna ed invia il valore di PDO dopo aver
ricevuto una "RTR" frame.
Meccanismi di trasferimento
dei dati: PDO


Asynchronous, device profile :
 Una frame è inviata all’occorrenza di un
Application Event, che e’ Device-Specific (ad
esempio ad ogni cambio di valore del PDO)
 Questa modalità permette ottime prestazioni realtime
 Lo svantaggio è la saturazione della rete, se le
variazioni dei valori PDO occorrono
frequentemente (nell’esempio citato prima)
Asynchronous, manufacturer profile :
 La trasmissione è legata a quanto definito dal
produttore del device (manufacturer)
Meccanismi di trasferimento
dei dati: PDO
Serve per evitare il blocco di PDO a bassa priorità
Meccanismi di trasferimento
dei dati: PDO
 Sincronizzazione dei Clocks
Meccanismi di trasferimento
dei dati: PDO
CANOpen in Applicom
I/O Mapping and PDO
Messages
Configurazione PDO
Sono possibili diversi modelli
di comunicazione impostabili
pr ogni PDO:
• Synchronous Acyclic
• Syncronous Cyclic
• Synchronous Remote
(Sync RTR)
• Asynchronous Remote
(Async RTR)
• Asynchronous
Manufacturer Profile
• Asynchronous Device
Profile
Programmazione

La libreria Applicom CANOpen:


Appio.dll, Appio.lib, Appio.h
Alcune funzioni di libreria:



IO_Init( wCard , &status )
IO_Exit( wCard , &status )
Funzioni di lettura: prelevano gli inputs dei devices presenti
nella rete



La lettura di tutti gli ingressi è realizzata tramite la chiamata ad una
singola funzione (IO_RefreshInput), che memorizza i dati in buffer
locali.
Tramite altre funzioni di lettura, è possibile accedere ai dati nei buffer
locali.
Funzioni di scrittura: settano le uscite dei devices presenti
nella rete


La scrittura è realizzata tramite la chiamata ad una singola funzione
(IO_RefreshOutput), che attinge i dati da buffer locali.
Tramite altre funzioni di scrittura, è possibile scrivere (in precedenza) in
tali buffer locali
Programmazione

IO_RefreshInput( wCard , &status )
 legge dall’interfaccia Applicom tutti i dati di
ingresso e gli stati dei devices presenti nella rete
(immagine dei device).
 Questi valori non sono ritornati direttamente
all’applicazione, ma sono memorizzati nei buffers
locali.
 Tutte le funzioni di lettura del tipo IO_ReadXXX e
le funzioni di accesso agli stati dei devices
accedono a questi buffers locali.
 L’applicazione non viene boccata
Pogrammazione

IO_ReadIxxx

(ad esempio IO_ReadIByte)
 IO_ReadIByte(wCard, wEquip, Offset, Nb, TabByte, &Status );
Programmazione: Esempio
#include <windows.h>
#include <stdio.h>
#include "appio.h"
 Modulo WAGO 16I/16Q
 Device #1
short wCard = 1; /* Board number */
short neq = 1; /* Device number */
short nb; /* Number of variables */
short status; /* Status */
long adr = 0; /* Address of first variable */
unsigned char tablbyte[2]; /* Table containing the values */
short i;
/* For loop counter
*/
void main()
{
IO_Init( wCard ,&status);
Programmazione: Esempio
case 4: {
printf("\n LETTURA di un solo byte");
IO_RefreshInput( wCard , &status);
if (status)
printf("\n problemi relativi alla scheda");
else {
nb=1;
printf("\n Inserisci il valore dell'address byte (0-1) ");
scanf(" %ld" , &adr);
IO_ReadIByte(wCard, neq, adr,nb, tablbyte, &status );
if (!status) {
printf("\n Valore del byte numero %ld = ",adr);
printf(" %hd\n", tablbyte[0]);
}
}
break;
}
short wCard = 1;
short neq = 1;
short nb;
short status;
long adr = 0;
unsigned char tablbyte[2];
Programmazione

IO_RefreshOutput( wCard , &status )



Questa funzione viene usata per scrivere tutte le
uscite settate in precedenza nel buffer locale
(usando le funzioni IO_WriteXXX) nei devices
presenti nella rete
La funzione ritorna status 0 se qualche device è
non accessibile.
Se il device diviene nuovamente accessibile,
l’ultimo valore scritto nel buffer locale della scheda
sarà mandato al device
Programmazione

IO_WriteQxxx (ad esempio IO_WriteQByte)
 IO_WriteQByte(wCard,wEquip,Offset,Nb, TabByte, &Status );
Programmazione: Esempio
#include <windows.h>
#include <stdio.h>
#include "appio.h"
 Modulo WAGO 16I/16Q
 Device #1
short wCard = 1; /* Board number */
short neq = 1; /* Device number */
short nb; /* Number of variables */
short status; /* Status */
long adr = 0; /* Address of first variable */
unsigned char tablbyte[2]; /* Table containing the values */
short i;
/* For loop counter
*/
void main()
{
IO_Init( wCard ,&status);
Programmazione: Esempio
short wCard = 1;
short neq = 1;
short nb;
short status;
long adr = 0;
unsigned char tablbyte[2];
case 1: {
}
printf("\n SCRITTURA di un solo byte");
printf("\n Valore del byte da scrivere (-128 +127) = ");
scanf(" %hd", &tablbyte[0]);
printf("\n Valore dell'address byte (0-1) = ");
scanf("%ld", &adr);
nb=1;
IO_WriteQByte(wCard, neq, adr,nb, tablbyte, &status );
if (!status)
IO_RefreshOutput( wCard , &status);
break;
Programmazione: SYNC, RTR

E’ possibile che il Master trasmetta:


SYNC e RTR
Viene utilizzato il meccanismo di lettura/scrittura
considerando un Virtual Device 0
 Si possono gestire max 64 Slaves
 Il Device 0 viene visto come composto da:


Entrambe le aree sono formate da:





65 byte per l’output (comandi) e 65 byte per l’input (conferma)
Byte 0: Master commands
Byte 1-64: 1 byte per uno Slave
Le uscite sono aggiornate tramite IO_RefreshOutput()
Gli ingressi sono aggiornati tramite IO_RefreshInput()
L’area degli ingressi è usata per la conferma remota di
ciascun comando inviato.
Programmazione: SYNC, RTR

Byte 0 Area Output: Master Commands Area
 Bit 0: Comando di trasmissione di un SYNC e di una Remote
Frame (il SYNC period deve essere zero).
 Bit 1: Comando di trasmisione di SOLO un SYNC (il SYNC
period deve essere zero).
 Bit 2: Stop/resume nodeguarding.
 Bit 3: Toggle bit.
 Ogni comando ha effetto quando il Toggle bit cambia
 Tra ogni coppia di trasmissioni di comandi, il Master deve
attendere la conferma nell’area di Input, leggendo il primo
byte relativo al Master STATUS area, organizzato come il
Master Commands.

Il contenuto del byte dell’area STATUS deve essere identico a
quello dell’area di Commands.
Programmazione: SYNC, RTR

Byte 1-64, Area Output: Master Commands Area
 L’area di 64 bytes è dedicata alle operazioni dei RTR
TPDOs.
 Un byte rappresenta un device (max 64) e può essere sato
per gestire fino a 7 PDOs del device



1 bit per inviare una RTR per ogni PDO configurato nel device
1 "toggle bit“, che deve cambiare di stato per abilitare la
trasmissione di una RTR.
Anche in questo caso, l’area di input è utilizzata come
conferma, per ogni invio di un comando

Per ogni comando inviato, l’area di input corrispondente deve
assumere valori identici
Programmazione: SYNC, RTR

Esempio di trasmissione di un RTR al Device 1, TPDO2:
 1. Nel Byte 1 dell’Area Output: write 0x82.
 2. Wait until the Byte 1 nell’Area Input changes to 0x82
(report).
 3. write 0x02 nel Byte 1 dell’Area Output.
 4. wait for 0x02 nel Byte 1 dell’Area Input.
 5. write 0x82 nel Byte 1 dell’Area Output.
 6. wait for 0x82 nel Byte 1 dell’Area Input.
 7. write 0x02 nel Byte 1 dell’Area Output.
 8. wait for 0x02 nel Byte 1 dell’Area Input.
 9. ……….
Nota: 0x=esadecimale, 0x82=10000010, 0x02=00000010
Esempio di Programmazione:
Sync RTR

Synchronous Remote (Sync RTR):
 Il device invia il valore del PDO dopo aver ricevuto la "RTR"
frame.
 I dati sono aggiornati solo alla ricezione di un SYNC object.
 SYNC object viene inviato manualmente
Esempio di Programmazione:
Sync RTR

Esempio di programma in C:


Il Master invia manualmente comandi di Sync (per
aggiornare PDO) e Remote Frame (RTR) per imporre allo
Slave l’aggiornamento e l’invio di ingressi
Configurazione:



Device #1 con TPDO1
 Il Master legge il primo byte di ingresso del device
Device #3 con TPDO2
 Il Master legge il secondo byte di ingresso del device
Trasmissione periodica del SYNC object Disabilitata.
Esempio di Programmazione:
Sync RTR
unsigned
unsigned
unsigned
unsigned
char
char
char
char
byBufferOut[65]; /* AREA OUTPUT dei comandi inviati dal Master*/
byStatusRtr[65]; /* AREA INPUT per la conferma */
byBufferIn[65]; /* conterrà gli ingressi che voglio leggere*/
byToggleBit=0x80; /* 0x80=10000000*/
memset( byBufferOut, 0, 65);
byToggleBit ^= 0x80; /*OR esclusivo, diventano tutti 0*/
//Transmission of a SYNC
byBufferOut[0] = 0x02 ; /* 0x02=00000010, comando di un SOLO Sync*/
// Write RTR commands for device 1 TPDO1
byBufferOut[1]= byToggleBit | 0x01; /* OR 0x01=00000001, device 1 - TPDO1*/
// Write RTR commands for device 3 TPDO2
byBufferOut[3]= byToggleBit | 0x02; /* OR 0x02=00000010, device 3 – TPDO2*/
Esempio di Programmazione:
Sync RTR
// Refresh data on the applicomIO® board device 0
Equip = 0; Offset = 0; nb = 4; //solo i primi 4 bytes !
IO_WriteQByte (wCard, Equip,Offset, nb, byBufferOut, &Status );
IO_RefreshOutput (wCard, &Status );
// Read RTR STATUSES
do
{
// Read data on the applicomIO® board device 0
IO_RefreshInput (wCard, &Status );
Equip = 0; Offset = 0; nb = 4; //solo i primi 4 bytes !
IO_ReadIByte (wCard, Equip, Offset, nb, byStatusRtr, &Status );
Ret = memcmp(byStatusRtr, byBufferOut,4)
}while (Ret != 0); /*while the arrays are different*/
Esempio di Programmazione:
Sync RTR
// Read Input DATA from device 1
Equip = 1; Offset = 0; nb = 1; /*primo byte di ingresso*/
IO_ReadIByte (wCard, Equip, Offset, nb, &byBufferIn[0], &Status );
// Read Input DATA from device 3
Equip = 3; Offset = 1; nb = 1; /*secondo byte di ingresso*/
IO_ReadIByte (wCard, Equip, Offset, nb, &byBufferIn[1], &Status );