L’interfaccia software

Capitolo 5

L’interfaccia software

5.1 Introduzione: il software del computer remoto

Parte integrante della sezione di Data Processing del progetto SPADA, affidata all’università di Pisa, sarà costituita dal software del computer remoto usato per il controllo del sistema.

Tale software dovrà svolgere diverse funzioni:

• Attraverso un’interfaccia il più possibile intuitiva dovranno essere possibili le impostazioni necessarie al funzionamento della Data Processing Board e della Detection Board, nelle tre differenti applicazioni.

• I dati acquisiti ed elaborati dalla Data Processing Board saranno salvati in appositi file (ad esempio con estensione .fits) e potranno anche essere visualizzati tramite un diagramma a 60 settori, a simmetria cilindrica.

• Si dovranno svolgere post-elaborazioni dei dati, legate soprattutto alla diagnostica del corretto funzionamento del sistema e a statistiche sulle immagini acquisite.

Finora è stato curato il solo aspetto grafico del software, elaborato con l’ausilio di LabView. La descrizione di tale interfaccia grafica sarà utile anche ai fini di una ricapitolazione finale delle funzioni che dovranno essere svolte dal sistema in ciascuna delle tre applicazioni previste.

Figura 5.1: funzionalità del software per la gestione del sistema SPADA.

5.1.2 Il software LabView

Il software utilizzato per la costruzione dell’interfaccia è LabView, della National Instruments. Esso è comunemente usato in applicazioni che richiedono una “strumentazione virtuale”: tramite un unico pannello di controllo, definibile dall’utente, è possibile la gestione di più apparecchiature di test e di più strumenti di misura, collegati in vario modo ad un unico computer remoto.

In ambito LabView i programmi sono definiti VI (Virtual Instruments) e, una volta realizzati, possono anche essere controllati in modo remoto, via rete.

La creazione dei programmi avviene normalmente in modalità grafica, ma c’è la possibilità di inserire del codice C per svolgere elaborazioni di elevata complessità.

Ogni VI è costituito essenzialmente da tre parti: “Front Panel”, “Block Diagram” e “Icon and

Connector Panel”.

Il Front Panel simula sullo schermo il pannello frontale di uno strumento tradizionale, con controlli, manopole, indicatori sia di tipo analogico sia di tipo digitale. Il contenuto e l’aspetto del Front Panel vengono selezionati per mezzo dell’editor grafico.

Software

Il Block Diagram è l’equivalente, in forma grafica, di un codice sorgente per un programma. Esso è strutturato secondo il concetto del data flow: l’esecuzione del codice è pilotata dal flusso di dati che “avanzano” da un lato all’altro del diagramma. E’ possibile anche inserire le tradizionali strutture del controllo di flusso, come cicli e salti condizionali anche a scelta multipla.

L’Icon and Connector Panel è costituito da un simbolo grafico con ingressi e uscite, che consente di utilizzare un VI come subroutine di un VI più complesso. Non a caso, sono disponibili nelle librerie di LabView molti VI elementari, utilizzabili all’interno di strumentazioni virtuali più complesse.

Gli strumenti di misura veri e propri appaiono nel programma tramite il loro Connector Panel e vengono controllati tramite appositi driver, già disponibili in LabView od ottenibili dal costruttore dello strumento. In questo modo l’utente non ha bisogno di conoscere le stringhe che devono essere inviate a ciascuno strumento per controllare le funzioni e prelevare i risultati delle misure.

Nell’ambito del progetto SPADA l’utilizzo del software LabView è stato deciso in quanto la Data Processing Board, alla quale il computer è connesso tramite la connessione Firewire, altro non è che un versatile strumento di misura: LabView offre tutte le risorse elementari necessarie alla definizione di uno o più pannelli di controllo per tale strumento, e mette a disposizione anche la possibilità di costruire facilmente, anche in C, dei programmi per la post-elaborazione dei dati acquisiti.

5.2 Schermata di ingresso

L’interfaccia dello “SPADA software” prevede una schermata di ingresso dalla quale si possa accedere, in modo mutuamente esclusivo, ad uno dei tre pannelli di controllo relativi alle tre differenti applicazioni previste (Adaptive Optics, Fast Transient Imaging, Layer Sensing).

A seconda della scelta, la scheda di Data-Processing sarà configurata in modo da poter svolgere l’applicazione richiesta. Per questo è importante che la scelta sia univoca e che non si possano aprire contemporaneamente più pannelli di controllo: ad ognuno di questi corrisponde una precisa definizione dell’hardware. Tentare di aprire contemporaneamente più pannelli comporta la visualizzazione di un messaggio d’errore.

In figura 5.2 è mostrata la schermata d’ingresso, mentre in 5.3 si osserva il diagramma a blocchi dal quale la precedente è costituita.

Figura 5.2: Schermata d’ingresso allo SPADA Control Software.

In quest’ultimo diagramma si può notare come la pressione di uno qualsiasi dei tre pulsanti (ed uno solo) dell’interfaccia provoca l’apertura del corrispondente pannello di controllo. Un file che genera un messaggio di errore è invece richiamato se si tenta di aprire più di un pannello alla volta. Tale messaggio, ed il semplice diagramma corrispondente, sono mostrati nelle figure 5.4 e 5.5.

Figura 5.5: messaggio di errore: diagramma corrispondente

5.3 Pannelli di controllo

Verranno ora mostrati i pannelli di controllo per le tre differenti applicazioni. Alcuni controlli e alcune impostazioni sono comuni alle tre interfacce, altri sono specifici del pannello considerato. Gli elementi comuni sono:

• L’interruttore di gate e quello di interlock (software).

• L’interruttore di attivazione della modalità “safety” per la gestione dell’interlock hardware.

• L’impostazione della temperatura di lavoro e la lettura della temperatura effettiva. • L’impostazione di hold-off time ed over-voltage per la detection board.

5.3.1 Fast Transient Imaging

Figura 5.6: pannello di controllo per FTI

Elementi tipici di questa configurazione sono:

• La durata del singolo conteggio, quindi la frequenza delle immagini acquisite. • La durata totale dell’esperienza di misura.

• Un utile, anche se non strettamente necessario, indicatore immediato del fatto che uno o più contatori siano andati in saturazione: in questo caso l’operatore potrà decidere di ridurre la durata del singolo conteggio, adattando la durata di tale finestra temporale al flusso medio incidente di fotoni. Si ricorda che per finestre di durata minore di 3.3ms i contatori non dovrebbero mai saturare.

• Un interruttore che comanda l’apertura e la chiusura di uno schema di visualizzazione dei dati acquisiti, a 60 settori e a simmetria cilindrica (Vedere paragrafo 5.4).

5.3.2 Adaptive Optics

Il pannello di controllo per l’applicazione AO è mostrato in figura 5.7.

Figura 5.7: pannello di controllo per AO

Elementi tipici di questa configurazione sono:

• La possibilità di impostare i parametri (ampiezza, frequenza, fase) della sinusoide generata dal sistema.

• La selezione del numero di periodi di sinusoide (da 1 a 256) durante i quali accumulare nei contatori A e B, alternativamente, i fotoni incidenti.

• La possibilità di scegliere, attraverso un selettore, se effettuare l’upload del solo segnale di curvatura od anche dei contenuti dei registri interni A e B.

• Anche in questo caso, come nell’applicazione FTI, un indicatore della saturazione di uno o più contatori. Ora esso diviene ancora più importante poiché, senza tale indicatore, se non si è in “safety mode” e se viene fatto l’upload del solo segnale C=(A-B)/(A+B), potrebbero giungere dati di curvatura errati, inficiati dalla saturazione dei contatori, senza che l’operatore se ne possa accorgere.

• Un interruttore per visualizzare uno schema a 60 settori analogo a quello usato nell’applicazione FTI. In questo caso esso deve mostrare non un’immagine, ma il segnale di curvatura acquisito (Vedere paragrafo 5.4).

5.3.3 Layer Sensing

Il pannello di controllo per l’applicazione LS è mostrato in figura 5.8.

• La possibilità di impostare i parametri (ampiezza, frequenza, fase) della sinusoide che viene generata dal sistema, come nell’applicazione di Adaptive Optics.

• L’impostazione del tempo di integrazione, misurato anche questa volta in periodi di sinusoide.

• L’indicatore della saturazione di uno o più contatori: anche in questo caso, come in FTI, esso non è essenziale ma utile.

• Un interruttore per accedere alla schermata in cui può essere visualizzata una qualsiasi delle 15 immagini fornite dall’ultima sequenza di acquisizione (Vedere paragrafo 5.4).

5.4 Visualizzazione dei dati acquisiti.

I dati acquisiti sono visualizzati in tutte le 3 applicazioni tramite un diagramma a simmetria cilindrica composto da 60 settori, corrispondenti alla disposizione fisica dei sensori SPAD all’interno dell’array utilizzato. In particolare, nello schema vi sono cinque corone circolari concentriche contenenti rispettivamente, dall’interno verso l’esterno: 4, 8, 12, 16 e 20 settori, corrispondenti ai rispettivi sensori.

Per costruire graficamente lo schema, utilizzando LabView, si è fatto ricorso alle librerie di disegno di tale software, che permettono ad esempio di tracciare linee e circonferenze, colorare settori circolari e spostare il cursore di disegno in un punto desiderato dello schermo.

Figura 5.9: Diagramma di visualizzazione dei dati, con i settori colorati in modo casuale in toni di grigio.

Figura 5.10: Struttura a blocchi usata per disegnare il diagramma di visualizzazione.

Come si evince dalla struttura a blocchi usata per disegnare il diagramma di visualizzazione, per prima cosa vengono colorati i 20 settori del cerchio esterno, cui è poi sovrapposta la griglia nera di separazione tra un settore e l’altro. Quindi si passa al disegno dei settori del cerchio più interno, concentrico al precedente, con i relativi riempimenti di colore e la propria griglia. Si procede in questo modo fino ad arrivare al cerchio centrale, quello suddiviso in soli quattro settori.

Ogni corona circolare di settori è quindi disegnata con l’utilizzo di due VI: il primo per riempire i settori dei colori desiderati (“fill#”), ed il secondo con la funzione grafica di sovrascrivervi la griglia nera di separazione tra settori, per esigenze estetiche nonché di migliore leggibilità (“grid#”).

5.4.1 Riempimento dei settori

In figura 5.11 sono mostrati i risultati grafici prodotti da fill1, fill2, fill3, fill4 e fill5. Nello schema complessivo questi cerchi risultano sovrapposti in modo concentrico. I colori sono stati generati casualmente in scala di grigio.

Figura 5.11: risultati grafici prodotti dalle esecuzioni di fill1, fill2, fill3, fill4 e fill5.

Per semplicità è mostrato un solo diagramma a blocchi, quello di fill4. Si nota come esso sia semplicemente costituito da una serie di VI, presenti nelle librerie LabView, che permettono di disegnare settori circolari: in ingresso a tali VI vanno forniti:

- le coordinate del centro del cerchio ed il suo raggio

- il colore, in questo caso creato tramite una generazione casuale all’interno della scala di grigio (vedere paragrafo 5.5)

- l’indicazione di colorare effettivamente il settore (l’alternativa è tracciare il solo arco) - l’angolo spazzato dal settore e quello di riferimento sull’intero cerchio

L’uscita di ogni elemento è un’immagine, la quale viene fornita in ingresso all’elemento successivo, in modo da sovrascrivervi ad ogni passo un nuovo settore.

Figura 5.12: diagramma costitutivo di Fill4.

5.4.2 Griglie di demarcazione

In figura 5.13 sono mostrati i risultati grafici prodotti dai VI grid1, grid2, grid3, grid4 e grid5. Tali griglie, sovrapposte ai corrispondenti settori, consentono una maggiore leggibilità del diagramma, marcando la separazione tra due settori adiacenti anche quando questi siano di gradazioni di colore molto simili tra loro.

Anche in questo caso, per semplicità, è mostrato un solo diagramma a blocchi elementari, quello costitutivo di grid3.

Figura 5.14: diagramma a blocchi relativo a grid3.

In questo caso i VI di libreria utilizzati sono tre.

Per prima cosa è tracciata la circonferenza (o le due circonferenze in grid1). Al VI che la genera devono essere forniti:

- Raggio

- Coordinate del centro

- Arco descritto (in questo caso 360 gradi) e a partire da quale angolo. - Colore

Quindi vengono tracciati i raggi; per ognuno di essi si usano due VI: il primo posiziona il cursore di disegno in un punto voluto, in questo caso il centro della circonferenza, ed il secondo traccia la linea; ad esso vanno forniti:

- L’indicazione che si vuole lavorare con coordinate relative - Le coordinate relative del punto d’arrivo

- Il colore.

Anche in questo caso sia l’ingresso sia l’uscita di ogni singolo blocchetto di libreria, come dei VI grid, è in formato picture, per poter sovrascrivere i nuovi disegni alla vecchia immagine.

5.5 La gestione del colore in LabView

Molte funzioni LabView di disegno, tra cui alcune di quelle utilizzate, richiedono come ingresso un “colore”. Spesso la via più veloce per attribuirlo al disegno è utilizzare un “color box constant”, cioè un colore costante scelto da una tavolozza predefinita. In questo modo, ad esempio, è stato assegnato il colore nero ai vari tratti delle griglie di separazione nei file di tipo grid# (vedere paragrafo 5.4.2).

Vi sono tuttavia dei casi in cui il colore deve essere legato a quantità variabili: ad esempio ogni settore del diagramma descritto nei paragrafi precedenti deve essere colorato, nell’applicazione FTI, con un tono di grigio correlato al numero di fotoni rilevati dal sensore corrispondente. Nell’applicazione di Ottica Adattiva, invece, tramite un’apposita colorazione, si devono poter visualizzare addirittura dei numeri reali. E’ ovvio che per poter fare questo si deve analizzare il modo in cui un colore viene rappresentato in LabView: esso è definito da un numero intero di 32 bit, i cui tre byte meno significativi costituiscono i componenti rosso, verde e blu del colore descritto. Quindi, ad esempio, se si vogliono creare diversi colori in una scala di blu, si deve variare solamente il byte meno significativo della sequenza. Se invece si vuole lavorare su una scala di grigi, bisogna fare in modo che per ogni tono i numeri che descrivono i componenti rosso, verde e blu siano uguali tra loro.

In questo modo è quindi possibile creare colori “proporzionali” a quantità variabili.

Per fornire una visione colorata dei vari diagrammi, anche in assenza di dati reali provenienti da sensori, si è creata una presentazione dell’interfaccia grafica in cui i toni cromatici sono stati generati in modo casuale o pseudo-casuale.

Un generatore casuale di toni di grigio è mostrato in figura 5.15. Esso è quello utilizzato, ad esempio, per produrre il diagramma di figura 5.9.

E’ stato utilizzato un generatore di numeri casuali tra 0 ed 1: il numero reale da esso generato, moltiplicato per 255 e arrotondato ad un intero su 8bit, può essere copiato, con gli artifizi matematici necessari, nei tre byte meno significativi dell’intero a 32bit che definisce il colore. In questo modo, come già esposto precedentemente, si ottengono toni della scala di grigio, con luminosità variabile in modo casuale.

5.5.1 Generazione del diagramma di presentazione per FTI

Una distribuzione di toni di grigio completamente casuale come quella di figura 5.9 non ha alcun valore realistico. In applicazioni di imaging ottico vi saranno probabilmente delle zone più o meno ampie del diagramma con colorazioni dei settori molto simili tra loro, corrispondenti a sorgenti di luce o zone d’ombra.

Per questo, nella presentazione del diagramma di visualizzazione per FTI, si è utilizzato un semplice sistema di generazione di toni di grigio pseudo-casuale. Si sono definiti i seguenti 3 generatori casuali:

- LightGenerator produce interi a 32 bit corrispondenti a zone di luce (grigi chiari): gli 8 bit che sono poi ricopiati nei tre byte meno significativi assumono valori tra 192 e 256. - EdgeGenerator produce interi a 32 bit corrispondenti a zone di penombra (grigi

intermedi): gli 8 bit che sono poi ricopiati nei tre byte meno significativi assumono valori tra 64 e 192.

- DarkGenerator produce interi a 32 bit corrispondenti a zone d’ombra (grigi scuri): gli 8 bit che sono poi ricopiati nei tre byte meno significativi assumono valori tra 0 e 64. Quindi si sono definite sul diagramma, a priori, le zone di luce e quelle d’ombra e si sono assegnati di conseguenza, ai VI che creano i settori colorati, i generatori di colore corrispondenti.

(b)

(c)

Figura 5.16: Schemi a blocchi per la generazione di grigi chiari (a), intermedi (b) e scuri (c).

In questo modo si riesce ad ottenere una buona approssimazione di quella che sarà un’immagine effettivamente acquisita dai sensori. In figura 5.17 è mostrato il diagramma risultante di quest’operazione: esso è stato ottenuto imponendo la presenza di una fonte di luce di intensità elevata nel primo quadrante del diagramma ed una meno intensa nel terzo quadrante.

Figura 5.17: Presentazione “realistica” del diagramma di visualizzazione dei dati acquisiti, in un’applicazione di tipo FTI.

Quando poi si dovrà passare da questa grafica, puramente di presentazione, a quella definitiva, in cui i colori dei settori saranno effettivamente legati al numero di fotoni rilevati dai singoli sensori, si potrà prevedere un meccanismo di normalizzazione dei dati, prima che questi vengano visualizzati. In questo modo si potranno evidenziare con sufficiente chiarezza anche sorgenti luminose di bassissima entità ed ottenere immagini non troppo scure anche quando le finestre temporali di acquisizione saranno molto brevi: in entrambi i casi, infatti, i fotoni contati da ogni sensore saranno di diversi ordini di grandezza minori dei 216 _{fotoni che segnano la saturazione dei contatori.}

5.5.2 Generazione del diagramma di presentazione per AO

Nelle applicazioni di ottica adattiva, quello che deve essere visualizzato è, per ogni settore, il corrispondente segnale di curvatura. Esso è rappresentato da un numero reale compreso tra -1 ed 1.

Si può pensare di effettuare una codifica cromatica di tale segnale utilizzando due colori differenti: uno per le quantità negative ed uno per le positive; tanto più il segnale di curvatura sarà elevato in valore assoluto, tanto più il colore apparirà luminoso.

Nell’esempio di presentazione si sono usati i colori verde e rosso, a rappresentare quantità rispettivamente positive e negative.

In figura 5.18 sono mostrati i generatori casuali dei colori verde e rosso, ed il generatore di un colore, rosso o verde, casuale. Una distribuzione equa dei due colori sul diagramma appare improbabile: a seconda che l’immagine sia focalizzata sopra o sotto il piano dei sensori, si otterranno distribuzioni con uno dei due colori prevalente sull’altro. Solo in caso di perfetta focalizzazione si potrà avere equilibrio tra i due colori, e probabilmente l’immagine apparirà molto scura (cioè il segnale di curvatura avrà valori assoluti vicini allo 0).

(a)

(b)

(d)

Figura 5.18: Generatori casuali di interi a 32 bit per i colori rosso (a) e verde (b). Generazione di un colore casuale rosso o verde, con probabilità pari a 0.8 di ottenere un tono verde (c e d).

Per poter ottenere i colori nelle scale di rosso e di verde si sono dovuti modificare i soli byte corrispondenti ai toni rossi e verdi del numero intero a 32 bit che rappresenta il colore. Non sono state tuttavia utilizzate le intere scale cromatiche: poiché i colori corrispondenti ai toni più scuri risultavano tanto cupi da essere di difficile interpretazione, si sono utilizzate solamente le metà più

luminose delle due scale cromatiche. Cioè i byte corrispondenti al tono (rosso o verde) voluto si sono fatti variare non tra 0 e 256, ma tra 128 e 256.

In figura 5.20 è mostrato il risultato, in ogni caso approssimativo, di un’ipotetica situazione in cui i valori del segnale di curvatura siano prevalentemente positivi.