il canopen. il modello di riferimento di canopen iso, is-11898, "road vehicle - interchange of...

Il CANOpen

Il modello di riferimento di CANopen

ISO, IS-11898, "Road Vehicle - Interchange of Digital Information - Controller Area Network (CAN) for High Speed Communication", 1993.

CIA – DS2xx, DS3xx, DS4xx

Cenelec, EN50325-4, "Industrial Communications Subsystem based on ISO 11898 (CAN) for Controller-device Interfaces.

Part 4: CANOpen", 2001.

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

Il modello di riferimento di CANopen

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 sub-Indici 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

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.

Meccanismi di trasferimento dei dati: PDO

Tra

smis

sion

e s

u E

VEN

TI

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

Tra

smis

sion

e S

INC

RO

NA

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

Tra

smis

sion

e s

u

RIC

HIE

STA

REM

OTA

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

Ad esempio: solo se il valore è cambiato dall’ultima volta

Synchronous Cyclic and Acyclic PDOs

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 real-time

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

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"

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

Modulo WAGO 16I/16Q

Device #1

Programmazione: Esempioshort wCard = 1; short neq = 1; short nb; short status; long adr = 0; unsigned char tablbyte[2];

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;}

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"

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

Modulo WAGO 16I/16Q

Device #1

Programmazione: Esempioshort 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:

65 byte per l’output (comandi) e 65 byte per l’input (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() 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

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

Programmazione: SYNC, RTR

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 char byBufferOut[65]; /* AREA OUTPUT dei comandi inviati dal Master*/

unsigned char byStatusRtr[65]; /* AREA INPUT per la conferma */

unsigned char byBufferIn[65]; /* conterrà gli ingressi che voglio leggere*/

unsigned char byToggleBit=0x80; /* 0x80=10000000*/

memset( byBufferOut, 0, 65);byToggleBit ^= 0x80; /*OR esclusivo, diventano tutti 0*///Transmission of a SYNCbyBufferOut[0] = 0x02 ; /* 0x02=00000010, comando di un SOLO Sync*/

// Write RTR commands for device 1 TPDO1byBufferOut[1]= byToggleBit | 0x01; /* OR 0x01=00000001, device 1 - TPDO1*/

// Write RTR commands for device 3 TPDO2byBufferOut[3]= byToggleBit | 0x02; /* OR 0x02=00000010, device 3 – TPDO2*/

Esempio di Programmazione:Sync RTR

// Refresh data on the applicomIO® board device 0Equip = 0; Offset = 0; nb = 4; //solo i primi 4 bytes !IO_WriteQByte (wCard, Equip,Offset, nb, byBufferOut, &Status );IO_RefreshOutput (wCard, &Status );

// Read RTR STATUSESdo{

// Read data on the applicomIO® board device 0IO_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 3Equip = 3; Offset = 1; nb = 1; /*secondo byte di ingresso*/IO_ReadIByte (wCard, Equip, Offset, nb, &byBufferIn[1], &Status );