CONDIVISE USARE LE VARIABILI IN LABVIEW OTTIMIZZARE I TEST AUTOMATIZZATI PER PROCESSORI MULTICORE COME SVILUPPARE CON SUCCESSO SETTEMBRE E 5,00

Transcript

1 SETTEMBRE 2007 E 5,00 ISSN L A P R I M A R I V I S T A I T A L I A N A P E R L A C O M U N I T À L A B V I E W USARE LE VARIABILI CONDIVISE IN LABVIEW OTTIMIZZARE I TEST AUTOMATIZZATI PER PROCESSORI MULTICORE COME SVILUPPARE CON SUCCESSO IN LABVIEW

2

3 SCENARIO LABVIEW SFRUTTA LA POTENZA DEI PROCESSORI MULTICORE Ci siamo: è nato LabVIEW 8.5! Nel corso di NI Week 2007, in una ballroom affollata da oltre 3000 persone in perfetto silenzio, James Truchard, presidente, CEO e cofondatore di National Instruments, ha dato l annuncio che tutti aspettavamo. E la nuova versione ci permetterà di fare grandi cose! Intanto, dopo quasi 10 anni di investimenti nella tecnologia multithreading, LabVIEW 8.5 semplifica lo sviluppo di applicazioni basate sia su processori multicore che su Fpga, grazie al suo intuitivo linguaggio a flusso di dati. Inoltre, LabVIEW estende ulteriormente la piattaforma di programmazione grafica nelle applicazioni embedded ed industriali, con il nuovo modulo di progettazione a grafico di stati per modellare ed implementare il comportamento di sistema. Per non parlare delle nuove librerie di I/O e di funzioni analitiche per il monitoraggio ed il controllo industriale Ma procediamo con ordine, partendo da una citazione fatta proprio dal Dottor T : La rivoluzione rappresentata dall elaborazione concorrente sarà probabilmente più esplosiva della rivoluzione portata dai sistemi operativi (dal libro The Free Lunch is Over di Herb Sutter, Microsoft). E, con il passaggio ai processori multicore sul PC, i programmatori LabVIEW potranno beneficiare di un approccio grafico semplificato al multithreading, che permetterà di massimizzare le prestazioni della tecnologia multicore con minime modifiche delle applicazioni. Il motivo è semplice: LabVIEW ha già un architettura intrinsecamente parallela. Il linguaggio a flusso di dati parallelo di LabVIEW permette perciò di mappare facilmente le proprie applicazioni su architetture multicore e Fpga per data streaming, controllo, analisi ed elaborazione dei segnali. Basandosi sulla capacità multithreading automatica delle precedenti versioni, LabVIEW 8.5 gestisce le applicazioni degli utenti in funzione del numero di core disponibili ed offre driver e librerie a prova di thread per migliorare il throughput delle applicazioni RF, di I/O digitale ad alta velocità e di test a segnali misti, ha aggiunto Truchard. In più, LabVIEW 8.5 offre il multiprocessing simmetrico (SMP) con l ambiente LabVIEW Real-Time, dove i progettisti di sistemi embedded ed industriali possono automaticamente caricare task bilanciati su più core senza sacrificare il determinismo. Con l ultima versione di LabVIEW, gli utenti possono assegnare manualmente parti di codice a specifici core processori per mettere a punto sistemi real-time o isolare parti di codice critiche nel tempo su un core dedicato, ha sottolineato Truchard. Un linguaggio di programmazione richiede 15 anni per essere adottato su vasta scala, aveva affermato il Dottor T nel 1986, quando fu introdotto LabVIEW. Oggi, ben lungi dall essersi conclusa, l evoluzione di LabVIEW prosegue: progressi nel multiprocessing, il modulo LabVIEW Statechart, progressi sul LabVIEW to the pin per LabVIEW Fpga, simulazione Fpga prima della compilazione, miglioramento delle prestazioni di LabVIEW e dei toolkit ed integrazione con tool di progettazione meccanica come SolidWorks sono solo degli esempi. Perché la soddisfazione del viaggiatore è nel viaggio stesso, ha concluso Truchard, citando Steve Jobs, Apple Computer. Un emozionato Dottor T ha quindi lasciato il palco, tra le ovazioni dei presenti. Valerio Alessandroni 1

4 SOMMARIO LABVIEW SFRUTTA LA POTENZA DEI PROCESSORI MULTICORE Nel corso di NI Week 2007 è stato presentato LabVIEW 8.5 LABVIEW: IL PUNTO DI VISTA DELL R&D Un nutrito team di ingegneri lavora quotidianamente al progetto LabVIEW TOOL DI REPLICA DI SISTEMI REAL-TIME Un file eseguibile e alcuni VI per la replica di sistemi LabVIEW Real-Time CONTROLLO SIMULTANEO DI PANNELLI FRONTALI REMOTI Controllo remoto simultaneo delle applicazioni COME USARE LE VARIABILI CONDIVISE IN LABVIEW L articolo introduce le variabili condivise e loro caratteristiche e prestazioni OTTIMIZZARE APPLICAZIONI DI TEST AUTOMATIZZATI PER PROCESSORI MULTICORE Usando tecniche di programmazione parallela 24 UN'APPARECCHIATURA PER LA COLTURA DI CELLULE 26 L'invenzione descritta nell'articolo è coperta da un brevetto congiunto Ispesl-CNR DERT: DATA EVALUATION REAL TIME Un sistema a basso costo e flessibile per valutare sistemi di Difesa COME SVILUPPARE CON SUCCESSO Questo articolo descrive tecniche di sviluppo basate su anni di esperienza nell ingegneria del software DALLA CARTA AL WEB Come sempre, la rubrica offre una serie di link ad articoli di approfondimento o altri documenti disponibili sul web LA VOCE DEGLI UTENTI Alessandro Ricco ha selezionato alcuni spunti di discussione apparsi sul Forum di ILVG.it ILVGDAY: LA COMUNITÀ DI LABVIEW SI RIUNISCE Il 23 giugno si è svolto il primo ILVGDAY FORUM AEROSPAZIO E DIFESA 2007: MISSIONE COMPIUTA Grande successo per la terza edizione dell evento organizzato a Roma da NI 44 APPUNTAMENTI National Instruments sarà presente a numerosi eventi, oltre ad organizzare propri corsi e seminari. Scegliete quelli che vi sono più comodi 46 IL DEBUG DI VI Per avviare un VI, dovete collegare tutti i subvi, le funzioni e le strutture con i tipi di dato corretti per i terminali LABVIEW E LAVORO Sapete utilizzare LabVIEW? Forse troverete la proposta che fa per voi AAA Per il contributo apportato al progetto LabView World, si ringraziano: Valerio Alessandroni, Lino Fiore, Matteo Bambini, Nadia Albarello, Matteo Foini, Alessandro Ricco. Progetto grafico e impaginazione: Bimage.it SEI UN FAN DI LABVIEW? ENTRA NELLA NOSTRA COMUNITÀ! Caro lettore, se ritieni che questa nuova iniziativa LabVIEW World sia un utile strumento per la tua attività e desideri continuare a rimanere aggiornato sul mondo LabVIEW, collegati alla pagina

5 A TU PER TU LABVIEW: IL PUNTO DI VISTA DELL R&D Valerio Alessandroni Un nutrito team di ingegneri lavora quotidianamente al progetto LabVIEW. Ma anche altri team R&D, la rete commerciale e gli utenti LabVIEW interni ed esterni hanno molta voce in capitolo In occasione di NIWeek 2007 abbiamo intervistato Jeff Washington, Principal Engineering nel gruppo R&D di LabVIEW. Egli ci ha spiegato come vengono prese le decisioni che sostengono la costante evoluzione del software di programmazione grafica National Instruments. In National Instruments da 13 anni, Jeff Washington dirige attualmente un gruppo di altri quattro ingegneri, ma dedica la maggior parte del suo tempo ad attività di ricerca e sviluppo. I progetti sui quali lavora il mio gruppo sono cambiati spesso negli ultimi anni, egli ha affermato. Principalmente, siamo oggi responsabili del LabVIEW Project e di alcune altre parti di funzionalità interne. Attualmente, metà del mio team è impegnato su un grosso sforzo in ambito real-time, che abbiamo intrapreso in vista di una futura release. Come è organizzato il gruppo D: R&D di LabVIEW? La nostra organizzazione ha una struttura R: tipicamente piramidale, che cambia nel tempo per adattarsi meglio ai progetti sui quali siamo focalizzati. Guardando le cose da un livello elevato, siamo organizzati in gruppi focalizzati principalmente sul prodotto LabVIEW core e su Real-Time, Fpga, LabVIEW Embedded, Matematica, Analisi dei segnali, Elaborazione dei segnali, ecc. I responsabili di tali gruppi rispondono direttamente al Vicepresidente R&D di National Instruments. Naturalmente, come dicevo, la struttura dei gruppi non rimane fissa, perché quando una certa parte del progetto è terminata le risorse disponibili vengono riallocate sulle altre parti. Questo movimento di persone è utile, perché le personalità e le competenze dei singoli vengono continuamente ricombinate, permettendo spesso di risolvere problemi che nella configurazione precedente non avevano trovato una risposta valida. E comunque molto importante per noi trovarci nello stesso luogo geografico e sotto la stessa leadership, per avere una direzione comune, velocizzare le comunicazioni e reagire più tempestivamente alle decisioni prese. Fig. 1 Afferma Jeff Washington, Principal Engineering nel gruppo R&D di LabVIEW: Molte delle nuove caratteristiche che entrano in LabVIEW provengono direttamente dalla base utenti. Da dove giungono le idee di nuove funzionalità e caratteristiche nelle nuove versioni di D: of LabVIEW? Come vengono discusse (brainstorming, meeting, strategia/marketing)? Le idee di nuove caratteristiche e miglioramenti di R: LabVIEW provengono da molte sorgenti diverse. Gli utenti interni ed esterni forniscono, a noi del gruppo R&D di LabVIEW, un costante feedback nel corso dell anno. A una parte di questo feedback possiamo rispondere rapidamente introducendo cambiamenti nella prossima versione di LabVIEW, mentre altro feedback richiede soluzioni più a lungo termine, che possono dipendere da altre caratteristiche previste sulla nostra roadmap o da nuove tecnologie emergenti. Un buon esempio di quanto ho detto è rappresentato dai 3

6 A TU PER TU considerevoli cambiamenti e miglioramenti apportati al LabVIEW Project in LabVIEW 8.5. Il LabVIEW Project è stato introdotto per la prima volta nel 2005 con LabVIEW 8 e, benché abbia certamente semplificato lo sviluppo in LabVIEW in vari modi, NI ha raccolto da molti utenti l esigenza di ulteriori caratteristiche e comportamenti. Nell Agosto del 2006, molti dei nostri utenti più avanzati si sono riuniti in modo informale durante NIWeek, la nostra conferenza degli utenti che si svolge annualmente ad Austin, in Texas, ed hanno discusso dei vari problemi che dovevano affrontare quando utilizzavano il LabVIEW Project. Il risultato diretto di quel meeting è stato che io stesso e molti altri sviluppatori del gruppo R&D di LabVIEW abbiamo iniziato a formulare soluzioni per i problemi che erano stati descritti. Abbiamo discusso in riunioni di brainstorming diverse idee e finalmente abbiamo definito un set di nuove caratteristiche che, eravamo certi, avrebbero risolto tali problemi. Nel corso degli ultimi 12 mesi, abbiamo rifinito iterativamente queste caratteristiche, oltre a richiedere un input periodico ai clienti per essere sicuri di trovarci sulla strada giusta. Il risultato è una grande suite di caratteristiche in LabVIEW 8.5 progettate per offrire al programmatore LabVIEW strumenti migliori di gestione dei file e debugging nell ambito del LabVIEW Project. In che modo tenete conto ed implementate il D: feedback che proviene dalla grande base utenti di LABVIEW? Molte delle nuove caratteristiche che entrano in R: LabVIEW provengono direttamente dalla base utenti. La nostra sorgente primaria di feedback è il database online di suggerimenti sui prodotti, dove gli utenti possono sottoporre richieste di caratteristiche che vanno direttamente al gruppo R&D. Osserviamo anche i nostri forum utenti ed i meeting di gruppi di utenti per feedback, miglioramenti dei prodotti e suggerimenti di nuove caratteristiche. Un buon esempio di questo è NIWeek, dove possiamo parlare con gli utenti su come utilizzano LabVIEW, mentre essi possono fornire un input direttamente a noi dell R&D. Ma, al di là di NIWeek, manteniamo sempre un contatto diretto con i nostri ingegneri commerciali e di marketing tecnico, che interagiscono quotidianamente con gli utenti, per raccogliere il feedback che essi ottengono dagli utenti stessi. Essi rappresentano un importante sorgente di feedback, proprio perché ottengono un input talmente cospicuo da potere individuare le richieste che si ripetono continuamente. Quando abbiamo raccolto tutto questo input, lo combiniamo con la nostra visione e la direzione che riteniamo LabVIEW debba seguire ed iniziamo a dare una diversa priorità alle differenti caratteristiche, non solo all interno del team LabVIEW, ma in tutta l azienda, e ad ogni caratteristica suggerita viene assegnato un colore. Verde significa che quella caratteristica deve essere inclusa nel prodotto che consegneremo; giallo significa che vorremmo avere quella caratteristica ma potremmo consegnare il prodotto anche senza di essa, se necessario; rosso, infine, significa che scegliamo di non avere quella caratteristica nella release in elaborazione, a causa di vincoli di schedulazione, problemi di fattibilità o sovrapposizione con un altro progetto. Come vengono sviluppate le attività del D: gruppo e come vengono allineati ed integrati fra loro i progetti paralleli? I responsabili dell ingegneria nell ambito delle attività R&D LabVIEW collaborano con il nostro team di R: strategia di prodotto per contribuire a definire le roadmap di prodotto. L ingegneria deve quindi definire le pietre miliari tecniche ed analizzare le dipendenze. Infatti, vi sono spesso molte dipendenze che è necessario risolvere prima di potere implementare una certa caratteristica; dobbiamo quindi esaminare le relazioni reciproche di tali dipendenze e decidere quando la caratteristica in oggetto sarà possibile. Per esempio, nel corso degli anni, molti clienti hanno richiesto una caratteristica Zoom per lo schema a blocchi LabVIEW. Vi sono diverse tecnologie, eventualmente implementabili in una futura versione di LabVIEW, che ne renderebbero più semplice la creazione e soddisferebbero realmente ciò che è stato richiesto. Se NI dovesse sviluppare una caratteristica Zoom oggi, probabilmente non si tratterebbe di una soluzione a lungo termine, quindi stiamo aspettando che altre tessere del mosaico vadano al loro posto prima di iniziare a sviluppare questo tipo di tool. Come interagite con altri gruppi di sviluppo, D: relativi per esempio a DAQ, strumenti modulari, ecc.? R: Il gruppo R&D LabVIEW ed i team di sviluppo driver devono coordinarsi molto spesso per fare in modo che i nostri sforzi di sviluppo, dipendenti fra loro, procedano senza intoppi. All inizio di un idea, abbiamo una cultura molto aperta, dove ciascuno può parlare ad un altro team circa una caratteristica che vorrebbe vedere aggiunta. Per esempio, uno sviluppatore in un team dedicato ai driver software per la strumentazione modulare potrebbe venire da noi se desidera che venga aggiunto un nuovo tipo di dati o un nuovo meccanismo di gestione dei grafici. Tuttavia, quando il nostro set di caratteristiche per una particolare versione è deciso, abbiamo un processo molto formalizzato 4

7 PER LA VOSTRA PUBBLICITÁ SU QUESTE per essere sicuri che un cambiamento in un prodotto software come LabVIEW o un driver non abbia impatti negativi su un altro. Questo è il processo attraverso il quale gestiamo gli ultimi ritocchi di una versione beta di LabVIEW prima di passarla ai team hardware, che potranno validare il loro codice rispetto ad essa. Gran parte di questo processo, in termini di creazione di rapidi ritocchi e di loro installazione su macchine di test, è estremamente automatizzato. Quale processo utilizzate per il collaudo del D: codice per il programma di utenti beta di LAB- VIEW? Come ho affermato in precedenza, il nostro processo R: di collaudo è molto definito. Durante lo sviluppo, abbiamo frequenti giornate di test, nelle quali trascorriamo l intera giornata eseguendo test automatizzati e manuali per identificare i problemi. Lo stesso vale per i gruppi hardware che dipendono dal nostro software. Quando siamo arrivati ad una prima costruzione che riteniamo sia abbastanza stabile e completa in termini di caratteristiche per garantire un collaudo esterno, notifichiamo ai nostri utenti beta che è disponibile la prima versione beta per il download. Il gruppo R&D LabVIEW tipicamente rilascia due o tre versioni beta di LabVIEW prima della release finale per la produzione; il beta testing avviene normalmente entro gli ultimi 4-5 mesi prima della finalizzazione del software. Mano a mano che vengono riportati dei bug, sia internamente che attraverso i clienti beta, essi vengono classificati e tracciati in modo da essere sicuri di risolvere prima i bug più critici. Qual è l arco temporale tipico nel quale viene D: sviluppato un progetto? readerservice.it n.300 PAGINE CONTATTATE I NOSTRI AGENTI REGIONALI TRI-VENETO IDELFONSO ELBURGO VIA PIRANO, PADOVA TEL FAX ielburg@tin.it PIEMONTE-LIGURIA ROSARIO ROMEO - PUBLIKAPPA VIA SAGRA S. MICHELE, TORINO TEL./FAX publika@tin.it L arco temporale di un ciclo di rilascio LabVIEW è probabilmente più breve di quanto pensi la maggior R: parte delle persone, in parte anche perché abbiamo recentemente cambiato il nostro modo di lavorare. In passato, quasi tutti gli sviluppatori dovevano lavorare sulla prossima versione, quindi il tempo era inferiore ma erano comunque richieste moltissime ore-uomo. Oggi, abbiamo team di persone che lavorano su versioni LabVIEW in anticipo di tre cicli di rilascio. Poiché il nostro obiettivo è avere una release LabVIEW ogni anno, ciò significa che abbiamo persone che stanno attivamente lavorando su versioni di LabVIEW in anticipo di tre anni. Abbiamo anche strateghi di prodotto che guardano persino più avanti, a quelle che dovrebbero essere le future direzioni di LabVIEW. Abbiamo quindi una visione di LabVIEW che si protrae per diversi anni nel futuro in aree che spaziano dalle interfacce web thin-client alle piattaforme di sviluppo embedded emergenti. MARCHE-UMBRIA-LAZIO-ABRUZZO- CAMPANIA-MOLISE-BASILICATA-PUGLIA- CALABRIA-SICILIA-SARDEGNA ANDREA CESARANO CELL CELL.335 andrea.cesarano@libero.it andrea.cesarano@libero.it 5

8 WHAT S NEWS TOOL DI REPLICA DI SISTEMI REAL-TIME L'articolo descrive l utilizzo di un file eseguibile e di alcuni VI specifici per la replica di sistemi LabVIEW Real-Time Figura 2 Utilizzando un file eseguibile e VI specifici per la replica di sistemi LabVIEW Real-Time, si può utilizzare una singola utility o customizzarne una con LabVIEW per creare più copie identiche dello stesso target Real-Time. Questo evita l utilizzo di un client FTP e del Measurement and Automation Explorer (MAX), il programma di configurazione dei prodotti National Instruments. L eseguibile e i VI sono utili nel caso della distribuzione su target multipli o nel caso di back up e di reinstallazione di un sistema Real-Time, quando non siano disponibili diverse copie del MAX o di LabVIEW. Sono strumenti ideali per OEM ed utenti con più target identici, che possono trarre notevoli benefici dall'avere un set di VI e file eseguibili che risolvono il problema di salvare intere configurazioni relative ai target o assegnare un'immagine a più target. I VI richiedono l'internet Toolkit per LabVIEW per implementare funzioni FTP (File Transfer Protocol). E' importante ricordare che le immagini possono essere distribuite esclusivamente su sistemi identici. Ciò è dovuto al fatto che su ogni tipo di target sono scaricate le informazioni specifiche relative alle differenti versioni di sistema operativo, driver e database che identificano l'hardware. USO DELL'UTILITY D ESEMPIO IN FORMATO ESEGUIBILE Per molti utenti, l'eseguibile può essere sufficiente per le loro esigenze di replica. Esso può essere eseguito su un desktop Windows, dalla linea di comando o all'interno di un file batch come parte di un installer. L'esecuzione dell'eseguibile dal desktop offre un'interfaccia utente grafica intuitiva, su cui si basa la descrizione che segue. Spiegheremo in seguito l utilizzo dei singoli VI che permettono maggiori funzonalità e flessibilità. MEMORIZZAZIONE DI UN'IMMAGINE Normalmente, il processo di sviluppo porta alla configurazione di un target Real-Time con il necessario set di driver e un eseguibile. Per la successive replica su sistemi identici, l'eseguibile di replica memorizza l'immagine di questi driver e, a scelta, anche il contenuto rimanente del disco rigido. Per Figura 1 copiare il contenuto del disco rigido remoto nel file system locale sono sufficienti pochi passi. 1. Nell'utility, selezionate RT Target come sorgente, quindi il pulsante Browse adiacente per scegliere un RT Target che serva da Master (fig. 1). Premendo il pulsante browse viene creato un elenco di target Real-Time disponibili nella sottorete locale (fig. 2). Vengono forniti indirizzo IP, indirizzo MAC (un identificatore unico assegnato alle single schede di rete), Nome e Modello per facilitare l'identificazione della corretta macchina remota. Scegliete la macchina che volete replicare e premete OK. 2. Scegliete ora Folder come destinazione (fig. 3), quindi selezionate la directory del file system locale dove volete salvare l'immagine master. 3. Premete Start per iniziare il processo 6

9 WHAT S NEWS Figura 3 Figura 4 di backup. Alla fine del processo, la finestra Messages dovrebbe visualizzare Image created successfully (fig. 4). DISTRIBUIRE UN'IMMAGINE MEMORIZZATA Questa utility presuppone che i target d'interesse siano pronti ad accettare trasferimenti di file. Ciò significa che devono avere un indirizzo IP valido assegnato. 1. Selezionate questa volta Folder come sorgente. Quindi navigate o digitate il percorso verso l'immagine memorizzata nel paragrafo precedente. 2. Selezionate RT Target come destinazione. Digitate poi l'indirizzo IP del target desiderato o utilizzate il pulsante Browse per selezionare interattivamente un target. 3. Premete ora Start per iniziare il processo di copiatura dell'immagine precedentemente memorizzata. ALTRE POSSIBILITÀ Le sezioni Source e Destination possono essere configurate per i seguenti usi: 1. RT Target >> Folder Fare il back up del target in un folder sulla macchina host 2. RT Target >> RT Target Eseguire la replica di un sistema su un altro sistema presente nella stessa rete 3. Folder >> RT Target Scaricare su un target un'immagine salvata Si può spuntare la casella Installed Software per installare sul target solo i componenti che verrebbero installati dal MAX (software e driver National Instruments). In altri termini, non vengono copiati altri file o eseguibili sul disco rigido. USO DEI VI DI REPLICA DEL SISTEMA I VI di replica del sistema permettono di creare VI ed eseguibili custom per eseguire operazioni di replica e di backup. Per esempio, un integratore di sistemi può utilizzare un eseguibile di questo tipo per distribuire upgrade del software ai clienti, senza richiedere ai clienti stessi di installare dei driver o utilizzare il MAX e un client FTP per eseguire l'aggiornamento. Il paragrafo seguente discute un VI d esempio per installare un'immagine su un target che non ha software installato, né un indirizzo IP configurato. Dopo questo esempio, ven- Figura 5 gono discussi brevemente gli altri VI. Il programma trova un target appena formattato e vi applica un'immagine selezionata. Esso ha il solo scopo di fornire un punto di partenza per capire l'uso dei VI e non viene indicato da National Instruments come soluzione unica o speciale. Il pannello frontale fornisce i passi da seguire per utilizzare il VI (fig. 5). In primo luogo, scegliete il percorso verso l'immagine memorizzata e scegliete un hostname da applicare al target per distinguerlo da altri target. Premete quindi il pulsante Run per iniziare a utilizzare il resto del VI. Dopo pochi secondi, la parte intermedia del pannello frontale dovrebbe visualizzare un indirizzo MAC, un indirizzo IP ed un nome di modello (come PXI-8196) per ogni target non configurato trovato. Scegliete il target d'interesse e selezionate il pulsante Image This Target per procedere con l'installazione dell'immagine. Dopo un tempo variabile in base al traffico di rete e all'hardware, viene visualizzato l'indirizzo IP assegnato (assegnato dal DHCP) e l'immagine è stata copiata con successo, inclusi eventuali eseguibili di startup e file di supporto. Esaminiamo ora lo schema a blocchi per capire meglio i VI di replica del sistema. In primo luogo, viene eseguito il VI denominato Find All Targets.vi (fig. 6). La costante booleana True collegata a 7

10 WHAT S NEW Figura 6 questo VI comporta il rilevamento dei soli target non configurati. Ciò significa che vengono restituiti solo i target che non hanno un indirizzo IP assegnato. L'array di cluster restituito contiene i dettagli relativi a ogni target trovato, come il nome, gli indirizzi MAC e IP, il modello e altri ancora. Questi possono essere utilizzati per filtrare l'elenco e restringerlo solo a determinati modelli di target. Ciò è particolarmente utile per la gestione della replica automatica dei sistemi, perché una stessa immagine deve essere distribuita solo su target identici. Per esempio, si potrebbe effettuare il parsing dell'array di cluster per trovare solo i controllori PXI Successivamente, quando l'utente ha selezionato il target d'interesse, l'indirizzo MAC del target viene isolato e passato a Set IP Address.vi (fig. 7). Questo VI può abilitare o disabilitare il DHCP (assegnazione automatica dell'ip) ed impostare gli indirizzi IP, Subnet, Gateway e DNS. Esso applica inoltre un hostname al target. Il VI restituisce l'indirizzo IP assegnato, cosa particolarmente utile nel caso del DHCP, visto che trova automaticamente un indirizzo IP disponibile e potrebbe fornire indirizzi imprevedibili. Set Target Image.vi Questo indirizzo IP viene trasferito al VI Set Target Image.vi. Tale VI esegue l'operazione finale di copia dell'immagine master sulla macchina duplicata. Il VI rileva eventuali installazioni Windows ed evita di sovrascrivere Windows e file relativi. Pertanto, è sicuro eseguire Set Target Image su target dual-boot. Il VI preserva inoltre le impostazioni degli indirizzi IP anziché sovrascriverle con le impostazioni del master. Un normale trasferimento FTP sovrascriverebbe invece le impostazioni degli indirizzi IP. I VI rimanenti che non sono ancora stati esaminati si riveleranno utili nella progettazione di applicazioni di replica custom. Get Target Info (IP).vi e Get Target Info (MAC).vi Questi due VI cercano un singolo target in base al suo indirizzo IP o MAC e restituiscono la stessa informazione di Find All Targets.vi, ma solo per il singolo target specificato. Per esempio, può essere utile per verificare che l'indirizzo IP o MAC corrisponda al Modello corretto. Format Target.vi Format Target formatta il disco di target remoti. Esso è supportato su target che non richiedono un floppy disk per il boot in safe mode e può rivelarsi utile per i target che possono creare numerosi file durante l'esecuzione o che possono richiedere frequenti upgrade e modifiche. I vecchi target potrebbero non supportare questa funzione, perché il loro firmware non è stato aggiornato. Applicando l'aggiornamento firmware più recente si può porre rimedio al problema. Get Target Image.vi Questo VI salva l'immagine target nella directory specificata. Un ingresso booleano determina se devono essere copiati tutti i file presenti sul target o solo quelli che sono normalmente installati dal MAX. Se vengono copiati tutti i file, ogni eventuale eseguibile impostato come startup verrà anche eseguito allo startup della macchina duplicata. CONCLUSIONE Utilizzando i VI e gli esempi descritti, si può realizzare una varietà di applicazioni di replica del sistema. Gli integratori che desiderano evitare ai loro utenti di aprire o installare il MAX e tutti gli utenti che intendono duplicare più macchine, troveranno questi VI utili e flessibili. Figura 7 readerservice.it n

11 WHAT S NEW 03 CONTROLLO SIMULTANEO DI PANNELLI FRONTALI REMOTI LABVIEW Vediamo come utilizzare una delle ultime funzionalità introdotte in LabVIEW per il controllo remoto simultaneo delle applicazioni Una nuova funzionalità permette di costruire applicazioni in LabVIEW che consentono ad ogni utente remoto di avere la propria interfaccia utente, anziché visualizzarne una sola in comune per tutti gli utenti. In altri termini, più utenti possono controllare contemporaneamente il pannello frontale remoto di un VI senza influenzare eventuali altri utenti connessi allo stesso pannello contemporaneamente. VI; tuttavia, in precedenza, solo un client per volta poteva controllare il VI. La novità ora è che più client possono controllare contemporaneamente il pannello frontale del VI. Ogni volta che viene assegnato il controllo, viene creata una nuova istanza del pannello frontale, permettendo a ciascun client di controllare il VI senza influenzare gli altri client. Per illustrare l'uso di questa funzionalità, seguiamo un'applicazione Figure 2 Abilitazione del Web Server di LabVIEW Figure 1 VI d esempio per pannelli frontali remoti e selezionate Web Server: Configuration. Spuntate la casella di Enable Web Server e cliccate OK. In questo modo si lancia il web server (fig. 2). Ora che il web server è stato abilitato, il passo successivo è rendere rientrante il VI. Impostare il VI come rientrante permette a più client di ottenere la propria istanza del pannello frontale. Nell'esecuzione rientrante, le chiamate a istanze multiple di un VI possono essere eseguite in parallelo con gestione separata della memorizzazione dei dati. La possibilità di impostare un VI come rientrante era già presente nelle precedenti versioni di LabVIEW, ma ora I pannelli frontali remoti di LabVIEW permettono di vedere e controllare un VI attraverso un web browser standard. Creare la pagina web di un pannello frontale remoto è facile grazie al Web Publishing Tool di LabVIEW. Con pochi click del mouse si può creare una pagina web che incorpora l'immagine del pannello frontale del VI, visualizzabile attraverso il web browser del client. I pannelli frontali remoti permettono a più client di visualizzare simultaneamente il pannello frontale dello stesso esemplificativa che utilizza questa tecnica. Il VI di figura 1 legge un file dati e visualizza un'onda sinusoidale con disturbo. L'utente può quindi applicare un filtro e visualizzare su un grafico i risultati dell operazione. LabVIEW utilizza il proprio web server per pubblicare il pannello frontale su un web browser in modo tale da rendere il VI accessibile da remoto. Il primo passo nell'uso dei pannelli frontali remoti è abilitare il web server integrato in LabVIEW. Andate su Tools > Options Figure 3 Impostazione dell'esecuzione rientrante 9

12 WHAT S NEW Figure 4 Uso del Web Publishing Tool Figure 7 Controllo remoto di un VI in un web browser Figure 5 Creazione di titolo, intestazione e piede della pagina Figure 6 Creazione della pagina HTML per il pannello frontale remoto l ambiente offre la possibilità di utilizzare la rientranza con i pannelli frontali remoti. Per impostare a rientrante l'esecuzione del VI, andate su File > VI Properties e selezionate Execution dall'elenco a tendina Category. Spuntate la casella di Reentrant execution (fig. 3). Quando il VI è stato impostato come rientrante, potete iniziare i passi necessari per pubblicare il vostro VI sul web. Andate su Tools > Web Publishing Tool. Selezionate il VI che volete pubblicare, in questo esempio Remote_Front_Panels.vi. Selezionate poi l'embedded Viewing Mode che vi permetterà di visualizzare e controllare il VI da remoto, quindi cliccate Next (fig. 4). Potete anche selezionare il pulsante Preview in Browser in qualsiasi momento per vedere come si presenterebbero le vostre impostazioni correnti in un web browser. La schermata della fig. 5 vi permette di creare il titolo del documento, l'intestazione ed il piede della pagina web dove il VI verrà pubblicato. Selezionate quindi la directory di destinazione nella quale la pagina web creata verrà salvata ed il filename della pagina web. Il Web Publishing Tool fornisce anche l'url per la pagina web del pannello frontale remoto che può essere inserito direttamente in un browser. Cliccate Save to Disk e quindi OK. Ora è possibile accedere remotamente al VI (fig. 6). Per accedere al pannello frontale remoto attraverso il web, aprite una pagina web e navigate all'url specificato nel Web Publishing Tool. A questo punto, potete visualizzare l'interfaccia utente attraverso il web. Per ottenere il controllo, cliccate con il tasto destro del mouse nella pagina web e selezionate Request Control of VI. Ora il VI può essere controllato remotamente. Potete ora eseguire il VI, interagire mediante i controlli e visualizzare i vostri dati negli indicatori come se steste eseguendo il VI dall'ambiente di sviluppo (fig. 7). Anche un altro utente in un luogo differente può aprire un web browser, navigare allo stesso indirizzo ed ottenere la propria istanza di questo VI, che può controllare senza essere influenzato dalla presenza di eventuali altri utenti collegati simultaneamente. readerservice.it n

13 TIPS & TECHNIQUES COME USARE LE VARIABILI CONDIVISE IN LABVIEW Mike Trimborn L articolo introduce le variabili condivise e contiene una discussione sulle loro caratteristiche e prestazioni in LabVIEW LabVIEW permette di accedere a un ampia varietà di tecnologie per creare applicazioni distribuite. La variabile condivisa (shared variable) introdotta in LabVIEW 8 rappresenta un importante passo avanti nella semplificazione della programmazione necessaria per tali applicazioni. shared variable single-process. Il Modulo LabVIEW Real- Time e il Modulo LabVIEW Datalogging and Supervisory Control (DSC) offrono proprietà configurabili addizionali. CREAZIONE DELLE SHARED VARIABLE Utilizzando le shared variable, potete condividere dati fra più cicli paralleli nello stesso diagramma o fra VI distinti distribuiti su una rete. A differenza di molti metodi esistenti di condivisione dei dati in LabVIEW come UDP/TCP, le code e le FIFO Real-Time, tipicamente dovete configurare la shared variable in fase di creazione della risorsa, mediante finestre di configurazione delle proprietà, e non è necessario includere codice di configurazione nella vostra applicazione. Potete creare tre tipi di shared variable: single-process, network-published e time-triggered. L articolo discute in dettaglio le shared variable single-process e networkpublished. Per creare una shared variable dovete avere un progetto aperto. Per aggiungere una shared variable a un progetto, cliccate con il pulsante destro del mouse su un target, su una libreria di progetto o su una cartella all interno di una libraria di progetto nella finestra Project Explorer. Quindi selezionate New»Variable nel menu rapido per visualizzare la finestra Shared Variable Properties, selezionate le opzioni di configurazione di vostro interesse e cliccate il pulsante OK. Se cliccate con il pulsante destro del mouse direttamente su un target oppure su una cartella che non sia all interno di una libreria di progetto e selezionate New»Variable dal menu rapido, LabVIEW crea una nuova libreria di progetto e pone la shared variable al suo interno. La figura 1 mostra la finestra di dialogo Shared Variable Properties per una Figure 1 Finestra delle proprietà di una shared variable single-process TIPI DI DATO Creata una nuova shared variable, potete selezionare fra un numero elevato di tipi di dato standard. In aggiunta, potete specificare anche un tipo di dato custom selezionando Custom nell elenco a tendina Data Type e navigando verso un controllo custom. Tuttavia, quando si utilizzano tipi di dato custom, LabVIEW non consente di abilitare le opzioni FIFO real-time e scalatura. Inoltre, se avete installato il Modulo LabVIEW DSC, la gestione degli allarmi si limita alle notifiche di stato errato. Dopo avere configurato le proprietà della shared variable ed avere cliccato il pulsante OK, la shared variable appare nella vostra finestra Project Explorer sotto la libreria o il target che avete selezionato, come mostrato in figura 2. Figure 2 La shared variable nel progetto RIFERIMENTI ALLA VARIABILE Dopo avere aggiunto una shared variable ad un progetto LabVIEW, potete trascinare la shared variable nello schema a blocchi di un VI per effettuare operazioni di lettura e scrittura, come mostrato in figura 3. Potete cliccare con il pulsante destro del mouse su una shared variable nella finestra Project Explorer e così editarne le pro- 11

14 TIPS & TECHNIQUES prietà in qualsiasi momento. Il progetto LabVIEW propaga le nuove impostazioni a tutti i riferimenti alla variabile presenti in memoria. Quando salvate la libreria di variabili, questi cambiamenti vengono applicati anche alla definizione della variabile memorizzata su disco. SHARED VARIABLE SINGLE-PROCESS Utilizzate variabili single-process per trasferire dati fra due punti del diagramma di uno stesso VI che non possono essere connessi con un filo, come accade nel caso di cicli paralleli, oppure fra due VI distinti presenti sulla stessa mecchina. L implementazione di una variabile single-process è simile a quella di una variabile globale di LabVIEW. Il vantaggio principale della nuova variabile è la possibilità di convertirla in una variabile network-published, accessibile a qualsiasi nodo sulla rete. Figura 3 Operazioni di lettura e scrittura di una shared variable Figura 5 Scrittori e lettori multipli che condividono una singola FIFO Figura 4 Variabile condivisa operante come FIFO real-time LE SHARED VARIABLE SINGLE-PROCESS E LABVIEW REAL-TIME Per mantenere il determinismo, un applicazione real-time richiede l uso di un meccanismo deterministico non bloccante per trasferire i dati dalle parti critiche del codice, come i timed loop a priorità più alta e i VI con priorità time-critical, alle sezioni non deterministiche dell applicazione. Quando installate il modulo LabVIEW Real-Time, potete configurare una shared variable per far sì che utilizzi le FIFO real-time, abilitando tale funzionalità dalla finestra di dialogo Shared Variable Properties. In questo modo potete evitare l uso dei VI real-time FIFO di basso livello. LabVIEW crea una FIFO real-time la prima volta che un nodo di variabile cerca di scrivere o leggere una variabile. Questo comportamento si traduce in un tempo di esecuzione leggermente più lungo al primo utilizzo di una shared variable rispetto agli accessi effettuati successivamente. Se un applicazione richiede una temporizzazione estremamente precisa, vi conviene prevedere alcune iterazioni iniziali di assestamento, per tenere conto di questa fluttuazione nei tempi di accesso, oppure leggere la variabile almeno una volta all esterno del ciclo critico (fig. 4). LabVIEW crea un unica FIFO real-time per ogni shared variable single-process anche quando la variabile gestisce lettori/scrittori multipli. Per assicurare l integrità dei dati, gli scrittori si bloccano reciprocamente e lo stesso accade per i lettori multipli. Tuttavia, un lettore non blocca uno scrittore ed uno scrittore non blocca un lettore. National Instruments raccomanda di evitare lettori/scrittori multipli di shared variable single-process utilizzate in cicli time-critical (fig. 5). Potete selezionare fre due tipi leggermente differenti di variabile con FIFO real-time abilitata: il buffer singolo elemento e il buffer multielemento. Una prima differenza fra i due è che il buffer singolo elemento non riporta notifiche relative a condizioni di overflow o underflow. Una seconda distinzione si riferisce al valore restituito da LabVIEW quando più lettori leggono un buffer vuoto. I lettori multipli di una FIFO singolo elemento ricevono lo stesso valore e il buffer restituisce lo stesso valore finché uno scrittore scrive nuovamente su quella variabile. Ciascuno dei lettori multipli di una FIFO multielemento vuota ottiene l ultimo valore che ha letto dal buffer, oppure il valore di default 12

15 TIPS & TECHNIQUES Figura 6 Shared variable con FIFO real-time multielemento e modalità di lettura del buffer condiviso da parte di più variabili associato al tipo di dato della variabile, nel caso in cui non abbia mai letto prima la variabile. Tale comportamento è descritto in figura 6. Se un applicazione richiede che ogni lettore ottenga ogni singolo dato scritto in una shared variable con FIFO multielemento, utilizzate una shared variable separata per ciascun lettore. Figura 7 Motore delle shared variable e gestione dei cambi di valore delle variabili SHARED VARIABLE NETWORK-PUBLISHED Usando una shared variable network-published, cioè pubblicata in rete, potete scrivere e leggere una variabile per condividere dati su una rete Ethernet. L implementazione delle modalità di comunicazione sulla rete viene gestita interamente dalla variabile. Oltre a rendere disponibili i vostri dati sulla rete, la shared variable network-published aggiunge molte funzionalità non disponibili con la shared variable single-process; questo comporta che l implementazione interna della variabile pubblicata in rete sia molto più complessa. I prossimi paragrafi ne discutono alcuni aspetti e offrono raccomandazioni per ottenere le migliori prestazioni con il loro utilizzo. IL PROTOCOLLO NI-PSP Le variabili condivise network-published utilizzano NI Publish-Subscribe Protocol (NI-PSP) per inviare e ricevere dati attraverso la rete. Il protocollo NI-PSP è costruito sopra il protocollo UDP e ne sfrutta quindi i tipici aspetti di rapidità ed efficienza. l protocollo NI-PSP utilizza meno ampiezza di banda ed è più efficiente del TCP/IP, in relazione alle specifiche proprie del protocollo NI-PSP. Tuttavia, a differenza del protocollo UDP, NI-PSP garantisce la ricezione dei dati, implementando uno strato addizionale sopra il protocollo UDP grezzo. DISTRIBUZIONE E HOSTING DELLE VARIABILI Dovete assegnare le shared variable pubblicate in rete a un motore di gestione delle variabili condivise, o SVE (Shared Variable Engine), che ospita (hosting) i valori delle variabili sulla rete. Quando scrivete su un nodo di variabile, LabVIEW invia il nuovo valore al motore di competenza che ospita la variabile. Il Variable Engine pubblica quindi il valore in modo tale che i richiedenti ottengano il valore aggiornato. La figura 7 illustra tale processo. Utilizzando la terminologia client/server, il motore SVE è il server per una shared variable, mentre tutti i riferimenti alla variabile sono i client, indipendentemente dal fatto che leggano o scrivano la variabile. Il lato client è parte integrante dell implementazione di ogni nodo di variabile condivisa. LE VARIABILI NETWORK-PUBLISHED E LABVIEW REAL-TIME Potete abilitare la FIFO real-time anche per una shared variable pubblicata in rete ma occorre tenere presente che si comportano in modo diverso rispetto alle variabili singleprocess, come visto in precedenza. Con le variabili singleprocess, tutti gli scrittori e tutti i lettori condividono un unica FIFO real-time. Con le variabili network-published, ogni lettore possiede una propria FIFO real-time, sia nel caso a singlo elemento che nel caso multielemento, come illustrato in figura 8. Figura 8 Shared variable pubblicata in rete con opzione FIFO real-time abilitata 13

16 TIPS & TECHNIQUES Figura 9 Abilitazione della bufferizzazione di una shared variable pubblicata in rete BUFFERIZZAZIONE DI RETE Con le shared variable network-published potete abilitare un buffer di rete, configurandolo nella finestra di dialogo Shared Variable Properties, come illustrato in figura 9. Con la bufferizzazione, tenete sotto controllo le fluttuazioni temporanee che possono avvenire fra le velocità di lettura e scrittura di una variabile. I lettori che occasionalmente leggono una variabile più lentamente rispetto alla situazioni in cui le velocità di lettura/scrittura hanno fluttuazioni temporanee. Se l applicazione viene eseguita per un periodo indefinito, i lettori che leggono costantemente ad una velocità più bassa del rate di scrittura alla fine perdono dei dati, indipendentemente dalle dimensioni del buffer che specificate. Poiché la bufferizzazione alloca un buffer per ogni richiedente, usatela solo quando è necessario, per evitare di sprecare memoria. BUFFERIZZAZIONE DI RETE E FIFO REAL-TIME Se abilitate sia la bufferizzazione di rete che la FIFO realtime, l implementazione della shared variable includerà sia un buffer di rete che una FIFO real-time. Ricordate che l opzione FIFO real-time crea una coda separata per ogni scrittore e ogni lettore; pertanto scrittori e lettori multipli non si bloccano reciprocamente. Anche se potete impostare indipendentemente le dimensioni di questi due buffer, nella maggior parte dei casi National Instruments raccomanda di utilizzare le stesse dimensioni per entrambi (fig. 11). VITA DEI BUFFER LabVIEW crea i buffer di rete e le FIFO real-time in occasione di una scrittura o lettura iniziale. I buffer lato server sono creati quando uno scrittore scrive per la prima volta su una shared variable. I buffer lato client sono creati quando un richiedente legge per la prima volta da una shared variable. Se uno scrittore scrive dati su una shared variable prima che un richiedente inizi a leggere da tale variabile, i valori iniziali non saranno più disponibili per il richiedente (fig. 12). velocità di scrittura, possono perdere qualche aggiornamento. Se l applicazione può tollerare la perdita occasionale di qualche valore, non c è necessità di abilitare la bufferizzazione. Tuttavia, Figura 10 Bufferizzazione di rete se il lettore deve ricevere ogni aggiornamento, abilitate la bufferizzazione. Potete impostare le dimensioni del buffer nella pagina Variable della finestra di dialogo Shared Variable Properties, in modo tale da poter decidere quanti aggiornamenti l applicazione deve mantenere memorizzati in coda prima di iniziare a sovrascrivere i vecchi dati. LabVIEW usa la dimensione del buffer che specificate per creare due buffer interni, uno sul motore SVE e uno a livello del richiedente. Dato che ogni lettore di una shared variable pubblicata in rete ottiene il proprio buffer, i lettori non interagiscono fra loro. Figura 11 Bufferizzazione di rete e FIFO real-time abilitata La bufferizzazione è utile solo nelle OVERFLOW/UNDERFLOW DEL BUFFER La shared variable pubblicata in rete riporta le condizioni di overflow e underflow dei buffer di rete a partire dalla versione di LabVIEW Una FIFO real-time, invece, indica l overflow/underflow della coda, restituendo errori, in tutte le versioni di LabVIEW. Un applicazione in LabVIEW 8.0 o può verificare gli underflow dei buffer di rete in due modi. Quando aggiornate la variabile a una frequenza inferiore a 1 khz, tenuto conto che la riso- 14

17 TIPS & TECHNIQUES luzione temporale del timestamp di una shared variable è di 1 ms, potete confrontare il timestamp di una variabile con quello relativo a una lettura successiva per rilevare gli underflow dei buffer. Oppure, per applicazioni non realtime, il lettore può utilizzare un numero sequenziale da legare ai dati per notificare gli overflow/underflow dei buffer. Non potete utilizzare il secondo approccio con le shared variable usate all interno di un loop time-critical, perché le shared variable con opzione FIFO real-time abilitata non supportano il tipo di dato Custom Control (cluster). VITA DELLE SHARED VARIABLE Come detto in precedenza, tutte le shared variable sono parte di una libreria di progetto. Il motore SVE registra le librerie di progetto e le shared variable contenute in queste librerie ogni volta che LabVIEW richiede una di tali variabili. Di default, l SVE scarica e pubblica una libreria di shared variable sul target di competenza, come indicato dal progetto, non appena eseguite un VI che fa riferimento ad una qualsiasi delle variabili contenute. Il motore scarica l intera libreria e pubblica tutte le shared variable presenti, indipendentemente dal fatto che un VI in esecuzione faccia riferimento solamente a una parte di esse. Potete scaricare manualmente qualsiasi libreria di progetto cliccando con il pulsante destro del mouse sulla libreria nella finestra Project Explorer. L arresto del VI o il reboot della macchina che ospita la shared variable non rende la variabile indisponibile alla rete. Se volete rimuovere la shared variable dalla rete, dovete farlo esplicitamente nella finestra Project Explorer. Potete anche selezionare Tools»Shared Variable»Variable Manager per rimuovere variabili o intere librerie di variabili. DATA BINDING SUL PANNELO FRONTALE Una caratteristica addizionale disponibile solo per le shared variable pubblicate in rete è il data binding per oggetti del pannelo frontale. Dalla finestra Project Explorer trascinate una shared variable sul pannello frontale di un VI per creare un controllo legato alla shared variable. Quando abilitate il data binding per un controllo, cambiando il valore del controllo cambiate il valore della shared variable alla quale il controllo è legato. Mentre il VI è in esecuzione, se la connessione all SVE ha successo, appare un piccolo indicatore verde accanto all oggetto sul pannello frontale del VI, come si vede in figura 13. Potete modificare le proprietà di binding relative a un qualsiasi controllo o indicatore dalla pagina Data Binding della finestra di dialogo Properties. Quando utilizzate il modulo LabVIEW Real-Time o LabVIEW DSC, potete selezionare Tools»Shared Variable»Front Panel Binding Figura 12 Vita dei buffer Mass Configuration per visualizzare la finestra di dialogo Front Panel Binding Mass Configuration e creare un interfaccia operatore che lega numerosi controlli e indicatori alle shared variable. ACCESSO PROGRAMMATICO Come discusso in precedenza, potete creare, configurare e scaricare interattivamente le shared variable utilizzando il LabVIEW Project, e potete leggere e scrivere le variabili utilizzando i nodi relativi presenti sullo schema a blocchi o attraverso il data binding. LabVIEW offre anche l accesso programmatico a tutte queste funzionalità. Utilizzate il VI Server per creare programmaticamente librerie di progetto e shared variable nelle applicazioni dove dovete creare un grande numero di variabili. Inoltre, il Modulo LabVIEW DSC offre un set completo di VI per creare ed editare programmaticamente shared variable e librerie di progetto, nonché per gestire l SVE. Potete creare programmaticamente librerie di shared variable solo su sistemi Windows; tuttavia, potete distribuire Figura 13 Binding di un controllo a una shared variable programmaticamente queste nuove librerie sia su sistemi Windows che LabVIEW Real-Time. Usate l API DataSocket nelle applicazioni dove dovete cambiare dinamicamente la shared variable che un VI legge e scrive. Potete cambiare dinamicamente una shared variable costruendo programmaticamente l URL della connessione DataSocket. Potete anche controllare programmaticamente altre caratteristiche della shared variable, come le dimensioni del buffer. Inoltre, l API DataSocket ha una lettura bloccante che restituisce un valore solo quando la shared variable viene aggiornata (fig. 14). Figura 14 Uso dell API DataSocket per leggere e scrivere programmaticamente shared variable 15

18 TIPS & TECHNIQUES Figura 15 Architettura idonea per un delta filtering efficace SHARED VARIABLE ENGINE L SVE è un framework che permette ad una shared variable pubblicata in rete di inviare valori attraverso la rete. Su Windows, LabVIEW configura l SVE come servizio e lancia l SVE allo startup di sistema. Su un target real-time, l SVE è un componente di startup installabile che viene caricato al boot di sistema. Per utilizzare le shared variable pubblicate in rete, un SVE deve essere in esecuzione su almeno uno dei nodi del sistema distribuito. Qualsiasi nodo sulla rete può leggere o scrivere le variabili pubblicate dall SVE. Potete anche avere più SVE installati su più sistemi simultaneamente se dovete distribuire le shared variable in posizioni differenti in base alle esigenze applicative. RACCOMANDAZIONI PER LA SCELTA DEL LUOGO IN CUI OSPITARE LE VARIABILI Quando scegliete il dispositivo che ospiterà le variabili di rete e da cui effettuare la distribuzione delle variabili che utilizzate in un sistema distribuito, dovete considerare una serie di fattori. Il dispositivo di elaborazione è compatibile con l SVE? La tabella 1 riassume le piattaforme per le quali è disponibile l SVE e identifica le piattaforme che possono utilizzare variabili condivise pubblicate in rete tramite nodi di variabile o l API DataSocket. National Instruments richiede 32 MB di RAM e ne raccomanda 64 MB per l SVE su tutte le piattaforme valide. L applicazione richiede funzionalità di datalogging e supervisione? Se volete usare le caratteristiche proprie del modulo LabVIEW DSC, dovete ospitare le shared variable su Windows. Il modulo LabVIEW DSC aggiunge le seguenti funzionalità alle shared variable pubblicate in rete: Logging storico nel database NI Citadel. Allarmi in rete e logging degli allarmi. Scalatura. Sicurezza basata sull utente. Valore iniziale. Possibilità di creare server di I/O custom. Integrazione della struttura a eventi di LabVIEW con le shared variable. VI LabVIEW per controllare programmaticamente tutti gli aspetti delle shared variable e del motore delle variabili. Questi VI sono particolarmente utili per gestire grandi numeri di shared variable. Il dispositivo di elaborazione ha risorse adeguate in termini di processore e memoria? L SVE è un processo addizionale che richiede risorse di elaborazione e memoria. Per ottenere le migliori prestazioni in un sistema distribuito, installate l SVE su macchine che garantiscono la massima capacità di memoria ed elaborazione in quel sistema. Dove vengono generati ed elaborati i dati? L SVE riduce il traffico di rete quando la bufferizzazione è disabilitata. Abilitate la bufferizzazione se vi occorre ogni nuovo valore di una shared variable. Quando la bufferizzazione è disabilitata, l SVE esegue il cosiddetto delta filtering: rimuove i valori ridondanti e invia ai richiedenti solo gli effettivi cambi di valore di una shared variable. L architettura di un sistema distribuito può influenzare notevolmente l efficacia di questa funzionalità, come si vede in figura 15. LabVIEW implementa questo tipo di filtraggio solo per tipi scalari come numeri interi, numeri decimali in virgola mobile e booleani, e per gli array di stringhe e di booleani. Il delta filtering è efficace soprattutto se generate dati sulla stessa macchina che ospita una variabile, come mostrato in figura 15. In questo esempio, lo scrittore è su My SVE Nodi di variabile DataSocket API con PSP PC Windows Mac OS... Linux... PXI Real-Time Compact FieldPoint CompactRIO Compact Vision System PC commerciali con LabVIEW Real-Time ETS RTX Tabella 1 Sintesi delle compatibilità per le shared variable pubblicate in rete 16

19 TIPS & TECHNIQUES Figura 16 Architettura che non consente un delta filtering efficace Computer e scrive più valori ridondanti su una variabile. L SVE esegue il filtraggio delta e invia solo due aggiornamenti sulla rete al target PXI RT. La figura 16 illustra un esempio di filtraggio delta non efficace. Lo scrittore è sul target PXI RT e invia all SVE tutti i cambi di valore, inclusi gli aggiornamenti ridondanti. I valori ridondanti vengono rimossi successivamente su My Computer per i richiedenti ma questo non riduce il traffico in rete. Se costruite un applicazione distribuita e sapete che alcuni dei sistemi possono andare offline periodicamente, fate in modo di ospitate l SVE su un sistema che sia sempre online. CARATTERISTICHE ADDIZIONALI DELLO SHARED VARIABLE ENGINE La figura 17 illustra le numerose responsabilità dell SVE, oltre a quella di gestire le shared variable pubblicate in rete: Raccogliere i dati ricevuti dai server di I/O. Fornire i dati ai richiedenti, attraverso i server OPC e PSP. Fornire servizi di scalatura, allarme e logging per qualsiasi shared variable per cui siano stati configurati tali servizi che, ricordiamo, sono disponibili solo con il modulo LabVIEW DSC. Monitorare le condizioni di allarme e rispondere di conseguenza. Figura 18 Legare variabili ad item OPC SERVER DI I/O I server di I/O sono plug-in dell SVE con i quali i programmi possono usare l SVE per pubblicare dati. NI FieldPoint 5.0 include un server di I/O che pubblica i dati direttamente da banchi FieldPoint sull SVE. Poiché l SVE è un server OPC, la combinazione dell SVE e del server di I/O FieldPoint configura di fatto un server OPC per FieldPoint. L installer del driver FieldPoint non include l SVE, che deve essere installato da un altro componente sofware, ad esempio LabVIEW. Anche il driver NI-DAQmx dalla versione 8.0 include un server di I/O che può pubblicare automaticamente canali virtuali globali NI-DAQmx sull SVE. Tale server di I/O sostituisce il server OPC e la tecnologia di accesso remoto RDA (Remode Device Access) presenti nel vecchio driver NI-DAQ Traditional. Il driver NI-DAQmx include l SVE. Con il modulo LabVIEW DSC, gli utenti possono creare nuovi server di I/O. OPC L SVE è conforme alla versione 3.0 e può operare come un server OPC su macchine Windows. Figura 17 Shared Variable Engine (SVE) Qualsiasi client OPC può scrivere o leggere una shared variable ospitata su una macchina Windows. Quando installate il modulo LabVIEW DSC su una macchina Windows, l SVE può operare anche come client OPC. Potete legare le shared variable ospitate su una macchina Windows a degli item OPC con il DSC e abilitare la comunicazione in lettura e scrittura tra le variabili e gli item OPC. Poiché OPC è una tecnologia basata su COM, una API di Windows, i target real-time non lavorano direttamente con OPC. Come mostrato in figura 18, potete comunque accedere agli item OPC da un target real-time ospitando le shared variable su una macchina Windows. 17

20 TIPS & TECHNIQUES PRESTAZIONI Questo paragrafo fornisce delle linee guida generali per creare applicazioni ad alte prestazioni utilizzando le shared variable. Poiché la shared variable single-process ha un implementazione simile alle variabili globali e alle FIFO realtime di LabVIEW, National Instruments non ha particolari raccomandazioni per ottenere buone prestazioni con questo tipo di variabili. I paragrafi seguenti si concentrano quindi sulle shared variable pubblicate in rete. Figura 20 Uso efficiente delle shared variable pubblicate in rete su un target real-time CONSIDERATE LA POSIZIONE DELL SVE Nel paragrafo Raccomandazioni per la scelta del luogo in cui ospitare le variabili abbiamo discusso una serie di fattori che dovete considerare nella scelta del punto in cui installare l SVE. La figura 19 mostra un altro fattore che può avere un forte impatto sulle prestazioni delle shared variable. Questo esempio riguarda un target real-time, ma le stesse considerazioni valgono anche per sistemi non real-time. La figura mostra un uso inefficiente delle shared variable pubblicate in rete: generate dati su un target realtime e avete necessità di eseguire il logging locale dei dati elaborati e monitorare il processo da una macchina remota. Dato che i richiedenti delle variabili devono ricevere i dati dall SVE, la latenza fra la scrittura nel loop ad alta priorità e la lettura nel loop a priorità normale è elevata e sono richiesti due viaggi attraverso la rete. Figura 19 Uso inefficiente delle shared variable pubblicate in rete su un target real-time NON MONOPOLIZZATE IL PROCESSORE La shared variable pubblicata in rete semplifica i diagrammi a blocchi di LabVIEW nascondendo all interno della sua implementazione molti dettagli strutturali tipici della programmazione di rete. Le applicazioni comprendono i VI LabVIEW, l SVE e il codice client SVE. Per ottenere le migliori prestazioni dalle shared variable, sviluppate l applicazione in modo tale che liberi regolarmente il processore per l esecuzione dei thread SVE. Un modo per ottenere questo effetto è quello di inserire delle attese nei cicli di elaborazione e assicurarsi che l applicazione non faccia uso di cicli non temporizzati. L esatta quantità di tempo che dovete attendere dipende dall applicazione, dal processore e dalla rete; ogni applicazione richiede un certo livello di messa a punto empirica per ottenere le massime prestazioni. La figura 20 illustra un architettura migliore per questa applicazione. L applicazione usa una shared variable single-process per trasferire i dati fra il loop ad alta priorità e il loop a bassa priorità, riducendo notevolmente la latenza. Il loop a bassa priorità esegue il logging dei dati e scrive l aggiornamento in una shared variable pubblicata in rete per il richiedente presente sull host. Note sull autore Mike Trimborn, LabVIEW FPGA Product Marketing Manager, National Instruments. Readerservice.it n