Capitolo 4

(1)

Capitolo 4 –Descrizione Codice lato server

35

Capitolo 4

Descrizione del diagramma a blocchi dell’applicativo lato Server

In questo capitolo descriveremo il codice contenuto nel diagramma a blocchi dell’applicativo lato server .

Il pannello frontale del VI è mostrato in figura 4.1 .

Fig. 4.1 : Pannello fontale del VI Server.vi

4.1 Struttura del programma

La struttura del programma è composta da cinque cicli while che agiscono in parallelo. E’ stata scelta questa strada per poter eseguire più istruzioni contemporaneamente e con diversi livelli di priorità .

(2)

36

Passiamo alla descrizione del ciclo while principale che racchiude la gestione delle principali funzionalità del sistema.

La prima parte del codice contiene le istruzioni per l’inizializzazione dei valori visualizzati nel pannello frontale , viene eseguita ogni volta che termina la sessione di lavoro del client. Dall’analisi della figura 4.2 si vede che si fa uso di variabili locali associate agli indicatori e ai controlli presenti nel display.

Fig. 4.2 : Inizializzazione delle variabili

La figura 4.3 mostra , invece, la parte di codice che si occupa della eliminazione dei files di dati creati dal client durante la sessione e della chiusura di eventuali Vis rimasti aperti al termine della sessione.

(3)

37

Il subVI Inizializzazione File svolge due compiti : elimina i files precedentemente creati e scrive i valori di default nei files di testo che permettono di recuperare il percorso in cui vengono salvati i files creati nella sessione.

In particolare viene inserita una stringa vuota nei due files che contengono i percorsi dei files da inviare mentre viene scritto un percorso di default nei files contenenti i path da utilizzare per il salvataggio dei files creati dal client.

Il subVI Chiudi VI Parte 2 permette di terminare l’esecuzione del VI e chiude il relativo pannello frontale.

Il codice del diagramma a blocchi del subVI è mostrato in figura 4.4 .

Fig. 4.4 : codice del subVI “Chiudi VI Parte 2”

Questo meccanismo funziona grazie all’apertura di riferimenti al percorso del VI in esecuzione e all’utilizzo di due property node.

E’ stato necessario introdurre la funzione clear error per eliminare errori generati dalla mancata individuazione di Vis aperti.

In effetti , se nel corso della sessione non si verificano malfunzionamenti , tutti i Vis aperti vengono chiusi e all’inizio della nuova sessione non si trovano applicativi in esecuzione. Completata la fase di inizializzazione il server si mette in ascolto della rete, in attesa di richieste di connessione provenienti da client .

La funzione TCP Listen ,mostrata in figura 4.5, consente di ascoltare la rete e permette di specificare la porta su cui attendere le eventuali richieste di connessione

(4)

38

Fig. 4.5 a : Funzione TCP Listen Fig. 4.5 b : Ascolto della rete

.

Nel nostro caso è stata scelta la porta 2000 perché non è presente nella lista delle porte utilizzate da altre applicazioni.

L’ingresso resolve remote address permette di tradurre l’indirizzo IP nel suo formato alfanumerico collegandosi ad un server DNS.

Per i nostri scopi è stato necessario porre tale ingresso a False dato che questa operazione comportava un inutile rallentamento del sistema.

La funzione TCP Listen permette , inoltre, di ricavare l’indirizzo IP dell’utente che ha fatto richiesta di connessione e di visualizzare la porta locale utilizzata dal client.

L’indirizzo IP è utilizzato dal server durante tutta la sessione di lavoro per l’identificazione del client .

L’ingresso Connection ID permette di identificare univocamente la connessione mediante il

refnum associato .

Grazie a questo riferimento il server è sempre in grado di inviare dati verso il client ; con l’utilizzo del solo indirizzo IP questo, in alcune situazioni , non sarebbe possibile.

Nelle prove sperimentali effettuate durante lo sviluppo del sistema , infatti , abbiamo verificato che se client e server si trovano entrambi su una rete locale , ambito dal quale siamo partiti per lo sviluppo del sistema , il server è sempre in grado di conoscere l’IP del client e quindi di inviare i dati verso la destinazione corretta ; testando successivamente il sistema su rete pubblica ,abbiamo verificato che in alcune situazioni , per esempio se il client si connette attraverso un dispositivo che implementa il NAT (network address translation), il server non è in grado di conoscere la corretta destinazioni dei pacchetti avendo a disposizione l’IP pubblico del client ma non quello privato ;

Un esempio di questa configurazione è mostrato in figura 4.7.

In questo caso, se la connessione aperta dal client , tramite la funzione TCP Open

(5)

39

Close Connection , mostrata in figura 4.6b, il server non è più in grado di trasmettere dati al

client tramite l’utilizzo del solo indirizzo IP .

Fig. 4.6 : Funzioni per l’apertura e la chiusura di una connessione

Se il server, invece, utilizza l’ID connection e le connessioni vengono aperte sempre dal client , il problema non si pone , perché tale parametro identifica tutti i riferimenti necessari per il corretto indirizzamento dei dati.

Fig. 4.7 : Possibile configurazione del sistema

Quando si apre una sessione di lavoro con un client connesso i dati raccolti dalla funzione

TCP listen vengono inviati alla funzione TCP Read ,mostrata in figura 4.8, che ne consente

la lettura .

(6)

40

Questa funzione va utilizzata nella modalità Immediate perché non si conosce esattamente il numero di bytes inviati dal client.

E’ infatti certamente nota la dimensione dei dati di autenticazione corretti ( 8 byte per l’username e 8 per la password ) ma è stato necessario prevedere anche il caso di inserimento di dati errati di dimensioni differenti.

In labVIEW tutti i dati inviati tramite protocollo TCP IP vengono trasmessi sotto forma di stringa , un carattere corrisponde dunque a 1 Byte.

Fig. 4.9 : Ricezione dati di autenticazione

Come si vede dalla parte di codice mostrata in figura 4.9 è stata impostata una dimensione massima di 10.000 caratteri , certamente superiore al numero massimo di caratteri che verranno verosimilmente trasmessi dal client.

E’ stato necessario inoltre cancellare l’errore con codice 66 che si verifica ogni qual volta la dimensione dei dati in arrivo non è quella attesa .

Per fare ciò è stato creato un sub VI chiamato elimina errori.vi che risulta essere una versione modificata del VI già presente in labVIEW denominato clear error.vi . Nella nostra versione è possibile specificare il codice dell’errore da eliminare.

I dati , una volta letti e suddivisi in username e password ,vengono inviati al sub VI Verifica

(7)

41

Fig. 4.10 : Icona del subVI Verifica dati.vi

Il subVI , la cui icona è mostata in figura 4.10, provvede al confronto dei dati inviati con quelli memorizzati su un file di testo denominato datiaccesso.txt contenuto nella cartella

dati del server.

In caso di mancata autenticazione il server invia al client il carattere F e si rimette in ascolto. Il client viene cosi’ invitato a inserire nuovamente i dati.

In caso di corretta autenticazione, l’indirizzo IP del client viene memorizzato in un file di testo denominato storiaconnessioni.txt ,contenuto anch’esso nella cartella dati del server. Vengono memorizzate anche data e ora della connessione.

Il salvataggio dei dati avviene grazie al subVI scrivi dati.vi la cui icona è mostrata in figura 4.11.

Fig. 4.11 : Icona del subVI scrivi dati.vi

Ad autenticazione avvenuta il server provvede ad inviare al client la lista dei Vis disponibili per il controllo remoto .

Tale lista viene conservata all’interno di un file di testo denominato nomivi.txt contenuto all’interno della cartella dati del server .

Il server comunica al client anche il tempo a disposizione per completare la sessione . La parte di codice che implementa queste istruzioni è mostrata nella figura 4.12.

(8)

42

Fig. 4.12 : Invio al client della lista contenente i nomi VI

A questo punto il server si rimette in ascolto sulla porta 2000 in attesa che il client invii la stringa che contiene informazioni sul VI scelto per il controllo.

La stringa ricevuta viene convertita nel numero corrispondente al VI scelto.

In particolare viene effettuato un controllo che permette di verificare se la stringa ricevuta contiene un numero , se il controllo va a buon fine , il numero è inviato alla parte di codice successiva che si occuperà di avviare l’applicativo , altrimenti il server si rimette in ascolto in attesa della stringa corretta ; questo sistema è stato adottato per evitare sovrapposizioni di connessioni. Un ulteriore controllo che viene effettuato ogni volta che l’utente invia comandi verso il server prevede la verifica della presenza del carattere speciale CR+LF che viene codificato in alfanumerico con il numero 10 .

Come si nota in figura 4.13 , il riscontro viene effettuato confrontando la stringa ricevuta con il codice corrispondente al carattere speciale. In caso di mancata coincidenza si genera un errore che viene gestito in maniera tale da consentire il ripristino del server.

L’elenco dei VI disponibili per il controllo è memorizzato in un file di testo denominato

(9)

43

Tutti questi meccanismi di verifica sono stati adottati perché può accadere che nella fase in cui il server aspetta dati dal client connesso un ulteriore client invii i dati per l’accesso sulla stessa porta.

Con il sistema descritto il server è in grado di ignorare le stringhe inviate dal nuovo utente. Tutta la parte di codice descritta fino ad ora è contenuta in un ciclo while che permette il ripristino delle funzionalità del server in qualsiasi situazione.

Fig. 4.13 : Attesa della stringa che contiene il riferimento al VI da controllare

Il riferimento al VI da aprire viene inviato al subVI richvi.vi la cui icona è mostrata in figura 4.14a

(10)

44

Il SubVI costruisce un vettore contenente i percorsi dei VI controllabili da remoto a partire da un file di testo denominato percorsivi.txt contenuto nella cartella dati del server e associa a ognuno di questi un numero che viene confrontato con quello inviato dal client.

Il percorso associato al VI selezionato viene passato poi al subVI avvio vi parte 1.vi la cui icona è mostrata in figura 4.14b e il cui diagramma a blocchi è illustrato in figura 4.15.

Fig. 4.15 : Codice del subVI Avvio vi parte 1.vi

Per mandare in esecuzione il VI selezionato dal client viene aperto un riferimento al suo percorso e successivamente, tramite un property node viene aperto il pannello frontale e tramite un invoke node viene avviato.

Le istruzioni appena descritte introducono alla parte operativa del sistema che si occupa della gestione della sessione di controllo vero e proprio da parte del client.

Tutte le istruzioni che seguono sono contenute in un secondo ciclo while che garantisce l’interazione ciclica con il client .

Le prime istruzioni , mostrate in figura 4.16 , permettono di ascoltare le richieste del client ;

(11)

45

Per evitare che il server rimanga inutilmente in attesa di richieste , nel caso in cui la connessione con il client venga interrotta ,a causa di malfunzionamenti o problemi di connessione, è stato introdotto un meccanismo che permette il recupero della durata massima della sessione ; questo tempo viene utilizzato come timeout .

Quando scatta il timeout si genera un errore e tutte le istruzioni successive non vengono eseguite .

La variabile booleana Status, presente nel cluster di errore , passa allo stato True e un successivo controllo sullo stato della variabile consente di fermare l’esecuzione del ciclo

while che stiamo descrivendo.

L’errore generato viene successivamente cancellato onde evitare che possa influire negativamente sul funzionamento del server nella sessione successiva.

Fig. 4.17 : Meccanismo di chiusura della sessione

Questo meccanismo consente , in definitiva, il ripristino del server allo stato iniziale di ascolto della rete in qualsiasi situazione.

Nella parte di codice che segue , mostrata in figura 4.18, si implementa la costruzione di un vettore contenente gli indirizzi IP degli utenti che fanno richiesta di accesso al sistema quando questo è occupato.

Tale lista viene visualizzata a display assieme al numero di tentativi effettuati.

(12)

46

Fig. 4.18 : Costruzione della lista dei client che richiedono l’accesso al sistema

Le istruzioni successive sono contenute in una struttura case contenente tre sotto casi . Il client decide quale parte di codice eseguire attraverso l’invio di una stringa che permette la selezione di uno dei tre casi della struttura .

Cominciamo dalla descrizione del caso di passaggio da uno strumento all’altro che viene effettuato solo se si riceve la stringa Camb .

La prima operazione effettuata consiste nel bloccare l’esecuzione e chiudere il pannello frontale del VI precedentemente controllato . Nella variabile locale path ,mostrata nella figura successiva, è contenuto il percorso dell’ultimo VI controllato dal client che verrà chiuso attraverso il subVI Chiudi VI parte 2.vi .

Fig. 4.19 : Chiusura ultimo VI controllato dal client

Il codice che segue contiene istruzioni , già descritte in precedenza ,che consentono di avviare il nuovo VI scelto a partire dal numero inviato dal client sotto forma di stringa.

(13)

47

Fig. 4.20 : Avvio del nuovo VI scelto dal client

Nel caso in cui non si siano verificati errori, la variabile status permette di non bloccare l’esecuzione del ciclo while che contiene le istruzioni descritte consentendo al server di ritornare in ascolto di nuovi comandi provenienti dal client ; se invece si verificano errori si blocca il ciclo while e il server torna ad ascoltare la rete in attesa di nuove connessioni . La parte di codice descritta viene ripetuta ogni volta che il client invia una richiesta di cambio strumento nei limiti definiti dal tempo a disposizione per completare la sessione.

Nel caso in cui l’utente decida di terminare la sessione o nel caso in cui il tempo a sua disposizione scada, il server riceve la stringa fine che seleziona il corrispondente caso nella

struttura case.

In questo caso la prima operazione sarà quella di chiudere l’ultimo VI controllato dal client ; successivamente verranno recuperati il numero dei files di testo e di immagine creati dall’utente nella sessione di lavoro ,come mostrato in figura 4.21.

(14)

48

Le istruzioni mostrate in figura 4.21 sono contenute in un ciclo for che viene eseguito due volte , una volta per i files di testo e una per le immagini salvate .

I percorsi dei files creati sono contenuti in due differenti files di testo , denominati File di

testo da inviare.txt e File immagini da inviare.txt contenuti nella sottocartella Agilent della

cartella dati del server.

A partire da questi files vengono costruiti due vettori che contengono i percorsi dei files sopraccitati .

Nel primo ciclo viene aperto il file che fa riferimento ai files di testo e nel secondo quello che fa riferimento alle immagini.

Dalla dimensione di questi vettori è possibile recuperare il numero dei files da inviare al client .

Tali numeri vengono convertiti in un vettore di stringhe , come si vede nella figura 4.22 ed utilizzati per costruire un messaggio contenente le informazioni da inviare client .

Fig. 4.22 : Numero di files da inviare al client

Il messaggio viene generato effettuando una composizione di stringhe tra il vettore sopraccitato e un messaggio di default , come si vede in figura 4.23 .

(15)

49

Una volta inviato il messaggio , il subVI filesender.vi comincia l’invio dei files creati al client . L’icona del subVI file sender.vi è mostrata in figura 4.24 .

Fig. 4.24 : Icona del subVI “filesender.vi”

Tutte le istruzioni presenti nel subVI sono contenute in un ciclo for che viene ripetuto due volte .

Fig. 4.25 : Prima partearte del codice del subVI “filesender.vi”

La prima operazione è quella di ascolto della rete in attesa dell’invio da parte del client di una stringa che identifichi il tipo di files da inviare .

Per selezionare quale da quale dei due files di elenco leggere, si utilizza una struttura case pilotata direttamente dalla stringa inviata dall’utente.

Da questi files si recupera il numero dei files generati dall’utente, che viene utilizzato per pilotare il successivo ciclo for da eseguire una volta per ognuno dei files da inviare.

Il numero totale di files da inviare , convertito in stringa , viene inviato al client , che conosce cosi’ in anticipo il numero di files da ricevere, come mostrato in figura 4.26.

(16)

50

Fig. 4.26 : Calcolo del numero dei pacchetti da inviare

Attraverso l’indice i del ciclo for si ricava ,dal vettore contenente i files da spedire, il percorso relativo a ciascun file.

Per la trasmissione di tali files è stata adottata una suddivisione in pacchetti di dimensione fissata ( impostazione di default 1000 Byte ).

Dapprima si legge il contenuto del file per calcolarne la dimensione in Byte , poi si divide tale numero per la dimensione del pacchetto, ottenendo il numero di pacchetti che compone il file. Tale numero viene convertito in stringa e inviato al client.

Questo è necessario perché, per l’invio del file, si ripeteranno determinate istruzioni contenute in un ulteriore ciclo for da eseguire un numero di volte pari al numero dei pacchetti ,come si vede in figura 4.27.

(17)

51

Fig. 4.27 : Ciclo For per l’invio del singolo pacchetto

Innanzitutto viene letto ,come file binario, il numero di bytes , specificato dalla dimensione del pacchetto, dal file da trasmettere e questo permette l’invio di qualunque tipo di file . Successivamente viene cancellato l’errore numero 4 che può avvenire se alla fine della lettura del file non si hanno i Bytes necessari per completare il pacchetto di dimensione fissata.

I dati vengono inviati sotto forma di vettore binario al subVI Crea pacchetto.vi il cui codice è mostrato nella figura 4.28.

Fig. 4.28 : Codice del subVI Crea pacchetto.vi

La prima operazione consiste nel convertire il vettore in una stringa e nel calcolarne la dimensione .

(18)

52

Parallelamente viene eseguita un’operazione di checksum sfruttando direttamente la funzione presente in labVIEW Add Array Elements ; tale funzione permette di sommare gli elementi di un vettore numerico ottenuto , nel nostro caso , dalla conversione del vettore binario.

Il risultato della somma viene convertito in stringa e composto con la stringa ottenuta dalla prima conversione andando a comporre la stringa pacchetto.

Inoltre viene anche creata un’ulteriore stringa dalla conversione della dimensione del pacchetto incluso il checksum ( dimensione stringa ).

Il client effettuerà la stessa operazione di checksum sul pacchetto ricevuto e confronterà il risultato ottenuto con quello ricevuto.

Se i risultati coincidono la spedizione è andata a buon fine , in caso contrario i dati possono essere stati alterati e l’utente riceverà un messaggio di errore.

Non è stato previsto un sistema di ritrasmissione dei dati in caso di errore perché durante le numerose prove effettuate non abbiamo riscontrato malfunzionamenti.

Come si vede dalla figura 4.27 le due stringhe in uscita dal subVI vengono inviate al client mediante due funzioni TCP write .

Tutte queste operazioni sono ripetute per ogni pacchetto; è da notare come, sia il riferimento al file che quello alla connessione, siano riutilizzati ad ogni ciclo for grazie all’uso di shift register .

Concluso il ciclo for , viene chiuso il riferimento al file ma non quello alla connessione che viene impiegato per l’invio dei files successivi .

Terminate le operazioni di invio dei files dello stesso tipo viene chiuso il riferimento alla connessione .

A questo punto il subVI si rimette in ascolto della rete in attesa di richieste di invio di files di diverso tipo .

Al termine del processo di invio dei files viene eseguito il subVI inizializzazione file.vi che compie le operazioni già descrite all’inizio del capitolo .

(19)

53

Fig. 4.29 : Fine della sessione di lavoro

Le ultime operazioni riguardano la cancellazione di eventuali errori , necessaria per il ripristino del server , il cambio dello stato del led Stato Server , che torna verde , e l’uscita dal secondo ciclo while descritto.

Trattiamo infine il caso in cui un nuovo utente invii i dati di autenticazione quando il server è occupato.

Durante le operazioni di controllo degli strumenti da parte del client il server rimane sempre in ascolto della rete, sia per gestire le richieste di cambio strumento e fine sessione di lavoro, sia per rispondere ad eventuali nuove richieste di connessione da parte di altri client. Anche questo caso è gestito dalla struttura case pilotata dalla stringa inviata dal client. Nel caso in cui non siano state riscontrate le stringhe camb o fine viene eseguito il caso di default corrispondente al caso False; le istruzioni contenute in questo caso sono illustrate in figura 4.30 .

Utilizzando il riferimento alla connessione con il nuovo client, il server è in grado di inviare una stringa contenente la lettera “o” che causerà la comparsa di un messaggio di occupato sul client.

(20)

54

Fig. 4.30 : Gestione del caso di server occupato

La nuova connessione viene a questo punto chiusa per evitare conflitti con la sessione in corso.

Da notare che il secondo ciclo while , in questo caso , non viene fermato per permettere al sistema di tornare ad ascoltare la rete per gestire eventuali altre richieste.

I due cicli while appena descritti sono contenuti all’interno di un ciclo while più esterno che permette di tornare , nei casi di fine sessione di lavoro o interruzione della connessione , all’ascolto della rete .

4.2 Cicli while paralleli

Passiamo ora alla descrizione degli altri cicli while presenti nel diagramma a blocchi dell’applicativo lato server.

Quello illustrato in figura 4.31 permette di controllare lo stato del tasto associato all’avvio del subVI nuova_password.vi che gestisce il cambio dei dati di accesso al sistema .

(21)

55

Fig. 4.31 : Attivazione del subVI per il cambio dei dati d’accesso

Tutte le istruzioni relative a questo subVI è contenuto all’interno di una struttura sequence . La prima parte del codice si occupa di aprire e leggere il contenuto del file di testo

datiaccesso.txt e li visualizza a display nel pannello del subVI.

La seconda parte , mostrata in figura 4.32 , gestisce il pannello per l’inserimento di nuovi dati .

E’ previsto un meccanismo di controllo della dimensione dei dati inseriti ; se la dimensione è quella attesa (8 caratteri per la password e 8 per l’username ) i dati vengono memorizzati nel file di testo attraverso il codice presente nella terza parte della struttura sequence.

In caso contrario si genera un messaggio di errore che invita l’amministratore del sistema a inserire dati della dimensione corretta.

(22)

56

Il ciclo while mostrato in figura 4.33 si occupa del controllo del tasto che attiva il subVI vipercorsi.vi ( icona al centro della struttura sequence ) che gestisce l’inserimento ,

l’eliminazione e la visualizzazione dei VI disponibili per il controllo.

Fig. 4.33 : Attivazione del subVI “vipercorsi.vi”

La prima parte del codice del subVI , mostrata in figura 4.34, crea il menù per la scelta dello strumento da rendere disponibile per il controllo remoto.

Nel pannello frontale vengono visualizzati due tabelle contenenti i percorsi e i nomi degli strumenti disponibili.

Queste tabelle sono create a partire dal file di testo percorsivi.txt in cui, per distinguere i vari elementi, è stato utilizzato il carattere speciale CR+LF .

(23)

57

Fig. 4.34 : Prima parte del codice associato al subVI vipercorsi.vi

Nel caso si voglia inserire un nuovo VI è necessario scegliere il percorso e premere il tasto

inserisci del pannello.

Viene poi effettuata una conversione da path a stringa del percorso stesso che viene

memorizzato nel file di testo dove sono presenti i VI precedentemente inseriti.

Dato che ad ogni VI è associato un numero , l’amministratore, mediante un selettore numerico può selezionare un VI da eliminare dalla lista.

Selezionato il numero e premuto il tasto elimina viene letto il file , creato il vettore dei VI indicizzato ed eliminato il VI corrispondente all’indice selezionato.

Viene infine riscritto e memorizzato il file con i percorsi contenuti nel nuovo vettore in cui sono presenti solamente i VI non eliminati.

Gli ultimi due cicli while presenti nel diagramma a blocchi , mostrati nella figura 4.35 , gestiscono , rispettivamente , il controllo dello stato del tasto di uscita dall’applicazione e la visualizzazione a display di data e ora del sistema.

(24)

58

Fig. 4.35 : Cicli while per l’arresto del VI e la visualizzazione di data e ora

Nel ciclo while che gestisce l’uscita dall’applicazione si notano due importanti funzioni; la prima ,già presente in labVIEW, è chiamata Current Vis path , ha l’ icona mostrata in figura 4.36 e consente di ricavare il percorso associato al VI in cui è posizionata.

Fig. 4.36 : Funzione Current VI’s Path

Questo percorso è necessario perché conoscendolo possiamo risalire all’estensione del programma in esecuzione ( .vi o .exe ) e indurre due comportamenti differrenti per il blocco dell’esecuzione.

Infatti il VI Quit.vi , il cui codice è mostrato in figura 4.37 , riceve in ingresso tale percorso e, dopo aver ricavato l’estensione del programma in esecuzione, seleziona la modalità di arresto .

(25)

59

Nel caso si tratti di un VI ne blocca semplicemente l’esecuzione ma si rimane nell’ambiente labVIEW ; nel caso di un eseguibile l’arresto comporta l’uscita dall’applicazione.

Infine si fa notare che tutte le volte che è stato necessario richiamare un file di testo nel codice , è stato utilizzato uno schema simile a quello illustrato in figura 4.38 .

Fig. 4.38 : Schema utilizzato per richiamare un file di testo

Nel codice , oltre alla funzione Current Vis path è presente il subVI Folder Path.vi. Il codice di quest’ultimo subVI è mostrato in 4.39.

Fig. 4.39 : Codice del VI Folder Path.vi

A partire dal percorso ,ricavato dalla funzione Current Vis path ,si ottiene l’estensione del programma in esecuzione.

In questo caso, l’operazione è necessaria perché se il file è un eseguibile oppure una libreria , nel suo percorso comparirà una ulteriore directory con nome uguale a quello del file ; quindi per ottenere il percorso esatto del file di testo da richiamare dobbiamo utilizzare, a seconda dei casi ,una o due volte la funzione Strip Path che consente di eliminare dal percorso l’ultima directory.

(26)

60

Lo schema usato permette di svincolare l’applicativo dalla collocazione della cartella che ospita il VI o l’eseguibile .

Non esistono inoltre vincoli sul percorso in cui installare la versione “installer” dell’applicativo.