[LabVIEW] L'oscilloscopio virtuale

Lo scopo di questo post è di farvi vedere come realizzare con LabVIEW una piccola applicazione, senza troppe pretese, ma completa e funzionale in tutto e dall'aspetto professionale. Ecco gli aspetti che andremo a toccare in questa puntata di LabVIEW per tutti:

• Come realizzare un'applicazione usando la programmazione per eventi.
• Abilitare il login dell'utente in modo avere disponibili comandi differenti a seconda della tipologia di utente (normal user, power user e super cow). 
• Modificare il menu dell'applicazione aggiungendo comandi definiti dall'utente. 

Se siete pronti, direi che possiamo iniziare, scaricatevi l'intero progetto dell'oscilloscopio virtuale da qui e cominciate a sfogliare il diagramma mentre leggete il resto. 

Programmare per eventi

Abbiamo già visto nel precedente episodio come la gestione degli eventi possa aiutare nell'ottimizzazione delle risorse dell'pplicazione, oggi ne faremo largo uso, quindi se non vi ricordate cosa fossero questi eventi e perché sono così importanti, leggete l'episodio precedente e poi tornate qui.

La struttura ad eventi che domina l'intero diagramma è contenuta in un ciclo while che ne garantisce l'esecuzione continua. Questa struttura è simile in concetto a quella di una macchina a stati di un microprocessore ed infatti il primo evento che viene chiamato è proprio initialize. Questo evento contiene tutte le operazioni necessarie da effettuarsi al momento dell'avvio dell'applicazione, per esempio vengono disabilitati tutti i controlli che non sono disponibili per l'utente e impostati alcuni valori di default.

Per essere sicuri che initialize sia proprio il primo evento ad essere richiamato, al di fuori del ciclo while abbiamo messo il nodo proprietà value (signaling) della variabile booleana initialize e abbiamo collegato lo stream d'errore al bordo del while in modo da essere sicuri che LabVIEW eseguirà questa operazione prima di passare al loop.

Value signaling

Qui vediamo anche una prima peculiarità della programmazione per eventi. Viene definito value change di una qualsiasi variabile, l'evento in cui questa variabile cambia di valore. Ma, attenzione, questo cambiamento di valore deve essere causato dall'interazione dell'utente con l'applicazione e quindi deve avvenire attraverso il front panel. Assegnare un nuovo valore utilizzando una variabile locale o la proprietà value non genera il corrispondente evento di cambio valore. Se volete programmaticamente generare l'evento dovete utilizzare la proprietà value (signaling). 

Tab control

Sempre all'interno del primo evento troviamo anche l'inizializzazione del tab control, ovvero l'oggetto che sul front panel appare come una menu a diversi fogli visualizzabili singolarmente. L'idea è che solo la prima pagina sia visibile a tutti i livelli di utente, mentre per vedere la seconda dovete essere loggati ad un livello superiore. Nella seconda pagina, solo alcuni controlli sono disponibili per gli utenti esperti, mentre altri sono riservati ai super-user. Chiaramente la vostra applicazione potrebbe essere differente, ma l'idea resta sempre quella.

Nella parte inferiore vedete un ciclo for utilizzato per eseguire le stesse operazioni sui menu, ma ci ritorneremo più avanti quando parleremo appunto dei menu personalizzati.

I pulsanti, i controlli booleani di tipo latch e gli eventi

Il secondo evento, quello dello stop, è di una banalità sconcertante. Viene attivato dalla pressione del tasto stop e non fa nient'altro che interrompere il ciclo while esterno e quindi lasciar terminare l'esecuzione del programma. In questo caso, per il pulsante Stop abbiamo usato l'azione meccanica "Latch when release" ovvero il segnale booleano viene inviato solo quando il tasto viene rilasciato. Questa azione meccanica è molto comoda perché di fatto il pulsante ritorna nella posizione iniziale. Tutti questi latch hanno però un problema nella gestione degli eventi, infatti la proprietà value (signaling) non è disponibile e quindi diventa difficile inviare il segnale da diagramma.

Vedete un esempio di questa difficoltà nel fatto che abbiamo due eventi legati al login. Il primo viene attivato dalla pressione sul tasto Login (evento login button), mentre il secondo è attivato da un segnale non presente direttamente sul pannello chiamato login signal. Il motivo è che vogliamo attivare la procedura di login sia quando l'utente pigia sul tasto apposito sia quando seleziona login dal menu File. Se avessimo un solo evento per entrambe le cose allora dovremmo associare alla selezione dal menu l'emissione del segnale di login, ma essendo questo connesso ad un booleano con azione meccanica di tipo latch non è possibile. Si risolve usando due segnali: la pressione sul pulsante invia il segnale ausiliario che fa partire le operazioni di login. Selezionando dal menu viene subito inviato il segnale ausiliario con il medesimo risultato.

Gli eventi di tipo filtro

Se guardate nella lista degli eventi, noterete che alcuni terminano con un punto di domanda e altri no. I secondi sono gli eventi tradizionali che vengono chiamati quando l'interazione è già stata completata. Per esempio se avete un controllo numerico e ne cambiate il valore da 1 a 10, l'evento corrispondente verrà attivato quando l'utente ha terminato l'operazione e il controllo già segna 10. Se invece cliccate sul bottone con la X in alto a destra sulla finestra per chiuderla, l'evento viene avviato prima che LabVIEW processi l'azione, ovvero chiuda la finestra, in modo che voi potete modificarne il funzionamento. Questa tipologia di eventi prende il nome di filtro, perché vi permette di intromettervi nelle operazioni "normali" per poterle modificare.

L'evento Close Panel? è uno di questo. Collegato alla X di chiusura finestra, potete intercettarlo e fargli fare qualcosa di diverso, come per esempio chiedervi se siete veramente sicuri o robe del genere. Se guardate nell'evento Close Panel? vedrete che è di fatto una copia dello stop, infatti cliccando sulla X mentre l'applicazione è in esecuzione comporta l'arresto della stessa, ma non la chiusura della finestra.

Se volete potete completamente rimuovere qualsiasi azione collegando una costante True al terminale Discard? che vedete sul bordo interno destro dell'evento.

Personalizzare il menu

Passiamo al secondo task di questo mini tutorial, ovvero come personalizzare i menu. Questo è un tocco di stile che renderà la vostra applicazione veramente professionale. Mentre il VI non è in funzione, selezionate Edit e quindi Run-Time Menu come vedete nella finestra qui a lato.

Vi si apre una nuova finestra di dialogo e da qui potete scegliere se utilizzare i menu standard di sistema oppure uno sviluppato ad hoc da voi. Fate un po' di prove, ma vedrete che è assolutamente facile da fare.

Per ogni elemento del menu avrete da inserire due stringhe, una che rappresenta il nome come compare sul menu e, l'altra, il tag, è il nome della variabile corrispondente. Di default le due variabili vengono settate uguali, ma per il tag vi consigliamo di usare nomi facilmente ricordabili.

Quando avrete finito, vi verrà chiesto di salvare il vostro menu e vi suggeriamo vivamente di aggiungerlo al vostro progetto in modo da facilitarne la mobilità.

A questo punto dobbiamo associare una funzione ad ogni menu. Queste operazioni le trovate nell'evento Menu Selection (user) che viene attivato ogni volta che l'utente clicca sul menu o anche semplicemente quando usa una via breve che avete definito. La scritta user tra parentesi serve per differenziare questo evento da quello invece riservato per i menu di sistema (app), dove abbiamo anche la versione con il punto di domanda di cui abbiamo già detto sopra.

All'interno di questo evento dovete definire cosa far fare. Noi abbiamo collegato un case al terminale ItemTag che fornisce appunto la tag dell'elemento di menu selezionato dall'utente. Quando, per esempio, pigiate su Frequency o Amplitude, la vostra applicazione esegue la finestra di dialogo dove vi chiede di inserire i nuovi valori dei parametri.

E le password? 

Tutta la gestione dei livelli di utenza è limitata a due eventi: il current user level e il login signal. Quando l'utente esegue il login o cliccando sul bottone o dal menu, viene mostrata una finestra di dialogo dove vi viene chiesto di autenticare il vostro livello di utenza e di inserire la password corrispondente. Se la password è quella giusta, allora current user level cambia valore e viene di conseguenza eseguito il diagramma contenuto in questo evento.

Anche in questo caso il diagramma è piuttosto semplice e composto principalmente da un case che setta alcuni costanti in modo differente a seconda del livello di utenza. Vedete che ci sono svariate proprietà degli elementi del pannello frontale che vengono abilitate/disabilitate, mentre i due cicli for servono per attivare / disattivare le voci del menu. Questi cicli for sono identici a quelli del foglio initialize di cui vi avevamo parlato prima.

E le password? Ah giusto, vorreste sapere le password... certo che non ve le diciamo! Un premio al primo lettore che le scrive nei commenti. Un consiglio, dovete sfogliare il diagramma di una subVI.

Il front panel

Ma vi rendete conto che fino ad esso abbiamo solo guardato il diagramma, praticamente non curandoci di cosa c'era sul pannello frontale? Significa che questo diagramma di massima vale per tutte le applicazioni e che può facilmente essere adattato alle vostre esigenze specifiche. Però adesso, dateci la soddisfazione di guardare anche il pannello e l'oscilloscopio virtuale!