Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
04
E 5,00 L A P R I M A R I V I S TA I TA L I A N A P E R L A CO M U N I T L A BV I E W
NOVEMBRE
2007
In caso di mancata consegna restituire alleditore che si impegna a pagare la relativa tassa presso il CMP di Roserio - Milano
SCENARIO
04
INTERNAZIONALE
D
opo oltre un anno di vita, proviamo a tracciare un bilancio del magazine che state sfogliando. Vorremmo soffermarci, in particolare, su un aspetto che riteniamo fondamentale: quello della crescente internazionalizzazione di LabVIEW World. Come noto, una critica spesso rivolta ai nostri media nazionali (sia su carta che via etere) quella della scarsa presenza allestero. Spesso, i servizi dalle zone calde del mondo vengono tradotti utilizzando i testi di agenzie o addirittura riprendendo e adattando il lavoro di colleghi inviati dai grandi editori che possono permettersi rimborsi spese molto consistenti. Quindi, fra la fonte della notizia ed il suo fruitore (lettore, ascoltatore o spettatore) esistono numerosi filtri, che tendono per natura a distorcere il contenuto iniziale. Nel nostro piccolo, cerchiamo di eliminare il pi possibile questi filtri, mettendoci direttamente in contatto con le fonti e, molto spesso, recandoci direttamente sul posto. In questo numero, gli esempi sono numerosi. Nella rubrica A tu per tu riportata unintervista con Kamran Shah, che abbiamo incontrato di persona durante NIWeek 2007. E, naturalmente, anche il Report dedicato a NIWeek 2007 stato scritto dopo avere partecipato allevento e avere sentito Truchard, Kodosky, Anderson e tanti altri illustrarci il senso degli annunci forniti agli oltre 2.000 presenti. Durante NIWeek, poi, abbiamo distribuito LabVIEW World, ottenendo numerose manifestazioni dinteresse. Interesse che si tradurr concretamente in una serie di articoli scritti da autori stranieri (e non solo tradotti, come spesso accade). Iniziamo questo mese con un contributo di Jan Klasson di Endevo, un NI Alliance Member svedese. Proseguiremo in futuro con altri interventi dello stesso calibro. Che cosa significa tutto ci? Per noi, naturalmente, significa un importante riconoscimento dalla comunit NI internazionale. Per i nostri lettori, significa poter contare su informazioni di prima mano, non riciclate, provenienti in larga misura dai luoghi di ricerca e sviluppo NI deputati (Austin, in prima istanza, ma anche Milano, Roma, Stoccolma o Parigi, quando avremo qualche novit importante da comunicare). E questa tendenza in crescita. Sappiamo che esiste linteresse per edizioni locali di LabVIEW World in varie parti del pianeta, ma finora quella italiana lunica lingua nella quale i lettori possono trovare articoli, interviste e news su LabVIEW e dintorni. Non poco, se si considerano i numeri a confronto, se si paragona la massa enorme dei lettori anglofoni con i relativamente pochi lettori di lingua italiana. Il nostro impegno quello di proseguire su questa strada. Con il vostro aiuto, naturalmente!
SOMMARIO
04
39 REPORT
42 APPUNTAMENTI 43
INTERVISTA
Oltre ad organizzare propri corsi e seminari, National Instruments sar presente a numerosi eventi
18 LA RICERCA DELLECCELLENZA
Un innovativo sistema per il test in ambiente automotive con tecnologia National Instruments
Federico Van der Velden di Siram ci racconta la sua esperienza con i corsi di formazione LabVIEW
21 IL DEBUG DI VI - PARTE II
46 LABVIEW E LAVORO
AAA
A TU PER TU
04
Lo abbiamo annunciato nel numero di Settembre: la nuova versione 8.5 di LabVIEW stata progettata per sfruttare in modo ottimale la potenza dei processori multicore
N
R:
el corso di NIWeek 2007 abbiamo incontrato Kamran Shah, Group Manager LabVIEW Marketing presso National Instruments, che ci ha spiegato limportanza delle nuove caratteristiche di LabVIEW 8.5. In particolare, di quelle che permettono di sviluppare applicazioni in parallel processing su architetture multicore.
Multicore pocessing e parallel processing: D: che cosa ci pu dire circa limportanza di queste novit?
La settimana di NIWeek sempre molto interessante per noi e per i nostri utenti, e queste novit lo dimostrano ancora una volta. Partiamo dal multicore processing: che cosa cambia rispetto a prima? Il multicore processing porta nuovi chip nei PC che utilizziamo tutti i giorni, mettendoci a disposizione la potenza di pi processori. National Instruments si posta lobiettivo di consentire ai propri utenti di sfruttare pienamente questa potenza nelle loro applicazioni, utilizzando LabVIEW con tecniche di programmazione parallela. Come sappiamo, le innovazioni apportate nella tecnologia dei processori si sono tradotte classicamente in CPU con frequenze di clock sempre pi elevate. Ma, con lavvicinarsi di tali frequenze al loro limite fisico teorico, sono stati sviluppati nuovi processori con pi core di elaborazione, anzich uno solo. In sostanza, se prima si cercava di avere PC con CPU sempre pi veloci pensando che ci avrebbe automaticamente reso pi veloci anche le applicazioni, ora non pi cos. I nuovi PC hanno precisi requisiti in termini di assorbimento di potenza e dissipazione di calore, quindi non pi possibile aumentare oltre certi limiti la velocit della CPU. Ecco perch i produttori di microprocessori stanno mettendo pi core CPU nei nuovi prodotti: per aumentare le prestazioni, il trucco quello di fare pi cose contemporaneamente.
Esiste infatti un problema di sviluppo, proprio perch tradizionalmente si pensano le nuove applicazioni secondo uno schema di operazioni sequenziali, dove unistruzione viene eseguita dopo listruzione precedente. Ora, le istruzioni devono essere invece eseguite in parallelo. E la classica architettura di Von Neumann appare superata per questo nuovo tipo di approccio. Daltra parte, il concetto alla base dello sviluppo di applicazioni che possano essere eseguite su architetture multicore non nuovo. Gi diversi anni fa, sui supercomputer le applicazioni venivano sviluppate in parallelo, ma era richiesto un livello molto elevato di esperienza e conoscenza. Oggi, a seguito dellaumento di velocit dei chip ed al conseguente incremento di prestazioni offerte dallhardware, non possiamo tuttavia fare a meno dellapproccio parallelo. Quindi, il primo problema questo: come possono i linguaggi di programmazione utilizzare meglio le architetture multicore, permettendoci di sviluppare facilmente applicazioni eseguite in parallelo senza loverhead e la complessit che in origine caratterizzavano queste tecniche? Programmare applicazioni in grado di sfruttare tecnologie hardware parallele
R:
Ma la migrazione a processori multicore e la D: programmazione parallela non pongono qualche nuovo problema, dato che le applicazioni vengono generalmente sviluppate in modo sequenziale?
Kamran Shah e Valerio Alessandroni
A TU PER TU
04
rappresenta una grande sfida in campo informatico. Ma gli sviluppatori di LabVIEW hanno creato un ambiente di programmazione ideale per i processori multicore: infatti, LabVIEW 8.5 offre un ambiente intuitivo per creare algoritmi paralleli e pu assegnare dinamicamente thread multipli a una data applicazione. Il linguaggio a flusso di dati parallelo di LabVIEW permette di mappare facilmente le applicazioni su architetture multicore e Fpga per data streaming, controllo, analisi ed elaborazione dei segnali, ecc.
Ci significa che National Instruments intenD: de in qualche modo nascondere sotto il cofano la complessit della programmazione parallela su architetture multicore offrendo allutente LabVIEW la semplice interfaccia grafica a cui gi abituato?
Certamente. Nove anni fa, National Instruments ha introdotto la versione LabVIEW 5, che per la prima volta utilizzava il concetto di multithreading. Se osserviamo i tradizionali linguaggi di programmazione, il codice ancora sequenziale ed difficile avere una visione parallela delle operazioni. Ma LabVIEW un linguaggio grafico, a flusso di dati, e questo permette intrinsecamente una sincronizzazione dei dati lungo thread diversi. Se si prende un filo che esce da un VI, lo si divide in due e si fanno entrare le due parti risultanti in due blocchi di processo, in modo che questi dipendano dallo stesso dato a monte, abbiamo realizzato unesecuzione parallela. Ci elimina in gran parte la necessit di preoccuparsi circa la programmazione parallela e le architetture multicore. Infatti, LabVIEW ha capacit intrinseche di programmazione multithreading e sincronizzazione dei thread, offrendo agli sviluppatori tool di alto livello che permettono unastrazione rispetto a quanto accade ai livelli pi bassi. E non dimentichiamo che qualsiasi applicazione in cui si acquisiscono ed elaborano o memorizzano grandi quantit di dati ad elevata velocit, come la progettazione ed il collaudo di protocolli di comunicazione o lelaborazione audio/video, pu raggiungere prestazioni pi elevate grazie alla tecnologia multicore.
R:
ti. In particolare, lacquisizione dei dati da pi canali deve essere eseguita in parallelo, quindi occorrono driver in grado di portare a termine lacquisizione parallela sullhardware disponibile. I bus interni, poi, devono eseguire lo streaming dei dati acquisiti in parallelo. I nostri driver sono progettati per rispondere a queste esigenze e, su bus come il PCI Express, disponiamo di una banda dedicata per ciascuna scheda; quindi possibile eseguire lo streaming dei dati acquisiti in parallelo, portarli alle applicazioni ed eseguire veloci operazioni parallele su pi core. Quando occorre acquisire ed analizzare un flusso di dati, molto spesso lelaborazione dei dati stessi pu rappresentare una strozzatura Suddividendo lapplicazione in due loop paralleli (acquisizione ed analisisi) su un sistema dual-core, o in pi loop (acquisizione, analisi e memorizzazione dei dati) su un sistema multicore, si pu ottenere un throughput pi veloce, attraverso il pipelining. Dividendo il carico fra i processori disponibili, possibile acquisire ed elaborare i dati in parallelo, pi velocemente di quanto si otterrebbe con unelaborazione seriale tradizionale. In altre applicazioni, come i sistemi di controllo ad alta velocit, pu essere necessario separare il codice time-critical da altro codice meno importante di comunicazione o di I/O di file. Usando un sistema multicore, possibile isolare le parti time-critical del proprio codice su un core di elaborazione separato dal resto dellapplicazione, per maggiori affidabilit e prestazioni. Oggi, National Instruments mette pertanto a disposizione lhardware, il software di programmazione grafica, le librerie e le routine avanzate richiesti dal nuovo approccio della programmazione parallela su piattaforme multicore.
A queste capacit contribuiscono anche il D: parallelismo intrinseco di LabVIEW e la sua capacit di esecuzione multithread?
Sicuramente. Se consideriamo uno schema a blocchi LabVIEW, possiamo vedere come il compilatore LabVIEW suddivide lapplicazione in thread secondo un approccio parallelo. Utilizzando LabVIEW, si possono quindi costruire soluzioni parallele in modo naturale, usando tecniche, come quella dello schemi a blocchi, che sono note a tutti i programmatori. Gli utenti LabVIEW traggono automaticamente vantaggio da questo parallelismo quando sviluppano le loro applicazioni, senza nemmeno rendersene conto. Quindi, nella maggior parte dei casi, possibile aspettarsi dei miglioramenti di prestazioni trasferendo le proprie applicazioni LabVIEW su macchine multicore. Grazie al parallelismo intrinseco del flusso di dati in LabVIEW, possibile implementare facilmente applicazioni su architetture multicore ed FPGA per il trasferimento di dati, il controllo, lanalisi e lelaborazione dei segnali. Basato sulle funzionalit di multithread automatico delle
R:
Come viene risolto il problema di integrazioD: ne degli I/O nelle applicazioni parallele su architetture multicore?
Questo aspetto molto interessante. Partiamo da un esempio. Se per tutta la vita avessi programmato frattali, non dovrei preoccuparmi degli I/O, perch i frattali sono oggetti puramente matematici e il nuovo approccio della programmazione parallela non porrebbe particolari difficolt. Nelle applicazioni di misura, tuttavia, le applicazioni parallele su sistemi multicore possono offrire incrementi di prestazioni davvero significativi. Ma ci pone alcuni requisi-
R:
A TU PER TU
versioni precedenti, LabVIEW 8.5 in grado di adattare lesecuzione delle applicazioni in base al numero totale di core disponibili ed dotato di driver e librerie thread-safe ad elevate prestazioni per migliorare le applicazioni RF, di I/O digitali ad alta velocit e di test a segnale misto.
In LabVIEW 8.5 stato introdotto anche lo D: Statechart Module. Qual limportanza di questa novit?
Se osserviamo le ultime versioni di LabVIEW, possiamo notare lo sforzo che National Instruments sta facendo per ottenere una rappresentazione sempre pi ad alto livello delle applicazioni (pensiamo, per esempio, alla possibilit di utilizzare MathScript introdotta nella versione LabVIEW 8.21 per rappresentare algoritmi matematici in forma testuale nel codice grafico). Il LabVIEW Statechart Module ha permesso di compiere un importante passo avanti in questa direzione. Si tratta infatti di un nuovo addon che permette di progettare le applicazioni utilizzando diagrammi ad alto livello basati sullo standard UML (Unified Modeling Language). Gli statechart sono normalmente utilizzati per progettare macchine di stato in grado di sviluppare il funzionamento dei sistemi embedded e realtime per descrivere le occorrenze eventi e le risposte per la progettazione dei protocolli di comunicazione digitali, i controller delle macchine e applicazioni fault-handling. Quando iniziamo a descrivere un processo di controllo, normalmente utilizziamo una serie di stati e di transizioni fra gli stati. Le macchine a stati rappresentano il modo pi naturale per formalizzare questi schemi ad alto livello. La cosa pi interessante che lo stesso statechart pu essere eseguito su un PC desktop, LabVIEW Real-Time o LabVIEW FPGA. Inoltre, gli sviluppatori embedded si possono avvalere dello Statechart Module per progettare in modo pi facile e intuitivo software pensato per I/O in esecuzione su
R:
hardware real-time o basati su FPGA. Gli strumenti di progettazione avanzati, come il modulo statechart e i diagrammi di simulazione, permettono di eliminare il divario tra la progettazione e le applicazioni di test per utilizzare pi rapidamente le progettazioni dei prodotti e velocizzarne la presenza in commercio. E da notare che il parallelismo di cui abbiamo parlato prima pu essere ottenuto eseguendo pi statechart simultaneamente, con qualche punto di sincronizzazione. Infine, il nuovo LabVIEW Statechart Module in grado di progettare e implementare i protocolli di comunicazione come SPI o I2C per prototipare rapidamente i nuovi prodotti o comunicare con unit durante i processi di test.
R:
R:
Kamran Shah
W H AT S N E W
l modello di programmazione a diagrammi di stato completa il panorama dei modelli presenti in LabVIEW per la gestione del flusso di dati, la matematica testuale, la modellazione di sistemi dinamici e lo sviluppo basato su finestre di configurazione. Potete scegliere il modello o la combinazione di modelli pi adatta per sviluppare il vostro sistema in base ai requisiti specifici dellapplicazione.
opera di sistemi. I diagrammi di stato di LabVIEW offrono uno strumento di progettazione ad alto livello di grande scalabilit grazie a concetti di programmazione quali gerarchia, concorrenza ed eventi. Poich i diagrammi di stato offrono una visione a livello di sistema, potete utilizzarli come specifiche dei programmi eseguibili. Il modello di programmazione a diagrammi di stato parti-
La piattaforma di progettazione grafica di sistemi di National Instruments combina i modelli di programmazione di LabVIEW con I/O di misura e controller commerciali desktop ed embedded. Grazie a questa combinazione, potete avere una catena di strumenti di sviluppo integrata per la progettazione, la prototipazione e la messa in
colarmente utile per sviluppare sistemi complessi che devono rispondere ad una variet di eventi, come sistemi di controllo embedded e sistemi di telecomunicazione. Con lo Statechart Module potete distribuire progetti su unampia gamma di piattaforme hardware che spazia dai PC desktop ai chip FPGA.
W H AT S N E W
04
aggiungendo un elemento di controllo della temperatura al software dentro il distributore automatico. La figura 4 spiega come potete incapsulare la logica di dispensazione ed il controllo della temperatura in un and state. Gli and-state descrivono un sistema che simultaneamente in due stati indipendenti fra loro. La transizione T7 descrive come i diagrammi di stato possono definire
unuscita che vale per entrambi i sottodiagrammi di stato. Oltre a gerarchia e concorrenza, i diagrammi di stato hanno altre caratteristiche che li rendono utili per i sistemi complessi. I diagrammi di stato hanno un concetto di storia, che permette ad un superstato di ricordare quale sottostato al suo interno stato attivo in precedenza. Consideriamo, per esempio, un superstato che descrive una macchina che versa una sostanza e quindi la scalda. Un evento di arresto potrebbe mandare in pausa lesecuzione della macchina mentre essa sta versando. Quando si verifica un evento di ripresa, la macchina ricorda di riprendere a versare.
La figura 3 illustra un diagramma di stato che descrive il comportamento della stessa macchina. Notate come la nozione di gerarchia ed eventi riduca il numero di stati e transizioni. Nel diagramma di stato, potete annidare gli stati conteggio delle monete e dispensazione allinterno di un superstato. Dovete definire semplicemente una transizione (T3) da uno di questi due stati allo stato dare il resto. Potete configurare la transizione T3 per rispondere a tre eventi: bibita erogata, resto richiesto o monete rifiutate. Inoltre, potete eliminare lo stato selezione della bibita nel classico diagramma a stati introducendo una condizione di guardia sulla transizione T2. Figura 4 - Implementazione di un and state Le condizioni di guardia devono diventare vere perch la transizione possa avvenire. Se il risultato della condizione di guardia falso, levento viene ignorato e la transizione non si verifica. A questo punto, potete espandere il diagramma di stato per dimoFigura 3 - Diagramma di stato, realizzato tramite Figura 5 - Progetto di LabVIEW con definizione strare la nozione statechar t s, equivalente alla versione di figura 2 dello statechart LVStatechart 1.lvsc di concorrenza
W H AT S N E W
04
descrive una macchina per imballaggio. Potete facilmente vedere i diversi stati della macchina e le transizioni fra gli stati. I diagrammi di stato sono molto utili anche per descrivere sistemi reattivi. Potete progettare ciascuno stato con pi risposte associate, che corrispondono ad una variet di trigger o eventi, inviati al diagramma di stato da un dispositivo hardware o da uninterfaccia utente. Le reazioni sono implementate con la programmazione grafica di LabVIEW. La figura 6 mostra il codice LabVIEW che viene eseguito quando il sistema nello stato Produzione e si verifica il trigger Livello materiale basso. I trigger possono anche causare transizioni da eseguire fra gli stati. Un modo alternativo per determinare le transizioni utilizzare codice LabVIEW per valutare una guardia. Una guardia descrive le condizioni che devono essere soddisfatte per potere eseguire una transizione. La figura 7 illustra il codice di guardia per la transizione denominata Materiali esauriti. Il codice LabVIEW assicura che il livello sia minore di 35,5 per eseguire la transizione dallo stato Produzione allo stato Standby. Per soddisfare le esigenze associate a casi di utilizzo differenti, i diagrammi
di stato di LabVIEW generano codice secondo due modalit di esecuzione: modalit sincrona e asincrona. Il modo sincrono progettato per descrivere il comportamento di un controllore con diversi stati che reagiscono ad un set di ingressi di I/O aggiornati ad una frequenza costante.
Questo modo pu essere applicato a sistemi di controllo embedded come le unit di controllo motori (ECU), motion controller e controllori ambientali. Il modo asincrono progettato invece per applicazioni che coinvolgono eventi provenienti da unapplicazione esterna. Esso utile per programmare interfacce uomo-macchina (HMI) e per modellare sistemi ed algoritmi basati su eventi. Quando avete determinato il corretto modo di esecuzione per il vostro diagramma di stato, potete generare codice eseguibile sotto forma di un subVI modulare, o chiamata di funzione. Potete quindi chiamare il subVI dallinterno di uno schema a blocchi di LabVIEW come illustrato nella figura 7. Potete eseguire visivamente il debug del diagramma di stato sia attraverso la modalit di Highlight Execution presente in LabVIEW, sia attraverso elementi di debugging standard come breakpoint, sonde (finestre mobili di osservazione) e lesecuzione passopasso. Potete generare codice basato su diagrammi di stato per una variet di piattaforme hardware, inclusi sistemi desktop, interfacce uomo-macchina (HMI), programmable automation con-
W H AT S N E W
troller (PAC) come NI CompactRIO e PXI, field-programmable gate array (FPGA) presenti su hardware NI e qualsiasi microprocessore a 32 bit. La possibilit di distribuire applicazioni basate su diagrammi di stato su varie piattaforme hardware rende lo Statechart Module di LabVIEW un eccellente strumento di progettazione per lo sviluppo e la messa in opera di sistemi embedded. Potete anche utilizzare i diagrammi di stato con il Control Design and Simulation Module di LabVIEW per modellare e valutare sistemi ibridi attraverso la simulazione di sistemi dinamici.
CONCLUSIONE
Il modello di calcolo a diagramma di stato offre un metodo sofisticato per affrontare lo sviluppo di applicazioni complesse. I diagrammi di stato sono particolarmente utili per programmare applicazioni che rispondono ad eventi, come intricate interfacce utente e macchine a stati avanzate, utilizzate per implementare controllori di sistemi dinamici, logica di controllo macchine e protocolli digitali di telecomunicazione. Con il nuovo Statechart Module di LabVIEW, potete beneficiare dei brevi tempi di sviluppo e della stretta integrazione hardware offerti dalla piattaforma LabVIEW. Ora potete aggiungere anche i diagrammi di stato alla lista dei vostri strumenti per la programmazione di applicazioni complesse.
Readerser vice.it n. 403
BREVI
Il modulo Real-Time di LabVIEW 8.5 per il multiprocessing simmetrico
Lultima versione del modulo Real-Time di LabVIEW aggiunge il supporto per il multiprocessing simmetrico (SMP), al fine di estendere il determinismo ai sistemi embedded multicore. Oggi potete utilizzare LabVIEW per progettare rapidamente applicazioni real-time embedded parallele, in grado di sfruttare le prestazioni dei processori multicore. Con questa nuova funzionalit, i sistemi embedded possono migliorare i tempi-ciclo ed elaborare set di dati di maggiori dimensioni per sviluppare sistemi di controllo ad alte prestazioni, come simulazioni hardware-in-the-loop e sistemi di motion control ad alta velocit. Inoltre, la nuova versione di Real-Time Execution Trace Toolkit permette il debug di applicazioni LabVIEW multithreaded su sistemi multicore embedded. Il modulo Real-Time di LabVIEW estende lapproccio di sviluppo grafico di LabVIEW ad hardware NI e di terze parti con sistema operativo real-time, ed offre interfacce verso unampia variet di I/O commerciali, per aiutarvi a sviluppare rapidamente sistemi real-time embedded. Il modulo Real-Time di LabVIEW fa parte della piattaforma embedded di LabVIEW una famiglia di prodotti National Instruments che comprende i moduli LabVIEW FPGA, LabVIEW PDA, LabVIEW Touch Panel e LabVIEW Microprocessor SDK (Software Development Kit) che offre un ambiente completo di programmazione per sistemi embedded. Readerservice.it n. 402
04
Lar ticolo utilizza un caso esemplificativo per esplorare leffetto della conversione di un programma LabVIEW tradizionale in un programma orientato agli oggetti
seconda di come il vostro programma LabVIEW strutturato, lo sforzo necessario per modificare ed estendere il programma stesso pu variare notevolmente. La programmazione orientata agli oggetti, introdotta in LabVIEW 8.20, una tecnica che pu aiutarvi a migliorare la struttura del programma e a semplificare laggiunta e la modifica di funzionalit. Lo scopo quello di sottolineare come lorientamento agli oggetti influisca sulla struttura del programma ed esplorare i benefici riguardanti le modifiche e le estensioni del programma.
Fig. 1 Test della corrente di carica strutturato come un programma LabVIEW tradizionale
SOLUZIONE TRADIZIONALE
La figura 1 illustra lesempio di test, relativo alla misura della corrente di carica. Il GetConfiguration.vi funziona come una variabile globale, memorizzando la configurazione di tutti i canali fisici di I/O. Meas_V.vi misura la tensione sul canale dingresso analogico ChargerCurrent. Poich lo stesso VI di test viene eseguito per ogni UUT, lid dellUUT corrente viene fornito come ingresso al test. La corrente viene calcolata usando la resistenza dellUUT, a sua volta fornita come array di input al VI dellesempio di test.
IL PROBLEMA
- Eseguire una serie di test per verificare un caricabatterie. - La stazione di test prova quattro caricabatterie in parallelo. - Sono utilizzate quattro unit DAQ di due modelli differenti, gli NI USB DAQ 6210 e 6211. - Test: viene coperto un esempio di test: la misura dellassorbimento di corrente del caricabatterie.
Fig. 2 - Test della corrente di carica strutturato come un programma orientato agli oggetti
11
04
zione orientata agli oggetti meno affollata di dati e pi focalizzata su ci che il test deve fare. Larray di resistenze degli UUT non pi necessario, perch questa informazione viene letta da un ini-file dalloggetto UUT ed quindi utilizzata per inizializzare loggetto Variable ChargeCurrent con i dati corretti. Inoltre, lalgoritmo per il calcolo della corrente viene gestito da un VI, anzich esplicitamente nello schema a blocchi, migliorando laffidabilit. Anche i valori min/max ed il riferimento del canale fisico sono scomparsi dallo schema a blocchi nella soluzione orientata agli oggetti. Per spiegare che cosa successo con tale informazione, nella figura 4 illustrata una visione dinsieme della struttura del programma orientato agli oggetti. La figura 4 indica le classi della soluzione orientata agli oggetti. Il campo intermedio del blocco di ogni classe indica i campi dati della classe, mentre il campo inferiore indica i VI della classe. Ogni oggetto UUT memorizza un array di nomi di variabili ed un array di oggetti Variable. In questo esempio, abbiamo visto solo la variabile ChargeCurrent, ma vi sono naturalmente altre variabili nel sistema completo. Ogni oggetto Variable memorizza un oggetto Channel ed anche la resistenza, se essa richiesta per il punto di misura. Per la resistenza di ChargeCurrent utilizzata la resistenza degli UUT. Ogni oggetto Channel rappresenta un canale fisico dal quale viene letta (o scritta) la misura. Loggetto Channel ha anche i valori min/max per essere in grado di configurare il canale fisico. Per configurare tutti gli oggetti con i dati corretti, loggetto UUT legge le informazioni di configurazione da un ini-file ed usa tali informazioni per inizializzare gli oggetti Variable e gli oggetti Channel. Ecco uno schema di come potrebbero apparire le informazioni di configurazione del canale per la variabile ChargeCurrent (per lUUT1): [VARIABLE_UUT1_ChargeConsumption] PhysicalChannel=DAQ1/ai0 MaxVal=5 MinVal=1
Fig. 4 Visione dinsieme delle classi della soluzione orientata agli oggetti
12
corrente nel nuovo VI di test. Ma questa non una buona idea, perch necessario correggere potenziali errori software in due punti. La seconda possibilit quella di aggiungere un subVI che calcola la corrente prendendo come parametri la tensione e la resistenza. Questa soluzione migliore. Che cosa succede nella soluzione orientata agli oggetti? Tutti i VI di utilit richiesti sono gi stati creati e possono essere semplicemente utilizzati nel nuovo VI di test. Pertanto, facile usare la variabile ChargeCurrent nel nuovo VI di test. Non occorre alcun cambiamento di codice. Notate come la funzionalit (GetCurrent.vi) sia raggruppata insieme ai dati di cui ha bisogno (la resistenza). Questo il modo con il quale i programmi orientati agli oggetti sono strutturati; tipicamente fra i VI di una soluzione orientata agli oggetti sono cablati meno dati. La ragione che i dati sono memorizzati allinterno degli oggetti. Questo effetto molto chiaro se si confrontano le figure 1 e 2.
figura 5. Per i canali stata usata una convenzione sui nomi e la funzionalit di questo VI si basa su tale convenzione. Tutti i canali memorizzati in questa variabile globale seguono una convenzione sui nomi come DAQ1/ai3. Per ottenere il nome di canale di uno specifico id UUT, questo VI sostituisce semplicemente DAQ1 con lappropriato numero di UUT, per esempio per lid UUT = 2, il nome del canale sarebbe DAQ2/ai3. Limplementazione di questo VI deve essere riscritta perch possa funzionare nella nuova configurazione hardware. Che cosa succede nella soluzione orientata agli oggetti? Poich non viene utilizzata alcuna convenzione per i nomi dei canali, sufficiente aggiornare lini-file perch il programma possa funzionare nella nuova configurazione hardware. Non richiesto alcun cambiamento di codice. Stazioni di test differenti possono utilizzare configurazioni hardware differenti e controllare la configurazione modificando lini-file del sistema.
Che cosa succede nella soluzione tradizionale? Poich le informazioni di configurazione sono memorizzate nel GetConfiguration.vi, questo il luogo naturale per aggiungere i dati di configurazione del mux. La figura 6 illustra il GetConfiguration.vi aggiornato. Le impostazioni del mux devono essere applicate prima di richiamare Meas_V.vi (che legge lingresso analogico). Che cosa succede nella soluzione orientata agli oggetti? Tre cose, e nessuna di esse ha effetti sul VI di test! In primo luogo, la configurazione del mux deve essere aggiunta allini-file. Ecco uno schema di come potrebbe apparire:
Fig. 5 - Pannello di connessione del VI dati globale GetConfiguration
I nomi degli indicatori devono quindi essere aggiornati; non un grosso cambiamento, ma necessario salvare nuovamente il VI di test. Se stato usato un sistema di controllo della versione, ci sar una nuova versione del VI. Il secondo problema evidente quando si legge il testo di help nella
13
04
In secondo luogo, il VI nellUUT che legge lini-file deve essere aggiornato. Quindi, la classe Channel viene aggiornata secondo la figura 7. Essa memorizza le linee del mux
solo come la misura viene eseguita. Poich la classe UUT ha la responsabilit di leggere la configurazione dallini-file, anche questo aggiornamento naturale. Le figure 9 e 10 indicano i VI di test risultanti aggiornati per poter gestire il mux. La complessit della soluzione LabVIEW tradizionale aumentata, rendendo pi difficile la lettura del codice. La soluzione orientata agli oggetti non invece influenzata dal supporto al mux.
RIASSUNTO DEGLI EFFETTI DELLA STRUTTURA DEL PROGRAMMA ORIENTATO AGLI OGGETTI
Dopo questa terza modifica del software, la soluzione orientata agli oggetti pi capace e flessibile della soluzione iniziale. E stata aggiunta funzionalit per consentire al software di gestire lhardware con o senza mux. La scelta configurabile e non si propagher al VI di test. Nella soluzione tradizionale, esiste la stessa funzionalit, ma essa influisce sul VI di test, richiedendo quindi una maggiore codifica (quindi, la manutenzione del programma pi costosa). - Il raggruppamento di dati e VI si traduce in una minore quantit di dati da cablare fra i VI. Ci rende pi semplici la lettura e la manutenzione del codice. Gli array cablati allinterno dellapplicazione sono spesso sostituiti da una classe con istanze multiple, che incapsulano i dati e le operazioni sui dati. - Suddividendo lapplicazione in classi, ciascuna con la propria responsabilit, lapplicazione diventa pi flessibile e robusta per i cambiamenti.
Fig. 8 - Schema a blocchi della Channel.lvclass:Read_AI.vi aggiornata per impostare i latch del mux prima di leggere lingresso analogico
Fig. 9 - Test della corrente di carica, nella soluzione LabVIEW tradizionale, aggiornato per gestire il mux
e le blocca in due array senza alcuna ipotesi circa il numero di linee. La figura 8 illustra la Channel.lvclass:Read_AI.vi aggiornata per la gestione del mux. LUsingMux.vi controlla semplicemente se gli array del mux sono vuoti o meno. Il SetMux.vi applica i latch del mux se il mux viene utilizzato. Questo esempio illustra un beneficio di un progetto orientato agli oggetti: le responsibilit totali dellapplicazione sono distribuite in classi individuali. In questo caso c una classe Channel responsabile della gestione dei canali DAQ. Il cambiamento del metodo di misura si traduce in un aggiornamento in questa classe, cosa che naturale. Esso non ha effetti sul VI dellesempio di test e ci positivo, perch ci che il test fa non cambiato, ma cambiato
Fig. 10 - Test della corrente di carica, nella soluzione orientata agli oggetti, non influenzata dal suppor to al mux
14
La semplicit con cui stato aggiunto il mux lo dimostra. Il nuovo requisito non ha provocato alcun cambiamento della struttura del programma. Anzich propagarsi ai VI allinterno dellapplicazione i cambiamenti provocati dai nuovi requisiti sono spesso localizzati in singole classi. Osservando il progetto nel suo complesso (figura 4), normalmente molto naturale vedere quale classe deve essere aggiornata per un nuovo requisito. - La struttura del programma riflette il problema che si sta risolvendo. La classe UUT riflette lesistenza degli UUT nel
CONCLUSIONE
Nel tempo, tutti i programmi cambiano, spesso pi di quanto si preveda. Spesso, inoltre, essi vengono utilizzati in modi non previsti allinizio del progetto. In questo articolo abbiamo potuto vedere che due programmi molto simili a prima vista, avevano comunque qualit molto differenti in termini di robustezza per i cambiamenti. Applicare la programmazione orientata agli oggetti pu avere effetti positivi sulla struttura del programma, rendendo pi facile modificare ed estendere il programma stesso. Ci permette di fare in modo che la produttivit del programmatore non diminuisca al crescere del programma. Per il programmatore LabVIEW, la programmazione orientata agli oggetti un modo nuovo di pensare alla struttura del programma e per entrare in questa tecnica pu essere necessario un po di tempo. Ma ne varr la pena, sia per i benefici effettivi, sia per il gusto di imparare qualcosa di nuovo.
sistema di test. Lo stesso vale per la classe Channel. Questo va a vantaggio della comprensione della struttura del programma. - Infine, c un focus maggiore sulla struttura (classi) anzich sulla funzionalit in termini di VI e subVI.
Note sullautore
Jan Klasson Vice President Prodotti & Training presso Endevo un Alliance Member NI svedese, ed anche docente di LabVIEW System Design nei corsi Goop in Svezia ed Europa. Egli lavora da 15 anni con lo sviluppo e la metodologia orientati agli oggetti, utilizzando C++, Java e LabVIEW. Jan ha lavorato come consulente utilizzando LabVIEW in diversi progetti di misura, dalla versione LabVIEW 4. Pu essere contattato allindirizzo jan.klasson@endevo.se.
15
04
In questo ar ticolo si descrive la procedura per accedere ai registri di I/O attraverso qualche esempio
abVIEW permette di pilotare periferiche sfruttando driver di alto livello (VISA,IVI, ecc.) ma anche direttamente alle API di Windows, sfruttando laccesso diretto alle porte di memoria
LINTERFACCIA PARALLELA
La porta parallela ha subito un evoluzione negli anni e ancora oggi disponibile in larga scala. Nata come porta per linterfacciamento delle stampanti, poi divenuta, con laumento delle capacit di trasferimento, lo standard per lo scambio di dati con dispositivi come hard disk esterni e altro. Le macchine pi anziane (primi IBM e compatibili) montano parallela SPP, per arrivare allo standard PC attuale che vede una porta EPP+ECP (da Bios si pu settare il modo di funzionamento multiplo o uno dei due). SPP (Standard Parallel Port), nota anche come Tipo AT o ISAcompatible, la porta parallela standard, basata sulla porta Centronics per stampanti. Le sue caratteristiche principali sono: Trasferimento: 8 bit alla volta. Direzione: solo uscita 8 bit e bidirezione in nibble mode (4 ingresso e 4 uscita). PS/2 o SPP modificata (bidirezionale semplice). Caratteristiche: Trasferimento: 8 bit alla volta (byte). Direzione: Ingresso/Uscita. EPP (Enhanced Parallel Port). Anche in questo caso si tratpin descrizione e (indirizzo porta) 1 2 3 4 5 6 7 8 9
ta di una porta bidirezionale, che ha come caratteristica la velocit (scrive o legge un byte in circa 1 ms) ed circa 4 volte pi veloce di SPP e PS/2. Una EPP pu emulare una SPP e in qualche caso anche una PS/2 (da Bios). ECP (Extended Capabilities Port). Caratterizzata da trasferimento dei dati e bidirezionalit come la EPP, supporta DMA (direct memory access) ed bufferizzata. Pu emulare le altre porte (SPP,PS2,EPP).
PIN E REGISTRI
La parallela utilizza un connettore femmina DB25 lato computer (fig. 1). La tabella seguente evidenzia la piedinatura e indirizzamento per pin. pin descrizione e (indirizzo porta)
Strobe, uscita di handshake. Non usato in questa applicazione(37A) 14 Non usato in questa applicazione(37A) D0 (378) D1 (378) D2 (378) D3 (378) D4 (378) D5 (378) D6(378) D7 (378) 15 16 17 18 19 20 21 22 23 24 25 Non usato in questa applicazione(37A) Non usato in questa applicazione(37A) Non usato in questa applicazione(37A) Massa Massa Massa Massa Massa Massa Massa Massa
16
2. Word Di default il controllo in ingresso ad Out Port, si pu sfruttare ad esempio quando si vuole inviare una sequenza di byte, in modo molto pi pratico ed economico dal punto di vista computazionale che linvio di array di boolean (fig. 4).
Nota: Lingresso di Out Port e luscita di In Port sono due integer, che rappresentano il numero corrispondente al byte del registro interrogato. Si pu quindi scrivere direttamente 0 per accendere il pin su D0 (con address 378h) oppure utilizzare un byte booleano e trasformarlo in numero con boolean array to number. Si possono personalizzare diversi sistemi per manipolare quindi gli array.
3. Selected pin Si pu anche usare un metodo ad indirizzamento, usando ad esempio un array di Boolean preinizializzato e, con un replace array subset, modificare lo stato di uscita di un pin specifico (fig. 5). 4. String pack Infine, si pu inviare la sequenza di accensione dei pin mediante stringa e scrivere quindi procedure di scrittura su file. Nell esempio della fig. 6, il controllo byte string contiene sequenze di byte separate da line feed (invio a capo o codice /n ). Esse vengono processate e inviate byte per byte alla porta.
Note sullautore
Fig. 3 Scrittura su pin D0-D7 (Array of boolean)
17
D A L L A T E O R I A A L L A P R AT I C A
04
LA RICERCA DELLECCELLENZA
Alessandro De Grassi, Francesco Siano, Carmine Ungaro
Il Gruppo Loccioni ha realizzato un innovativo sistema per il test in ambiente automotive con tecnologia National Instruments: flessibilit, affidabilit e facilit di utilizzo ne caratterizzano la struttura portante ed innovativa
l Gruppo Loccioni da considerarsi una vera sartoria tecnologica, un fiore allocchiello per il made in Italy, grazie allo sviluppo di soluzioni personalizzate che garantiscono qualit, confort e sicurezza in ogni settore: dalla casa, allauto, ai luoghi di lavoro, fino allambiente. Il Gruppo opera in sinergia con Universit e Centri di Ricerca nello sviluppo e realizzazione di sistemi chiavi in mano, ad alto contenuto tecnologico, per lindustria, i servizi e la Pubblica Amministrazione ed integra le sue competenze nellambito di misura e collaudo per il controllo qualit, automazione, ICT, energia e service, su diversi settori tra cui: automotive, elettrodomestici, ambiente, agroalimentare, sanit e manifatturiero. Il modello a rete e linnovazione sono alla base del successo del Gruppo: rete con il territorio ed innovazione a 360.
che per il cliente finale. I settori di competenza sono molto articolati e prevedono test su misure di pressione, di portata volumetrica, di portata massica e operazioni di caratterizzazione degli iniettori. Proprio in questo ambiente tecnologico ha preso vita il progetto Mexus, innovativo sistema di misura specifico per iniettori realizzato con tecnologia National Instruments.
MEXUS: LA STORIA
Lobiettivo di questo progetto nasce dallesigenza di misurare la portata degli iniettori per i motori diesel tramite la quantificazione accurata del combustibile iniettato durante una singola iniezione. Il prodotto finale uno strumento utilizzato dai principali costruttori di iniettori mondiali, per il collaudo di fine linea della produzione. Obiettivo del Gruppo Loccioni e quindi del team di R&D stato quello di fornire un prodotto a prezzi molto competitivi dotato di tecnologie
ATELIER AUTOMOTIVE
LAtelier Automotive nasce nel 1980 per soddisfare le esigenze dei mercati nazionali e internazionali. In un tempo molto breve il laboratorio tecnologico del Gruppo Loccioni diventato un centro di ricerca, di rilevanza nazionale, riconosciuto dal M.U.R.S.T. (Ministero dellUniversit e della Ricerca Scientifica e Tecnologica). In questo ambiente stato introdotto il concetto di Qualit Totale come elemento cardine di una filosofia aziendale lungimirante, finalizzata ad imporsi nei mercati mondiali quale centro ad alta specializzazione nella progettazione e realizzazione di sistemi integrati per il collaudo automatico e il controllo di qualit. Leccellenza dei contenuti tecnologici porta immediatamente lazienda a focalizzare i propri interessi in due segmenti di mercato in continua evoluzione, quello del settore automobilistico e quello degli elettrodomestici ove il Gruppo si colloca come leader mondiale. Attualmente il Gruppo partner tecnologico dei maggiori produttori di componenti automobilistici per i quali implementa linee e banchi di collaudo di tipo custom.
18
D A L L A T E O R I A A L L A P R AT I C A
allavanguardia e pi performanti degli strumenti attualmente presenti sul mercato. La soluzione stata individuata offrendo al mercato dellautomotive un prodotto per il test molto affidabile, in grado di effettuare in maniera accurata le due misure fondamentali per la caratterizzazione di un iniettore: la portata iniettata per ogni shot e il grafico della portata istantanea. A dimostrazione delloriginalit della soluzione proposta, il progetto e lalgoritmo di calcolo sono stati brevettati dal Gruppo Loccioni. Dopo un anno di sviluppo sui prototipi del sistema, il Gruppo Loccioni finalmente pronto per mandare in produzione una preserie del sistema nella sua versione ingegnerizzata per la produzione. Questo primo lotto sar consegnato ai principali clienti del gruppo, leader nello sviluppo di iniettori, per le prime verifiche sul campo. Il Team R&D intanto al lavoro per aumentarne le funzionalit del sistema ed il range di lavoro anche per iniettori per il mercato dellHeavy Duty.
state iniettate nel tempo: ovvero la legge di iniezione della massa istantanea. Queste informazioni risultano fondamentali per la caratterizzazione degli iniettori, in considerazione del fatto che le normative in campo di emissioni inquinanti sono sempre pi restrittive: ne deriva di conseguenza che per il costruttore fondamentale avere informazioni sempre pi accurate per ottimizzare ai massimi livelli la combustione riducendo al minimo sia il consumo di carburante che la quantit di gas inquinanti immessa nellambiente. Una particolarit del Mexus da segnalare lattenzione che i progettisti hanno messo per garantire tempi di manutenzione contenuti al minimo a fronte di grandi quantitativi di prove effettuate in una linea di produzione di iniettori che lavora 24 ore al giorno.
INTEGRAZIONE DI TECNOLOGIE
Per garantirsi affidabilit nella misura, il Gruppo Loccioni si affidato alla tecnologia National Instruments. Per la realizzazione del programma di controllo di Mexus stato utilizzato LabVIEW nella sua ultima versione per tutto ci che riguarda la gestione dellacquisizione dati, lelaborazione e la presentazione dei dati. Elemento critico del sistema Mexus rappresentato dalla camera di iniezione, ovvero il cilindro opportunamente dotato di sensori e valvole di controllo, nel quale liniettore immette il combustibile e nel quale vengono effettuate le misure specifiche. La camera di iniezione ed il relativo sistema di controllo sono stati modellati in
19
D A L L A T E O R I A A L L A P R AT I C A
04
TRI-VENETO IDELFONSO ELBURGO VIA PIRANO, 15 35135 PADOVA TEL. 049 8642988 - FAX 049 8642989 e-mail: ielburg@tin.it
LabVIEW attraverso il Simulation Module. In questa fase, quindi, stata effettuata una serie di simulazioni utilizzando lambiente LabVIEW su un personal computer. Successivamente, in fase di prototipo, si mantenuta la stessa piattaforma PC e Windows con schede di acquisizione dati National Instruments per PC con lo scopo di effettuare la caratterizzazione e la verifica del principio di funzionamento. Questa fase cruciale di sviluppo del progetto ha messo in evidenza la necessit di un modello della camera di iniezione pi raffinato, e per questo stato utilizzato un ulteriore strumento di cui LabVIEW dispone, il System Identification Toolkit, con il quale stato possibile ottenere la funzione di trasferimento della camera di iniezione e di conseguenza progettare lalgoritmo di controllo pi adeguato. Per poter garantire lindustrializzazione su larga scala si deciso di utilizzare hardware adatto allambiente industriale, con tecnologie immuni da disturbi, funzionante 24 ore su 24 con spazi ed ingombri ridotti. La scelta quindi ricaduta per la fase di rilascio su un sistema embedded che garantisca la massima compatibilit con il software sviluppato. Il sistema CompactRIO di National Instruments ha permesso una rapida transizione dalla fase prototipale a quella di rilascio sul mercato, garantendo le prestazioni richieste sia a livello di elevata frequenza di campionamento (richiesta per i requisiti di misura), sia il controllo real-time deterministico del processo. Linterfaccia operatore del sistema finale, infine, viene gestita da un touch panel computer con sistema operativo WinCE, programmato tramite LabVIEW Touch Panel Module e connesso al sistema CompactRIO attraverso rete Ethernet. Il grosso vantaggio per il team stato quello di disporre di un unico ambiente di sviluppo dalla fase di progettazione, al prototipo fino al rilascio finale riducendo cos linterfacciamento con altri linguaggi di programmazione. LabVIEW ha permesso grande flessibilit, sia per lintegrazione nello sviluppo, sia per la facilit di utilizzo e la gestione dellhardware.
CONCLUSIONI
Mexus garantisce la massima affidabilit nelle operazioni di test. Laccuratezza delle misure garantita dallintroduzione di metodologie di lavoro innovative che assicurano al cliente finale prove conformi con le pi restrittive normative. Il Gruppo Loccioni attraverso il proprio know-how e la partnership tecnologica con National Instruments ha voluto fornire al mondo dellautomotive un prodotto che oltre a garantire standard di test di eccellenza garantisce tempi di fermo macchina ridotti a zero, nel pieno rispetto dellambiente e della natura, con investimenti adeguati al rendimento e di facile utilizzo.
PIEMONTE-LIGURIA-VALLE DAOSTA ROSARIO ROMEO - PUBLIKAPPA VIA SAGRA S. MICHELE, 37 10139 TORINO TEL./FAX 011 723406 e-mail: publika@tin.it
Sede legale - Via Salvatore Rosa, 14 - 20156 Milano, tel +39 02 366092.1 - fax +39 02 366092.280 Sede operativa - Viale Espinasse, 141- 20156 Milano, tel.+39 02 366092.1 - fax +39 02 366092.525 www.ilb2b.it - www.edizionifieramilano.it
20
SCUOLA DI LABVIEW
04
PUNTI DINTERRUZIONE
Utilizzate il tool Breakpoint, mostrato di seguito, per inserire un punto dinterruzione in un VI, in un nodo o su un collegamento dello schema a blocchi ed arrestare lesecuzione in quella posizione.
ma a blocchi e selezionate SubVI Node Setup dal menu rapido. Contrassegnate il riquadro Suspend when called per sospendere lesecuzione solo per quellistanza del subVI. La finestra VI Hierarchy, che visualizzate selezionando ViewVI Hierarchy, indica se il VI in pausa o sospeso. Una freccia indica un VI regolarmente in esecuzione o in esecuzione passo passo.
Quando impostate un punto dinterruzione su un collegamento, lesecuzione si arresta dopo che il dato passato attraverso il collegamento. Inserite un punto dinterruzione sullo schema a blocchi per arrestare lesecuzione dopo che tutti i nodi nello schema a blocchi sono stati eseguiti. Quando un VI si ferma su un punto dinterruzione, LabVIEW porta lo schema a blocchi in primo piano ed utilizza un simbolo per evidenziare il nodo o il collegamento che contiene il punto dinterruzione. Quando spostate il cursore su un punto dinterruzione esistente, larea nera del cursore Breakpoint appare bianca. Quando raggiungete un punto dinterruzione durante lesecuzione, il VI si ferma e il pulsante Pause appare rosso. Potete svolgere le seguenti azioni: Eseguire passo passo utilizzando i pulsanti single-stepping. Sondare i collegamenti per verificare i valori intermedi. Modificare i valori dei controlli del pannello frontale. Cliccare sul pulsante Pause per proseguire con lesecuzione fino al punto dinterruzione successivo o finch il VI non ha finito lesecuzione.
Un simbolo di pausa verde o vuoto in bianco e nero, indica un VI che si mette in pausa quando richiamato. Un simbolo di pausa rosso, o uno solido in bianco e nero, indica un VI in pausa. Un punto esclamativo indica che il subVI sospeso.
SOSPENSIONE DELLESECUZIONE
Sospendete lesecuzione di un subVI per modificare i valori dei controlli e degli indicatori, per controllare il numero di volte che il subVI viene eseguito prima di tornare al programma chiamante, o per tornare indietro allinizio dellesecuzione del subVI. Potete avviare tutte le chiamate ad un subVI con lesecuzione sospesa o potete sospendere una specifica chiamata ad un subVI. Per sospendere tutte le chiamate ad un subVI, aprite il subVI e selezionate OperateSuspend when Called. Il subVI viene sospeso automaticamente quando un altro VI lo chiama. Se selezionate questa voce di menu quando eseguite passo passo, il subVI non viene sospeso immediatamente. Il subVI viene sospeso quando viene chiamato. Per sospendere una specifica chiamata al subVI, cliccate con il tasto destro del mouse sul nodo del subVI nello sche-
21
SCUOLA DI LABVIEW
04
lesecuzione di una radice quadrata di un numero negativo. Inf (infinito) rappresenta un valore in virgola mobile prodotto da operazioni tipo la divisione di un numero per zero. LabVIEW non verifica condizioni di overflow o di underflow su valori interi. Gli overflow e gli underflow di numeri in virgola mobile sono trattati secondo lIEEE 754, Standard for Binary Floating-Point Arithmetic. Le operazioni in virgola mobile propagano NaN e Inf in modo affidabile. Quando convertite esplicitamente o implicitamente NaN o Inf in interi o in booleani, i valore diventano privi di significato. Per esempio, la divisione di 1 per 0 produce Inf. Convertendo Inf in un intero a 16 bit si ottiene il valore 32767, che appare come un valore normale. Prima di convertire dati in interi, utilizzate lo strumento Probe per verificare la validit di valori in virgola mobile intermedi. Verificate NaN collegando la funzione Not A Number/Path/Refnum? sotto Comparison al valore che sospettate non sia valido. Non basatevi su valori particolari come NaN, Inf o array vuoti per determinare se un VI produce dati indefiniti. Invece, confermate che il VI produce dati definiti facendo s che un VI riporti un errore se incontra una situazione che probabile che produca dati indefiniti. Per esempio, se create un VI che utilizza un array in ingresso per indicizzare un For Loop, determinate cosa volete che faccia il VI quando larray in ingresso vuoto. Se producete un codice di errore in uscita, sostituite i dati definiti per il valore che crea il ciclo o utilizzate una struttura Case che non esegue il For Loop se larray vuoto.
ne automatica degli errori per un subVI o una funzione in un VI, collegate il parametro error out a quello error in di un altro subVI o funzione o ad un indicatore error out.
22
SCUOLA DI LABVIEW
ricamente lerrore. Un codice di errore nonzero accoppiato con uno status di FALSE segnala un avvertimento piuttosto che un errore. source una stringa che identifica dove avvenuto lerrore. La gestione degli errori in LabVIEW segue il modello a flusso di dati. Proprio come i valori dei dati fluiscono attraverso un VI, cos fanno le informazioni sugli errori. Collegate le informazioni sugli errori dallinizio del VI fino alla fine. Includete un VI di gestione degli errori alla fine del VI per determinare se il VI stato eseguito senza errori. Utilizzate i cluster error in ed error out in ogni VI che utilizzate o realizzate per passare informazioni sugli errori attraverso il VI. Quando il VI in esecuzione, LabVIEW verifica se ci sono gli errori in ogni nodo di esecuzione. Se LabVIEW non trova errori, il nodo viene eseguito normalmente. Se LabVIEW rileva un errore, il nodo passa lerrore al nodo successivo senza eseguire quella parte di codice. Il nodo successivo fa lo stesso e cos via. Alla fine del flusso di esecuzione, LabVIEW riporta lerrore.
le selettore di una struttura Case, letichetta del selettore di condizione visualizza due casi - Error e No Error - e la cornice della struttura Case cambia colore - rosso per Error e verde per No Error. In caso di errore, la struttura Case esegue la parte Error dello schema a blocchi. Quando un cluster degli errori collegato al terminale di selezione, la struttura Case riconosce solo lo status booleano del cluster.
Note sullautore
Figura 1. Condizione No Error
Laureato in ingegneria nucleare al Politecnico di Milano, Matteo Foini lavora in qualit di Technical Marketing Engineer presso National Instruments Italy
23
SCUOLA DI LABVIEW
04
Analizzare un progetto prima di iniziare a costruire un VI pu aiutarvi a sviluppare VI in modo pi efficiente e ad evitare bachi nelle funzionalit. Questa lezione descrive i passi essenziali del processo di analisi di un progetto: valutazione del documento delle specifiche, creazione del documento dei requisiti e definizione dellapplicazione. Alla fine della lezione, analizzerete un documento delle specifiche ed un documento dei requisiti. Il documento dei requisiti definisce le caratteristiche richieste allapplicazione affinch funzioni secondo le specifiche
- Il sistema deve essere implementato entro il 10 Ottobre - I VI devono essere scalabili Le specifiche funzionali e non funzionali sono legate fra loro. Separare le specifiche nelle categorie funzionale e non funzionale pu facilitare limplementazione di unapplicazione. Le specifiche funzionali diventano requisiti nel documento dei requisiti. Successivamente, quando implementerete le specifiche, le specifiche funzionali diventeranno moduli dellapplicazione. Le specifiche non funzionali definiscono gli attributi delle specifiche funzionali. Le specifiche definiscono ci che il cliente desidera ottenere con il software o quali funzioni devono essere eseguite dallapplicazione. Unanalisi dettagliata delle specifiche produce le esigenze partendo dai desideri. Molte volte, un documento delle specifiche diventa un elenco dei desideri anzich un documento ben definito. Eliminando le specifiche non essenziali dal documento delle specifiche si favorisce la prevenzione di un errato funzionamento delle caratteristiche. Potete ottenere le esigenze dai desideri analizzando le parole chiave nella specifica. Parole come faremo, dovremo e potremo definiscono le specifiche che il sistema deve implementare. Parole come faremmo, dovremmo, potremmo indicano specifiche che il cliente desidera ma di cui potrebbe non avere bisogno. Potete organizzare le specifiche che sono semplici desideri in un elenco dei desideri da utilizzare in futuro. Lanalisi delle specifiche richiede una buona comprensione dello scopo generale dellapplicazione. Anche se il cliente ha fornito un documento delle specifiche completo, importante esaminarlo in modo dettagliato e determinare se nelle specifiche manca qualche elemento. Fate domande e raccogliete tutti i requisiti che non sono menzionati nel documento.
24
SCUOLA DI LABVIEW
Non tutte le voci dellelenco sono pertinenti ad ogni specifica di progetto. Esiste gi un documento delle specifiche? Le operazioni eseguite dallutente sono indicate nel documento delle specifiche? Le specifiche sono definite chiaramente? Il documento specifica chiaramente i requisiti tecnici del progetto? Il documento delle specifiche privo di conflitti? Sono state elencate tutte le specifiche? I costi e i tempi sono indicati chiaramente? Tutte le specifiche sono implementabili? Dal documento delle specifiche sono stati esclusi dettagli del progetto? Ogni specifica verificabile mediante collaudo? Per un documento delle specifiche completo e dettagliato, necessario verificare tutti gli elementi applicabili dellelenco di controllo. Tutti gli elementi che non potete verificare rappresentano domande da porre al vostro cliente.
Conosce eventuali problemi E coerente nellesposizione del suo punto di vista. Poich le loro aspettative reciproche sono diverse, il cliente ed il programmatore parlano lingue differenti. E importante capire che il cliente si aspetta che risolviate molti degli elementi riguardanti i requisiti finali del progetto. Potete usare questa aspettativa a vostro vantaggio, perch potete raccomandare la tecnologia migliore per risolvere un particolare problema. Per esempio, il cliente potrebbe richiedere la visualizzazione di dati in formato tabulare, ma dopo avere valutato i dati, voi potreste raccomandarne la visualizzazione in un tracciato grafico, in modo che i dati siano disponibili visivamente. E proprio nella risoluzione dei problemi riguardanti i requisiti finali del progetto che potete aggiungere valore al processo di analisi del progetto stesso. Comunicare con il vostro cliente pu anche contribuire a ridurre i costi. Se le specifiche cambiano durante la fase di implementazione, potreste essere costretti a scartare del codice. Non facile aggiungere cambiamenti ad unapplicazione esistente. Studi software compiuti da aziende come IBM, TRW e GTE hanno messo in luce i significativi incrementi di costo associati al cambiamento delle specifiche durante le varie fasi del processo di sviluppo del software. Se si verifica un cambiamento durante la fase di progettazione, esso cinque volte pi costoso. Se si verifica un cambiamento nella fase di implementazione, esso dieci volte pi costoso. Se si verifica un cambiamento nella fase di test, esso venti volte pi costoso. Se il cambiamento si verifica durante la messa in opera, esso 50 volte pi costoso. E quindi importante accertarsi che il documento delle specifiche sia il pi completo possibile, in modo che eventuali cambiamenti possano verificarsi solo nella fase di progettazione. E inoltre importante fare in modo di comunicare con le persone giuste. Comunicate sempre con la persona che ha unautorit sulla progettazione. Per evitare frustrazioni, formalizzate il processo decisionale in modo che la persona che ha la parola finale sul progetto sia identificata e sia consapevole dei requisiti del progetto stesso. Per comunicare efficacemente con il vostro cliente, accertatevi innanzitutto di potere verificare tutte le voci applicabili nellElenco del Contenuto delle Specifiche. Tutti gli elementi che non potete verificare rappresentano domande da porre al vostro cliente.
25
SCUOLA DI LABVIEW
04
I metodi di gestione dei dati e reportistica sono stati definiti? Le esigenze di interfaccia utente sono state definite? Lhardware stato definito? Tutte le funzioni che il software deve eseguire sono state definite?
D. DEFINIZIONE DELLAPPLICAZIONE
I requisiti del progetto descrivono ci che il sistema software deve fare. Avere un set di requisiti del progetto il prossimo passo verso lo sviluppo dellapplicazione. Dopo avere comunicato con il cliente ed avere finalizzato le specifiche del progetto, potete determinare i requisiti del progetto. I requisiti sono potenti strumenti che vi dicono esattamente che cosa il software dovrebbe fare. Quindi, i requisiti devono contenere un dettaglio sufficiente. Se i requisiti non sono abbastanza dettagliati, potreste perdere di vista lintento del cliente ed implementare codi-
ce che non soddisfa le sue esigenze. Determinare i requisiti del progetto pertanto essenziale per sviluppare un documento dei requisiti. Prima di sviluppare un progetto dettagliato di un sistema, definite chiaramente gli obiettivi. Iniziate componendo un elenco dei requisiti. Alcuni requisiti sono specifici, come i tipi di I/O, le velocit di campionamento o la necessit di analisi real-time. Fate qualche ricerca in questa fase iniziale per essere sicuri di riuscire a soddisfare le specifiche. Altri requisiti dipendono invece dalle preferenze dellutente, come i formati dei file o gli stili grafici. Potete ricavare lelenco dei requisiti direttamente dalle specifiche. Cercate di distinguere fra i requisiti assoluti e quelli desiderati. Anche se potete cercare di soddisfare tutte le richieste, meglio avere unidea circa le caratteristiche che potete sacrificare se il tempo non vi basta. Fate attenzione a non rendere talmente dettagliati i requisiti da vincolare il progetto. Per esempio, quando progettate un sistema di I/O, il cliente probabilmente ha determinati requisiti in termini di velocit di campionamento e precisione. Tuttavia, anche il costo un vincolo. Includete tutti questi elementi nei requisiti. Se potete evitare di specificare lhardware, potete semplicemente mettere a punto il progetto dopo avere iniziato la prototipazione ed il benchmarking dei vari componenti. Fintantoch i costi rientrano nel budget specificato e gli aspetti di timing e precisione sono rispettati, il cliente pu non fare caso al fatto che il sistema utilizzi un particolare tipo di scheda plug-in o altro hardware. Un altro esempio di vincolo globale di un progetto quello di essere troppo specifici circa il formato di visualizzazione utilizzato nelle varie schermate con le quali il cliente interagisce. Unimmagine di un display pu essere utile per spiegare i requisiti, ma dovete essere chiari sul fatto che limmagine sia un requisito o una linea guida. Alcuni progettisti attraversano notevoli difficolt per produrre un sistema che si comporti in un modo specifico perch un certo comportamento faceva parte dei requisiti. In questo caso, esiste probabilmente una soluzione pi semplice che produce gli stessi risultati ad un costo minore e in un periodo di tempo pi breve. Un modo per limitare la quantit dinformazione che dovete scrivere quando analizzate un progetto quello di disegnare uno schema dellapplicazione. Creare uno schema aiuta a migliorare la propria capacit di progettare lapplicazione e trasferire idee al vostro cliente. Il primo passo nella creazione di uno schema determinare i componenti astratti di ogni requisito.
26
SCUOLA DI LABVIEW
stessa. Lastrazione generalizza lapplicazione ed elimina i dettagli. In generale, lastrazione pu essere di due categorie: lastrazione procedurale e lastrazione dei dati. Astrazione procedurale Lastrazione procedurale separa ci che una procedura deve ottenere da come la procedura implementata. Per esempio, consideriamo la seguente descrizione di unapplicazione. Procedura Aprire il file datalog. Ottenere linformazione di frequenza per i dati. Visualizzare tutti i dati che soddisfano il parametro di ricerca. Con questo esempio di astrazione procedurale, limplementazione della procedura separata dalla funzione della procedura stessa. Astrazione dei dati Lastrazione dei dati separa i dati che desiderate memorizzare dal mezzo fisico di memorizzazione dei dati stessi. Lastrazione dei dati offre una visione pi logica dei dati, rispetto ai bit e ai byte che formano i dati. Un esempio di astrazione dei dati un cluster. Un cluster pu rappresentare i dati in modo pi logico, senza richiedere allutente di interessarsi ai dettagli della sua implementazione. Consideriamo il seguente estratto dal documento dei requisiti di un sistema di controllo delle luci teatrali. Per analizzare il documento dei requisiti di questo esempio, estraiamo tutti i nomi dal documento ed utilizziamo i nomi per la definizione dei componenti. Inizio dellestratto del documento dei requisiti Implementazione
Record. Quando lutente clicca il pulsante Play, il controllore attua ogni effetto contenuto nel Controllo degli Effetti ciclando attraverso gli effetti registrati, a partire dal primo effetto nel Controllo degli Effetti. Un effetto riprodotto deve aspettare il tempo di attesa specificato, quindi attenuare i canali al colore e allintensit desiderati entro il tempo di attenuazione specificato ed infine aspettare per il tempo di attuazione specificato. Lutente pu interrompere leffetto attualmente in riproduzione cliccando il pulsante Stop. Lutente pu spostare verso lalto un effetto nel Controllo degli Effetti cliccando il pulsante Up. Lutente pu spostare verso il basso un effetto nel Controllo degli Effetti cliccando il pulsante Down. Lutente pu cancellare un effetto nel Controllo degli Effetti cliccando il pulsante Delete, che cancella leffetto attualmente selezionato. Il controllore si ferma quando lutente seleziona FileExit. Fine dellestratto del documento dei requisiti Lelenco seguente indica i nomi ottenuti dal precedente documento dei requisiti: sistema di controllo delle luci teatrali, ingegnere delle luci teatrali, luci teatrali, controlli di produzione, pannello frontale, indicatori, stato, controllore, intensit del canale, colore del canale, tempo di attesa del canale, tempo di attenuazione del canale, tempo di attuazione del canale, nome, effetto, utente, pulsante di registrazione, pulsante di riproduzione, controllo degli effetti, pulsante di interruzione, pulsante Up, pulsante Down, pulsante di cancellazione, effetto selezionato. Quando avete ottenuto un set di nomi, potete raggrupparli formando componenti effettivi del vostro sistema. La tabella seguente organizza i componenti in componenti pi astratti: Nomi Luci teatrali Indicatori Stato Pulsante di registrazione Pulsante di riproduzione Pulsante di interruzione Pulsante Up Pulsante Down Pulsante di cancellazione Controllo degli effetti Effetto selezionato Intensit del canale Nome Effetto Colore del canale Tempo di attesa del canale Tempo di attenuazione del canale Tempo di attuazione del canale Nomi astratti Hardware Display
OBIETTIVO
Progettare, implementare, collaudare e mettere in opera un sistema di controllo delle luci teatrali che permetta a un tecnico delle luci di controllare e programmare facilmente le luci teatrali per qualsiasi produzione. Comandi sul pannello frontale controllano il funzionamento del software di controllo delle luci teatrali. Indicatori sul pannello frontale indicano lo stato corrente del software di controllo delle luci teatrali.
Effetto
FUNZIONAMENTO GENERALE
Il controllore memorizza lintensit del canale, il colore del canale, il tempo di attesa del canale, il tempo di attenuazione del canale, il tempo di attuazione del canale ed il nome delleffetto quando lutente clicca il pulsante
Temporizzazione
27
SCUOLA DI LABVIEW
04
Applicando la tecnica di astrazione allintero documento dei requisiti si ha una soluzione per determinare un set di componenti astratti. Il sistema di controllo delle luci teatrali ha i seguenti componenti: Hardware, Display, Effetto, Temporizzazione, Errore e File. I componenti diventano i moduli del sistema. Nota I componenti astratti sono un set di componenti che vi permettono di modularizzare il sistema. Potete astrarre un numero infinito di componenti. Lesperienza e la conoscenza del problema vi permetteranno di astrarre il set migliore di componenti per lapplicazione. Luso di documenti dei requisiti correttamente formattati facilita la determinazione delle azioni per ogni modulo. Il documento dei requisiti contiene molti verbi ed espressioni verbali che rappresentano il comportamento del sistema e sono tipicamente correlati ai VI che definirete. Potete fare corrispondere i verbi e le espressioni verbali con i componenti astratti che eseguono le azioni. Consideriamo il seguente estratto dal documento dei requisiti di un sistema di controllo delle luci teatrali. Inizio dellestratto del documento dei requisiti
Quando avete ottenuto un set di verbi, potete organizzare i verbi per determinare le funzioni eseguite dai componenti astratti. Potete ignorare i verbi che non migliorano la vostra conoscenza del sistema, come cliccare nellelenco precedente. Dovete anche cercare di ricordare il contesto dei verbi. La tabella seguente organizza i verbi in componenti astratti. Verbo Disabilitare Abilitare Aggiornare Caricare Scrivere Attendere Smorzare Creando una frase per ogni verbo si migliora la leggibilit e si ottiene la seguente lista di funzioni. Espressione verbale Disabilita il pannello frontale Aggiorna il pannello frontale Ottieni leffetto Scrivi colore e intensit Attendi, esegui Smorza Eseguendo lanalisi verbale sullintero documento dei requisiti si pu generare un elenco delle singole azioni eseguite da ciascun componente. La tabella seguente elenca ciascun componente e le singole azioni eseguite dal modulo. Modulo Hardware Display Azioni Scrivi colore e intensit Inizializza il pannello frontale Aggiorna il pannello frontale Seleziona un effetto Abilita/disabilita il pannello frontale Aggiorna la lista degli effetti Aggiungi effetto Cancella effetto Preleva i valori delleffetto Imposta i valori delleffetto Scambia Preleva il numero degli effetti Preleva effetto vuoto Attendi Smorza Attua Crea report errori Gestisci errori Salva effetti Leggi effetti Componente astratto Display Effetto Hardware Temporizzazione Effetto Hardware Temporizzazione Componente astratto Display
RIPRODUZIONE
Cliccate il pulsante Play per riprodurre gli effetti registrati. Quando la riproduzione inizia, il controllore dovrebbe disabilitare i pulsanti di spostamento verso lalto degli effetti, spostamento verso il basso degli effetti, cancellazione, registrazione e riproduzione sul pannello frontale. I valori del primo effetto nellelenco degli effetti vengono caricati in memoria. Il controllore attende in base al numero di secondi specificato per il tempo di attesa delleffetto corrente. Il controllore quindi smorza o amplifica il canale in base allintensit corrente del canale stesso ed allintensit desiderata per il canale. Il software scrive il colore e lintensit nel sistema di controllo hardware delle luci teatrali ed aggiorna i canali sul pannello frontale. Il controllore deve finire lo smorzamento entro il tempo di smorzamento specificato. Il controllore finisce lelaborazione del tono aspettando il numero di secondi specificato per il tempo di attuazione delleffetto corrente. Quando la riproduzione terminata, il controllore deve abilitare i pulsanti di spostamento verso lalto degli effetti, spostamento verso il basso degli effetti, cancellazione, registrazione e riproduzione sul pannello frontale. Fine dellestratto del documento dei requisiti Estraete i verbi dallestratto del documento dei requisiti. Considerate il contesto dei verbi per stabilire le funzioni eseguite dai componenti astratti. Lelenco seguente indica i verbi dal precedente estratto del documento dei requisiti: cliccare, disabilitare, caricare, attendere, smorzare, scrivere, abilitare, aggiornare.
Effetto
28
SCUOLA DI LABVIEW
Dopo avere identificato le azioni ad alto livello per ogni modulo, potete dividere ciascuna azione in azioni pi piccole. Questa tecnica vi aiuter ad analizzare pi a fondo lapplicazione e ad assicurarvi che ciascun modulo esegua un solo compito. Se un modulo esegue pi di un compito, infatti, difficile testare il modulo e determinare se funziona correttamente. Se determinate che un modulo esegue pi di un compito, dividetelo in pi moduli. Con questo approccio, ogni modulo esegue un solo compito specifico. Creare un progetto software con questo livello di dettaglio vi aiuta a sviluppare VI scalabili, leggibili e consistenti di codice riutilizzabile.
da leggere e il codice per un compito pu influire sul funzionamento del codice di un altro compito. In questo caso, eliminare un errore in un compito potrebbe bloccare il codice di un altro compito. Un VI con una forte coesione ha un compito per modulo. La forte coesione diminuisce il tempo di sviluppo complessivo. Potete capire pi facilmente un singolo modulo, se esso focalizzato su un compito. Potete leggere rapidamente uno schema a blocchi pulito e senza complicazioni, eseguendo con sicurezza i cambiamenti deliberati. I VI e le funzioni matematiche forniti con LabVIEW dimostrano una forte coesione. Per esempio, la funzione Seno esegue un singolo compito e lo esegue bene. Essa un perfetto esempio di una funzione che ha una forte coesione. Il nome della funzione indica chiaramente ci che la funzione esegue. Altri VI che hanno una forte coesione sono i VI e le funzioni File I/O. I VI e le funzioni File I/O mostrano una coesione sequenziale, perch deve essere eseguito un modulo prima che ne possa essere eseguito un altro. Le funzioni Apri File, Leggi File, Scrivi File e Chiudi File eseguono un singolo compito ciascuna allinterno di ogni modulo. Dopo avere astratto i componenti, potete produrre uno schema che aiuta a visualizzare i componenti astratti. Usate lo schema per iniziare a progettare i singoli moduli nellapplicazione. Ogni componente astratto corrisponde ad un modulo allinterno dellapplicazione. Al livello superiore, definirete le azioni per ogni componente astratto. La definizione delle azioni vi permetter di determinare il compito specifico di ogni singolo modulo.
ACCOPPIAMENTO
Un modulo raramente vive da solo. Un VI viene richiamato da altri VI. I VI di livello superiore possono diventare dei plug-in in altri VI o utilit per il sistema operativo. Laccoppiamento indica le connessioni esistenti fra i moduli. Qualsiasi modulo che si basa su un altro modulo per eseguire qualche funzione accoppiato a quel modulo. Se un modulo non funziona correttamente, anche gli altri moduli a cui esso accoppiato non funzionano correttamente. Pi sono le connessioni fra i moduli, pi difficile determinare quale modulo causa un problema. Laccoppiamento misura quante dipendenze sono contenute in un sistema di moduli. Meno sono le uscite esposte da un modulo, pi potrete cambiare il codice allinterno del modulo senza bloccare altri moduli. Un basso accoppiamento contribuisce inoltre a rendere pi efficiente il tracciamento degli errori software. Per esempio, un errore di acquisizione dati non pu verificarsi in un VI che esegue solo un controllo di strumenti GPIB. Se in un VI GPIB appare un errore di acquisizione dati, sapete che il codice probabilmente ha un accoppiamento troppo stretto. Il modello a flusso di dati di LabVIEW incoraggia automaticamente un basso accoppiamento fra i moduli. Modello a flusso di dati significa che ogni VI ha solo linformazione che gli occorre per eseguire il suo compito. Un VI non pu cambiare i dati in un altro VI. Potete introdurre altri percorsi di comunicazione, come variabili globali, code, collegamenti di I/O, ecc. che aumentano laccoppiamento, ma un tipico VI autosufficiente e si accoppia solo con i SubVI che richiama. Lobiettivo di ogni architettura gerarchica fare in modo che limplementazione usi un accoppiamento limitato o nullo.
DIAGRAMMI DI FLUSSO
I diagrammi di flusso sono un modo potente per organizzare le idee relative a un blocco di codice. I diagrammi di flusso dovrebbero fornire una buona comprensione del flusso dellapplicazione. Il paradigma di programmazione basato su diagrammi a blocchi usato in LabVIEW facile da capire e simile a un diagramma di flusso. Molti tecnici usano gi i diagrammi di flusso per descrivere i loro sistemi. Il diagramma di flusso semplifica infatti la conversione del progetto in codice eseguibile. Lo scopo di un diagramma di flusso dividere in modo logico un compito in singole parti. Iniziate a progettare la gerarchia dei VI dividendo il problema in parti logiche. La figura 1 illustra un diagramma di flusso per la funzionalit Riproduzione relativa al Controllore delle luci teatrali.
COESIONE
In un VI ben progettato, ogni modulo esegue un solo compito ed quindi fortemente coesivo. Se un singolo modulo cerca di eseguire pi di un compito, dovreste probabilmente dividerlo in pi moduli. Quando un modulo cerca di eseguire pi compiti, lo schema a blocchi diventa pi difficile
29
SCUOLA DI LABVIEW
04
External Entity Rappresenta elementi esterni al sistema con i quali il sistema comunica. Data Flow Indica il flusso dei dati. La figura 3 illustra un diagramma a flusso di dati per la funzionalit Riproduzione nel Controllore delle luci teatrali. Notate come il focus di un diagramma a flusso di dati sia rappresentato proprio dai dati, concettualizzando il sistema in base al flusso dei dati attraverso il sistema, analogamente al paradigma a flusso di dati di LabVIEW. Anche se LabVIEW un linguaggio di programmazione a flusso di dati, comunque importante dedicare del tempo lontano da LabVIEW per progettare un sistema appropriato.
Figura 3. Diagramma a flusso di dati della funzione di riproduzione nel sistema di controllo delle luci teatrali
Figura 1. Schema di flusso della funzione di riproduzione nel sistema di controllo delle luci teatrali
Come potete vedere dalle differenze esistenti tra il diagramma di flusso e il diagramma a flusso di dati della funzione di riproduzione nel sistema di controllo delle luci teatrali, i processi sono differenti. I nodi del diagramma di flusso rappresentano le funzioni da eseguire. I nodi del diagramma a flusso di dati rappresentano invece i processi e lattenzione posta sul flusso dei dati attraverso il sistema. Potete tradurre un diagramma a flusso di dati in uno schema a blocchi di LabVIEW.
Note sullautore
Data Store Rappresenta file o archivi nel sistema. Process - Accetta dati in ingresso, elabora i dati e genera dati in uscita.
Laureato in ingegneria nucleare al Politecnico di Milano, Matteo Foini lavora in qualit di Technical Marketing Engineer presso National Instruments Italy
30
D A L L A C A RTA A L W E B
04
HTTP://WWW
Quando le nostre pagine non bastano, lenorme serbatoio del web pu dare una mano. Su una rivista cartacea, anche la pi voluminosa, sarebbe impossibile trattare per esteso tutti gli argomenti relativi a LabVIEW. In molti casi, tuttavia, sul web sono disponibili articoli esaustivi o altri documenti, a cui rimandiamo i lettori interessati Questo esempio ricrea il classico gioco della difesa missilistica e mostra luso del modulo Statechart di LabVIEW. Ridimensionate la finestra per esperienze di gioco differenti. Confrontate questo progetto con un secondo programma di difesa missilistica scritto sempre in LabVIEW utilizzando unarchitettura basata su una macchina a stati e variabili condivise. Link alla pagina: http://ni.com/info infocode:itendm
Acquisire e generare dati in continuain LabVIEW Real-Time ed inviarli ad un host tramite TCP/IP
Questo esempio acquisisce e genera dati temporizzati hardware in continua su un sistema operativo Real-Time. Nello stesso tempo, i dati vengono inviati allhost tramite TCP/IP per essere visualizzati e memorizzati in un file. Link alla pagina: http://ni.com/info infocode:itendm
32
D A L L A C A RTA A L W E B
ENTRA A FAR PARTE DELLA CERCHIA DI TECHNOLOGY LEADERS CHE COLLABORANO CON NATIONAL INSTRUMENTS
Scopri NI Labs su ni.com/labs
Che cosa sono gli NI Labs? NI Labs un progetto rivoluzionario: una vetrina, un contenitore con lanteprima delle ultime tecnologie di National Instruments appena uscite dal calderone creativo del reparto R&D, ma non ancora pronte per il rilascio ufficiale sul mercato. I laboratori virtuali di ni.com/labs offrono la possibilit all'utente curioso di scaricare le anteprime di prodotto e di contribuire attivamente alla loro ultima fase di sviluppo, offrendo preziosi feedback di prodotto, porre domande, ricevere risposte e conoscere tutto sui prodotti pi nuovi in progettazione. Ogni prototipo presentato contiene un kit di presentazione del progetto per facilitarne lesplorazione: Istruzioni per linstallazione Documentazione tecnica Esempi di esecuzione rapida Le tue domande e suggerimenti verranno immediatamente visionate da un ingegnere R&D di National Instruments. Esplora le seguenti sessioni su ni.com/labs e scopri in anteprima i futuri sviluppi di prodotto che ti aiuteranno a sviluppare le tue applicazioni e raggiungere i tuoi obiettivi.
Readerser vice.it n. 450
33
04
Vi presentiamo una selezione di argomenti di discussione sul Forum di ILVG.it
34
zeriCUT http://www.ilvg.it/ht/3506
Inviato: Ven Ott 26, 2007 5:57 pm ...salve...ho un array 2D, con un ciclo for 'prelevo' i singoli vettori, con un altro 'leggo' i singoli elementi...poi volevo eliminare gli zeri (che si trovano solo alla fine della forma d'onda...ma con scarso risultato!!!) Crying or Very sad dove sbaaaglioooooooo???? gianni1 Potresti fare una ricerca degli zeri nell'array (con il blocco Search, paletta Array) e poi cancellare l'elemento nella posizione corrispondente (con il blocco Delete, paletta Array). Oppure se sai che gli zeri sono in fondo puoi fare una ricerca (blocco Search) e dalla prima posizione trovata in poi cancellare il vettore. Ciao!! MagicBotolo si' potrei fare come dici tu...ma come ho fatto io non va bene?...nel senso che voglio capire perche' mi consigli di fare come dici tu oppure me lo hai detto solo per informarmi delle altre possibilita'...gianni1 Se sostituisci gli zero con dei NaN in ogni caso sono esenti dei "valori" nell'array, quindi se vai a verificare la lunghezza questa sar identica a prima. Io girerei l'array (il primo elemento diventa l'ultimo) e farei un delete element fintanto che l'ultimo elemento =0. Ovviamente per fare cio' non potrai passare direttamente il filo sul bordo del for con l'autoindexing ma dovrai sfruttare uno shift register, altrimenti l'array risultante resterebbe comunque lungo uguale a quello originale. ..ma ciao! gepponline Le soluzioni alternative che ti ho indicato non dovrebbero comportare grandi differenze, sono solo altri modi per lavorare sugli array. A volte bisogna valutare soluzioni diverse per migliorare le prestazioni del VI in termini di memoria e velocit di esecuzione. Lavorare sugli array pu rivelarsi pericoloso nel senso che LabView crea delle copie delle variabili durante alcuni procedimenti. Creare una copia dell'array pu voler dire, a volte, creare variabili aggiuntive grandi (se le posizioni dell'array sono tante). Ci sono alcune strategie che permettono di lavorare sugli array senza creare copie, manipolando direttamente l'array originale. In linea di massima si pu dire che se l'array entra in un blocco e ne esce modificato (in realt non bisognerebbe modificare la dimensione o il tipo dei dati... oppure le modifiche devono avvenire con un blocco solo...) non ci sono problemi a livello computazionale. Altrimenti la CPU fa i conti con variabili di troppo... Lo so, abbastanza incasinato e poco chiaro... ottimo! Very Happy Ciao!! MagicBotolo [continua su http://www.ilvg.it/ht/3506] gianni1
35
EVENTI
04
NIWEEK: UN APPUNTAMENTO DA
NON PERDERE
Valerio Alessandroni
Durante il grande evento annuale, realizzato con la formula della mostra-convegno, National Instruments ha presentato le proprie novit in termini di por tafoglio di tecnologie e prodotti
o scorso 7 agosto, James Truchard, presidente, CEO e cofondatore di National Instruments, ha dato inizio alla 13 edizione di NIWeek, la conferenza annuale sulla strumentazione virtuale.
LABVIEW 8.5
La novit pi importante stata introdotta nella sua keynote dallo stesso Truchard, che ha annunciato agli oltre 2.000 ospiti presenti la nascita di LabVIEW 8.5. La piattaforma LabVIEW, ideale per la progettazione di applicazioni multithread in parallelo, semplifica lo sviluppo di applicazioni multicore ed FPGA grazie al suo intuitivo linguaggio a flusso di dati, egli ha affermato. La diffusione dei processori multicore implica un bisogno crescente di linguaggi di programmazione paralleli in grado di sfruttare la velocit sempre maggiore dei processori multicore. LabVIEW, con la sua architettura multithread intrinseca, rappresenta una soluzione ideale. Truchard ha portato esempi reali di come la combinazione di LabVIEW e dei nuovi processori multicore fornisca elevate prestazioni di calcolo e funzionalit di I/O avanzate per il test, il controllo e la progettazione, come il caso dei ricercatori del Max-Planck-Institut fr Plasmaphysik che hanno osservato un incremento della velocit di elaborazione pari a venti volte utilizzando un processore a otto core piuttosto che un processore a core singolo. Nella sua keynote, Jeff Kodosky, socio e cofondato-
re di National Instruments, conosciuto comunemente come il padre di LabVIEW, ha invece illustrato la sua visione personale del futuro di LabVIEW cos come dell'attuale sfida della programmazione multicore. Kodosky ha poi descritto la visione globale della societ riguardo alla progettazione grafica di sistemi, ripercorrendo la storia del diagramma a blocchi di LabVIEW e parlando poi di una nuova prospettiva nel modo in cui LabVIEW sfrutta la moderna tecnologia grafica per rappresentare in modo sempre pi efficiente i componenti delle applicazioni e le loro connessioni, e per migliorare il supporto per target multipli. Grazie a LabVIEW System Diagram, attualmente in fase di sviluppo, ingegneri e scienziati useranno LabVIEW come una lavagna bianca eseguibile in grado di offrire diversi livelli di astrazione e specifiche di configurazione e comportamento flessibili ma rigorosamente definite. Le macchine moderne possiedono unit di elaborazione grafica incredibilmente potenti e i recenti sistemi operativi stanno puntando su interfacce utente molto sofisticate, ha sottolineato Kodosky. Anche LabVIEW deve quindi essere in grado di offrire esperienze evolute di pari livello. Egli ha pure dimostrato come la sfida dellelaborazione multicore che gli ingegneri devono fronteggiare non debba destare particolari preoccupazioni per le migliaia di utenti LabVIEW. "Il mondo parallelo, ha detto Kodosky. Siamo abituati normalmente a compiere diverse azioni nello stesso tempo, come camminare e mangiare un panino. Allora perch costringerci a pensare in modo sequenziale quando scriviamo programmi per computer?, egli ha affermato. Mentre il resto dellindustria lotta per venire alle prese con i processori multicore, voi programmatori LabVIEW potete continuare semplicemente a fare quello che avete sempre fatto e raccogliere i benefici del multicore. Come noto, Truchard, Kodosky e William Nowlin hanno fondato National Instruments nel 1976 quando lavoravano presso lUniversit del Texas di Austin. Truchard un
36
EVENTI
membro della National Academy of Engineering e un pioniere riconosciuto nel mondo della misura e dellautomazione. Kodosky ha inventato il linguaggio grafico di programmazione di LabVIEW, incoraggiando lo sviluppo e la diffusione della strumentazione virtuale e rendendo lautomazione degli strumenti disponibile a tutti gli ingegneri. un membro dellAssociation for Computing Machinery e dellInstitute of Electrical and Electronics Engineers (IEEE).
di test ridotti, per soddisfare nuove esigenze applicative, ha affermato Truchard. Le precedenti applicazioni di data streaming richiedevano sistemi dedicati proprietari, spesso molto costosi. Un esempio dei nuovi strumenti il generatore di forme donda arbitrarie a 16 bit NI PXIe-5442, che pu leggere da disco alla velocit di 100 MS/s (200 Mbyte/s) per la generazione di forme donda arbitrarie che possono raggiungere una lunghezza di parecchi terabyte. Ci permette di ridurre i tempi di test, eliminando il ritardo dovuto allupload delle forme donda attraverso i bus di controllo di strumenti pi lenti. Il modulo NI PXIe-5442 completa il digitalizzatore a due canali NI PXIe-5122 a 100 MS/s ed i moduli di I/O digitali a 32 canali, 32 bit, 25/50 MHz, NI PXIe-6536/7.
I SUMMIT
Durante NIWeek 2007, si sono svolti anche quattro summit tecnici su progettazione grafica di sistemi; comunicazioni RF e wireless; acustica e vibrazioni; e visione. I summit hanno offerto ai partecipanti keynote dedicate, addestramento tecnico sui prodotti e dimostrazioni fornite da sviluppatori NI e ricercatori leader nei rispettivi settori. I partecipanti hanno potuto assistere a dimostrazioni sul contenuto dei summit nel settore espositivo, presso gli stand corrispondenti. In particolare, il summit sulla progettazione grafica di sistemi, sponsorizzato da Intel e CMP Media, ha ospitato esperti provenienti sia da aziende che dal mondo accademico, tra cui esponenti Intel, Rensselaer Polytechnic Institute e Max Planck Institute. Nel corso del summit, stato spiegato come progettisti embedded esperti ed esperti di settore senza conoscenze di programmazione possono sfruttare le tecnologie pi avanzate nellambito della progettazione
37
EVENTI
04
che di calibrazione dei sensori di suono e vibrazioni, progressi nella prognosi per la manutenzione predittiva e laccelerazione dei test audio con lanalisi multitono. Infine, il summit sulla visione ha offerto ai partecipanti presentazioni interattive su argomenti come lo streaming dimmagini ad alta velocit e le tecnologie dei sensori. Il summit stato caratterizzato anche da workshop pratici su temi quali Completamento del sistema, che ha coperto lilluminazione, lottica, il software ed altre sfaccettature della visione artificiale, grazie al contributo di esperti provenienti da Edmund Optics, Basler, Flir e Sony. embedded. Per esempio, stato spiegato come linearizzare lo sviluppo embedded attraverso tool grafici ad alto livello e piattaforme di prototipazione flessibili. Gli argomenti della sessione hanno incluso limpatto commerciale delle piattaforme di progettazione, lingegneria di algoritmi, la meccatronica e casi concreti di progettazione embedded in settori quali il biomedicale, la ricerca, la progettazione di macchine, il settore industriale e quello automotive. Nel summit sulle comunicazioni RF e wireless, esperti di Freescale Semiconductor, University of California di San Diego e Wi-Fi Alliance hanno esaminato i progressi pi recenti nei tool di sviluppo per prodotti RF, wireless e di comunicazione. Il summit stato concepito sia per tecnici RF senza esperienza, sia per tecnici esperti, nonch per tecnici di sistemi di comunicazioni e wireless. Gli argomenti della sessione hanno incluso le radio definite via software, i trend emergenti nel wireless, le architetture di test riconfigurabili e lottimizzazione dei test di produzione. Il summit su acustica e vibrazioni ha ospitato esperti di Boeing, Sirius Satellite Radio e University of Cincinnati, che si sono rivolti a tecnici nei settori vibrazioni industriali, rumore automotive, NVH (vibration and harshness) e progettazione audio ed elettroacoustica. Le presentazioni ed i workshop pratici hanno offerto ai presenti informazioni preziose sulle ultime tecniche di analisi dei suoni e delle vibrazioni. Tra gli argomenti discussi, gli array di microfoni per lidentificazione del rumore; le misure e le analisi dintensit del suono, le tecni-
LANNO PROSSIMO
NIWeek 2008 si svolger ad Austin dal 5 al 7 agosto 2008. Perch non unire unesperienza professionale unica con una
38
REPORT
04
i conclude dopo 9 date il Mese della Formazione sullAutomazione Avanzata di National Instruments, una serie di corsi di mezza giornata dedicati alla programmazione dei sistemi PAC (Programmable Automation Control) per l'automazione ed il controllo e alla visione artificiale in ambito industriale. Fedele alla tradizione National Instruments, questo road show si prefiggeva l'obiettivo di formare il pubblico presente in sala sui temi caldi per il mercato nazionale dellautomazione, rispondendo ad una diffusa necessit di apprendere in tempi brevi contenuti da mettere subito in pratica. La prima sessione del corso si concentrata sulle piattaforme PAC come risposta ideale alle nuove esigenze di mercato di poter sfruttare la potenza di calcolo e le potenzialit del PC per applicazioni in ambito industriale. Dopo una breve introduzione sullarchitettura ed alcuni concetti di base quali determinismo e Real-Time, i tecnici NI hanno esplorato le funzionalit di NI LabVIEW Real-Time e LabVIEW FPGA per
la programmazione multithread, passando poi ad illustrare le pi efficaci tecniche di diagnostica e debugging con NI Execution Trace Toolkit e NI Real-Time System Manager, concludendo con i metodi di comunicazione tra chip FPGA e CPU Real-Time. La seconda sessione del corso era tutta dedicata ai sistemi di visione: componenti principali, tecniche di illuminazione, ottiche per telecamere, tecniche di programmazione IMAQ e utilizzo di sistemi embedded ed FPGA. I partecipanti al Mese della Formazione hanno potuto conoscere in anteprima assoluta le funzionalit della nuova Smart Camera di National Instruments, un prodotto innovativo in grado di rispondere allesigenza di compattezza ed integrazione di una soluzione unica, sempre programmata attraverso LabVIEW o tramite il software di configurazione, con diagramma a stati integrato, Vision Builder for Automated Inspection. Ottimi i feedback ricevuti dai partecipanti, che hanno segnalato di aver trovato spunti interessanti e coinvolgenti, sia sui PAC, sulla programmazione in real time, che per la visione, dove stata apprezzata in particolare la nuova Smart Camera.
39
REPORT
opo i successi ottenuti nella prima met dellanno, si ripetuto in settembre un evento di grande seguito e interesse, proponendo sei nuove date in altrettante citt italiane. Aggiornato nei contenuti, alla luce delle novit dellultima versione della piattaforma NI LabVIEW 8.5, cuore del seminario stato il mondo articolato della progettazione grafica di sistemi, con un taglio mirato al contesto della progettazione di sistemi di controllo e della simulazione di sistemi dinamici. LIng. Matteo Foini - Technical Marketing Engineer di National Instruments Italy - ha condotto le sessioni alternando esempi pratici a nozioni teoriche, per scandire in dettaglio le fasi che guidano un progettista verso la sintesi e la successiva implementazione di un sistema di controllo. Filo conduttore della discussione, le potenzialit offerte dal Graphical System Design quale approccio innovativo allo sviluppo di sistemi embedded. Come sottolinea lIng. Foini, Lintegrazione di tecnologie embedded investe da anni, in modo sempre pi capillare, mercati ad elevato profilo di innovazione, per applicazioni tecnologicamente evolute nei campi dellautomazione, della meccatronica e dei sistemi robotici. Nel contempo, si attesta un dato interessante che vede ambiti storicamente
40
poco inclini ad abbandonare standard di lavoro consolidati, cavalcare oggi attivamente londa del cambiamento in unottica di rinnovamento dei processi produttivi. Come ben noto, uno dei maggiori problemi che i progettisti devono affrontare la gestione del time-to-market, cio il tempo necessario per immettere un prodotto finito sul mercato. Per questo motivo, lintroduzione di nuove tecnologie di frontiera e la necessit di acquisire, in tempi brevi e in vari campi, un buon livello operativo di conoscenza, richiedono classi di nuovi esperti e ladozione di piattaforme dalto livello in grado di integrare diversi approcci allo sviluppo di progetti di sistemi anche molto complessi. Su questa visione si basa la piattaforma di sviluppo grafico NI LabVIEW e la logica espressa dal Graphical System Design.
REPORT
C2 - LA FORMULA VINCENTE
Valerio Alessandroni
Ancora una volta, la mostra-convegno organizzata da Edizioni Fiera Milano ha fatto len plein
i recentemente svolta la mostra-convegno C2 Control & Communication, un appuntamento annuale che questa volta approdato a Milano e a Bari. I due eventi sulle tecnologie pi recenti per lautomazione distribuita, dalla comunicazione a bordo macchina, alla comunicazione fra i dispositivi sul campo, fino al livello di supervisione e controllo, hanno registrato ancora una volta un elevato numero di visitatori. C2 Control & Communication diventata una delle pi importanti occasioni di aggiornamento per tutti gli addetti ai lavori che si occupano di bus di campo, raccolta dati, elaborazione e controllo distribuiti, interfacciamento uomo-macchina e supervisione, ha dichiarato un visitatore. La mostra-convegno integra perfettamente le informazioni fornite da riviste come Automazione Oggi e Fieldbus & Networks, offrendo in pi la possibilit di un contatto diretto con i protagonisti del settore ed altri utilizzatori che hanno problemi tecnici simili. Nel corso delle due giornate si sono svolti numerosi seminari tecnici a cura delle aziende partecipanti che, in un apposito spazio, hanno potuto esporre i loro prodotti specifici pi recenti. Unoccasione unica per toccare con mano prodotti che in precedenza avevo visto solo sulle pagine delle riviste specializzate o su cataloghi scaricati da Internet, ha affermato un altro visitatore. Inoltre, ho apprezzato molto la presenza di personale specializzato negli stand degli espositori, perch ho potuto dialogare con persone che parlano il mio stesso linguaggio. Toccare con mano lofferta commerciale delle singole aziende, confron-
tare le soluzioni di fornitori diversi, scambiare biglietti da visita, apprendere le basi o livelli pi avanzati della comunicazione sul campo Questa la chiave del successo di un evento come C2 Control & Communication. E i numeri hanno dato ragione alle aspettative pi rosee: ben 300 visitatori per ledizione del capoluogo lombardo e 175 per quella delledizione pugliese. Tutti i visitatori hanno potuto partecipare ai seminari tecnici ed approfondire le tematiche trattate direttamente presso gli stand espositivi. Il successo della giornata di Bari, in particolare, rappresenta un segnale molto incoraggiante sulla diffusione che le tecnologie di comunicazione industriale stanno trovando anche in regioni meno industrializzate rispetto a quelle del Nord Italia. Ho gradito molto il fatto che, per una volta, non sia stata necessaria una trasferta presso una delle grandi fiere di settore, come il Bias o il FluidtransCompomac, per ottenere le informazioni di cui avevo bisogno, ha dichiarato un visitatore dellevento di Bari. Finalmente, infatti, le maggiori imprese del settore si sono riunite nella mia zona. Ho quindi visitato la mostra ed ho assistito ad alcuni seminari senza perdite di tempo e, soprattutto, senza dovere affrontare le spese e le scomodit di un viaggio. Come noto, la mostra-convegno C2 Control & Communication nata come unione delle gi collaudate iniziative HMI & Software Automation e Fieldbus&Networks: dal sensore al PC. Ci a sottolineare la stretta complementariet dei mondi della comunicazione, del controllo, della presentazione grafica e della supervisione di macchine ed impianti, le cui tecnologie non possono vivere nellazienda se non a stretto contatto tra loro e come base indispensabile per la gestione dei livelli pi elevati dellimpresa. Parteciper senzaltro anche alla prossima edizione, ha riferito un visitatore. Il mio livello di conoscenza sar superiore a quello attuale, proprio perch lazienda in cui lavoro prevede di iniziare ad utilizzare soluzioni basate su fieldbus. Potr quindi rivolgere domande pi approfondite agli esperti presenti alla mostra-convegno, da cui spero di ottenere spunti concreti per il mio lavoro.
41
A P P U N TA M E N T I
04
Come sempre, vi segnaliamo i prossimi corsi di formazione di LabVIEW e i principali eventi internazionali che vedranno la partecipazione di National Instruments
EVENTI NI
AUTOMATED TEST SUMMIT VIRTUALE
Scopri le migliori tecniche e strategie per la progettazione di sistemi di test flessibili ed efficienti all' Automated Test Summit 2007. La quarta edizione dell'evento annuale organizzato da National Instruments si sposta online per offrire un accesso comodo alle ultime tendenze tecnologiche sulla progettazione efficace di sistemi di test automatizzati Questo evento gratuito si svolger dal vivo marted 27 novembre 2007; durante l'intera giornata potrai assistere alla presentazione delle keynote (in lingua inglese), partecipare attivamente alle numerose sessioni tecniche e interagire dal vivo con gli espositori di alcune della maggiori aziende di test grazie ad un ambiente espositivo virtuale. Sar anche possibile richiedere informazioni attraverso una chat dal vivo con consulenti tecnici di National Instruments in lingua italiana. Per registrarti: www.ni.com/testsummiteurope Online, 27 Novembre 2007
NIDAY 08
In collaborazione con Edizioni Fiera Milano, National Instruments ha il piacere di invitarti al Forum Tecnologico per la Strumentazione Virtuale - NIDays 08, l'annuale conferenza mondiale dedicata alla Strumentazione Virtuale e al Graphica System Design che nell'area dell'Europa mediterranea toccher le citt di Roma, Parigi, Madrid e Lisbona. Entra a far parte della comunit di ingegneri, tecnici, sviluppatori e professori che ruota attorno al mondo National Instruments e non perderti unintera giornata di sessioni tecniche interattive, applicazioni e sessioni hands-on dedicate agli ultimi sviluppi nei settori della progettazione, controllo, automazione, misura e acquisizione dati. Per registrarti: www.ni.com/italy/nidays Roma, 27 Febbraio 2008
CORSI DI LABVIEW
LABVIEW BASE I: INTRODUZIONE
Milano: dal 10 al 12 dicembre 07 dal 21 al 23 gennaio 08 dal 3 al 5 marzo 08 dal 10 al 12 dicembre 07 dal 4 al 6 febbraio 07 dal 22 al 24 gennaio 08
Roma: Padova:
42
I N T E R V I S TA
04
INTERVISTA
Siram ci racconta la propria esperienza con i corsi di formazione di LabVIEW (Base, Intermediate, Real-Time). Risponde per noi Federico Van der Velden, Responsabile Sistemi di Controllo presso la Direzione Gestione Tecnica.
grammazione ed utilizzare efficacemente gli strumenti resi disponibili da LabVIEW. Il corso Real Time stato necessario per realizzare applicazioni destinate a sistemi di controllo automatico efficienti che richiedano determinati tempi desecuzione dei cicli programma.
Come realizzata la D: Direzione Gestione Tecnica? Ci descriva la vostra esperienza: in termini di fabbisogno, di figure professionali coinvolte di tipologia di corsi svolti (base, intermediate, advanced)
R:
R:
Siram svolge attivit di gestione e manutenzione di impianti tecnologici, al servizio di strutture civili e industriali. La Direzione Gestione Tecnica costituisce un riferimento per le attivit tecniche e operative, in particolare per quanto riguarda la scelta dei sistemi di controllo automatico, supervisione e telegestione, essenziali per garantire e verificare lefficienza degli impianti. Anche se la realizzazione dei sistemi demandata a fornitori esterni, necessario disporre di collaboratori in grado di comprendere le logiche di regolazione implementate sui dispositivi di controllo automatico, ne consegue la necessit di preparare adeguatamente le figure professionali attraverso strumenti di formazione opportuni. Siram costantemente alla ricerca di soluzioni che permettano di fronteggiare i problemi inerenti i sistemi dautomazione dedificio (building automation), in costante e rapida evoluzione, ma frequentemente vincolati a contratti di manutenzione che, oltre a rivelarsi onerosi per il cliente finale, costituiscono un limite alle attivit che necessitano dinterventi rapidi e risolutivi per laggiornamento delle logiche di controllo automatico. LabVIEW si rivelato lo strumento adatto allo scopo ed ha permesso di realizzare strumenti video grafici per la simulazione dinamica dei sistemi di controllo per impianti di tipo Hvac (heating, ventilation, air conditioning). Lalternativa avrebbe richiesto la realizzazione di modelli fisici in scala ridotta. I corsi Base I e II ed Intermediate I e II sono stati essenziali per ottimizzare le attivit di pro-
PERCH LABVIEW? Come applicate nello specifico le esperienze acquisite? Quali sono i benefici a livello strategico ed economico derivati dalla scelta? Come stato messo in pratica il know how acquisito?
D:
Il rapporto di collaborazione con NI iniziato da circa un anno e mezzo e si sviluppato a fronte di esigenze specifiche nel settore dellautomazione dei sistemi di controllo destinati agli impianti di tipo Hvac. LabVIEW uno strumento di sviluppo estremamente efficiente, in quanto caratterizzato da un livello di flessibilit ed intuitivit dimpiego difficilmente riscontrabile con altri prodotti disponibili sul mercato. Premesso che il buon utilizzo dei criteri di programmazione resta comunque un requisito essenziale per lo sviluppo delle applicazioni, i benefici sono emersi fin dalle prime fasi dutilizzo, mirate alla creazione doggetti di base per il controllo degli impianti di tipo Hvac. I modelli realizzati con LabVIEW, oltre a richiedere un tempo di realizzazione estremamente ridotto, permettono di rappresentare graficamente i sistemi da analizzare, simulandone il com-
R:
43
I N T E R V I S TA
04
portamento su scale temporali opportune che consentono di valutare levoluzione delle variabili fisiche controllate nei processi. Un esempio pu essere costituito dal modello per simulare la regolazione termo igrometrica degli ambienti di un edificio mediante ununit di trattamento dellaria: il simulatore permette danalizzare la risposta della regolazione implementata, visualizzando landamento grafico dinamico delle temperature dellaria e delle azioni di riscaldamento, raffreddamento ed umidificazione lungo lintero processo di trattamento, dalla presa daria esterna, allambiente condizionato. La modularit di LabVIEW e la realizzazione ottimizzata di oggetti (VI) impiegati nellambito dei controlli per impianti Hvac, permette di utilizzare le medesime funzioni di controllo realizzate a scopo didattico, anche in applicazioni destinate al controllo reale attraverso dispositivi programmabili PAC, come i Compact Field Point. Per quanto concerne la realizzazione di sistemi di controllo automatico, la Direzione Gestione Tecnica in grado di collaborare attivamente con gli integratori di sistemi rendendo disponibili, in modalit controllata, eventuali librerie doggetti (VI), verificati, documentati e realizzati per il controllo degli impianti.
Avete condotto survey per verificare D: grado di soddisfazione? Difficolt riscontrate? Visione d'insieme?
Le difficolt principali sono costituite dalla scarsa conoscenza di LabVIEW nellambito dei sistemi di controllo per impianti di tipo Hvac. Lutilizzo di LabVIEW richiede un buon livello dimpegno iniziale per la preparazione delle librerie doggetti ottimizzati per il controllo; i risultati dellimpegno sono apprezzabili dal momento in cui possibile impiegare gli oggetti creati nella creazione del nuovo codice. Tempi e difficolt di programmazione si riducono via via che si definiscono nuovi oggetti dedicati al controllo. Si consideri che la preparazione tecnica media dei programmatori del settore spesso limitata allimpiego di applicazioni mirate che non consentono elevati gradi di libert e permettono di realizzare logiche di controllo sofisticate soltanto mediante codici complessi, poco versatili e vincolati da funzioni poco flessibili. LabVIEW non unapplicazione mirata a settori specifici ma per Siram si rivelato un ambiente di sviluppo facilmente accessibile in quanto permette di definire logiche di controllo estremamente sofisticate ed efficaci senza la conoscenza delle regole sintattiche caratteristiche dei linguaggi di programmazione tradizionali. Nellambito dellautomazione dei grossi edifici, LabVIEW, in abbinamento ai sistemi di controllo Compact Field Point e allhardware NI dedicato alla visione artificiale, permetterebbe di realizzare soluzioni integrate estremamente performanti, soprattutto grazie allimpiego degli algoritmi di riconoscimento delle immagini. Nella visione dinsieme si pu ritenere che, a fronte di una fase di studio ben organizzata e mirata ai problemi caratteristici degli impianti di tipo Hvac, possibile definire e realizzare un meta-ambiente di programmazione personalizzato, in grado dassolvere ogni esigenza di controllo attraverso codici finali estremamente compatti, leggibili e manutenibili.
R:
I BENEFICI DERIVATI DAI CORSI Esempi pratici di competenze acquisite per la risoluzione di problemi, quali i vantaggi ottenuti?
D:
R:
Gli esempi pratici concernenti le competenze acquisite sono riscontrabili nella semplificazione delle applicazioni create prima della frequentazione dei corsi Base II e successivi. La semplificazione del codice stata ottenuta grazie alla creazione di oggetti ottimizzati utilizzando a pieno le risorse rese disponibili in LabVIEW.
Quali sono stati i vantaggi concreti D: derivanti dall'adesione al pacchetto Membership? Quali altre figure professionali sono state coinvolte nei corsi di formazione e perch?
Ladesione al pacchetto Membership permette un ottimo livello di preparazione garantendo la possibilit di ripetere i corsi di formazione ritenuti pi importanti per le proprie esigenze professionali. Ogni modulo di formazione mirato alla divulgazione di argomenti specifici ed introduce nuovi concetti, rivedendo anche quanto affrontato nei corsi precedenti, attraverso lapplicazione diretta su postazioni di lavoro
R:
D:
R:
A pochi mesi dal termine del programma di corsi frequentati, il know how acquisito ha consentito alla Direzione Gestione Tecnica di realizzare applicazio-
44
I N T E R V I S TA
SCELTI PER TE
Abbiamo scelto per te alcune risorse utili per approfondire le tua conoscenza di LabVIEW.
Forum ILVG.it www.ilvg.it LabVIEW www.ni.com/labviewzone LAVA - LabVIEW Advanced Virtual Architects http://forums.lavag.org/home.html Community DevZone www.zone.ni.com Community on ni.com http://community.ni.com/ Mindstorm NXT http://www.ni.com/academic/mindstorms/community.htm Contenuti LabVIEW on ni.com www.ni.com/labview LabVIEW on ni.com/italy www.ni.com/labview/i LabVIEW Jobs http://www.labviewjobs.com/ The VI Road Show http://viroadshow.blogspot.com/
ni distribuibili dedicate al supporto decisionale. Limpiego di tali applicazioni permette ai responsabili operativi di valutare opportunit dinvestimento per il conseguimento del risparmio energetico. Lapplicazione stata accolta con entusiasmo dai tecnici addetti al settore, in quanto costituisce un riferimento attendibile per la valutazione del rientro economico degli investimenti mirati al risparmio energetico. Nel settore dellautomazione stato implementato un sistema dacquisizione dati e gestione per un gruppo di cogenerazione destinato alla produzione denergia elettrica e termica presso lOspedale di Piacenza. In questultimo caso il sistema di controllo gestisce la modulazione dalla potenza complessiva perseguendo lobiettivo di non superare mai il regime variabile che comporterebbe la cessione denergia elettrica alla rete esterna. Inoltre stato implementato un sistema di contabilit energetica termica ed elettrica, che permette dimpostare liberamente il calendario di tariffazione vigente, gestendo il funzionamento del gruppo secondo criteri di convenienza economica, nel rispetto dei parametri limite stabiliti per la valutazione dellefficienza energetica complessiva (Limite Termico ed Indice di Risparmio Energetico). Ogni fine mese, il sistema inoltra automaticamente, ad un destinatario liberamente configurabile, un messaggio SMS contenente la sintesi relativa allenergia prodotta e
consumata, con relativi valori dei parametri defficienza. La programmazione implementata potr essere perfezionate e replicata per impianti simili con un impegno di risorse estremamente ridotto.
D: R:
45
L A B V I E W E L AVO R O
04
AAA
RICERCHIAMO
ELECTRONIC TECHNICAL COORDINATOR (RIF. EDP/AUT/764) DEMATIC, con 3500 persone, 800 milioni di ? di fatturato, sedi sparse in America, Europa ed Australia; il nome di riferimento al mondo nel settore degli impianti per la logistica. Nella filiale Italiana lavora da qualche tempo un management volitivo, intraprendente con la giusta dose di vivacit e frizzantezza, che ha saputo portare la cultura del servizio al cliente e la spinta ad una costante ricerca di soluzioni tecnologiche avanzate e personalizzate. I risultati non si sono fatti attendere: il lavoro continua ad aumentare, le commesse si moltiplicano e c la necessit di incrementare lattuale organico di 100 risorse, ormai insufficiente. Requisiti: Per la nuova sede di Cernusco S/N ricerchiamo un ELECTRONIC TECHNICAL COORDINATOR Laureato in ingegneria elettrotecnica/elettronica/informatica, proveniente dal settore automazione, con linglese e capace nella progettazione di schede elettroniche e nello sviluppo di Firmware per Microprocessori. Cerchiamo competenze nei principali linguaggi di programmazione quali: C, C++ e Visual Basic, meglio ancora se conoscesse sistemi di modellazione come Mathlab, Labview e Simulink. Inserito nellarea Engineering lavorer principalmente nella definizione della architetture di sistema che concretizzer con il supporto ed il coordinamento di fornitori esterni, fino alla pianificazione e realizzazione dei test finali di validazione del prodotto. Il lavoro e le responsabilit non mancano, lideale per chi vuole crescere professionalmente. I candidati ambosessi mandino il C.V. a: ANDREA POLETTI & ASSOCIATI Via Carlo Maria Maggi 2, 20154 Milano, tel. 02.45.71.26.61 e-mail cv@andreapoletti.it fax 02.45.71.91.62 citando il riferimento e rilasciando specifica
Conoscete bene LabVIEW? Date unocchiata alle offerte di lavoro che abbiamo selezionato da ILVG.it
autorizzazione al trattamento dei dati personali ai sensi della legge sulla Privacy (D.L. 196/03). Data di pubblicazione: 18/10/2007 Sede di Lavoro: Lombardia Prov. MI Categoria Ruolo: Engineering Titolo di studio richiesto: Laurea in ingegneria elettrotecnica/elettronica/informatica www.talentmanager.it
TECNICO ELETTRONICO -RIF H 7084 Per grande gruppo che opera in campo elettronico vicinanze Varese cerchiamo Tecnico Elettronico per la progettazione hardware elettronico e software per attrezzature di collaudo e realizzazione documentazione relativa. Il candidato ideale un Perito Elettronico o simili, et indicativa 30 anni circa, esperienza pregressa nel settore, ottima conoscenza di Visual Basic e/o di Labview. Studioemme Srl Via Veronese 2 21100 Varese Tel. 0332/241720,0332/239656 Fax 0332/497462 Email: cv@studioemme.va.it Data di pubblicazione: 18/10/2007 Sede di Lavoro: Lombardia Prov. VA Categoria Ruolo: Engineering Titolo di studio richiesto: Perito elettronico www.studioemme.va.it
OFFERTA DI STAGE PER SVILUPPO AREA SW SU PIATTAFORMA NATIONAL INSTRUMENTS PER BANCHI DI COLLAUDO SET TOP BOX BAMES S.r.l. (Bartolini After Market Electronics Services), azienda leader nella fornitura di Servizi Innovativi per lIndustria Elettronica, ricerca per la consociata SEM S.r.l. (Services for Electronic Manufacturing), azienda leader nelle tecnologie elettroniche sita in Vimercate (MI) Web sites: www.semtechnologies.it www.bartoliniames.it Requisiti: Il candidato dovr acquisire le conoscenze
SW dei tools National Instruments (quali LabView e TestStand) per realizzare un banco di collaudo che permetta di verificare le funzionalit di prodotti nell'area Set Top Box. Nello specifico si tratta di collaborare con il sistemista che ha disegnato il banco di collaudo e di automatizzare sia i singoli step di test che l'intera sequenza di collaudo. Le principali funzioni da collaudare sono legate all'area Audio/Video (DVB, Composito, RGB, Spdif, e simili), all'area di networking e traffico dati (USB, ethernet, ecc) ed all'area di IT (per colloquio con il processore). Sono disponibili i SW di sviluppo, la strumentazione di collaudo ed il supporto di personale qualificato in materia. Il profilo: Laurea Specialistica in Ingegneria Informatica o Ingegneria dellAutomazione, conseguita da meno di 18 mesi. Esperienza richiesta : nessuna Conoscenze di programmazione e preferibilmente conoscenze LabView e Test Stand Buona conoscenza della lingua inglese Conoscenza Windows 2000 (livello base) Lofferta si riferisce ad uno STAGE di 6 mesi (prorogabili), da effettuarsi presso lo Stabilimento SEM di Vimercate (MI), nellarea TEST DEVELOPMENT. Sono previsti : rimborso spese pari a 600 Euro mensili utilizzo gratuito mensa aziendale utilizzo gratuito trasporti aziendali da/per Cologno Monzese Nord o Stazione Ferroviaria di Carnate (MI) Riferimento: SEM004-S Data di pubblicazione: 10/10/2007 Sede di Lavoro: Lombardia Vimercate. Categoria - Ruolo: Stage - Test Development Titolo di studio richiesto: Ingegneria Informatica o Automazione www.stepstone.it
ANALISTA PROGRAMMATORE C++ TMS S.r.l., azienda in forte espansione nel settore dei sistemi di automazione hardware/software per la nautica da diporto, ricer-
46
L A B V I E W E L AVO R O
ca, per il potenziamento della propria struttura di Ricerca & Sviluppo: 1 analista programmatore in C++ Requisiti: Titoli preferenziali: - forte motivazione ad operare con obiettivi sfidanti in un ambiente dinamico e altamente innovativo - conoscenza del protocollo NMEA - conoscenza di LabView - conoscenza della lingua inglese (scritta e parlata). La retribuzione sar proporzionale all'esperienza ed all'aderenza al profilo richiesto. Sede di lavoro: Pomezia (RM) Inizio previsto: immediato. Gli interessati devono inviare all'indirizzo e-mail v.lombardi@gruppo-rs.it un dettagliato C.V. in formato DOC o PDF, indicando il riferimento "C++". L'e-mail deve essere corredata di riferimenti contrattuali, autorizzazione al trattamento dei dati personali ai sensi del D.Lgs. 196/03 e autocertificazione ai sensi del DPR 445/2000. L'offerta da intendersi nel rispetto delle norme sulle parit di trattamento in materia di occupazione e di condizioni di lavoro (L.903/77, L.125/91, D.Lgs. 215/03 e 216/03). Data di pubblicazione: 23/10/2007 Sede di Lavoro: Lazio - Pomezia (RM) www.job-net.it
senti nel sito www.catapulta.it devono intendersi riferiti a personale sia maschile che femminile ai sensi dell'articolo 1, 1 comma della legge 9/12/77 n. 903 che vieta qualsiasi discriminazione indipendentemente dalle modalit di assunzione e qualunque sia il settore o ramo di attivit. Riferimento: 7084 Data di pubblicazione: 12/10/2007 Sede di Lavoro: Lombardia - Varese Categoria Ruolo: tempo indeterminato www.catapulta.it
TECNICO ELETTRONICO Per grande gruppo che opera in campo elettronico vicinanze Varese cerchiamo Tecnico Elettronico per la progettazione hardware elettronico e software per attrezzature di collaudo e realizzazione documentazione relativa. Il candidato ideale un Perito Elettronico o simili, et indicativa 30 anni circa, esperienza pregressa nel settore, buona conoscenza Visual Basic, Labview. Per candidarsi: Studioemme Srl - agenzie di ricerca e selezione via Veronese 2, 21100 Varese Tel. 0332 / 241720 - 0332 / 239656 Fax 0332 / 497462 Tutte le offerte di lavoro e gli articoli pre-
TECNICO DI SUPPORTO ALLA PROGETTAZIONE DI ALIMENTATORI DI POTENZA La posizione dovr provvedere a: Supporto sviluppo unit hardware Collabora allo sviluppo di unit elettroniche di potenza ed in particolare: dovr supportare nella definizione del progetto elettrico, nella redazione dei documenti di specifica e delle procedure di collaudo degli apparati. Dovr supportare nelle attivit di ricerca dei fornitori e nella normalizzazione dei componenti. Dovr elaborare ed eseguire i test di laboratorio, secondo procedure di collaudo automatizzato Predisposizione dei tool di collaudo (hardware e software) necessari allesecuzione dei test e realizzazione di banchi di test automatici ed effettuare il trasferimento della documentazione in produzione per le fabbricazioni di serie Requisiti: Requisiti e competenze richieste alla Posizione: Perito elettronico/elettrotecnico con almeno due anni di esperienza nellambito dello sviluppo di circuiti elettronici di potenza (alimentatori, reti di distribuzione di potenza) Conoscenza delle problematiche connesse alla distribuzione delle alimentazioni ed alla loro realizzazione ed installazione sui sistemi. Conoscenza di software per la realizzazione di banchi di test automatici (Labview o equivalenti). Capacit di utilizzo degli strumenti di
misura (analizzatori di spettro, oscilloscopi digitali, power meter, RF sweep oscillator, sonde alta tensione etc.). Esperienza nella redazione di documenti di specifica e di collaudo di apparati elettronici. Conoscenza dei pacchetti di office automation (MS Office o equivalenti). Disposizione al lavoro in team. Requisiti Preferenziali Capacit di identificazione componenti e fornitori via WEB e conoscenza del mercato degli alimentatori Conoscenza di tool di simulazione schematici (Microsim, Orcad o equivalenti). Disponibilit ad effettuare trasferte nazionali ed internazionali. Conoscenza della lingua Inglese. Riferimento: OC/RM Data di pubblicazione: 4/10/2007 Sede di Lavoro: Lazio - Roma Titolo di studio richiesto: Perito elettronico www.stepstone.it
SOFTWARE ENGINEER - SPAIN We are looking for a self-motivated individual that will play a key role in our efforts to expand our operations. He/She will design the application software needed to our manufactured equipments and its start-up in the customer's facilities. The engineer may be asked occasionally to travel to different job sites for installation and customer training or support. Experience with LabWindows/CVI, Visual C, Visual Basic, SQL and Database would be a plus. A good level in English spoken and written is required. We offer immediate incorporation to company with international and innovative vocation, work in team and Retribution in function of the candidate's value. Job Type: Permanent Main job experience: General Test Other LabVIEW experience required: Test applications - Data acquisition - Industrial communication . Company Name: Mapro Sistemas de Ensayo, S.A. Country: Spain - Town: SAN FRUITOS DE BAGES www.labviewjobs.com
47
INFORMATIVA AI SENSI DEL CODICE IN MATERIA DI PROTEZIONE DEI DATI PERSONALI (Decreto Legislativo n. 196 del 30 giugno 2003) Il Decreto Legislativo n. 196 del 30 giugno 2003 ha la finalit di garantire che il trattamento dei Vostri dati personali si svolga nel rispetto dei diritti, delle libert fondamentali e della dignit delle persone, con particolare riferimento alla riservatezza e allidentit personale. Vi informiamo, ai sensi dellart. 13 del Codice, che i dati personali da Voi forniti ovvero altrimenti acquisiti nellambito dellattivit da noi svolta, potranno formare oggetto di trattamento, per le finalit connesse allesercizio della nostra attivit. Per trattamento di dati personali si intende la loro raccolta, registrazione, organizzazione, conservazione, elaborazione, modificazione, selezione, estrazione, raffronto, utilizzo, diffusione, cancellazione, distribuzione, interconnessione e quantaltro sia utile per lesecuzione del Servizio, compresa la combinazione di due o pi di tali operazioni. Il trattamento dei Vostri dati per le finalit sopraindicate avr luogo prevalentemente con modalit automatizzate ed informatiche, sempre nel rispetto delle regole di riservatezza e di sicurezza previste dalla legge, e con procedure idonee alla tutela delle stesse. Il titolare del trattamento dei dati personali Edizioni Fiera Milano S.p.A., con sede legale in Milano, nella persona del legale rappresentante; responsabili del trattamento sono i dipendenti e/o professionisti incaricati da Edizioni Fiera Milano S.p.A., i quali svolgono le suddette attivit sotto la sua diretta supervisione e responsabilit. Il conferimento dei dati personali da parte Vostra assolutamente facoltativo; tuttavia leventuale rifiuto ci rende impossibile lesecuzione di alcun adempimento contrattuale. I dati, o alcuni di essi, per i fini di cui dianzi, potranno essere comunicati a: societ appartenenti al medesimo gruppo societario di cui fa parte Edizioni Fiera Milano S.p.A.; soggetti esterni che svolgano funzioni connesse e strumentali alloperativit del Servizio, come, a puro titolo esemplificativo, la gestione del sistema informatico, lassistenza e consulenza in materia contabile, amministrativa, legale, tributaria e finanziaria; soggetti cui la facolt di accedere ai dati sia riconosciuta da disposizioni di legge o da ordini delle autorit. Un elenco dettagliato dei predetti soggetti disponibile presso Edizioni Fiera Milano S.p.A. Vi informiamo, inoltre, che potrete consultare, modificare, opporVi o far cancellare i Vostri dati o comunque esercitare tutti i diritti che Vi sono riconosciuti ai sensi dellart. 7 del Codice, inviando una lettera raccomandata a Edizioni Fiera Milano S.p.A. Via Salvatore Rosa, 14 - 20156 Milano. Se volete consultare il testo completo del Codice in materia di protezione dei dati personali, visitate il sito ufficiale dellAutorit Garante www.garanteprivacy.it
LabVIEW World - La prima rivista italiana per la comunit di LabVIEW Sede legale - Via Salvatore Rosa 14, 20156 Milano, tel +39 02 366092.1 fax +39 02 366092.280 www.edizionifieramilano.it Sede Operativa - Viale Espinasse 141, 20156 Milano tel. +39 02 366092.1 fax +39 02 366092.525 Direzione Sergio Maggioni Presidente Costante Casali Amministratore Delegato Alberto Taddei Publisher Nadia Albarello, Matteo Bambini, Matteo Foini, Alessandro Ricco, Alberto Taddei Direttore Responsabile - alberto.taddei@edizionifieramilano.it Valerio Alessandroni Direttore Tecnico valerio.alessandroni@tiscali.it Alessandra Pelliconi, Maddalena Pria Segreteria- tel: 02 366092.527 alessandra.pelliconi@edizionifieramilano.it Collaboratori: Nicola Bavarone, Michele Corr, Massimo Lorenzi, Marco Luciani, Enzo Nava, Alessandro Ricco, Emanuele Stucchi, Franco Trespidi, Halvor Snellingen Grafica e produzione Bimage.it Progetto grafico e Impaginazione Franco Tedeschi Coordinamento grafici - franco.tedeschi@edizionifieramilano.it Alberto Decari Coordinamento DTP - alberto.decari@edizionifieramilano.it Sate Zingonia Verdellino - BG - Stampa Giuseppe De Gasperis Sales Manager giuseppe.degasperis@edizionifieramilano.it - tel. 02366092 523 - fax: 02 366092 230 Agenti Italia: PIEMONTE, LIGURIA, VALLE D'AOSTA R. Romeo/Publikappa tel: 011-723406 fax: 011-723.406 cell 335-5304196 VENETO, TRENTINO ALTO ADIGE, FRIULI VENEZIA GIULIA Idelfonso Elburgo tel: 049-8642.988 fax: 049-8642989 cell 328-8855203 International Sales U.K.-SCANDINAVIA - OLANDA - BELGIO The Huson European Media Gerry Rhoades-Brown tel: +44-1932-564999 fax: +44-1932-564998 SWITZERLAND: Iff media ag Carla Widmer tel: +41-52-6330888 fax: +41-52-6330899 GERMANIA e AUSTRIA: Mediaagentur Adela Ploner tel: +49-8131-3669920 fax: +49-8131-3669929 USA: Huson European Media Usa Ralph S. Lockwood tel: +1-408-8796666 fax: +1-408-8796669 TAIWAN: Worldwide Services Stuart Phillips-Laurie tel: +886-4-2325-1784 fax: +886-4-2325-2967 Abbonamenti N. di conto corrente postale per sottoscrizione abbonamenti: 48199749 intestato a:Edizioni Fiera Milano SpA, Via Salvatore Rosa 14, 20156 Milano. Si accettano pagamenti anche con le principali carte di credito. Per gli utenti Developer Suite e standard Service Program di National Instruments gi incluso labbonamento alla rivista Abbonamento annuale (4 numeri): E 20,00 Abbonamento per l'estero (4 numeri) E 40,00 Prezzo della rivista: E 5,00 - Arretrati: E 10,00 Testata associata Associazione Nazionale Editoria Periodica Specializzata Edizioni Fiera Milano iscritta al Registro Operatori della Comunicazione n 11125 del 25/07/2003. Autorizzazione alla pubblicazione del tribunale di Milano n 754 del 11/12/2006. Tutti i diritti di riproduzione degli articoli pubblicati sono riservati. Manoscritti, disegni e fotografie non si restituiscono. LabVIEW World ha frequenza trimestrale, per un totale di 4 numeri all'anno. Tiratura del presente numero: 3.000 copie.
Pubblicit
48