ALMA MATER STUDIORUM – UNIVERSITÀ DI BOLOGNA
SCUOLA DI INGEGNERIA E ARCHITETTURA
- Sede di Forlì -
CORSO DI LAUREA
IN INGEGNERIA AEROSPAZIALE
Classe: L-9
ELABORATO FINALE DI LAUREA
in
Impianti Aerospaziali
PROGETTO E REALIZZAZIONE DI UN DISPOSITIVO DI CONTROLLO E
GESTIONE REMOTO PER UN SISTEMA DI TRACKING SATELLITARE
(ALMATRACKER)
CANDIDATO
Igor Gai
RELATORE
Prof. Paolo Tortora
CORRELATORE
Ing. Claudio Bianchi
Anno Accademico 2012/2013 Sessione IIa
Sommario
INDICE DELLE FIGURE ... 1
INDICE DELLE TABELLE ... 4
CAPITOLO PRIMO ... 5
INTRODUZIONE ... 5
1.1.PROGETTO ALMATRACKER... 5
CAPITOLO SECONDO ... 7
COMPONENTI DEL SISTEMA ... 7
2.1. PC CLIENT ... 7 2.2. COMPACT RIO ... 7 2.3. ENCODER ... 9 2.3.1. Interfaccia SSI ... 10 2.4. AZIONAMENTI ... 11 2.4.1. Protocollo USS® ... 12 2.5. MECCANICA ... 14 CAPITOLO TERZO ... 17 ARCHITETTURA SOFTWARE ... 17 3.1. INTERFACCIA FPGA... 18
3.1.1. Acquisizione dato angolare ... 18
3.1.2. Generazione dei segnali di velocità ... 21
3.1.3. Generazione dei segnali di fine corsa ... 23
3.2. INTERFACCIA CRIO ... 24
3.2.1. Elaborazione dati encoder ... 25
3.2.2. Calcolo delle velocità ... 26
3.2.3. Comandi motore (SiemensUSS.vi) ... 33
3.2.4. Sequenza di accensione ... 44
3.2.5. Preparazione pacchetti dati cRIO ... 48
3.3. INTERFACCIA CLIENT ... 50
3.3.1. Inizializzazione dei comandi ... 51
3.3.2. Acquisizione delle polinomiali ... 52
3.3.4. Interfaccia grafica ... 56
CAPITOLO QUARTO ... 58
COMUNICAZIONE DATI VIA TCP/IP ... 58
4.1. PROTOCOLLO ATTP(ALMATRACKER TCP/IP PROTOCOL) ... 59
4.2. CICLO DI RICEZIONE ... 59
4.3. CICLO DI TRASMISSIONE ... 61
4.4.STABILITA’ DELLA CONNESSIONE ... 63
CAPITOLO QUINTO ... 66
CONTROLLO DEL SISTEMA ... 66
5.0.1. Correzione del setpoint di velocità ... 68
5.0.2. Controllore di rampa ... 68
5.0.3. Contatti di fine corsa ... 69
5.1. SETPOINT DI VELOCITÀ ... 71
5.2. SETPOINT DI POSIZIONE ... 72
5.3. CONTROLLO SECONDO POLINOMIALE ... 74
CAPITOLO SESTO ... 79
CONCLUSIONI ... 79
6.1SVILUPPI FUTURI ... 81
APPENDICE ... 83
ALMATRACKER TRANSMISSION PROTOCOL (ATTP) ... 83
CENNI SU LABVIEW ... 89
SUBVI SVILUPPATE ... 91
ALMATRACKER REPORT STS.M ... 97
RIFERIMENTI BIBLIOGRAFICI ... 103
1
Indice delle figure
Figura 1 ... 8 Figura 2 ... 8 Figura 3 ... 10 Figura 4 ... 11 Figura 5 ... 12 Figura 6 ... 13 Figura 7 ... 15 Figura 8 ... 16 Figura 9 ... 17 Figura 10 ... 18 Figura 11 ... 19 Figura 12 ... 20 Figura 13 ... 20 Figura 14 ... 21 Figura 15 ... 22 Figura 16 ... 25 Figura 17 ... 28 Figura 18 ... 29 Figura 19 ... 30 Figura 20 ... 30 Figura 21 ... 31 Figura 22 ... 31 Figura 23 ... 31 Figura 24 ... 31 Figura 25 ... 35 Figura 26 ... 35 Figura 27 ... 36 Figura 28 ... 37 Figura 29 ... 38
2 Figura 30 ... 39 Figura 31 ... 40 Figura 32 ... 41 Figura 33 ... 42 Figura 34 ... 43 Figura 35 ... 44 Figura 36 ... 45 Figura 37 ... 46 Figura 38 ... 48 Figura 39 ... 49 Figura 40 ... 50 Figura 41 ... 50 Figura 42 ... 52 Figura 43 ... 52 Figura 44 ... 54 Figura 45 ... 54 Figura 46. ... 55 Figura 47 ... 55 Figura 48 ... 56 Figura 49 ... 57 Figura 50 ... 60 Figura 51 ... 61 Figura 52 ... 62 Figura 53 ... 63 Figura 54 ... 64 Figura 55 ... 65 Figura 56 ... 66 Figura 57 ... 67 Figura 58. ... 68 Figura 59 ... 71 Figura 60 ... 71 Figura 61 ... 72
3 Figura 62 ... 74 Figura 63 ... 75 Figura 64 ... 76 Figura 65 ... 77 Figura 66 ... 77 Figura 67 ... 81 Figura 68. ... 81 Figura 69 ... 92 Figura 70 ... 93 Figura 71 ... 94 Figura 72 ... 94 Figura 73 ... 95 Figura 74 ... 95 Figura 75 ... 96 Figura 76 ... 96 Figura 77 ... 96 Figura 78 ... 96
4
Indice delle tabelle
Tabella 1 ... 13 Tabella 2 ... 23 Tabella 3 ... 29 Tabella 4 ... 32 Tabella 5 ... 79 Tabella 6 ... 79 Tabella 7 ... 80 Tabella 8 ... 80
5
Capitolo Primo
I
NTRODUZIONE
La seguente tesi presenta lo sviluppo di un sistema di controllo e gestione remota per il tracking di un satellite. Il progetto, denominato ALMATracker, è sviluppato dal corso di Ingegneria Aerospaziale della scuola di Ingegneria e Architettura Aerospaziale dell’Università di Bologna con sede a Forlì. Consiste nella creazione di una motorizzazione per antenne su due assi, movimentata da un hardware commerciale programmabile. Il posizionamento può essere eseguito sia manualmente, su richiesta di un utente da PC remoto, sia automaticamente secondo un’orbita preimpostata. I setpoint di velocità o posizione sono elaborati dal sistema fino ad ottenere un segnale che procede alla movimentazione in velocità dell’antenna. Il comando automatico, invece, orienta l’antenna in modo tale da mantenerla fissa su una traiettoria orbitale di uno specifico spacecraft. La movimentazione automatica segue funzioni polinomiali fornite dall’utente, ricavate da software di propagazione e predizione esterno al sistema ALMATracker. In questo caso il sistema deve procedere alla rotazione mantenendo la velocità richiesta dalla funzione polinomiale. Il controllo effettuato in catena chiusa è attuato tramite una serie di trasduttori di posizione presenti nel sistema.
1.1.PROGETTO ALMATRACKER
Il progetto ALMATracker consiste nella creazione di una motorizzazione di antenna su due assi per il tracking satellitare la cui realizzazione si divide in tre macro-blocchi principali:
un sistema meccanico costituito da antenna e motorizzazione;
un sistema hardware costituito da CompactRIO e PC;
un sistema software costituito dagli algoritmi di movimentazione e controllo del sistema.
6
Tutto il sistema di movimentazione deve essere chiuso in cicli di retroazione (in the loop), cioè in un sistema hardware-software che permetta non solo di comandare la movimentazione ma anche di controllare lo spostamento effettivamente avvenuto, ed adotti eventualmente una correzione automatica della traiettoria di inseguimento. Il sistema di controllo deve interagire con quello di movimentazione in maniera attiva, utilizzando il segnale di ritorno dai sensori per verificare l’efficacia delle azioni intraprese. Nei prossimi paragrafi verranno approfonditi i punti principali di cui è composto il software, e di come questo è stato sviluppato per giungere all’efficienza più alta con i componenti a disposizione.
7
Capitolo Secondo
C
OMPONENTI DEL SISTEMA
Il sistema ALMATracker è composto di una serie di dispositivi per l’acquisizione degli angoli caratteristici, il controllo degli azionamenti e la gestione logica del sistema intero.
Il nodo centrale del sistema è costituito da un’elettronica programmabile della NI, la cRIO. Ad essa sono collegati tutti gli attuatori e tutti i trasduttori del sistema. Il controllo da parte dell’utente è eseguito non direttamente sulla cRio ma da PC remoto. Questa soluzione è stata adottata per rendere il più possibile remotata e autonoma la stazione di tracking.
2.1. PC CLIENT
L’HID del sistema ALMATracker è costituito da un PC Windows. Il PC rappresenta un terminale sul quale è eseguita quella parte del software che permette all’utente di potersi collegare al sistema remoto e di poterne controllare modalità di esecuzione del tracking – manuale o automatica – e modificarne i parametri (ad esempio i setpoint o le polinomiali). Il carico di calcolo richiesto al PC è minimo poiché le sue funzioni si limitano a visualizzazione, modifica dei parametri e comunicazione in TCP con la stazione di tracking.
2.2. COMPACT RIO
La CompactRIO (d’ora in poi cRIO) è un sistema hardware integrato per l’acquisizione e l’elaborazione dati commercializzato dalla National Instuments. Questo hardware è costituito da un controller, uno chassis e uno o più moduli di acquisizione inseribili nello chassis. Il controller, che ospita l’unità di elaborazione RT (Real-Time), è direttamente collegato allo chassis. All’interno dello chassis è alloggiato il chip FPGA collegato tramite un bus, sia ai vari moduli estraibili, sia al controller RT. Il funzionamento del sistema può avvenire o direttamente con una
8
comunicazione tra RT e i vari moduli alloggiati nello chassis chiamati C-module, oppure attraverso la programmazione diretta dell’FPGA nel caso siano richieste performance in termini di sincronia e velocità superiori. Sia il controller RT sia l’FPGA sono programmati in linguaggio LabVIEW con strumenti simili e medesima strategia software ma con diverse limitazioni. Nel caso dell’RT non si ha accesso diretto ai moduli e le frequenze di lavoro sono inferiori. Nel caso dell’FPGA si ha un’elevata frequenza di esecuzione ma con limitazioni all’uso di numeri interi avendo a disposizione operazioni binarie e non in virgola mobile. Nello specifico del progetto si è utilizzato una cRIO 9014 con chassis NI 9103 ed un unico C-module per l’acquisizione di segnali digitali NI 9401 a 8 canali. I canali da DIO0 a DIO3 sono stati impostati in lettura, mentre quelli da DIO4 a DIO7 in scrittura.
Figura 1 – Elementi costituenti di una cRIO. Da sinistra si possono osservare: il modulo RT NI 9014, lo chassis a
4 slot ed infine il modulo di acquisizione dei segnali NI 9104.
9
2.3. ENCODER
Gli encoder rotativi sono dei traduttori di posizione angolare che permettono la misura di un angolo tramite la conversione in un segnale elettrico digitale. Gli encoder sono tutti costituiti da un corpo fisso e da un rotore libero di ruotare, e si dividono in vari gruppi diversi per funzionamento e/o informazioni restituite:
A. principio di trasduzione a. capacitivo; b. magnetico; c. potenziometrico. B. informazioni sull’angolo a. encoder tachimetrico; b. encoder relativo; c. encoder assoluto.
Il principio di trasduzione riguarda l’elettronica interna del dispositivo e non è importante ai fini della rilevazione. Più interessante è invece la classificazione secondo le informazioni sull’angolo, poiché una stessa posizione è identificata da codici diversi a seconda del gruppo di appartenenza. Un encoder tachimetrico è costituito da un anello con due o più tacche separate, che invia un impulso ogni volta che il riferimento (un punto prefissato del rotore) passa da una tacca ad un’altra differente. Il segnale così generato sarà proporzionale al numero di tacche attraversate in un determinato intervallo di tempo, fornendo un’indicazione di velocità. Un encoder relativo invece restituisce direttamente un’informazione su velocità ed accelerazione del rotore, ma non sulla posizione. Un encoder assoluto, al contrario, fornisce l’angolo istantaneo di posizione del rotore. In quest’ultimo si utilizzano degli anelli concentrici presenti all’interno della carcassa, che allineandosi secondo varie combinazioni generano un segnale elettrico in uscita contenente le informazioni sull’angolo.
ALMATracker prevede l’utilizzo di due encoder rotativi assoluti ROTACOD
HS58M posizionati solidali con i due assi di rotazione. Questi dispositivi sono in
10
posizioni equidistanti. Volendo valutare la precisione in termini più comuni, si ottiene:
Figura 3 – Uno dei due encoder ROTACOD HS58M utilizzati per la lettura dei dati angolari sul sistema
ALMATracker.
2.3.1. Interfaccia SSI
L’Interfaccia SSI (Synchronous Serial Interface) è un sistema di comunicazione dati “compatto” nato appositamente per ridurre il numero di connessioni necessarie tra encoder e sistema di elaborazione. Ad esempio encoder come quelli utilizzati per ALMATracker utilizzano un protocollo formato da 32 bit dove i primi 6 bit meno significativi rappresentano il controllo a ridondanza ciclica (CRC, Cyclic Redundancy Check), seguono due bit – uno di avviso e uno di errore – e concludono i rimanenti 16 bit che rappresentano l’angolo misurato espresso in codifica Gray. Il codice Gray assicura un minore rischio di errori nella misura dell’angolo poiché tra due angoli adiacenti la stringa varia soltanto di un bit. L’interfaccia SSI consiste nell’invio seriale di sequenze di bit al cui interno sono presenti informazioni di
11 posizione e stato dell’encoder. La sequenza di bit contenente la posizione angolare è contenuta all’interno di uno shift register dell’encoder. La lettura di tale registro avviene in maniera sincrona con una linea di clock di frequenza compresa fra 100 kHz e 10 MHz. E’ necessario inviare un treno di impulsi (tanti quanti sono il numero dei bit dello shift register), al quale l’encoder risponde restituendo per ogni fronte di discesa del segnale di clock un bit in uscita fino allo svuotamento dell’intero registro.
L’encoder è stato collegato con la cRio tramite un bus seriale standard RS422 differenziale. L’alimentazione dell’encoder è stata fornita con un alimentatore stabilizzato a 12 V DC. Tuttavia il modulo (NI9401) utilizzato gestisce segnali in ingresso ed uscita di tensione compresa nell’intervallo 0 – 5 V. Per questo si è reso necessario l’utilizzo di un circuito che realizzasse la traslazione di livello da 0 – 12 V a 0 – 5 V.
Figura 4 – Circuito per la traslazione dei livelli logici tra encoder e modulo NI9401.
2.4. AZIONAMENTI
Gli azionamenti sono costituiti da due motori brushless AC e due moduli di controllo. Motori e moduli di controllo sono connessi tramite bus dati proprietari, per il controllo, e da linee di potenza. Il collegamento tra gli azionamenti avviene tramite BUS RS485. Tramite una specifica interfaccia RS232/RS485 che si affaccia sul BUS, la cRIO si collega con la propria seriale RS232 al BUS RS485. Gli
12
azionamenti utilizzati nel progetto sono costituiti da un modulo di potenza Siemens
Synamics Power Module 340, che alimenta il sistema, e dalla CPU Siemens CU305 DP. I motori scelti per questo progetto sono dei Siemens 1FK7032 dotati di encoder
interno.
Figura 5 – Azionamento SINAMICS (a sinistra) e motore brushless (a destra). L’azionamento è necessario per la
gestione del motore, e permette la comunicazione tramite protocollo Siemens USS®. Inoltre è dotato di un limitatore di velocità che permette di lavorare in sicurezza senza danneggiare il motore. Accedendo all’azionamento tramite porta di programmazione è possibile impostare molti dei parametri di controllo. All’interno del motore è presente un encoder che fornisce una misura sull’albero della velocità di rotazione.
2.4.1. Protocollo USS®
Il protocollo di trasmissione degli azionamenti Siemens, denominato USS®1 (Universal Serial Interface protocol) è un protocollo di comunicazione seriale tra azionamento e macchina, che nel caso in questione è la cRIO. La connessione identifica prima di tutto un master e uno slave: come master si intende il dispositivo che comanda, cioè la cRIO; per slave il dispositivo comandato, cioè l’azionamento. Il protocollo USS funziona nel seguente modo:
1
13 1. Il dispositivo MASTER (cRIO) invia una stringa di controllo (Task telegram)
allo SLAVE;
2. Il dispositivo SLAVE (azionamento) invia una stringa di risposta (Response
telegram) al MASTER.
Da evidenziare che nella risposta, cioè nel Response Telegram, sono presenti due serie di dati dove i primi 8 byte rappresentano il dato vero e proprio di informazioni del motore, i secondi 8 byte sono un eco dell’ultima stringa di controllo ricevuta. Come si vedrà in seguito in entrambe le comunicazioni è presente un byte di controllo che indentifica il dispositivo cui si riferisce (ADR). Il protocollo USS può controllare fino ad un massimo di 31 azionamenti (ADR da 0 a 30) ai quali invia i rispettivi Task Telegram, ricevendone la risposta.
La struttura del telegramma, inviato e ricevuto, presenta una parte comune. Il telegramma è diviso in pacchetti che, nel caso di ALMATracker, sono quelli mostrati in Figura 6.
STX LGE ADR PZD1 PZD2 BCC
net characters
Figura 6 – Struttura dati del protocollo USS®.
COD Denominazione Lunghezza Contenuto
STX Start of Text Carattere ASCII (02 HEX)
LGE Telegram Length 1 byte Lunghezza del carattere (ADR+PZD+BCC)
espressa in numero binario
ADR Address Byte 1 byte Indirizzo dello SLAVE, in codifica binaria
PZD Net Characters 2 byte/char Le informazioni dipendono dalla direzione di trasmissione
BCC 1 byte Carattere di controllo
14
Nel Task telegram PZD1 prende il nome di Control word e contiene 16 flags2 necessari per l’accensione e il controllo del dispositivo comandato. Il byte successivo PZD2 prende il nome di Main setpoint e contiene il set di velocità che si vuole impostare all’azionamento specificato nel campo ADR.
Nel Response telegram PZD1 è denominato Status word e contiene 16 flags che riportano lo stato del motore. PZD2 prende il nome di Main actual value e contiene il set di velocità letta dall’encoder interno al motore dell’azionamento specificato nel campo ADR.
2.5. MECCANICA
La movimentazione dell’antenna parabolica dell’ALMATracker è affidata ad un sistema motorizzato a due assi. Il sistema è composto da due assi motorizzati identici montati a novanta gradi uno su l’altro costituiti da una base rettangolare in alluminio (660 mm x 320 mm x 20 mm) su cui sono ancorati tutti gli elementi. Su ognuna delle basi sono stati posizionati i motori Siemens. Il primo riduttore è calettato direttamente sul motore. Tramite una trasmissione a cinghia l’uscita del primo riduttore va a movimentare la seconda coppia di riduttori del sistema. E’ stato scelto un sistema a doppio riduttore per poter riuscire a recuperare i giochi dovuti agli ingranaggi. I due riduttori hanno rispettivamente rapporti di demoltiplica pari a 28:1 e 70:1. Ciò permette di rallentare la rotazione ad elevata velocità e bassa coppia del motore ed ottenere bassa velocità ma elevata coppia3. Questa scelta è giustificata se si tiene conto che la parabola utilizzata dal sistema ha un diametro di circa 3 m, realizzata in lega leggera di alluminio, per una massa di circa 80 kg. Questo fatto introduce un elevato momento di inerzia che richiede un’elevata coppia.
2
Per la codifica esatta dei vari caratteri si rimanda alle specifiche del protocollo Siemens USS®
disponibile su
http://cache.automation.siemens.com/dnl/DU0MjczAAAA_24178253_HB/uss_24178253_spec_76.pd f
3 La velocità dell’asse finale può dunque essere calcolata come
15
Figura 7 – Rendering Solidworks del singolo asse del sistema ALMATracker. Sebbene in figura non siano
mostrate le cinghie, si possono notare le varie pulegge su cui le cinghie stesse andranno alloggiate. Il rettangolo grigio chiaro rappresenta il motore brushless, al quale è collegato il primo riduttore (28). Tramite cinghia il moto è poi trasmesso ai due riduttori maggiori (70) dai quali escono gli assi finali. Nell’asse uscente dal riduttore a sinistra è presente un secondo cinematismo a cinghia, sulla cui ruota condotta è montato l’encoder.
La struttura finale dell’ALMATracker sarà composta da due assi identici, dove il primo sarà ancorato al suolo e movimenterà il secondo asse più parabola. Il secondo posizionato sopra il primo andrà a movimentare direttamente la parabola in direzione ortogonale al primo (Figura 8).
16
Figura 8 – Rendering Solidworks del sistema di assi di ALMATracker.
La parabola ha dunque due gradi di libertà indentificati nei due angoli X e Y che individuano univocamente la direzione di tracking. Questi due angoli sono tuttavia limitati dalla meccanica del sistema, ed in particolare occorre tenere conto dei punti in cui le basi degli assi giungono a contatto con i supporti. Considerando quindi le possibili collisioni, otteniamo una limitazione dell’operatività dei due assi tra un angolo minimo ed uno massimo, verosimilmente diversi per i due assi. Per tenere conto della limitazione dell’escursione massima sono stati previsti due microinterruttori per ogni lato di ogni asse (cioè ridondanti due per l’angolo massimo e due per il minimo). Gli interruttori vengono fissati alla base dell’asse tramite una staffa in alluminio. Questi interruttori hanno lo scopo di fornire al software un segnale di avviso di collisione imminente, e sono attivati dal passaggio della lastra ad un certo angolo.
17
Capitolo Terzo
A
RCHITETTURA SOFTWARE
Il software di controllo e gestione di ALMATracker si sviluppa su tre livelli differenti: FPGA, cRIO e PC. In particolare l’algoritmo deve essere racchiuso in catena di comando, cioè ogni dispositivo deve utilizzare valori impostati o feedback provenienti dagli altri.
Lo snodo centrale del sistema è l’algoritmo di controllo e movimentazione che deve essere implementato sul sistema centrale (cRIO) e deve svolgersi in ciclo chiuso con gli altri algoritmi. Uno schema approssimativo del sistema può essere osservato in
Figura 9. cRIO NI9014 PC client Azionamenti SIEMENS RT module FPGA NI 9401 C-module ENCODER R O TA C O D S SI SI EM EN S U SS ATTP Interruttori fine corsa
Figura 9 – Architettura del sistema ALMATracker in cui si evidenziano le comunicazioni tra i vari componenti
hardware.
Il modulo FPGA ha come scopo l’acquisizione di dati dall’encoder e dei segnali di fine corsa. Inoltre si dovranno generare i valori di conteggio per il successivo calcolo delle velocità. Sempre all’interno della cRIO vi è il modulo RT che ospita la VI più complessa poiché deve svolgere molteplici compiti elencati di seguito:
comunicazione TCP/IP da/verso PC client;
comunicazione da/verso azionamenti Siemens;
18
elaborazione dei dati complessivi per il controllo e la movimentazione degli assi.
Il segmento PC deve acquisire tutti i comandi impostati dall’utente, gestendo opportunamente l’interfaccia grafica. Si deve inoltre provvedere alla comunicazione bidirezionale via TCP con la cRIO, dalla quale si acquisiscono i dati di sistema che devono essere visualizzati sul dispositivo.
3.1. INTERFACCIA FPGA
Il modulo FPGA si occupa della lettura dei dati dagli encoder, degli indicatori di fine corsa (si veda capitolo 5.0.3. Contatti di fine corsa) e di una prima elaborazione del dato angolare. Questo aspetto richiede l’accesso diretto ai segnali in ingresso dal C-module. La lettura delle posizioni degli encoder viene espressa come intero decimale per l’impossibilità di utilizzo della virgola mobile. Inoltre viene eseguito un conteggio degli impulsi e del periodo per il calcolo della velocità dell’encoder.
3.1.1. Acquisizione dato angolare
Come introdotto nel capitolo 2.3.1. Interfaccia SSI per ottenere i dati dall’encoder è necessario interrogare il dispositivo con un treno di 32 impulsi con logica negativa. Gli impulsi devono presentare un periodo di 2.4 μs e il periodo tra l’inizio di due treni consecutivi deve essere di 100 μs.
19
Figura 11 – Misurazione all'oscilloscopio del segnale in uscita dalla porta DIO0. In basso è possibile notare la
durata del singolo treno di impulsi di 75.60 μs, identificata dai riferimenti tratteggiati verticali.
Per ottenere il dato si lavora nel modulo FPGA generando il treno di impulsi e leggendo il dato in uscita dall’encoder. All’interno di una struttura sequenziale si utilizza il primo frame per porre il segnale di output alto4 sui canali utilizzati (DIO4 per l’asse X e DIO5 per l’asse Y). In un successivo frame si hanno tre cicli separati, uno per la raccolta del dato da encoder e due per il calcolo della velocità. Il ciclo che realizza la raccolta del dato è al suo interno diviso in un ulteriore struttura sequenziale. Il primo frame impone la cadenza dei treni di impulsi utilizzando un
Wait Until Next Multiple settato ad un valore di 100 μs. Nel secondo frame un ciclo For esegue 32 iterazioni nelle quali, ancora una volta con una struttura sequenziale,
manda il segnale basso nel primo frame (impostando il valore falso sul rispettivo DIO) e nel secondo attende 1 μs, lo riporta alto e attende un altro μs. La forma d’onda è così generata e per tutta la durata del secondo frame l’encoder mette a disposizione il dato sui canali DIO0 per l’asse X e DIO1 per l’asse Y, che vengono inseriti in due differenti array e memorizzati in uno shift register. In uscita dal ciclo
For i due dati angolari sono disponibili all’interno di due array. Nei frame successivi
si utilizza la funzione Array Subset per estrapolare dall’array i bit utili, cioè 16 bit a partire dal sesto e il dato viene convertito da codifica Gray ad intero decimale con un
4
20
semplice algoritmo. A questo punto il dato è stato ottenuto e sia encoder che sistema di controllo sono pronti ad un nuovo treno di impulsi e quindi allo scambio di un nuovo dato.
Figura 12 – Ciclo di generazione del treno di impulsi e lettura del dato da encoder. All’interno del modulo FPGA
i blocchetti di colore viola indicano la comunicazione con i moduli inseriti nello chassis. In questo caso il modulo NI 9401 era stato inserito nel secondo posto, per cui è indicato dall’FPGA come “Mod2”. L’informazione data da DIO (Digital Input/Output) si riferisce all’ingresso/uscita del modulo.
1:10 flags 11:26 angolo 28:32 controlli
Figura 13 – Struttura del dato letto da encoder sotto forma di array di boolean. Per ottenere l’angolo è sufficiente
utilizzare la funzione Delete from Array per eliminare i bit in eccesso, conoscendone la posizione all’interno del registro.
La funzione che si occupa della trasformazione del dato angolare da binario Gray ad intero decimale è racchiusa nella subVI sF_GrayToDecimal.vi. Questa funzione utilizza un ciclo While in cui due shift register vengono inizializzati l’uno al valore dell’angolo in Gray, uno a 0. Il primo registro esegue ad ogni iterazione lo spostamento dei bit verso sinistra (Logical shift) eliminando così il primo bit a sinistra per ogni iterazione. Il valore decimale dell’angolo è ottenuto per somma logica esclusiva (XOR) tra il valore uscente dal primo registro e quello del secondo. Il ciclo termina quando il valore residuo del registro è nullo, cioè la condizione “registro>0” risulta falsa. Il secondo shift register nel frattempo esegue ad ogni ciclo la somma modulo 2 tra i valori uscenti dai due registri. In uscita al ciclo il dato decimale è disponibile nel secondo registro.
21
Figura 14 – sF_GrayToDecimal.vi
3.1.2. Generazione dei segnali di velocità
Se si esegue una valutazione sulla frequenza di cambiamento del dato dell’encoder occorre considerare una velocità massima operativa del motore di 3000 RPM per cui si ottiene una velocità massima all’asse finale di circa 1.5306 RPM. Poiché una rotazione completa dell’encoder fornisce 65536 variazioni, e la frequenza è pari al reciproco del periodo, la frequenza di variazioni a 3000 RPM sarà pari a
(( ) )
Dal momento che la frequenza massima dell’FPGA è di 40 MHz, cioè di un Tick di sistema ogni 0.025 μs, è possibile utilizzare una frequenza di lettura dei dati di almeno tre ordini di grandezza superiore alla frequenza massima di aggiornamento del dato. Dal sistema di acquisizioni dei dati dall’encoder è noto che il tempo minimo di acquisizione è di 75.60 μs5: al di sotto di questo timing i treni di impulsi emessi sono troppo ravvicinati e l’encoder non risponde correttamente. Da qui deriva la scelta del tempo di temporizzazione del ciclo di acquisizione da encoder di 100 μs cioè di una frequenza di 10 KHz che è almeno tre ordini di grandezza superiore alla
fvel max appena calcolata. In questo modo si è certi di avere che tra due letture consecutive il dato angolare cambia al più di un bit. Più precisamente vi saranno
5 Verificato in laboratorio anche con l’utilizzo di un oscilloscopio sul treno di impulsi in uscita verso
22
alcuni cicli per cui il dato rimane costante e uno in cui si modifica e così via. E’ allora possibile creare una funzione che elabori un segnale per il conteggio dei tick che intercorrono tra due successive variazioni del dato. Questo si ottiene ponendo su FPGA due cicli in parallelo al ciclo di acquisizione da encoder. In particolare si dovrà generare un segnale per ogni asse, chiamato Pulse, che generi un gradino unitario ogni volta che il dato angolare si modifica, corredato da un altro segnale, chiamato Direction, che detiene informazioni circa il verso della rotazione (Direction ∈ [-1,0,1] ) definito come la funzione segno della variazione angolare. Contemporaneamente nel secondo ciclo si esegue il confronto tra il valore attuale ed il precedente di Pulse creando un segnale che risulta vero sui soli fronti di salita dell’impulso. La distanza tra i fronti di salita è cronometrata in termini di tick che intercorrono in un certo periodo di campionamento fornito dal segnale Sample secondo un ciclo temporizzato ogni numero Count tick. Ciò equivale a dire che la funzione realizzata conta quanti istanti sono passati tra successive variazioni del dato angolare, avendo effettuato la misura ogni volta che il segnale Sample è cambiato di stato e secondo una temporizzazione di misura pari a Count tick.
Figura 15 – Stralcio di codice della VI operante su FPGA. Il ciclo a destra serve alla generazione dell’onda
quadra XPulse e della direzione di rotazione. Queste variabili sono poi utilizzate nel ciclo a sinistra per il conteggio dei Tick e del periodo.
La realizzazione di questo algoritmo richiede di completare una tabella di verità per il calcolo della funzione Pulse. In particolare, utilizzando la funzione si avvale di tre porte logiche – un OR, un AND ed un NAND. La tabella di verità del circuito realizzato, si riporta in Tabella 2.
23 A B 1 2 3 0 0 0 0 1 1 0 1 1 1 0 1 1 1 1 1 1 1 0 0 0 0 0 1 0
Tabella 2 – Tabella di verità del circuito logico in cui si identificano: A segnale in uscita dall’operatore ≠; B
segnale di uscita dallo shift register; 1 segnale di uscita dall’OR; 2 segnale di uscita dall’AND nonché segnale
Pulse e nuovo valore dello shift register; 3 segnale di uscita dal NAND.
L’onda quadra Pulse contiene quindi l’indicazione di cambiamento dato all’interno dei fronti di salita e per questo viene filtrata da una comparazione tra un Feedback
Node e la variabile stessa. Questa comparazione risulta vera solo nel fronte di salita,
cioè quando 1 (segnale alto) > 0 (segnale basso) del ciclo precedente. Il valore del comparatore attiva un case che non modifica nulla se è falso (se l’angolo non è cambiato) mentre reinizializza lo shift register di periodo ed incrementa quello di conteggio tick nel caso di fronte di salita su Pulse. Un ulteriore case, attivato dal cambiamento di stato del segnale sample ottenuta con uno XOR tra dato corrente e dato precedente, fornisce il conteggio dei tick (con segno). L’attivazione di questo case fa si che si calcoli il Count tick ottenendone il valore da shift register (moltiplicato per il valore Direction), mentre il Period è ottenuto per differenza tra il tempo dell’ultima modifica dell’angolo e quello dell’ultima attivazione del case descritto.
3.1.3. Generazione dei segnali di fine corsa
Le due porte in ingresso rimaste libere – DIO2 e DIO3 – sono state utilizzate per i sensori di fine corsa dell’asse X. Questi sensori vengono realizzati con degli microinterruttori che vengono attivati fisicamente per contatto quando l’asse oltrepassa un certo angolo limite nelle due direzioni di rotazione. L’attivazione dell’interruttore cambia lo stato delle variabili X max/min collision, ed avrà su cRIO un effetto di limitazione sull’escursione angolare effettuabile. Dal momento che nella versione finale del sistema saranno presenti questi microinterruttori su entrambi gli assi, questi due segnali vanno ad attivare anche le corrispondenti variabili dell’asse
24
Y. Questo non ha alcun senso teorico, ma è utilizzato al fine pratico per testare la limitazione del range di entrambi gli assi, non disponendo di sufficienti porte in ingresso (necessarie due per asse). Quindi per poter implementare un vero controllo sulla versione finale di ALMATracker sono necessarie almeno quattro porte in ingresso oltra a quelle utilizzate per la comunicazione con l’encoder. Per ragioni di sicurezza sarà obbligatorio l’utilizzo di due moduli digitali I/O per avere almeno 16 canali così da poter avere per ogni angolo limite almeno due microinterruttori ridondanti che possono poi essere collegati via software tramite porta OR, presentando un’affidabilità superiore in caso di rottura del singolo componente.
3.2. INTERFACCIA CRIO
Come già detto la VI operante sul modulo RT della cRIO è lo snodo centrale del software. In particolare si devono svolgere contemporaneamente azioni di trasmissione dati da e per Client, azionamenti ed FPGA. Tutto ciò richiede una quantità di cicli separati che operino in parallelo, tutti temporizzati secondo un timing adeguato al loro scopo ma comunque mai inferiore ai 10 ms per evitare il sovraccarico della capacità di calcolo disponibile. Ogni ciclo esegue una funzione diversa, riportata di seguito:
Comunicazione con FPGA;
Impacchettamento dati;
Ricezione/Trasmissione via TCP/IP;
Controllo e movimentazione;
Comunicazione con azionamenti Siemens.
Il primo punto racchiude tutte quelle operazioni che riguardano la ricezione dei dati dell’encoder dal modulo FPGA e la loro elaborazione fino ad ottenere i dati di posizione e velocità. Nei cicli di impacchettamento dei dati e trasmissione TCP si ha la preparazione dei dati in funzione della frequenza di aggiornamento richiesta e l’inserimento in coda della richiesta di spedizione. Parallelamente, si provvede alla loro spedizione, oltre che al ricevimento dei dati di comando dal client come verrà approfondito nel capitolo quarto. I comandi derivanti dalla lettura TCP insieme ai dati derivanti da FPGA vengono poi portati nel ciclo di movimentazione per essere
25 elaborati fino ad ottenere un setpoint di velocità. Tale setpoint viene poi importato nel ciclo di trasmissione con gli azionamenti che provvede ad inviarlo secondo il protocollo USS tramite l’algoritmo studiato nel capitolo 3.2.3.
Event Receive TCP data Polynomial (ID=1) ATControls (ID=2) Auto/ Manual? Auto Position/ Speed? Controls (sID=0) Setpoint (sID=1) Time (sID=2) Sync requested? Update cRIO Time Start/Stop? yes Start Manual Polynomial to v(t) Siemens USS Position SP to Speed SP Position Speed rate limitator Speed SP Speed SP On clock time Operation Data System Data Send via TCP
Figura 16 – Schema logico del software contenuto su cRIO. La complessità progettuale è ben visibile nella
moltitudine di connessioni, ma viene districata in fase di stesura del programma grazie all’utilizzo di variabili locali che mettono a disposizione un dato continuamente aggiornato a più utenze. Nello schema qui sopra è stata volontariamente tralasciata la parte di elaborazione del dato dell’encoder (per evitare di complicare il grafico), che è a disposizione di tutti i blocchetti bianchi in cui è necessario il feedback.
3.2.1. Elaborazione dati encoder
Per l’interpretazione dei dati dell’encoder è necessario lavorare prima da lato FPGA, per quanto precedentemente descritto, fino ad ottenere l’angolo espresso come intero decimale. Il valore così ottenuto riporta il valore della posizione espresso in un sistema a 16 bit dove l’intero angolo di 360° è rappresentato da un valore pari a 216=65536. Per ottenere il valore in gradi è necessario un calcolo in virgola mobile, da eseguire dunque su modulo RT. L’intero decimale (DecimalAngle) viene convertito in angolo espresso in gradi (Angle) tramite la semplice relazione:
26
3.2.2. Calcolo delle velocità
I dati provenienti dagli encoder individuano soltanto la posizione angolare dell’antenna. Tuttavia, avendo un sistema comandato in velocità, è necessario ottenere in qualche modo anche una stima della velocità angolare istantanea (ω). Ricordando che:
il modo più intuitivo di realizzarlo sarebbe quello di calcolare in un determinato intervallo di tempo (dt) la variazione di angolo (dα), ed ottenere la velocità semplicemente dividendo l’angolo per il tempo. Tuttavia con tale metodo si incorre in problemi di sottostima della velocità angolare nel caso ωeffettiva< ωlimite. Per la
valutazione di ωlim si può considerare αlim 0.005493 deg (capitolo 2.3. Encoder ) e
un intervallo di campionamento dt=1 ms6, si ottiene così:
In base a questo risultato, dunque, non è possibile rilevare in tal modo velocità inferiori a ωlim se l’intervallo di campionamento è di 1 ms, giungendo, nel peggiore
dei casi, ad avere una velocità nulla per tutto il tracking se la velocità angolare è sempre minore di ωlim. Si potrebbe dunque pensare di alzare l’intervallo di
campionamento dt abbassando di conseguenza ωlim. Così facendo, però, si
perderebbe sensibilità in termini temporali, portando tutto il sistema ad aggiornarsi a frequenze più basse nonché si incorrerebbe in velocità medie per intervalli di tempo alti che si potrebbero discostare molto dalla velocità istantanea reale.
Una seconda possibile soluzione consiste nel considerare un campionamento non temporale, ma angolare: cioè non si calcola la velocità allo scadere di un intervallo di tempo fisso ma al verificarsi della condizione per cui l’angolo varia di uno step di encoder (1 di 65536 corrispondente a 0.005493 deg). Tramite shift register si tiene
6 Un intervallo di acquisizione di 1 ms può essere considerato un buon tempo di scansione al fine di
27 traccia del tempo e alla prima variazione di angolo si calcola la velocità istantanea7. In tal modo si evita il fatto di poter ottenere velocità nulle sempre, ma si accetta la possibilità di ottenere velocità medie nel caso in cui il sistema si muova a velocità inferiori all’angolo limite.
La soluzione adottata è tuttavia un’altra. Anziché lavorare nel dominio spaziale si lavora nel dominio temporale, sfruttando l’elevata frequenza di Tick del modulo FPGA. I dati così ottenuti da FPGA – cioè Count e Period – vengono letti dal modulo RT che ne esegue il calcolo finale di velocità, tenendo conto che un periodo pari a 40˙000˙000 tick corrisponde a 1 sec. In parallelo al ciclo principale viene aperto il canale di comunicazione con il modulo FPGA tramite l’istruzione
OpenFPGAReference. In seguito si accede ad un ciclo While temporizzato a 100 ms,
che rappresenta un timing adeguato alla frequenza di aggiornamento dei dati. In questo ciclo è presente una struttura sequenziale a due frame in cui si ha un primo frame di attesa di 1 ms per permettere ad un altro ciclo parallelo di aggiornare i valori di Sample e Tick Count. Nel secondo frame il blocco di comunicazione FPGA
Read/Write Control permette di esportare nel modulo FPGA i valori di Sample e Tick Count e di leggere i dati presenti sugli indicatori dell’interfaccia del modulo FPGA,
in particolare vengono importati i valori di DecimalAngle, Count, Period e gli indicatori di fine corsa hardware riferiti ai due assi.
7 A causa dell’architettura logica del modulo FPGA (operazioni a virgola fissa) è necessario che il
28
Figura 17 – Ciclo di acquisizione dei dati dal modulo FPGA. I blocchi a sfondo rosa sono riferiti alla
comunicazione con FPGA.
Il valore dell’angolo in gradi trecentosessagesimali è ottenuto tramite una subVI che esegue il calcolo
Il calcolo della velocità avviene nella subVI sR_SpeedFromFPGA.vi. In questo blocco si calcola la durata di acquisizione dei dati come il rapporto tra Period e la frequenza di acquisizione del modulo FPGA (40 MHz). Dividendo poi la durata di acquisizione per il numero di tick letti, contenuto nella variabile Count, si ottiene il valore del tempo trascorso tra due successive variazioni dell’angolo. Poiché la velocità è definita come il rapporto tra la variazione d’angolo ed il tempo ( ) ed essendo noto che la variazione di angolo è pari a
è possibile calcolare la velocità di rotazione dell’asse finale espressa in deg/sec. In questo calcolo occorre tenere presente che l’impulso Pulse viene analizzato sui soli fronti di salita, dunque una volta ogni due variazioni di angolo. Per questo l’angolo misurato attraverso il conteggio sarà pari a metà di quello reale. Questo coincide con il considerare, nel rapporto, che 65536 impulsi corrispondono al doppio di un angolo giro, ovvero 720 deg. Considerando inoltre il caso di velocità nulla in cui si avrebbe
29 una divisione con 0 a denominatore, per evitare errori di calcolo di velocità (cioè NaN, Not a Number), è stato inserito un Select? che imposta la velocità a 0 se Count è nullo o utilizza il valore calcolato altrimenti.
Figura 18 – sR_SpeedFromFPGA.vi
Il segnale Sample, così come Count tick, è spedito all’FPGA dal modulo RT secondo dei parametri che questa possiede. Il segnale di attivazione Sample, viene generato su RT come onda quadra unitaria di periodo fissato dal software in base alla velocità impostata ai motori. In particolare occorre variare il tempo di campionamento e il numero di tick da leggere, che dovranno essere maggiori tanto minore è la velocità del setpoint. Secondo le prove svolte in laboratorio si è giunti ad una tabella che riporta valori di velocità piuttosto soddisfacenti.
ωmin ωmax Sample time [ms] Tick count
0 0.1 1500 100000
0.1 1 500 10000
1 5 200 10000
5 10 100 1000
Tabella 3 – Valori preimpostati sul modulo RT per il conteggio dei tick e del periodo. Per il confronto con la
tabella occorre considerare la velocità in valore assoluto, espressa in deg/sec. Il confronto da effettuare comprende l’estremo superiore, ma non quello inferiore, cioè . Per il solo valore di velocità nulla è compreso anche l’estremo inferiore dell’intervallo.
L’implementazione dell’algoritmo di generazione dei segnali di cui sopra avviene tramite due cicli For temporizzati paralleli. Nel primo ciclo vengono estrapolati i valori di Tick Count e del Sample Timing. Prima di tutto la velocità comandata al motore viene convertita in velocità all’asse e se ne calcola il modulo per poterla
30
confrontare con i dati tabulati. Il confronto avviene tramite una serie di Select? attivati da comparatori tra la velocità e i range di velocità tabulati. I vari Select? selezionano a seconda del range di velocità i corrispondenti valori di Tick Count e del Sample Timing.
Figura 19 – Ciclo di selezione dei parametri Tick Count e Sample Timing.
Nel secondo ciclo While temporizzato secondo Sample Timing, si provvede alla generazione del segnale Sample tramite uno shift register. Il segnale infatti deriva dal valore stesso del registro, che viene cambiato ad ogni ciclo tramite una negazione logica.
Figura 20 – Ciclo di generazione del segnale Sample.
Una serie di test effettuati in laboratorio è stata volta a mirare la validità dei valori tabulati per le basse velocità. Tramite una funzione si è creato un file composto da tre colonne contenenti le informazioni su un asse del setpoint di velocità impostata, del valore di velocità letta da encoder e di quella letta dall’encoder interno al motore. Il tutto è stato inserito in una serie di cicli annidati in modo tale che le misurazioni avvenissero:
per diversi tick count (100000,10000,1000)
31 per diversi sample time (da 100 ms con 14 step di 100ms)
per 50 campioni.
Il file è poi stato sottoposto a post processing utilizzando Matlab. L’algoritmo allegato in appendice “Almatracker report STS.m” ha fornito i seguenti risultati.
Figura 21 – Errore medio percentuale in relazione al
setpoint di velocità del motore, utilizzando Tick e
Sample prestabiliti per ogni velocità.
Figura 22 – Errore medio percentuale per le varie
velocità alla variazione del Sample utilizzando un numero di Tick pari a 1000.
Figura 23 – Errore medio percentuale per le varie
velocità alla variazione del Sample utilizzando un numero di Tick pari a 10000.
Figura 24 – Errore medio percentuale per le varie
velocità alla variazione del Sample utilizzando un numero di Tick pari a 100000.
Il codice realizzato in Matlab ha analizzato i dati ottenuti da ALMATracker eseguendo una media dei 50 campioni di ogni misurazione e calcolando l’errore medio percentuale definito come:
32
Nello screenshot di Figura 21 si può osservare l’errore medio percentuale commesso utilizzando i dati tabulati in Tabella 3. Nello specifico si riportano di seguito anche i valori numerici ottenuti:
Velocità motore
(deg/sec)
Tick Sample (ms) RMSE % riferito al setpoint 0 100000 1500 0.000000 980 10000 500 0.108959 2940 10000 200 0.124241 3920 10000 200 0.024637 4900 10000 200 0.106621 5880 10000 200 0.137907 6860 10000 200 0.012454 7840 10000 200 0.063998 8820 10000 200 0.023074 9800 10000 200 0.017976 10780 1000 100 0.479570
Tabella 4 – Calcolo dell’errore medio percentuale rispetto al setpoint impostato.
E’ quindi intuitivo osservare che i valori di Sample time e Tick count scelti sono idonei, ottenendo un errore percentuale globale8 sempre inferiore allo 0.5 %. Dai rimanenti plot di Figura 22, Figura 23, Figura 24, eseguiti per differenti Tick count, è inoltre evidente come sia avvenuta la scelta di questi valori. I valori sono stati scelti dopo alcune prove in cui si è notato che maggiore è la velocità più si richiede un Tick
count basso. Tuttavia esiste un limite inferiore (1000 Tick) per ottenere una certa
attenuazione del rumore. D’altro canto anche per Sample troppo bassi si ottiene una repentina variazione dei valori dell’errore che sono minimi per un Sample maggiore di 200 ms. Da notare inoltre che nel caso di basse velocità sono richiesti alti numeri
8
33 di Tick ma anche alti periodi di Sample per poter raccogliere un numero adeguato di campioni. Si evidenzia anche che per alte velocità, cioè oltre ai 5 deg/sec, il fatto di avere bassi Sample permette di avere un sistema più reattivo, cosa non possibile per basse velocità perché sarebbero soggette ad alti errori, come si evince dalla Figura
24.
3.2.3. Comandi motore (SiemensUSS.vi)
Per ottenere un software in grado di comunicare correttamente con gli azionamenti occorre rispettare rigidamente il protocollo sia in termini di incapsulamento dei dati sia in termini di timing. Occorre prima di tutto impostare alcuni parametri tramite il software di programmazione della Siemens connettendo il PC all’azionamento tramite la porta di programmazione. In questo caso è stato impostato un timeout di lettura di 5000 ms che impedisse che l’azionamento si bloccasse in assenza del dato in ricezione per il tempo prestabilito e l’indirizzo (ADR) dei motori a 0 per l’asse X e 1 per l’asse Y.
La subVI sR_SiemensUSS.vi si occupa della comunicazione bidirezionale con gli azionamenti, e viene richiamata nella VI principale all’interno di un ciclo While a parte non temporizzato. Questo non crea nessun problema in quanto tutto il codice contenuto nella subVI è già all’interno di un ciclo While temporizzato a 30 ms. Tale durata è stata accuratamente scelta come compromesso tra il tempo massimo di timout dei motori, che porterebbe alla loro disconnessione con generazione di errore, e la frequenza di aggiornamento dei dati in entrambe le direzioni tra modulo RT e azionamenti (circa 27 ms). Le uniche istruzioni della subVI che rimangono all’esterno del ciclo sono quelle inerenti alla configurazione della porta seriale. Tramite l’istruzione VISA Configure Serial Port, sono stati impostati i seguenti parametri:
VISA resource name: ASRL1 (porta disponibile sulla cRIO);
Baud Rate: 38400;
Data bit: 8;
Parity: Even;
Stop bitss:1.0;
34
Enable terminator char: False;
Timeout: 5000ms.
Una volta configurata la porta è stato impostato con il comando VISA Set I/O Buffer
Size un buffer di dimensioni standard sui dati in spedizione e ricezione. Una volte
effettuate queste operazioni si accede al ciclo While principale. Il ciclo è diviso in due parti, una di ricezione ed una di trasmissione. I valori in ingresso ed uscita alla subVI sono importati ed esportati con variabili globali, racchiuse nell’interfaccia
SiemensVariables.vi.
Si comincia innanzitutto con la trasmissione dei pacchetti da MASTER a SLAVE, che richiede semplicemente di costruire il Task telegram impacchettando i dati di controllo in due byte (U8) contenuti nelle variabili PZD di Control word. I due PZD, chiamati PZD1 e PZD2, contengono il primo tutti i controlli per l’attivazione del motore, il secondo il setpoint di velocità richiesto. La parte di controllo, contenuta nel PZD1 è composta da 8 bit (cioè 8 comandi vero/falso) che devono essere usati in una determinata sequenza per l’accensione9
, la movimentazione e lo spegnimento dei motori. Gli 8 comandi distinti che devono essere opportunamente combinati secondo il protocollo USS sono:
1. Accensione;
2. Abilitazione operazioni; 3. Abilitazione rampa;
4. Abilitazione controllo rotazione; 5. Tacitazione anomalie.
Per motivi pratici le variabili di abilitazione rampa e abilitazione del controllo di posizione sono state poste a vero tramite una costante, istruzione lecita coerentemente al protocollo Siemens che non richiede un reale controllo su queste due variabili se non per usi particolari. Le variabili Accensione e Abilitazione
operazioni sono attivate insieme per i due assi rispettivamente dalle variabili globali On/Off ed Enable Operation.
9
35
Figura 25 – Stralcio di codice rappresentante la parte di trasmissione di SiemensUSS.vi in cui si nota come il
Task telegram sia ottenuto impacchettando i comandi motore ed il setpoint richiesto e venga subito inviato. Prima
dell’invio un comando Select? decide quale pacchetto inviare a seconda del valore assunto dalla variabile booleana posta nello shift register. Questa variabile cambia ad ogni ciclo – grazie alla porta di negazione logica posta a fianco del registro – permettendo di inviare alternatamente i dati ai due diversi azionamenti.
La generazione dei due byte appartenenti a Control Word è demandata alla subVI
sR_PZDControlWord.vi. I parametri booleani di ogni byte sono inseriti in un vettore
tramite la funzione Build Array. I due byte del PZD sono infine convertiti in interi U8 con il comando Boolean Array To Number.
Figura 26 – sR_PZDControlWord.vi Lo scopo della VI è quello di creare i due byte che compongono il Control
Word creando un vettore di parametri di azionamento, come specificato nel protocollo USS.
Il Main setpoint è ottenuto convertendo la velocità da double a due byte separati di interi (U8) nella subVI sR_PZDMainSetpoint.vi. La velocità da impostare
36
all’azionamento arriva qui sotto forma di double, espressa in RPM, dalla variabile
Axis Speed (RPM)10. Per prima cosa si esegue una correzione di scala. Volendo riportare il valore di velocità (da protocollo comprese tra -6000 e +6000 RPM) attraverso un intero a 16 bit (valori compresi tra -32768 e +32767), mantenendo il massimo della precisione disponibile, occorre adattare la scala. Dunque occorre fare coincidere gli estremi, ed in particolare essendo una scala di valori simmetrica attorno allo 0, è necessario fare coincidere gli estremi minori. Riportando il valore di -6000 a -32768, si ottiene la proporzione:
da cui . Successivamente si esegue la conversione in stringa tramite Format Into String, specificando il tipo di dato che si vuole ottenere tramite la stringa “%16b” che rappresenta i binari a 16 bit. Dal momento che l’azionamento richiede una stringa composta da un vettore di byte formattati come U8, si procede alla divisione della stringa tramite String Subset impostando 8 come numero di bit da leggere. Queste stringhe vengono infine convertite dal comando Scan Value secondo la codifica ad 8 bit (“%8b”) e riportati a due byte distinti in U8 tramite la funzione To Unsigned Byte.
Figura 27 – sR_PZDMainSetpoint.vi Questa VI realizza la conversione completa da velocità ai due byte richiesti
dal protocollo degli azionamenti.
I 4 byte così ottenuti vengono combinati in un array di byte U8 nell’ordine richiesto dall’azionamento, cioè:
STX; LGE;
10
37 ADR; PZD1 byte2; PZD1 byte1; PZD2 byte1; PZD2 byte2; BCC.
Come si può notare i byte 1 e 2 del PZD1 devono essere invertiti per rispetto del protocollo USS.
Figura 28 – sR_TaskTelegram.vi Assemblamento del Task telegram per il motore dell’asse X.
Ovviamente avendo due assi verranno assemblati due differenti Task telegram, che non possono tuttavia essere spediti contemporaneamente: si ricorre dunque ad uno
shift register, che viene cambiato ogni ciclo di trasmissione, per inviare
alternatamente i due telegrammi riferiti ai due diversi motori. La durata di un ciclo è di 30 ms, secondo la temporizzazione data con il comando Wait Until Next Time
Multiple.
38
Figura 29 – Stralcio di codice rappresentante la parte di ricezione di SiemensUSS.vi.
Un Property Node impostato sull’opzione “Number of Bytes at Serial Port” permette di conoscere il numero di byte sono disponibili alla porta seriale impostata. Tale valore viene importato in una struttura sequenziale assieme al nome della porta. Nel primo frame il comando VISA Read legge i dati disponibili sulla seriale, composti dei byte specificati dal valore di cui sopra, inserendoli in una stringa. La stringa viene immediatamente convertita in un vettore di interi U8 tramite la funzione String To
Byte Array. Nel frame successivo il vettore monodimensionale viene convertito in
bidimensionale tramite un ciclo For di iterazioni pari ai byte ricevuti, creando un array tramite Initialize Array. Nel frame seguente si divide il dato ricevuto considerando l’azionamento al quale si riferisce. Un case esegue un primo controllo sul numero di byte letti. Se non tutti i byte sono ancora stati letti si accede al caso falso, in cui si usa una stringa memorizzata in uno shift register del ciclo esterno che viene impostata all’uscita del case senza altre operazioni. Nel caso vero, invece, il tunnel11 richiede più passaggi. La stringa in uscita in questo caso risulta la concatenazione di due stringhe. La prima è quella derivante dalla subVI
sR_ByteToString.vi collegando in ingresso il vettore 2D precedentemente calcolato.
La seconda stringa deriva invece dal comando Replace Substring il cui ingresso è collegato al valore uscente dal registro e si occupa di sostituire con una stringa vuota i caratteri precedenti. Questo equivale a svuotare il registro se ci sono nuovi dati in arrivo, per evitare di incorrere in problemi di overflow delle stringhe. La subVI
sR_ByteToString.vi calcola inoltre l’azionamento di provenienza del dato leggendo il
11
39 valore corrispondente al terzo elemento della trasmissione (ADR). La lettura separata dei byte avviene dividendo il vettore con la funzione Index Array, in cui l’indice va da 0 a 7. Il vettore viene poi ricomposto tramite la funzione Build Array, e successivamente elaborato da Byte Array To String da cui si ottiene il dato sotto forma di stringa.
Figura 30 – sR_ByteToString.vi per il passaggio del dato da array di interi a stringa. Il check del motore avviene
per comparazione tra ADR e l’indirizzo di uno dei motori (qui 0). Se il segnale Device Address risulta vero, allora il telegramma è stato inviato dall’azionamento 0, se falso dall’1.
All’uscita del case la stringa viene inserita nel registro per essere disponibile al ciclo successivo, e viene reso disponibile il segnale Device Address. Questi valori sono utilizzati dai due case successivi, posti in serie l’uno con l’altro. Essi sono del tutto identici, a meno dell’inversione dei casi vero/falso. Infatti i due case sono attivati dal segnale Device Address posto in prodotto logico con la verifica di ricezione. Questo permette di attivare due casi differenti per attuare due operazioni diverse cioè:
mantenere il valore proveniente dal caso precedente se il dato non è riferito all’azionamento in questione;
aggiornare il valore se il dato ricevuto deriva dall’azionamento considerato. A livello software il case riesce a gestire la parte di selezione dei due casi qui presentati. L’aggiornamento dei dati è svolto tramite la procedura concatenazione del
40
Replaced Substring già descritta precedentemente. In questo caso però la prima
stringa deriva dal caso di controllo sui byte letti. La seconda stringa, invece, deriva dal valore di un registro (diverso per ognuno dei due assi) che viene aggiornato ad ogni ciclo dal valore in uscita dal case. In questo modo si ottiene una stringa per ogni azionamento che contiene l’informazione secondo la codifica USS. Il fatto di sfruttare i registri permette di avere il valore aggiornato per un azionamento o di disporre dell’ultimo dato ricevuto, nel caso in cui il dato ricevuto ad un dato istante sia riferito ad un altro azionamento.
Figura 31 – Stralcio di codice rappresentante la prima parte di ricezione di SiemensUSS.vi. Il Response telegram
viene letto dalla porta seriale e necessita di essere decodificato. Prima di affrontare la divisione dei pacchetti dati occorre capire da quale azionamento provenga tramite i case inseriti nel terzo frame della struttura sequenziale. I case identificati dalle etichette “motor 0” e “motor 1” si riferiscono agli azionamenti dei due assi, e si presentano identici a meno dell’inversione dei casi (vero e falso invertiti).
Dal frame successivo inizia la separazione dei vari pacchetti che compongono il
Response Telegram duplicati identicamente per i due assi, a partire dalle rispettive
stringhe derivanti dalla procedura fino a qui descritta. La stringa viene convertita in un vettore di interi grazie al comando String To Byte Array e da qui importata nella subVI sR_ResponseTelegram.vi che si occupa di dividere i vari PZD. I singoli byte
41 sono estrapolati dal vettore di interi U8 impostando al comando Index Array il valore d’indice del byte da estrapolare. I due byte di ogni PZD, assieme al carattere BCC, sono messi a disposizione all’uscita della funzione.
Figura 32 – sR_ResponseTelegram.vi per la divisione dei byte che compongono i caratteri di rete.
Il frame successivo è adibito al controllo sul carattere BCC, svolto dalla subVI
sR_BCCcheck.vi. In ingresso alla funzione vengono collegati l’array contenente
l’intero dato Response Telegram sotto forma di array, e il BCC ricevuto, opportunamente isolato dagli altri caratteri dalla funzione precedente. La VI fornisce in uscita una variabile, BCC check, che risulta vera se il BCC ricevuto e quello calcolato coincidono. Il controllo avviene comparando i due caratteri con il comando
Equal posto in prodotto logico con il segnale derivante dal confronto (NotEqual) tra
il conteggio di bit pari ad 1 e lo 0. Questo permette di sapere se l’array è composto da elementi tutti nulli, nel qual caso è sicuramente presente un errore di trasmissione. All’interno della subVI un ciclo For eseguito per l’intera lunghezza degli array, si occupa del calcolo di bit pari ad 1 andando a sommare ad un registro inizialmente nullo il valore di ogni bit. Per il calcolo del BCC si è fatto riferimento al protocollo USS che richiede il calcolo di uno XOR tra i singoli bit ed il valore del BCC calcolato dal bit precedente e qui implementato tramite un registro. Il valore uscente dal registro è il BCC calcolato e viene utilizzato per la comparazione.
42
Figura 33 – sR_BCCcheck.vi per il calcolo e la verifica del carattere BCC.
Inoltre in questo frame si provvede ad esportare Status Flag nell’interfaccia cRIO tramite variabile globale (una per azionamento). Questa variabile, derivante dalla subVI di divisione dei byte, contiene informazioni sullo stato dei motori, ed in particolare:
0. Pronto all’accensione; 1. Pronto alla movimentazione; 2. Operazioni abilitate;
3. Anomalia attiva;
4. Bloccaggio inerziale attivo; 5. Bloccaggio rapido attivo; 6. Blocco inserzione attivo; 7. Avviso attivo.
Nei due flag successivi si utilizzano i due byte di PZD2 per il calcolo delle velocità degli assi derivante dall’azionamento. Specularmente a quanto è stato fatto nella fase di preparazione del Main Setpoint del Task Telegram, occorre unire i due byte del dato concatenandoli in un’unica stringa, solo dopo averli formattati ad interi ad 8 bit tramite il comando Format Value. La stringa così ottenuta viene portata all’ingresso di una struttura case attivata dal segnale di ricezione dei due byte. Nel caso falso, cioè quanto il dato non è stato interamente ricevuto, si porta all’uscita del case una seconda stringa derivante da un registro in cui è stata inserita l’ultima stringa utile. L’uscita del case, infatti, è collegata al registro di cui ne aggiorna il valore. Nel caso vero, invece, si utilizza la stringa derivante dal frame precedente e si esegue la procedura di concatenazione con il valore del registro, opportunamente elaborato,
43 come descritto per i casi dei frame precedenti. Il successivo ed ultimo frame utilizza le due stringhe derivanti dai rispettivi assi per ricavare il dato di velocità. Nella subVI sR_PZDActualValue.vi all’interno di un ciclo For avviene la conversione del dato effettuando un numero d’iterazioni pari al numero di caratteri di PZD2. Il case inserito realizza la sostituzione degli spazi vuoti (carattere 32 ASCII) con degli 0 (carattere 48 ASCII), lasciando il resto dei caratteri inalterati. Fuori dal case il numero decimale si ricava effettuando la conversione da ASCII, cioè sottraendo 48 ad ogni carattere. Infine si somma ad un registro, inizialmente nullo, il valore ricavato dal carattere moltiplicato per 2x dove x è dato dalla posizione all’interno della stringa del carattere letto. La x più alta è per il bit più significativo. Il valore di
x viene calcolato tramite la sottrazione tra il numero caratteri-1 ed il numero d’iterazione-1, cioè i. Il valore in uscita dal ciclo rappresenta la velocità riportata in
I16, che va convertita all’intervallo -6000RPM/+6000RPM dividendo il valore per 5.46133333333.
Figura 34 – sR_PZDActualValue.vi SubVI per il calcolo della velocità dell’asse partendo dalla stringa PZD2.
I valori di velocità sono quindi esportati nella VI principale operante su cRIO tramite variabili globali, Motor Speed (RPM).
