8
SOMMARIO
Un sistema di automazione industriale complesso – come ad esempio una linea di produzione e/o assemblaggio – di solito necessita di una gerarchia organizzata di sistemi controllori per poter funzionare correttamente. In questa gerarchia è presente solitamente una ―Human Machine Interface‖ (HMI) in cima alla gerarchia, dove un operatore può monitorare o intervenire sul sistema. Quest‘interfaccia è generalmente collegata a un livello sottostante della gerarchia costituito da un insieme di ―Programmable Logic Controllers‖ (PLC) attraverso un sistema di comunicazione non critico dal punto di vista temporale (per esempio Ethernet). I PLC controllano aree individuali o ―celle‖ di produzione. Al livello più basso della catena di controllo troviamo I ―bus di campo‖ o ―fieldbus‖, che collegano i PLC ai componenti che svolgono effettivamente il lavoro, come sensori, attuatori, motori elettrici, switches, valvole etc.
La comunicazione ―classica‖ tra PLC e i sensori, attuatori etc. è realizzata mediante collegamenti con un doppino intrecciato schermato di tipo poin-to-point, come ad esempio nel ―4-20mA current loop‖: al valore 0% corrisponde una corrente di 4mA mentre al valore 100% corrisponde una corrente di 20mA. Tale collegamento è oggi ritenuto molto costoso perché si ha un elevato numero di collegamenti e il cablaggio risulta molto complesso ed ingombrante. Collegare in questo modo, ad esempio 100-1000 o anche 100-10000 punti, dal PLC risulta estremamente costoso. Questo è uno dei motivi (ma non l‘unico) che hanno spinto a cercare soluzioni che prevedessero il collegamento di tutti i dispositivi attraverso un unico bus detto appunto ―bus di campo‖ o ―Fieldbus‖.
Nel primo capitolo saranno presentate le caratteristiche peculiari dei Fieldbus, una panoramica sulla sua evoluzione, per giungere poi agli standard attuali per mostrare come il Fieldbus rappresenta una famiglia di soluzioni a problemi tra loro simili ma non uguali, ognuna delle quali meglio si adatta ad un particolare contesto.
Tra queste soluzioni, le più recenti si sono focalizzate su Ethernet come physical layer. Il motivo principale dell‘introduzione di Ethernet fu il suo ruolo dominante nel mondo dell‘ufficio e il risultante stato di soluzione di network uniforme. Altro fattore decisivo è la possibilità di creare network comunque complessi con un costo notevolmente più contenuto rispetto ad altre soluzioni. Inoltre Ethernet ha tutte le potenzialità per
9
soddisfare il requisito sempre più necessario di controllo in ―real-time‖. Tra i diversi approcci dell‘Industrial Ethernet spicca EtherCAT (Ethernet for Control Automation Technology, sviluppato da Bechkoff), per i suoi tempi di ciclo (periodo di aggiornamento dei dati) estremamente brevi (sull‘ordine del millisecondo indipendentemente dalla complessità del network), con bassissimi jitter di comunicazione (permettendo una perfetta sincronizzazione di tutti i dispositivi) e bassi costi dell‘hardware.
Le tipiche reti di automazioni sono caratterizzate da lunghezza dati molto corte per ogni nodo, significativamente minori del minimo payload di un frame Ethernet. In questa situazione, l‘uso di un frame per nodo per ciclo comporta uno scarso utilizzo della banda e quindi a delle povere prestazioni della rete. Inoltre l‘Ethernet standard prevede che il frame sia ricevuto, ―spacchettato‖, che avvenga la lettura/scrittura dei dati, ricostruito il frame e inviato all'elemento successivo della rete. EtherCAT utilizza un diverso approccio, chiamato ―on the fly‖ (―al volo‖) e un‘architettura di tipo Master\Slaves. Si può pensare al frame Ethernet come a un treno, i cui vagoni rappresentano i diversi comandi EtherCAT (per aumentare la banda, ogni frame Ethernet contiene più comandi indirizzati a uno o più slave). Questo ―treno‖ parte e ritorna al Master senza mai fermarsi: quando arriva nelle diverse stazioni (gli slaves) il treno/frame non si ferma ma rallenta, giusto il tempo necessario allo slave per recepire il comando e leggere/scrivere i dati nelle opportune aree del frame, per poi proseguire verso la stazione/slave successiva; arrivato all‘ultimo slave, il frame viene automaticamente mandato indietro verso il master.
Il secondo capitolo presenterà le caratteristiche essenziali di EtherCAT e l‘architettura del Master e degli Slave.
Qualunque dispositivo che supporti Ethernet come physical communication layer può implementare un controllore EtherCAT, dal PC al microcontrollore general purpose. Il microcontrollore netX della Hilscher nasce invece come dispositivo pensato per supportare prevalentemente (se non esclusivamente) i Fieldbus, e presenta a tale scopo una specifica architettura hardware nonché un particolare sistema operativo (―Realtime Communication-system for netX‖, rcX).
Il terzo capitolo presenterà il microcontrollore netX, il sistema operativo rcX e l‘ambiente di sviluppo.
10
Nella seconda parte di questo lavoro sarà mostrato come è stato realizzato il Master EtherCAT e l‘user layer per l‘interfacciamento con il Master da parte di un operatore umano.
Al fine di ridurre i costi di produzione, si è deciso di ricorrere a codice Open Source ove possibile. In particolare, la versione del sistema operativo rcX è quella gratuita contenuta nell‘Evaluation Kit della Hilscher. In questa versione è disponibile la versione base del kernel e i driver essenziali; tutto il resto è stato implementato manualmente.
Il punto di partenza per la realizzazione del codice Master è stato il SOEM, Simple Open EterCAT Master, una libreria scritta in C caratterizzata dall‘elevata portabilità. Questa libreria costituisce solo la backbone di un codice Master, mette a disposizione le funzioni primitive, ma manca delle caratteristiche salienti per poter lavorare su un impianto reale (a titolo di esempio, il codice SOEM permette la configurazione della rete attraverso la scansione degli slaves della rete, ma non la configurazione della stessa attraverso un file XML; inoltre non prevede la gestione di frame con più comandi EtherCAT).
Il presente lavoro si focalizza sulla realizzazione di un‘implementazione completa del codice Master, tale da poter essere effettivamente utilizzata in un impianto industriale. Successivamente verrà presentato lo sviluppo dell‘user layer.
L‘interfacciamento tipico tra Master EtherCAT e operatore (agente su un dispositivo ―host‖, tipicamente un PC) avviene attraverso l‘uso di una memoria dual-ported, in cui sono allocate le variabili di stato e di controllo del master e degli slave, nonché le Process Image di input ed output.
L‘originalità del presente lavoro consiste nell‘aver affiancato a questa dual-port memory un interfacciamento basato su Web-Server: in questo modo si può accedere al Master EtherCAT e quindi monitorare, controllare e perfino impostare l‘intero network EtherCAT comunque complesso, anche attraverso un semplice dispositivo di telefonia mobile (telefono, palmare, smartphone o tablet) purché dotato di connessione Internet e un Web-Browser.
