[LabVIEW] Come ottimizzare la Top Level Application

Ho avuto il mio primo incontro/scontro con LabVIEW, il linguaggio di programmazione visuale di National Instruments quando ero ancora all'università. All'epoca ero troppo interessato a far funzionare le cose e troppo poco istruito in programmazione per farmi troppo domande e cercare di ottimizzare le cose. Da allora, più o meno da vicino, ho sempre avuto a che fare con i VI (virtual instruments) ovvero i programmi e adesso tornerò a farne un uso pesante.

A differenza di allora, adesso oltre che a funzionare, mi piace cercare di ottimizzare i miei programmi per evitare di avere del codice che divora risorse come uno squalo senza restituire nulla in cambio. Man mano che trovo qualche cosa di utile, cercherò di scriverla qui in un post, non aspettatevi un vero e proprio tutorial o un corso di LabVIEW, ma più semplicemente una collezione di informazioni che spero vi possano essere utili come lo sono state a me.

Finita l'introduzione, veniamo al discorso di oggi. Ottimizzare l'esecuzione della top level application, ovvero come utilizzare gli eventi.

La prima volta che avete scritto un VI, avete preso un semplice operatore matematico, diciamo la somma collegati due controlli agli ingressi e un indicatore in uscita, tutto qui. La delusione sarà comparsa sui vostri occhi quando l'avete eseguita per la prima volta, infatti appena il tasto run, l'applicazione sarà già finita senza lasciarvi nemmeno il tempo di inserire i numeri da sommare. Allora siete tornati al diagramma e avete rinchiuso il tutto all'interno di un ciclo while con l'intento di tenere l'applicazione sempre attiva. Alla condizione di uscita avete connesso un controllo booleano sottoforma di pulsante sul pannello frontale in modo da poter terminare l'esecuzione (il diagramma è quello nell'immagine qui a lato). Funziona? Certo che funziona, il vostro pc continuerà a ripetere le operazioni all'interno del ciclo while e anche se voi non riuscite a vederlo, il computer continuerà a calcolare la somma anche quando non cambia nulla.

A vista non cambia nulla, se andate a vedere le risorse del vostro PC, in particolare l'utilizzo della CPU, noterete che nonostante l'interfaccia grafica non stia cambiando il computer resta impegnato a fare e rifare gli stessi conti. Se prendete il manuale di LabVIEW, troverete una "soluzione" per questo abuso di risorse: aggiungete un ritardo nel ciclo (icona orologio). In questo modo tra un'esecuzione e l'altra, il PC tira un sospiro di x ms - 100 nel diagramma qui a lato - così che l'utente continua a vedere i conti fatti in tempo reale senza uccidere troppo la CPU. Qui sorgono le prime domande: è 100 ms il ritardo giusto? vale per tutti i processori? non si può ottimizzare?

Ottimizziamo

Se il calcolo lo doveste fare voi a mente, come fareste? Di certo non continuerei a rifare i conti che ho già fatto, ma solo quando uno dei due input viene modificato. La parola magica è evento: eseguiamo le operazioni solo quando avviene una certa condizione, come nel caso specifico quando viene cambiato il valore di un controllo. Questa è sicuramente la soluzione ottimizzata, perché indipendentemente dalle altre condizioni, il vostro codice verrà eseguito solo quando serve.

Si può fare? Certo che si può. Non è una prerogativa di LabVIEW, anzi in genere è una caratteristica di tutti le librerie che permettono di sviluppare interfacce grafiche. Per esempio, all'interno delle librerie Qt, questo meccanismo si chiama Signals & Slots, infatti ogni volta che l'utente interagisce con l'interfaccia grafica - diciamo preme un tasto o cambia un numero - quell'elemento emette un segnale particolare che può venire captato da qualche ricevente (slot) che agisce di conseguenza.

Nel caso di LabVIEW si deve utilizzare l'event structure che è particolarmente simile a quella di un case perché ci sono diversi fogli, uno per ogni evento e ciascuno di essi contiene il codice che deve essere eseguito in ciascuno caso.

Quali eventi?

Adesso arriva la parte difficile, se così si può dire. Dobbiamo individuare tutti gli eventi a cui siamo interessati. Nella nostra semplice applicazione dobbiamo tenere sotto controllo due eventi:

1. Quando uno dei due controlli che corrispondono agli addendi della nostra somma cambia di valore
2. Quando l'utente clicca sul pulsante stop, che anche in questo caso possiamo ricondurre ad un cambio di valore del terminale booleano corrispondente. 

Ecco qui sotto come cambia il nostro diagramma con le due pagine dell'event structure. 

La struttura è simile a quella della versione sopra, c'è un ciclo while che circonda l'intera applicazione che contiene la struttura per eventi che ha due casi, quello di sinistra viene attivato quando il valore del booleano stop cambia, con il risultato di trasferire all'esterno della struttura il suo valore. Il secondo foglio è quello eseguito ogni volta che cambia il valore di x o y, ovvero i due input della somma.

Adesso che ho stimolato la vostra curiosità, andate a vedere tutti i dettagli della struttura per eventi nella documentazione e se volete potete scaricare il vi contenente la versione ad eventi della Top Level Application.

---

TopLevel With Event Structure.vi (22.5 kB)