Il CANOpen

1
Il CANOpen
2
Il modello di riferimento di CANopen
CIA DS2xx, DS3xx, DS4xx Cenelec, EN50325-4,
"Industrial Communications Subsystem based on ISO
11898 (CAN) for Controller-device Interfaces.
Part 4 CANOpen", 2001.
ISO, IS-11898, "Road Vehicle - Interchange of
Digital Information - Controller Area Network
(CAN) for High Speed Communication", 1993.
3
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.

4
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

5
Le interazioni tra gli strati del protocollo

• Nell Application Layer i dispositivi si
  scambiano Communication and Application Objects
  (COB)
• I COB permettono laccesso 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.

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

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

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

9
LObject 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.
• Laccesso allobject dictionary avviene tramite
  gli oggetti di comunicazione e i relativi servizi

10
LObject Dictionary

• L object dictionary definisce gli Static Data
  Types
• Sono i principali data types utilizzati

11
LObject 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)

12
LObject Dictionary

• Esempio di utilizzo di Indici e sub-Indici per
  accedere a ciascun oggetto contenuto nell object
  dictionary

13
Meccanismi di trasferimento dei dati

• CANopen definisce due meccanismi di trasferimento
  di dati
• Basata sulluso di Service Data Object SDO
• Basata sulluso di Process Data Object PDO

14
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 allObject
  Dictionary grazie allindice 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

15
Meccanismi di trasferimento dei dati SDO

• Solo per questo modello, è possibile trasmettere
  più di 8 byte, tramite segmentazione

16
Meccanismi di trasferimento dei dati SDO
17
Meccanismi di trasferimento dei datiSDO

• Accesso diretto agli oggetti del dizionario

18
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) sullObject
  Dictionary

19
PDO Mapping

• E possibile definire fino a 512 PDO per la
  trasmissione (TPDO) e 512 PDO per la ricezione
  (RPDO)

20
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".

21
Meccanismi di trasferimento dei dati PDO

• Il Master è lunica entità autorizzata
  allattivazione della comunicazione

22
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 su EVENTI
23
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.

Trasmissione SINCRONA
24
Meccanismi di trasferimento dei dati PDO

• Il trasferimento dati può anche essere
  sollecitato da una richiesta remota.
• Un PDO può essere inviato quando viene ricevuta
  una richiesta remota (RTR)

Trasmissione su RICHIESTA REMOTA
25
Meccanismi di trasferimento dei dati PDO
26
Meccanismi di trasferimento dei dati PDO
27
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
  allapplicazione che provoca linvio della PDO

28
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

29
Meccanismi di trasferimento dei dati PDO

• Synchronous Cyclic
• Il valore del PDO è inviato alla ricezione
  delloggetto 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
  loggetto Sync, come nel modo cyclic, ma non
  viene trasmesso in modo periodico
• Comunque, il valore del PDO è inviato solo in
  dipendenza di eventi interni allapplicazione (ad
  esempio se è cambiato rispetto lultima
  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)

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

31
Meccanismi di trasferimento dei dati PDO

• Asynchronous, device profile
• Una frame è inviata alloccorrenza di un
  Application Event, che e Device-Specific (ad
  esempio ad ogni cambio di valore del PDO)
• Questa modalità permette ottime prestazioni
  real-time
• Lo svantaggio è la saturazione della rete, se le
  variazioni dei valori PDO occorrono
  frequentemente (nellesempio citato prima)
• Asynchronous, manufacturer profile
• La trasmissione è legata a quanto definito dal
  produttore del device (manufacturer)

32
Meccanismi di trasferimento dei dati PDO
Serve per evitare il blocco di PDO a bassa
priorità
33
Meccanismi di trasferimento dei dati PDO

• Sincronizzazione dei Clocks

34
Meccanismi di trasferimento dei dati PDO
35
CANOpen in Applicom
36
I/O Mapping and PDO Messages
37
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

38
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

39
Programmazione

• IO_RefreshInput( wCard , status )
• legge dallinterfaccia Applicom tutti i dati di
  ingresso e gli stati dei devices presenti nella
  rete (immagine dei device).
• Questi valori non sono ritornati direttamente
  allapplicazione, 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.
• Lapplicazione non viene boccata

40
Pogrammazione

• IO_ReadIxxx
• (ad esempio IO_ReadIByte)
• IO_ReadIByte(wCard, wEquip, Offset, Nb, TabByte,
  Status )

41
Programmazione Esempio
include ltwindows.hgt include ltstdio.hgt include
"appio.h" 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 tablbyte2 / Table containing
the values / short i / For loop
counter / void main() IO_Init( wCard
,status)

• Modulo WAGO 16I/16Q
• Device 1

42
Programmazione Esempio
short wCard 1 short neq 1 short nb
short status long adr 0 unsigned char
tablbyte2
case 4 printf("\n LETTURA di un solo
byte") IO_RefreshInput( wCard , status)
if (status) printf("\n problemi
relativi alla scheda") else nb1
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", tablbyte0) break
43
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,
  lultimo valore scritto nel buffer locale della
  scheda sarà mandato al device

44
Programmazione

• IO_WriteQxxx (ad esempio IO_WriteQByte)
• IO_WriteQByte(wCard,wEquip,Offset,Nb, TabByte,
  Status )

45
Programmazione Esempio
include ltwindows.hgt include ltstdio.hgt include
"appio.h" 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 tablbyte2 / Table containing
the values / short i / For loop
counter / void main() IO_Init( wCard
,status)

• Modulo WAGO 16I/16Q
• Device 1

46
Programmazione Esempio
short wCard 1 short neq 1 short nb
short status long adr 0 unsigned char
tablbyte2
case 1 printf("\n SCRITTURA di un solo
byte") printf("\n Valore del byte
da scrivere (-128 127) ")
scanf(" hd", tablbyte0) printf("\n
Valore dell'address byte (0-1) ")
scanf("ld", adr) nb1
IO_WriteQByte(wCard, neq, adr,nb, tablbyte,
status ) if (!status)
IO_RefreshOutput( wCard , status) break
47
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
• 65 byte per loutput (comandi) e 65 byte per
  linput (conferma)
• Entrambe le aree sono formate da
• 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()
• Larea degli ingressi è usata per la conferma
  remota di ciascun comando inviato.

48
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 nellarea di
  Input, leggendo il primo byte relativo al Master
  STATUS area, organizzato come il Master Commands.
• Il contenuto del byte dellarea STATUS deve
  essere identico a quello dellarea di Commands.

49
Programmazione SYNC, RTR

• Byte 1-64, Area Output Master Commands Area
• Larea 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, larea di input è
  utilizzata come conferma, per ogni invio di un
  comando
• Per ogni comando inviato, larea di input
  corrispondente deve assumere valori identici

50
Programmazione SYNC, RTR

• Esempio di trasmissione di un RTR al Device 1,
  TPDO2
• 1. Nel Byte 1 dellArea Output write 0x82.
• 2. Wait until the Byte 1 nellArea Input changes
  to 0x82 (report).
• 3. write 0x02 nel Byte 1 dellArea Output.
• 4. wait for 0x02 nel Byte 1 dellArea Input.
• 5. write 0x82 nel Byte 1 dellArea Output.
• 6. wait for 0x82 nel Byte 1 dellArea Input.
• 7. write 0x02 nel Byte 1 dellArea Output.
• 8. wait for 0x02 nel Byte 1 dellArea Input.
• 9. .
• Nota 0xesadecimale, 0x8210000010,
  0x0200000010

51
Esempio di ProgrammazioneSync 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

52
Esempio di ProgrammazioneSync RTR

• Esempio di programma in C
• Il Master invia manualmente comandi di Sync (per
  aggiornare PDO) e Remote Frame (RTR) per imporre
  allo Slave laggiornamento e linvio 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.

53
Esempio di ProgrammazioneSync RTR
unsigned char byBufferOut65 / AREA OUTPUT dei
comandi inviati dal Master/ unsigned char
byStatusRtr65 / AREA INPUT per la conferma
/ unsigned char byBufferIn65 / conterrà gli
ingressi che voglio leggere/ unsigned char
byToggleBit0x80 / 0x8010000000/ memset(
byBufferOut, 0, 65) byToggleBit 0x80 /OR
esclusivo, diventano tutti 0/ //Transmission of
a SYNC byBufferOut0 0x02 / 0x0200000010,
comando di un SOLO Sync/ // Write RTR commands
for device 1 TPDO1 byBufferOut1 byToggleBit
0x01 / OR 0x0100000001, device 1 - TPDO1/ //
Write RTR commands for device 3
TPDO2 byBufferOut3 byToggleBit 0x02 / OR
0x0200000010, device 3 TPDO2/
54
Esempio di ProgrammazioneSync 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/
55
Esempio di ProgrammazioneSync RTR
// Read Input DATA from device 1 Equip 1
Offset 0 nb 1 /primo byte di
ingresso/ IO_ReadIByte (wCard, Equip, Offset,
nb, byBufferIn0, Status ) // Read Input
DATA from device 3 Equip 3 Offset 1 nb 1
/secondo byte di ingresso/ IO_ReadIByte (wCard,
Equip, Offset, nb, byBufferIn1, Status )