La presentazione è in caricamento. Aspetta per favore

La presentazione è in caricamento. Aspetta per favore

Il CANOpen. Il modello di riferimento di CANopen ISO, IS-11898, "Road Vehicle - Interchange of Digital Information - Controller Area Network (CAN) for.

Presentazioni simili


Presentazione sul tema: "Il CANOpen. Il modello di riferimento di CANopen ISO, IS-11898, "Road Vehicle - Interchange of Digital Information - Controller Area Network (CAN) for."— Transcript della presentazione:

1 Il CANOpen

2 Il modello di riferimento di CANopen ISO, IS-11898, "Road Vehicle - Interchange of Digital Information - Controller Area Network (CAN) for High Speed Communication", CIA – DS2xx, DS3xx, DS4xx Cenelec, EN , "Industrial Communications Subsystem based on ISO (CAN) for Controller- device Interfaces. Part 4: CANOpen", 2001.

3 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

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

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 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 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 Trasmissione su EVENTI

23 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 Trasmissione SINCRONA

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

25 Meccanismi di trasferimento dei dati: PDO

26

27 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 Ad esempio: solo se il valore è cambiato dallultima volta Synchronous Cyclic and Acyclic PDOs

28 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

29 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) Meccanismi di trasferimento dei dati: PDO

30 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

31 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) Meccanismi di trasferimento dei dati: PDO

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

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

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

46 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 ( ) = "); 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; }

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 Esempio di trasmissione di un RTR al Device 1, TPDO2: 1. Nel Byte 1 dellArea Output: write 0x 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: 0x=esadecimale, 0x82= , 0x02= Programmazione: SYNC, RTR

51 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

52 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 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 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= */ memset( byBufferOut, 0, 65); byToggleBit ^= 0x80; /*OR esclusivo, diventano tutti 0*/ //Transmission of a SYNC byBufferOut[0] = 0x02 ; /* 0x02= , comando di un SOLO Sync*/ // Write RTR commands for device 1 TPDO1 byBufferOut[1]= byToggleBit | 0x01; /* OR 0x01= , device 1 - TPDO1*/ // Write RTR commands for device 3 TPDO2 byBufferOut[3]= byToggleBit | 0x02; /* OR 0x02= , device 3 – TPDO2*/

54 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*/

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


Scaricare ppt "Il CANOpen. Il modello di riferimento di CANopen ISO, IS-11898, "Road Vehicle - Interchange of Digital Information - Controller Area Network (CAN) for."

Presentazioni simili


Annunci Google