Il CANOpen

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.

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

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

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

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) RICHIESTA REMOTA Trasmissione su

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

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 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 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: Esempio short 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: 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: 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

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