• Non ci sono risultati.

Capitolo 6

N/A
N/A
Protected

Academic year: 2021

Condividi "Capitolo 6"

Copied!
14
0
0

Testo completo

(1)

Capitolo 6 – Modifiche effettuate sui VI esistenti

84

Capitolo 6

Modifiche effettuate agli applicativi esistenti.

I VI che consentono il controllo da locale degli strumenti sono stati realizzati da tesisti precedenti.

Tuttavia , per permettere il controllo da remoto via web , è stato necessario introdurre delle modifiche per garantire la generazione di files e la corretta acquisizione dei dati .

6.1 Modifiche introdotte al VI che consente il controllo dell’oscilloscopio Agilent 54641 A

La prima parte di codice modificata è quella che riguarda l’acquisizione dell’immagine visualizzata dall’oscilloscopio.

Infatti nella versione originaria è stato creato un applicativo lato server e uno lato client. Il lato server serve esclusivamente per acquisire due vettori di dati rappresentanti le tracce dei due canali visualizzati sullo schermo dell’oscilloscopio.

Questo avviene tramite la pressione del tasto ACQUIRE .

(2)

Capitolo 6 – Modifiche effettuate sui VI esistenti

85

Il programma è strutturato , dunque , in maniera tale da consentire l’acquisizione dell’ immagine solo dal lato server tramite protocollo GPIB , attraverso le istruzioni mostrate in figura 6.2.

Fig. 6.2 : Parte del codice che implementa l’acquisizione dati dall’oscilloscopio

Il ciclo while consente il controllo dello stato del tasto ACQUIRE che una volta premuto invia il comando di acquisizione mediante la funzione GPIB Write su entrambi i canali e riceve vettori di dati, acquisendoli mediante la funzione GPIB Read .

Esiste poi un blocco di istruzioni che gestisce la trasmissione delle informazione verso i client.

Il server è continuamente in ascolto della rete per raccogliere le richieste di acquisizione dati provenienti dai client come si vede nella figura 6.3 .

(3)

Capitolo 6 – Modifiche effettuate sui VI esistenti

86

Se dal client giunge la stringa “A” viene aperta una nuova connessione e trasmesso , mediante la funzione TCP Write, il contenuto delle variabili “chan 1 data” e “chan 2 data” come mostrato nella figura seguente.

Fig. 6.4 : Apertura della connessione tra server e client

Questo meccanismo funziona perfettamente in ambito locale perché, permettendo l’acquisizione solo dal lato server, evita conflitti nell’acquisizione e permette la diffusione dell’immagine acquisita in modalità broadcast .

Per i nostri scopi era necessario fare in modo che il singolo client connesso potesse autonomamente acquisire le immagini dallo strumento.

Non avrebbe avuto infatti alcun senso prevedere un meccanismo che avesse bisogno dell’intervento di un amministratore sul lato server.

Abbiamo dunque deciso di trasferire le funzionalità riguardanti l’acquisizione delle immagini dal lato server al lato client dando vita a un nuovo VI chiamato Agilent_54641A.vi .

Abbiamo modificato il codice del VI originario , chiamato Agilent_54641A_client.vi,

intervenendo sulla event structure che gestisce le operazioni da compiere alla pressione

del tasto per l’acquisizione dal server .

E’ stata sostituita la parte che, alla pressione del tasto ACQUIRE, permetteva l’invio delle richieste e la lettura dei dati provenienti dal server, con le istruzioni che permettono di

(4)

Capitolo 6 – Modifiche effettuate sui VI esistenti

87

acquisire direttamente l’immagine dallo strumento mediante protocollo GPIB, come mostrato nella figura 6.5.

Fig. 6.5 :Codice per l’acquisizione dei dati dallo strumento

Con queste modifiche il VI controllato da remoto ha il comportamento voluto , essendo del tutto indipendente dal VI server del sistema originario.

E’stato inoltre necessario modificare il meccanismo di generazione dei files di testo e delle immagini.

Infatti il programma originario, lato client, permetteva la generazione di tali files mediante la pressione del tasto SAVE .

Alla pressione del tasto , il VI raccoglieva le informazioni utili per la generazione del file e le inviava ai subVI Save Graph.vi e Save XY Graph.vi a seconda della modalità in cui si trovava l’oscilloscopio (main o xy) .

(5)

Capitolo 6 – Modifiche effettuate sui VI esistenti

88

Fig. 6.6 : Pannello frontale del subVI Save Graph.vi

Nella versione originaria , una volta premuti i tasti Save data e Save graph, comparivano le finestre di dialogo che consentivano all’utente di scegliere il percorso di salvataggio dei file. Questo meccanismo funzionava correttamente quando il VI originario era presente sul pc client , come previsto per il funzionamento su rete locale.

Nel caso di passaggio al controllo remoto del VI , come nel nostro caso , il funzionamento è regolare fino all’apertura del pannello frontale di figura 6.6 ma alla pressione del tasto Save

data o Save graph viene aperta la finestra di dialogo per la scelta del percorso solo sul lato

server .

Questo , oltre a impedire il salvataggio dei dati sul lato client , comporta il blocco del server a causa della comparsa della finestra di dialogo che necessita della presenza di un operatore per la scelta del percorso.

Per aggirare questa difficoltà si è scelto di indicizzare i nomi dei files generati e salvarli sempre nella stessa cartella , nel percorso : Server Teledidattica\dati\AGILENT .

Descriveremo la procedura per l’indicizzazione dei nomi per i files immagine del menù main , negli altri casi, il meccanismo , mostrato in figura 6.7 , è analogo.

(6)

Capitolo 6 – Modifiche effettuate sui VI esistenti

89

Fig. 6.7 : Meccanismo di indicizzazione dei files

La parte di codice del subVI Save Graph.vi , che riguardava la creazione della finestra di dialogo, è stata sostituita con quella che permette l’indicizzazione del nome dei files.

Dapprima viene aperto il file di testo percorsjpeg.txt che contiene il nome dell’ultimo file salvato.

Tale nome è formato da parte fissa e da una parte variabile che consiste in un numero . Il numero viene incrementato alla creazione del nuovo file.

Il nome iniziale , recuperato alla prima apertura dal file di testo, è grafico0.jpeg e non corrisponde a nessun file creato ma serve solo per inizializzare il meccanismo.

Quando l’utente crea dei files , questi vengono salvati nella cartella AGILENT con i nomi : grafico1.jpeg , grafico2.jpeg e cosi’ via.

Questa operazione viene realizzata grazie al subVI Indicizza nome grafico.vi la cui icona è mostrata in figura 6.8.

Fig. 6.8 : Icona del file Indicizza nome grafico.vi

Tutto il codice relativo a questo subVI è contenuto in una struttura sequence .

Nel primo frame viene letto il contenuto di un file di testo il cui percorso è specificato in ingresso.

Nel secondo frame , che contiene il codice mostrato in figura 6.9 , si realizza il recupero dell’indice presente nel nome dell’ultimo file creato e si genera l’indice da aggiungere al nome del file successivo.

(7)

Capitolo 6 – Modifiche effettuate sui VI esistenti

90

Fig. 6.9 : Parte del codice del subVI Indicizza nome grafico.vi

Mediante una composizione , viene creata la stringa che rappresenta il nuovo percorso di salvataggio del file creato.

Questa , convertita opportunamente in path , viene memorizzato sia nel file percorsjpeg.txt, per poter essere successivamente recuperato , che nel file di testo File immagini da

inviare.txt contenuto nella stessa cartella.

Quest’ultima operazione è necessaria per la creazione di un file di testo contenente tutti i files di immagine creati dall’utente durante la sessione di lavoro.

Le istruzioni descritte sono mostrate nella figura seguente.

Fig. 6.10 : Ultima parte del codice del subVI Indicizza nome grafico.vi

Come spiegato nel capitolo tre , alla fine di ogni sessione viene esaminato il contenuto dei files che contengono l’elenco dei files da inviare per recuperare i relativi percorsi e provvedere all’invio verso il client.

(8)

Capitolo 6 – Modifiche effettuate sui VI esistenti

91

Alla fine della sessione di lavoro tutti i files generati vengono cancellati ; i files contenenti i percorsi vengono invece inizializzati ai valori di default ; infine , i files elenco, vengono inizializzati con una stringa vuota.

Dato che l’utente ha la possibilità di creare due tipi di files ( testo e immagini ) in due modalità differenti ( MAIN e XY ) è stato necessario creare quattro subVI che differiscono esclusivamente per il nome e l’estensione da associare ai files creati .

Il sistema utilizza due files di testo con l’elenco dei files .txt da inviare e con l’elenco dei files .jpeg da inviare.

Riportiamo di seguito una tabella con l’elenco dei files utilizzati dal sistema e una loro breve descrizione .

Nome del file Descrizione

File di testo da inviare.txt Contiene l’elenco dei percorsi dei files di testo da

inviare .

File immagini da inviare.txt Contiene l’elenco dei percorsi dei files di immagine

da inviare .

percorsjpeg.txt Contiene il percorso relativo all’ultimo file immagine

generato (modalità MAIN)

percorsotxt.txt Contiene il percorso relativo all’ultimo file di testo

generato (modalità MAIN dell’oscilloscopio o HP )

percorsoxyjpeg.txt Contiene il percorso relativo all’ultimo file immagine

generato (modalità XY)

percorsoxy.txt Contiene il percorso relativo all’ultimo file di testo

generato (modalità XY)

datitesto0.txt Contiene un file di testo vuoto che serve per avviare

l’indicizzazione dei files di testo (modalità MAIN dell’oscilloscopio o HP)

datitestoXY0.txt Contiene un file di testo vuoto che serve per avviare

l’indicizzazione dei files di testo ( modalità XY)

grafico0.jpeg Contiene un file di immagine vuoto che serve per

avviare l’indicizzazione dei files di immagine ( modalità MAIN)

graficoXY0.jpeg Contiene un file di immagine vuoto che serve per

avviare l’indicizzazione dei files di immagine ( modalità XY)

(9)

Capitolo 6 – Modifiche effettuate sui VI esistenti

92

Tutti i files che compaiono nella tabella sono contenuti nel percorso :

Server Teledidattica\dati\AGILENT .

Infine abbiamo eliminato l’immagine di default che veniva caricata all’avvio del VI .

Nella nostra versione, all’avvio , compare lo schermo vuoto e per ottenere un immagine è necessario premere il tasto Acquire.

6.2 Modifiche introdotte al VI che consente il controllo dell’analizzatore di trasmissioni digitali HP 3784A

Nell’architettura del sistema originario erano previsti tre VI : Hp3784A_server.vi, server.vi e Hp3784A_client.vi .

Il primo si occupava del dialogo tra il server e lo strumento tramite protocollo GPIB ed inoltre consentiva il collegamento con il client mediante protocollo TCP IP .

Il secondo permetteva all’amministratore del sistema di scegliere tra tre diverse modalità di funzionamento :

• Only Server: modalità che permette di controllare lo strumento unicamente dal server senza nessuna visualizzazione sui clients che si trovano quindi nello stato Offline.

(10)

Capitolo 6 – Modifiche effettuate sui VI esistenti

93

• Broadcasting: modalità in cui ogni client connesso riceve le impostazioni dal server

mentre questo comanda lo strumento.

Fig. 6.12 : Modalità Broadcasting

• Client Control: in questa modalità il client selezionato ha il controllo completo dello strumento e sul server vengono riportati i settaggi che il client prescelto imposta sullo strumento.

(11)

Capitolo 6 – Modifiche effettuate sui VI esistenti

94

Per i nostri scopi , essendoci un solo client connesso per ogni sessione di lavoro, sono state eliminate due modalità di funzionamento : broadcasting e client control.

Questo ha reso possibile l’eliminazione del VI server.vi , che permetteva all’amministratore la scelta della modalità di funzionamento .

Inoltre ,dato che non si ha più la necessità di separare le prerogative dell’amministratore e quelle dell’utente finale , abbiamo eliminato anche il VI Hp3784A_client.vi .

Abbiamo dunque utilizzato il VI Hp3784A_server.vi , opportunamente modificato e rinominato come Hp3784A.vi .

Quest’ultimo , controllato da remoto , consente l’utilizzo di tutte le funzioni disponibili nella versione originaria per il controllo dello strumento da locale.

Le prime modifiche apportate al VI riguardano la rimozione della parte di codice che permetteva il dialogo tra il server e i vari client tramite le funzioni TCP IP.

E’ rimasta inalterata , invece, la parte del VI che permette il dialogo con la macchina tramite le funzioni GPIB.

La versione originaria dell’applicativo , inoltre , non prevede la generazione di nessun tipo di file dato che le varie informazioni , riguardanti il settaggio dello strumento e i risultati della misura sono visualizzate a display.

Per i nostri scopi abbiamo previsto un meccanismo di recupero e salvataggio su file di testo di queste informazioni.

L’utente ha la possibilità di creare in ogni istante questo file premendo il tasto CREATE FILE , aggiunto appositamente al pannello frontale dello strumento.

Per la creazione del suddetto file è stato necessario introdurre una cospicua parte di codice che si occupa del recupero delle informazioni e della generazione della stringa che viene memorizzata nel file di testo.

Tutte le istruzioni aggiunte sono contenute in un ciclo while per permettere il controllo dello stato del tasto CREATE FILE .

(12)

Capitolo 6 – Modifiche effettuate sui VI esistenti

95

Fig. 6.14 : Parte del codice per la generazione del file che memorizza i dati della misura

Dato che la visualizzazione della maggior parte dei dati mostrati a display avviene tramite strutture ring , è stato necessario ricavare dalle proprietà di tali ring l’elenco delle corrispondenze tra numero in uscita e risultati associati.

Un esempio di tali corrispondenze è mostrato in figura 6.15.

(13)

Capitolo 6 – Modifiche effettuate sui VI esistenti

96

L’uscita del ring pilota poi una struttura case contenente tutte le opzioni possibili sotto forma di stringa .

In altri casi le informazioni visualizzate a display sono costituite da un singolo elemento di un vettore .

In questi casi è stato necessario ricavare tutti gli elementi del vettore mediante cicli for , utilizzando l’indice i del ciclo per ricavarli.

Un esempio è mostrato in figura 6.16.

Fig. 6.16 : Esempio di recupero dati da un vettore

Successivamente, le stringhe ricavate con questi meccanismi, vengono composte tramite la funzione Concatenate string e utilizzate per la creazione del file, come si vede in figura 6.17 .

(14)

Capitolo 6 – Modifiche effettuate sui VI esistenti

97

Fig. 6.17 : Generazione del file di testo che raccoglie impostazioni e risultati

Anche in questo caso abbiamo fatto ricorso al meccanismo di indicizzazione dei vari files creati dall’utente nella sessione di lavoro per le stesse ragioni già illustrate nel paragrafo precedente.

Il nome del file in cui vengono memorizzate tutte le informazioni raccolte è datitestoi.txt , dove l’indice i che compare alla fine del nome è incrementato ad ogni pressione del tasto

CREATE FILE .

Questi files , una volta creati , vengono aggiunti alla lista memorizzata nel file già descritto nel paragrafo precedente File di testo da inviare.txt.

Le istruzioni descritte sono mostrate in figura 6.18.

Figura

Fig. 6.1 : Architettura del sistema progettato per il controllo locale
Fig. 6.2 : Parte del codice che implementa l’acquisizione dati dall’oscilloscopio
Fig. 6.4 : Apertura della connessione tra server e client
Fig. 6.5 :Codice per l’acquisizione dei dati dallo strumento
+7

Riferimenti

Documenti correlati

Si definiscono tre relazioni RA(XA), RB(KA*, XB), RC(KA*, XC), dove RA contiene tutti gli elementi della classe A, anche se stanno in qualche sottoclasse,

Le caratteristiche delle basi di dati sono garantite da un sistema per la gestione di basi di dati (DBMS, Data Base Management System), che ha il controllo dei dati e

ABITA BRAVO CRLINI DECCA ESTERLE FUNDARI GIANI ABITA BACCO CARLINI DINI ESTERLE FALCONI GIANI. Sono incluse tutte

quando si inserisce un’ennupla nella tabella Studenti, o quando si modifica il campo chiave esterna, il valore della chiave esterna deve essere presente

 Data una collezione di documenti e un bisogno informativo dell’utente, obiettivo dell’IR è di recuperare, all’interno di una collezione, tutti e solo i

 Se i sistemi di indicizzazione e ricerca tradizionali sono basati sui termini, sulla logica delle parole chiave i sistemi di recupero più innovativi richiedono

 Afferisce è multivalore da Dipartimenti a Docenti: ad un oggetto della classe Dipartimenti possono essere associati più oggetti della classe Docenti; si modella

Si definiscono tre relazioni RA(XA), RB(KA*, XB), RC(KA*, XC), dove RA contiene tutti gli elementi della classe A, anche se stanno in qualche sottoclasse,