S C U O L A D I L A B V I E W

TECNICHE COMUNI DI PROGETTAZIONE

Questa lezione discute due differenti categorie di architet-
ture di programmazione: a cicli singoli e multipli. Queste
architetture sono note globalmente come schemi di pro-
gettazione.
Le architetture a ciclo singolo includono schemi di proget-
tazione di VI semplici, generali e di macchine a stati. Le
architetture a cicli multipli includono schemi di progetta-
zione di VI a cicli paralleli, Master/Slave e
Producer/Consumer.
La comprensione di quale sia lo schema di progettazione
migliore la chiave per la realizzazione di VI efficienti in
LabVIEW.
Gli argomenti della lezione saranno descritti secondo la
seguente sequenza:
A. Architetture a ciclo singolo
B. Parallelismo
C. Architetture a pi cicli
D. Temporizzazione di uno schema di progettazione
A. ARCHITETTURE A CICLO SINGOLO
Schemi di progettazione di VI semplici
Quando svolgete calcoli o effettuate misure veloci in labo-
ratorio, non avete bisogno di unarchitettura complicata. Il
vostro programma consiste di un unico VI che effettua
misurazioni, svolge calcoli, visualizza i risultati o li registra
su disco. Lo schema di progettazione di VI semplici non
richiede di solito unazione specifica di start o di stop da
parte dellutente. Lutente clicca semplicemente sul pulsan-
te Run.
Utilizzate questa architettura per semplici applicazioni o
per componenti funzionali nellambito di applicazioni pi
grandi. Potete convertire questi VI semplici in subVI che uti-
lizzate come blocchi componenti di applicazioni pi grandi.
Schemi di progettazione generali di VI
Uno schema di progettazione generale di VI possiede tre
fasi principali.
Ogni fase pu contenere codice che segue un altro tipo di
schema di progettazione. Le tre fasi sono le seguenti:
Inizializzazione - Questa sezione viene utilizzata per ini-
zializzare lhardware, leggere le informazioni di configura-
zione dai file o per richiedere allutente la posizione dei file.
Applicazione principale - Questa sezione in generale con-
siste di almeno un ciclo che viene ripetuto fino a quando
lutente decide di uscire dal programma o il programma si
arresta per altri motivi come il completamento di un I/O.
Chiusura - Questa sezione di solito si occupa di chiude-
re i file, di scrivere le informazioni di configurazione su
disco o di ripristinare lI/O sullo stato di default.
La figura 1 mostra questa architettura generale di VI.
Nella figura 1 il collegamento del cluster di errore control-
la lordine di esecuzione delle tre sezioni. Il While Loop
non viene eseguito finch il VI Start Up non ha finito
lesecuzione e restituisce il cluster di errore. Di conseguen-
za, il VI Shut Down non pu essere eseguito finch il pro-
gramma principale nel While Loop non ha finito e i dati del
cluster di errore non lasciano il ciclo.
La maggior parte dei cicli richiede una funzione Wait, spe-
cialmente se quel ciclo monitora gli ingressi dellutente sul
pannello frontale. Senza la funzione Wait, il ciclo potrebbe
rimanere in esecuzione continuativamente e utilizzare
tutte le risorse di sistema del computer. La funzione Wait
forza il ciclo ad essere eseguito in modalit asincrona
anche se specificate 0 millisecondi come tempo di attesa.
Se le operazioni allinterno del ciclo reagiscono agli ingres-
si dellutente, potreste incrementare il tempo di attesa ad
un livello accettabile per i tempi di reazione. Unattesa di
100 - 200 ms usualmente buona perch la maggior
parte degli utenti non pu rilevare quellentit di ritardo
tra il click su un pulsante del pannello frontale e la conse-
guente esecuzione dellevento.
Per applicazioni semplici, il ciclo dellapplicazione princi-
Potete svi l uppare programmi mi gl i or i i n LabVI EW e i n al t r i l i nguaggi di programmazi one se
segui te tecni che e archi tet t ure di programmazi one consi stent i
Training per principianti
A

c
u
r
a

d
i

M
a
t
t
e
o

F
o
i
n
i
Fi g. 1 - Schema di proget t azi one general e di un VI
10
S C U O L A D I L A B V I E W
pale pu essere abbastanza semplice e contenere codice
che segue lo schema di progettazione di VI semplici.
Quando avete interfacce utente complicate o eventi multi-
pli, come ad esempio azioni dellutente, trigger sullI/O e
cos via, questa sezione pu diventare pi complicata.
Schema di progettazione a macchine a stati
Lo schema di progettazione a macchine a stati una
modifica di uno schema pi generale. Di solito ha una fase
di startup ed una di shut down. Tuttavia la fase dellappli-
cazione principale consiste di una struttura Case inserita
in un ciclo. Questa architettura vi consente di avviare codi-
ce differente ogni volta che il ciclo viene eseguito sulla
base di alcune condizioni. Ogni condizione definisce uno
stato della macchina, da cui il nome, macchina a stati.
Utilizzate questo modello di progettazione per VI che sono
facilmente divisibili in compiti pi semplici, come i VI che
agiscono come interfaccia utente.
Una macchina a stati in LabVIEW consiste di un While
Loop, una struttura Case e un registro a scorrimento. Ogni
stato della macchina a stati una condizione nella strut-
tura Case. Inserite i VI e altro codice che volete eseguire
nella condizione corretta. Un registro a scorrimento
memorizza lo stato da eseguire fino alliterazione succes-
siva del ciclo.
Lo schema a blocchi di un VI a macchina a cinque stati
mostrato nella figura 2. La figura 3 mostra i casi nascosti,
o condizioni, della macchina a stati.
In questa architettura, progettate lelenco dei possibili
eventi, o stati, e quindi mappateli ognuno su una condi-
zione. Per il VI dello schema a blocchi in figura 2, gli stati
possibili sono Startup, Idle, Event 1, Event 2 e Shutdown.
Questi stati sono memorizzati in una costante di tipo enu-
merated. Ogni stato ha la sua condizione nella struttura
Case. Mentre una condizione in esecuzione, lo stato suc-
cessivo viene determinato sulla base del risultato corren-
te. Lo stato successivo viene memorizzato nel registro a
scorrimento. In caso di errore in uno degli stati, viene
richiamata la condizione shutdown.
Il vantaggio dellarchitettura con macchine a stati che lo
schema a blocchi pu diventare molto pi piccolo, ren-
dendone pi facile la lettura e la correzione. Un altro van-
taggio dellarchitettura con macchine a stati che ogni
condizione determina lo stato successivo, diversamente
dalle strutture Sequence che non possono saltare un
frame.
Uno svantaggio dellarchitettura con macchine a stati
che con questo approccio potete perdere degli eventi. Se
due eventi si presentano nello stesso istante, questo
modello gestisce il primo e perde il secondo. Ci pu con-
durre ad errori che sono difficili da correggere perch pos-
sono presentarsi solo occasionalmente. Versioni pi com-
plesse dei VI con architettura con macchine a stati con-
tengono codice aggiuntivo che realizza una coda di even-
ti con lo scopo di non perderli.
B. PARALLELISMO
Il parallelismo un modo di eseguire compiti in
parallelo nello stesso istante. Per discutere il paralle-
lismo, considerate lesempio della creazione e visua-
lizzazione di due sinusoidi a differenti frequenze.
Inserite una sinusoide in un ciclo e la seconda in un
ciclo differente.
Una sfida nella programmazione di compiti in paral-
lelo quella di passare dati tra pi cicli senza creare
una dipendenza tra i dati. Per esempio, se passate i
dati utilizzando un collegamento, i cicli non sono pi
in parallelo. Nellesempio di pi sinusoidi, potete
voler condividere un singolo pulsante di stop tra i
cicli, come mostrato nella figura 4.
Esaminate che cosa accade quando provate a condi-
videre dati tra cicli in parallelo con un collegamento.
Fi g. 3 - St at i I dl e ( Def aul t ) , Event 1, Event 2 e Shutdown
Fi g. 4 - Pannel l o f ront al e dei ci cl i i n paral l el o
Fi g. 2 - Macchi na a st at i con st ato di St ar t up
10
S C U O L A D I L A B V I E W
Metodo 1 (sbagliato)
Inserite il terminale Loop Control al di fuori di entrambi i
cicli e collegatelo a ciascun terminale condizionale, come
mostrato in figura 5. Lo stato del controllo booleano un
dato in ingresso per entrambi i cicli, quindi il terminale
Loop Control viene letto solo una volta, prima dellesecu-
zione dei While Loop. Se viene passato TRUE ai cicli, i
While Loop rimarranno in esecuzione indefinitamente.
Disattivando il selettore non si arresta il VI perch il selet-
tore non viene letto durante literazione di ciascun ciclo.
Metodo 2 (sbagliato)
Spostate il terminale Loop Control allinterno del Loop 1
affinch venga letto ad ogni iterazione del Loop 1, come
mostrato nello schema a blocchi di figura 6. Sebbene il
Loop 1 termini correttamente, il Loop 2 non va in esecu-
zione finch non riceve tutti i suoi dati dingresso. Il Loop
1 non passa dati al di fuori del ciclo fino a quando si arre-
sta, quindi il Loop 2 deve aspettare il valore finale di Loop
Control, disponibile solo quando Loop 1 termina. Quindi i
cicli non vengono eseguiti in parallelo. Inoltre, il Loop 2
viene eseguito solo per uniterazione perch il suo termi-
nale condizionale riceve un valore False dal selettore Loop
Control nel Loop 1.
Soluzione
Se potete leggere il pulsante di stop da un file, non avre-
te pi bisogno di avere una dipendenza di flusso dei dati
tra i cicli, dato che ogni ciclo pu accedere al file indipen-
dentemente. Tuttavia, la lettura e scrittura di file pu
richiedere tempo, parlando sempre rispetto ai tempi propri
del processore. Un altro modo di svolgere questo compito
di trovare il punto in memoria in cui il pulsante di stop
memorizzato e leggere quella locazione di memoria diret-
tamente.
C. ARCHITETTURE A PI CICLI
Modello di progettazione a cicli paralleli
Alcune applicazioni richiedono che il programma rispon-
da ed avvii diversi compiti contemporaneamente. Un
modo di progettare la sezione principale di questa appli-
cazione di assegnare un ciclo differente per ogni com-
pito. Per esempio, potreste avere un ciclo differente per
ogni pulsante sul pannello frontale e per ogni altro gene-
re di compito, come una selezione di menu, sincronizza-
zione di I/O e cos via. La figura 7 mostra questo model-
lo di progettazione a cicli paralleli.
Questa struttura semplice e adatta per VI a menu sem-
plici, in cui vi aspettate che un utente scelga tra uno di
diversi pulsanti che svolgono azioni differenti. Il modello
di progettazione a cicli paralleli vi consente di gestire pi
compiti, indipendenti e contemporanei. In questo model-
lo di progettazione, la risposta ad unazione non impedi-
sce al VI di rispondere ad unaltra azione. Per esempio, se
un utente clicca su un pulsante che visualizza una fine-
stra di dialogo, i cicli paralleli possono continuare a
rispondere a compiti di I/O.
Tuttavia, con il modello di progettazione a cicli paralleli
dovete coordinare e far comunicare cicli differenti. Il pul-
sante di Stop per il secondo ciclo di figura 7 una varia-
bile locale. Non potete utilizzare collegamenti per passa-
re dati tra i cicli perch cos facendo si impedisce ai cicli
Fi g. 5 - Esempi o del Metodo 1 con ci cl i i n paral l el o
Fi g. 6 - Esempi o del Metodo 2 con ci cl i i n paral l el o
Fi g. 7 - Model l o di proget t azi one a ci cl i paral l el i
S C U O L A D I L A B V I E W
lesecuzione in parallelo. Invece dovete utilizzare tecniche
specifiche per passare informazioni tra i processi.
Modello di progettazione Master/Slave
Il modello di progettazione Master/Slave consiste di pi
cicli in parallelo. Ogni ciclo pu eseguire compiti a diffe-
renti velocit. Un ciclo agisce come master e gli altri cicli
come slave. Il ciclo master controlla tutti i cicli slave e
comunica con loro utilizzando tecniche di trasferimento
dati, come mostrato in figura 8.
Utilizzate il modello di progettazione Master/Slave quan-
do avete bisogno che un VI risponda ai controlli dellinter-
faccia utente mentre contemporaneamente raccoglie
dati. Per esempio, volete costruire un VI che misuri e
memorizzi una tensione variabile lentamente una volta
ogni cinque secondi. Il VI acquisisce una forma donda da
una linea di trasmissione e la visualizza su un grafico
ogni 100 ms. Il VI fornisce anche uninterfaccia utente
che consente allutente di cambiare i parametri per ogni
acquisizione. Il modello di progettazione Master/Slave si
adatta bene a questa applicazione di acquisizione. Il ciclo
master contiene linterfaccia utente; lacquisizione di
tensione avviene in un ciclo slave e la gestione della
parte grafica avviene in un altro ciclo slave.
Utilizzando un approccio Master/Slave per questo VI,
dovreste mettere i processi di acquisizione in due While
Loop separati, entrambi guidati da un ciclo master che
riceve gli ingressi dai controlli dellinterfaccia utente.
Questo garantisce che i processi di acquisizione separati
non si influenzino lun laltro e che ogni ritardo causato
dallinterfaccia utente, come la visualizzazione di una
finestra di dialogo, non ritardi una qualsiasi iterazione
dei processi di acquisizione.
Anche i VI che includono un controllo beneficiano dellu-
so di modelli di progettazione Master/Slave. Considerate
un VI in cui un utente controlla un braccio robotizzato a
moto libero uilizzando i pulsanti su un pannello frontale.
Questo tipo di VI richiede un controllo efficiente, accura-
to e reattivo a causa dei danni fisici che possono essere
causati al braccio o allambiente circostante in caso di
controllo gestito male.
Per esempio, se lutente istruisce il braccio affinch si
arresti nel suo moto verso il basso, ma il programma
occupato con il controllo del perno del braccio, il braccio
robotizzato pu collidere con la piattaforma del suppor-
to.
Applicate il modello di progettazione Master/Slave
allapplicazione per evitare questi problemi. In questo
caso il ciclo master gestisce linterfaccia
utente e ogni sezione controllabile del
braccio robotizzato ha il proprio ciclo
slave. Siccome ogni sezione controllabile
del braccio ha il proprio ciclo e la sua
parte di tempo di elaborazione,
linterfaccia utente ha un controllo pi
reattivo del braccio robotizzato.
Con un modello di progettazione
Master/Slave, importante che i due
While Loop non scrivano sugli stessi dati
condivisi. Assicuratevi che non pi di un
While Loop possa scrivere su una data
porzione di dati condivisi.
Lo slave non deve impiegare troppo nel
rispondere al master. Se lo slave sta elaborando un
segnale proveniente dal master e il master invia pi di un
messaggio allo slave, lo slave riceve solo lultimo mes-
saggio. Questo uso dellarchitettura Master/Slave
potrebbe portare ad una perdita di dati.
Utilizzate unarchitettura Master/Slave solo se siete certi
che ogni task dello slave impieghi meno tempo del ciclo
del master.
Modello di progettazione Producer/Consumer
Il modello di progettazione Producer/Consumer si basa
sul modello Master/Slave e migliora lo scambio dati tra
pi cicli in esecuzione a differenti velocit. Simile al
modello Master/Slave, il modello di progettazione
Producer/Consumer separa compiti che producono e usano
i dati a differenti velocit. I cicli in parallelo nel modello di
progettazione Producer/Consumer sono separati in due
categorie: quelli che producono i dati e quelli che usano i
dati prodotti. Le code di dati comunicano i dati tra i cicli. Le
code di dati bufferizzano anche i dati tra il ciclo Producer e
quello Consumer.
Suggerimento
Un buffer un dispositivo della memoria che memorizza
dati temporanei tra i due dispositivi, o in questo caso, tra
pi cicli.
Utilizzate il modello di progettazione Producer/Consumer
quando dovete acquisire pi insiemi di dati che devono
Fi g. 8 - Model l o di proget t azi one Master /Sl ave
10
S C U O L A D I L A B V I E W
essere processati in ordine.
Supponete di voler realizzare un VI che accetta dati men-
tre sta processando gli insiemi di dati nellordine in cui
sono stati ricevuti. Il modello di progettazione
Producer/Consumer ideale per questo tipo di VI perch
la formazione delle code di dati avviene molto pi rapida-
mente di quanto i dati possano essere processati (usati).
Potreste mettere il Producer e il Consumer nello stesso
ciclo per questa applicazione, ma la coda di elaborazione
potrebbe non aggiungere ulteriori dati fino a quando la
prima parte dei dati non stata completamente elabora-
ta. Lapproccio Producer/Consumer per questo VI mette in
coda i dati nel ciclo Producer e processa i dati nel ciclo
Consumer come mostrato in figura 9.
Questo modello di progettazione consente al ciclo
Consumer di processare i dati alla sua andatura, mentre il
ciclo Producer continua a mettere in coda dati aggiuntivi.
Potete anche utilizzare questo modello di progettazione
per creare un VI che analizza la comunicazione di rete.
Questo tipo di VI richiede due processi che funzionano
contemporaneamente a differenti velocit. Il primo pro-
cesso interroga costantemente la linea della rete e recu-
pera pacchetti. Il secondo processo analizza i pacchetti
recuperati dal primo processo.
In questo esempio, il primo processo agisce come Producer
perch fornisce dati al secondo processo, che agisce come
Consumer. Il modello di progettazione Producer/Consumer
unarchitettura efficiente per questo VI. I cicli paralleli
Producer e Consumer gestiscono il recupero e lanalisi dei
dati off line e la comunicazione in coda tra i cicli consen-
te la bufferizzazione di pacchetti di rete recuperati. La buf-
ferizzazione pu diventare importante quando la comuni-
cazione con la rete occupata.
Con la bufferizzazione i pacchetti possono essere recupe-
rati e comunicati pi velocemente di quanto possano esse-
re analizzati.
D. TEMPORIZZAZIONE DI UN MODELLO
DI PROGETTAZIONE
Questa sessione discute due forme di temporizzazione: la
temporizzazione dellesecuzione e la temporizzazione a
controllo software. La temporizzazione dellesecuzione
utilizza funzioni di temporizzazione per fornire al proces-
sore tempo per completare altri compiti. La temporizzazio-
ne a controllo software riguarda la temporizzazione di
unoperazione reale da svolgere entro un periodo di
tempo prefissato.
Temporizzazione dellesecuzione
Potete temporizzare un modello di progettazione esplici-
tamente o sulla base di eventi che accadono nel VI. La
temporizzazione esplicita fornisce al modello di progetta-
zione una funzione che fornisce specificatamente al pro-
cessore il tempo di completare altri task, come la funzione
Wait Until Next ms Multiple. Quando la temporizzazione
basata sugli eventi, il modello di progettazione rimane in
attesa di azioni che devono avvenire prima di continuare e
consente al processore di completare altri compiti mentre
in attesa.
Utilizzate la temporizzazione esplicita per modelli di pro-
gettazione come Master/Slave, Producer/Consumer e mac-
chine a stati. Questi modelli di progettazione effettuano
una forma di polling mentre sono in esecuzione.
Suggerimento
Il polling il processo che effettua continue richieste di
dati ad un altro dispositivo. In LabVIEW, questo significa
generalmente che lo schema a blocchi richiede continua-
mente se ci sono dati disponibili, di solito dallinterfaccia
utente.
Per esempio, il modello di progettazione Master/Slave
mostrato in figura 10 utilizza un While Loop e una strut-
tura Case per implementare il ciclo master. Il master
sempre in esecuzione e rimane in attesa di un evento di
qualsiasi tipo, come la pressione di un pulsante da parte
dellutente. Nel caso si presenti un evento, il master invia
un messaggio allo slave. Avete bisogno di temporizzare il
master affinch non prenda il controllo sullesecuzione del
processore. In questo caso, utilizzate tipicamente la fun-
zione Wait (ms) per regolare quanto frequentemente il
master deve effettuare il polling. Utilizzate sempre una
funzione di temporizzazione come la funzione Wait (ms) o
Wait Until Next ms Multiple in ogni modello di progetta-
zione sempre in esecuzione con necessit di regolazione.
Se non usate una funzione di temporizzazione in una
struttura sempre in esecuzione, LabVIEW utilizza tutto il
tempo del processore e i processi in background non
possono essere eseguiti.
Fi g. 9 - Model l o di proget t azi one Producer /Consumer
S C U O L A D I L A B V I E W
Osservate che il ciclo slave non contiene alcuna forma di
temporizzazione. Luso delle funzioni di sincronizzazione,
come Queues e Notifiers, per passare messaggi fornisce
una forma intrinseca di temporizzazione nel ciclo slave. Il
ciclo slave attende che la funzione Notifier riceva un mes-
saggio. Dopo che Notifier ha ricevuto il messaggio, lo
slave esegue le operazioni sul messaggio. Ci crea uno
schema a blocchi efficiente che non spreca cicli di proces-
sore nel polling di messaggi.
Questo un esempio di temporizzazione mediante lattesa
di un evento.
Quando implementate modelli di progettazione in cui la tem-
porizzazione basata sul verificarsi di eventi, non dovete
determinare la corretta frequenza di temporizzazione perch
lesecuzione del modello di progettazione avviene solo in caso
di evento. In altre parole, il modello di progettazione entra in
esecuzione solo quando riceve un evento.
Temporizzazione a controllo software
Molte applicazioni che create devono eseguire unoperazione
per un determinato intervallo di tempo. Considerate
limplementazione di un modello di progettazione con mac-
chine a stati per un sistema di acquisizione della temperatura.
Se le specifiche richiedono che il sistema acquisisca tempera-
ture per 5 minuti, potreste rimanere nello stato di acquisizio-
ne fino a quando sono passati i 5 minuti. Tuttavia, durante
quel tempo non potete processare una qualsiasi azione del-
linterfaccia utente, come larresto del VI.
Per processare queste azioni dellinterfaccia utente, dovete
implementare la temporizzazione affinch il VI continui
lesecuzione per il tempo specificato. Limplementazione di
questa temporizzazione include il mantenimento dellesecuzio-
ne dellapplicazione mentre monitora un clock in tempo reale.
In figura 11 trovate un esempio di temporizzazione a control-
lo software per monitorare lo scorrere del tempo fino allac-
quisizione del gruppo successivo di dati da parte del VI.
Osservate luso del VI Express Elapsed Time per mantenere
traccia del clock.
Se utilizzate la funzione Wait (ms) o Wait Until next ms
Multiple per effettuare la temporizzazione software, la funzio-
ne di attesa deve finire prima che la funzione che state tem-
porizzando possa essere eseguita.
Queste funzioni non sono il metodo preferito per
limplementazione della temporizzazione a controllo software,
specialmente per VI in cui il sistema deve continuamente stare
in esecuzione. Un buon modello da utilizzare per la temporiz-
zazione di far ciclare il tempo corrente attraverso il VI, come
mostrato in figura 12.
La funzione Get Date/Time In Seconds, collegata al terminale sini-
stro del registro a scorrimento, inizializza il registro a scorrimen-
to con il tempo corrente del sistema. Ogni stato utilizza unaltra
funzione Get Date/Time In Seconds e confronta il tempo corren-
te con quello iniziale. Se la differenza tra questi due tempi supe-
riore o uguale al tempo di attesa, lo stato completa lesecuzione
e il resto dellapplicazione viene eseguita.
Utilizzate sempre la funzione Get Date/Time In Seconds inve-
ce della funzione Tick Count per questo tipo di confronto per-
ch il valore della funzione Tick Count pu ritornare a 0 duran-
te lesecuzione.
Fi g. 10 - Model l o di proget t azi one Master /Sl ave
Fi g. 11 - Ut i l i zzo del VI El apsed Ti me Express
Fi g. 12 - Tempor i zzazi one sof t ware che ut i l i zza l a f unzi one
Get Date/Ti me I n Seconds
R
e
a
d
e
r
s
e
r
v
i
c
e
.
i
t

n
.

1
0
2
4