Capitolo 4
Sviluppo software
Introduzione
La piattaforma di sviluppo software prescelta per la realizzazione dell’interfaccia grafica di visualizzazione dei risultati e impostazione dei parametri dell’esperimento è il software per strumentazione virtuale LabView 5.1 distribuito da National Instruments. Tuttavia, come accennato nel capitolo relativo alla descrizione delle piattaforme di sviluppo, si è reso necessario l’utilizzo di altri strumenti per la gestione del protocollo IEEE1394. Si è scelto pertanto di adottare una soluzione che prevedesse l’utilizzo di un’ulteriore PC sul quale è stata installata la versione Suse 9.1 del sistema operativo Linux. La possibilità di reperire in rete applicativi Linux per la gestione del protocollo IEEE1394 ha permesso quindi di utilizzare il PC aggiuntivo come ponte di comunicazione tra la Data Processing Board e il PC sul quale è stata realizzata l’interfaccia grafica vera e propria con LabView. La comunicazione tra i due PC avviene su protocollo TCP/IP (Transmission Control Protocol/Internet Protocol). Il PC remoto, su cui gira l’applicazione LabView agisce da client e il PC connesso alla Data Processing Board si comporta da server. In questo modo il PC equipaggiato di sistema operativo Linux realizza un server TCP/IP tramite il quale qualunque client collegato via Ethernet allo host può scaricare off-line i dati richiesti e gestire comunque il sistema completo di acquisizione.
Per l’utilizzo del protocollo TCP/IP esistono VI’s di libreria che consentono una facile gestione della comunicazione.
IEEE1
394 TCP/IP
Visualizzazione risultati Acquisizione dati su HDD via IEEE1394
e invio ogni 100ms di immagine a LV via TCP/IP
Ponte per ricezione e invio comandi a Data Processing Board via IEEE1394
SERVER
CLIENT
Orsys micro-line CPT6713
Figura 4.1: Architettura proposta per la comunicazione tra la Data Processing Board e il PC remoto.
In questo capitolo verrà mostrato lo stato attuale dell’interfaccia utente sviluppata su LabView per la ricezione e presentazione dei risultati di conteggio e l’invio dei comandi alla Data Processing Board.
4.1 Interfaccia LabView
Allo stato attuale del progetto SPADA l’interfaccia LabView è completa per la parte relativa all’applicazione FTI mentre resta da sviluppare la parte dell’interfaccia relativa alle altre due applicazioni. Tuttavia la presentazione dei risultati di conteggio e l’impostazione della finestra temporale di acquisizione e di memorizzazione dei dati, comune alle tre applicazioni è operativa e funzionante, come è stato provato durante la dimostrazione svoltasi a Milano il 17 dicembre 2004 in cui sono state fatte prove dell’intero sistema elettronico di acquisizione e visualizzazione con il sensore SPADA. Nel capitolo successivo verranno mostrati e discussi i risultati ottenuti durante la dimostrazione del sistema, i problemi riscontrati e le eventuali soluzioni proposte.
4.1.1 Front Panel e pannelli secondari
Il pannello frontale consente all’utente di selezionare il tipo di applicazione desiderata per l’esperimento da svolgere. Le possibilità sono:
• Fast Transient Imaging • Adaptive Optics
• Layer Sensing
• Detection Board Setting
Figura 4.2: Pannello frontale dell’interfaccia utente
La selezione dell’applicazione comporta l’apertura di un pannello per la impostazione dei parametri dell’esperimento dipendente dall’applicazione scelta.
4.1.1.1 Fast Transient Imaging
Figura 4.3: Pannello di controllo per l’applicazione FTI.
Per l’applicazione FTI è possibile:
• Impostare la finestra di integrazione per i contatori.
• Settare la durata dell’intero esperimento, ovvero il periodo di acquisizione totale dei risultati di conteggio.
• Immettere il nome del file su cui salvare i dati nonché visualizzare lo spazio richiesto e quello disponibile sul disco rigido del PC su cui gira l’applicazione Linux.
• Visualizzare l’eventuale stato di saturazione dei contatori.
• Mandare in esecuzione la VI con la mappa di visualizzazione premendo il pulsante Show Diagram.
Le funzionalità sopraesposte sono tutte operative, come detto precedentemente. Si illustrano di seguito le funzionalità a cui dovranno ottemperare le VI, ancora da sviluppare, per le altre due applicazioni.
4.1.1.2 Adaptive Optics
Figura 4.4: Pannello di controllo per l’applicazione AO.
Per l’applicazione AO il pannello da strumentazione virtuale deve consentire all’utente di:
• Settare i parametri ampiezza, frequenza e fase della sinusoide da generare.
• Impostare il tempo integrazione in termini di periodi della sinusoide.
• Selezionare la modalità di presentazione del segnale di curvatura consentendo di scegliere tra la visualizzazione del solo segnale di
curvatura indicatore della condizione di messa a fuoco sull’immagine oppure del segnale di curvatura assieme ai risultati di conteggio.
• Lo stato di funzionamento anomalo dei sensori riportato dalla condizione di saturazione dei contatori.
• Visualizzare il diagramma di curvatura.
Figura 4.5: Immagine ipotetica di visualizzazione del diagramma di curvatura. I colori rosso e verde indicano se il segnale di cuvatura C=A-B/A+B è maggiore o minore di zero.
4.1.1.3 Layer Sensing
Figura 4.6: Pannello di controllo per l’applicazione LS.
Per quanto riguarda l’applicazione LS la VI deve consentire all’utente di:
• Impostare la durata dell’esperimento in termini di numero di acquisizioni da effettuare.
• Settare i parametri della sinusoide ampiezza, frequenza e fase.
• Visualizzare i risultati di conteggio relativi alle quindici acquisizioni successive previste dall’applicazione.
4.1.1.4 Detection Board setting
Figura 4.7: Pannello di controllo per i settaggi della Detection Board.
Il pannello di controllo della Detection Board consente all’utente di: • Settare i segnali di Gate e Interlock software e riportare lo stato di
tali segnali se settati esternamente via hardware tramite la scheda GPIO.
• Impostare la modalità Safety Mode
• Impostare la temperatura della Detection Board e consentire di configurare il tempo di hold off e la tensione di anodo degli iAQC. Le funzionalità relative ai segnali di Gate e Interlock e al Safety Mode sono attualmente operative. Resta da sviluppare l’applicazione per la gestione delle informazioni sulla temperatura e sullo stato degli iAQC.
4.1.2 Mappa di visualizzazione
Per la visualizzazione dei risultati di conteggio dei contatori è stata sviluppata una VI che consente una visione immediata del livello di illuminazione dei sensori. Si tratta di una mappa circolare divisa in 60 settori ad ognuno dei quali corrisponde uno dei registri di uscita del SDPM e quindi lo stato di illuminazione di uno dei sensori dello SPADA.
Figura 4.8: Esempio di visualizzazione dei risultati di conteggio su mappa circolare a 60 settori.
I settori della mappa assumono una tonalità di colore appartenente ad una scala di grigi codificata su 8 bit e normalizzata rispetto al risultato di conteggio più alto dell’acquisizione attuale. L’intensità del tono dipende quindi dal risultato di conteggio a cui il settore è associato.
Andando più nel dettaglio si illustra ora la gestione del protocollo di comunicazione TCP/IP nell’ambiente di sviluppo LabView.
4.1.3 Acquisizione e invio dati su protocollo TCP/IP
La gestione del protocollo TCP/IP su LabView è realizzata sfruttando le funzioni di libreria fornite con il software di National Instruments. Le operazioni da compiere per utilizzare una connessione basata su protocollo TCP/IP sono:
• L’apertura di una porta sull’indirizzo IP del dispositivo remoto. Ciò è possibile sfruttando la VI TCPOpen la quale riceve in ingresso l’indirizzo IP e il numero della porta desiderata e restituisce un ID univoco a cui fare riferimento per le operazioni successive da compiere sulla connessione.
Figura 4.9 VI TCPOpen per l’inizializzazione della connessione TCP/IP.
• L’utilizzo, per operazioni di scrittura sulla porta del dispositivo remoto, della funzione TCPWrite che riceve in ingresso l’ID della connessione e i byte da scrivere, compie l’operazione richiesta e restituisce l’ID e il numero di byte scritti.
• L’utilizzo, per operazioni di lettura dalla porta del dispositivo remoto, della funzione TCPRead, che riceve in ingresso l’ID della connessione e il numero di byte da leggere e li restituisce in uscita.
Figura 4.11 VI TCPRead per la lettura sulla connessione TCP/IP.
Nel caso in esame le tre funzioni appena viste sono chiamate nella VI
client.vi in cui si inizializza la comunicazione tra i due PC e si
inizializzano le code per la trasmissione e ricezione dei dati. La VI viene chiamata automaticamente dal Top quando viene mandato in esecuzione. La coda di ricezione viene utilizzata come buffer di ingresso per la ricezione dei risultati di conteggio, del feedback sullo stato dei segnali di Gate e Interlock, e della notifica della eventuale condizione di saturazione dei contatori. La coda di trasmissione è invece usata per inviare all’applicazione Linux le impostazioni sulla finestra temporale di acquisizione, i settaggi software dei segnali di Gate e Interlock e l’impostazione del Safety Mode.
I dati ricevuti vengono interpretati come una stringa il cui contenuto riporta inizialmente informazioni circa il tipo di dati che sono stati trasmessi e la loro dimensioni in numero di byte. Ogni pacchetto viene quindi organizzato in un cluster, simile ad una struttura del linguaggio C, costituito dai campi type, len e data per la successiva elaborazione e presentazione dell’informazione che reca. La tabella seguente mostra i vari tipi di dati che possono essere ricevuti via TCP/IP e presentati.
Tipo Dimensione in byte Significato dati
2 64 (16*4) Informazioni circa lo stato dell’esperimento in corso come la durata dell’esperimento e la finestra di acquisizione attuale 3 124 (31*4) Risultati di conteggio e contenuto del registro COUNT_INFO_REG del SDPM 5 64 (16*4) Parametri di configurazione della Detection Board 7 Informazioni circa la
dimensione del file e lo spazio disponibile sul HDD del PC su cui
vengono memorizzati tutti i dati.
8 Messaggi di errore
Tabella 4.1: Codici identificativi dei pacchetti di dati ricevuti via TCP/IP
Il formato dei dati da inviare via TCP/IP è analogo a quello dei dati ricevuti ed è anch’esso costituito da dei campi contenenti informazioni sul tipo di informazioni inviate e sulla dimensione della stringa in numero di byte. La tabella seguente riporta i codici identificativi dei pacchetti che possono essere inviati via TCP/IP.
Tipo Dimensione in byte Significato dati
1 3 Inizio, fine esperimento,
trasmissione finestra di integrazione e durata esperimento.
4 3 Settaggi Detection Board,
Hold Off Time,
Temperatura e Anode High Voltage Supply.
9 3 Attivazione di Gate,
Interlock e Safety Mode.
4.1.4 Visualizzazione risultati acquisiti
Essendo la frequenza di ricezione dei risultati di conteggio ordini di grandezza superiore alla frequenza di rinfresco delle immagini sul monitor, non tutte le acquisizioni possono essere presentate sulla mappa durante l’esecuzione di un esperimento, pertanto si è stabilita una frequenza di rinfresco dell’immagine in modo tale da visualizzare dei nuovi risultati ogni 100 ms mentre tutti i dati, compresi quelli non visualizzati, vengono registrati in un file .dat sull’hard disk del server per successive analisi. In tal modo viene rispettata la caratteristica di tempo reale del sistema prevista dalle specifiche di progetto. Terminato un esperimento è possibile andare a visualizzare i dati acquisiti sempre tramite la mappa di visualizzazione ma utilizzando una VI apposita che consente di prelevare i dati dal file .dat creato in fase di acquisizione e di riprodurre tale file con una velocità di riproduzione impostabile dall’utente.
Figura 4.9: Interfaccia grafica per l’analisi visiva dei dati acquisiti. E’possibile visualizzare anche l’andamento nel tempo di uno qualunque dei 60 settori. L’immagine si riferisce ad uno dei test effettuati sul sistema durante la demo del 17 dicembre 2004, di cui si discuterà nel capitolo 5. La frequenza dell’onda triangolare è pari a 1KHz.
4.2 Applicazione Linux
Come accennato nell’introduzione, per immagazzinare le informazioni relative ai risultati di conteggio provenienti dalla Data
Processing Board tramite il link IEEE1394 è stata sviluppata un’applicazione
in linguaggio C++ compilato per il sistema operativo Linux. Tale soluzione è stata dettata, oltre che dalla difficoltà incontrate nel reperire soluzioni valide per la gestione del protocollo IEEE1394 in ambiente Windows, anche dall’intrinseco collo di bottiglia nel flusso di dati rappresentato dall’utilizzo di un unico PC per il controllo del modulo di elaborazione. Tale soluzione avrebbe infatti comportato un rischio per il soddisfacimento dei requisiti di acquisizione in tempo reale del sistema a causa dell’esecuzione concorrenziale di più processi con accesso random al disco rigido tipica di sistemi operativi multitasking. Per contro la soluzione dell’architettura server-client presentata nell’introduzione ha consentito di sviluppare sul PC server un’applicazione Linux in grado di realizzare un’acquisizione in tempo reale dei dati ricevuti dalla Data
Processing Board. Infatti il PC su cui essa gira, equipaggiato con un disco
rigido veloce acceduto in maniera sequenziale e non random, è sfruttato quasi esclusivamente per l’immagazzinamento dei dati appartenenti al flusso isocrono in modo da evitare il rischio della perdita di dati e garantire il soddisfacimento delle specifiche di progetto. L’unico, relativo, peso aggiuntivo all’applicazione è costituito dalle saltuarie transazioni asincrone sul bus IEEE1394 e dalla gestione della comunicazione via TCP/IP con il client. Sotto questo aspetto l’applicazione realizza una sorta di ponte tra i due canali di comunicazione, inviando al client, a seconda del caso, le informazioni sullo stato di un esperimento in corso o i risultati di conteggio da riportare sulla mappa del sensore SPADA nell’ambiente LabView, informazioni ricevute dalla Data Processing Board tramite il link asincrono. Via TCP/IP il server riceve inoltre dal client i vari parametri destinati alla Data Processing Board per l’avvio di un nuovo esperimento o i settaggi da inviare alla Detection Board per il controllo dello stato dei
sensori e inoltra tali informazioni alla scheda di elaborazione operando una transazione asincrona su bus IEEE1394. Si conclude evidenziando, come ulteriore vantaggio dell’architettura server-client sviluppata, la possibilità di realizzazione di uno scenario in cui un qualunque ricercatore in astrofisica possa accedere via Ethernet al sistema di acquisizione, controllando lo stato di un esperimento in corso o variandone i parametri stando comodamente seduto alla sua scrivania posta dall’altra parte del mondo.
