CAPITOLO 2
GPIB
In questo capitolo verrà descritto come avviene la comunicazione fra strumento e server via GPIB.
2.1 – HPIB / GPIB
Il bus GPIB fu progettato nel 1965 dalla Hewlett-Packard per connettere i propri strumenti di misura ai PC e fu allora nominato HPIB (Hewlett Packard Interface Bus). Successivamente è stato reso standard dalla IEEE (Institute of Electrical and Electronics Engineers) ed è divenuto il più importante e popolare bus di comunicazione per gli strumenti di misura. In particolare IEEE standard 488-1975 definisce le specifiche elettroniche e meccaniche mentre ANSI/IEEE 488.2-1987 standard definisce il protocollo di comunicazione fra PC e strumenti. Un singolo bus GPIB supporta fino ad un massimo di 15 dispositivi collegati simultaneamente ed ha un transfer rate di 1 MByte al secondo.
2.2 – Principio di comunicazione e regole sintattiche
Le informazioni che lo strumento riceve, sotto forma di stringhe di testo, sono di 2 tipi:
•
Commands: sono stringhe che fanno si che lo strumento compia un’azione (ad es. la variazione di un settaggio)•
Queries: sono stringhe che fanno si che lo strumento generi una risposta, di solito senza causare nessun cambiamento di stato dello strumento.Il bus GPIB opera con modello block oriented che consente di poter combinare più commands e queries in un’unica linea di testo.
Commands e queries seguono la stessa regola sintattica: entrambe sono costituite da un header (una stringa di massimo 12 caratteri, ma in genere non più lunga di 4) che rappresenta l’abbreviazione del settaggio o della richiesta inviata allo strumento. L’unica differenza è che le queries terminano sempre con il punto interrogativo.
Nel progetto realizzato la comunicazione via GPIB viene gestita da 2 moduli presenti in LabVIEW: • write gpib che gestisce l’invio dei commands e delle queries allo strumento
2.3 – write gpib
Questo modulo ha la seguente struttura:
Dove:
timeout ms indica il tempo massimo in millesecondi trascorso il quale l’operazione viene annullata.
address string contiene l’indirizzo dello strumento col quale vogliamo comunicare. data è la stringa di testo contenente commands e\o queries che vogliamo inviare. mode indica come deve terminare la stringa da inviare alla periferica GPIB. In questo caso abbiamo usato come parametri i seguenti valori:
timeout = 5000 ms address string = 7 mode = 0
2.4 – read gpib
Questo modulo ha la seguente struttura:
timeout ms indica il tempo massimo in millesecondi trascorso il quale l’operazione viene annullata.
address string contiene l’indirizzo dello strumento col quale vogliamo comunicare. byte count specifica il numero di bytes che devono essere letti.
mode indica come termina la stringa ricevuta dalla periferica GPIB. In questo caso abbiamo usato come parametri i seguenti valori: timeout = 5000 ms
address string = 7 byte count = 2100 mode = 0
2.5 – Acquisizione dati
Quando viene premuto il tasto ACQUIRE sul server viene avviata la procedura di acquisizione dati (Fig. 2.1) ed ha inizio la comunicazione con lo strumento.
L’acquisizione delle 2 forme d’onda avviene in 4 passi successivi detti frame, numerati da 0 a 3:
Frame 0 (Fig. 2.2): viene inviata allo strumento, tramite il modulo write gpib, una stringa in cui sono presenti 2 commands e 2 queries.
Fig. 2.2 Frame 0
Il primo command (:wav:form byte) fa sì che lo strumento invii i dati in formato byte. Nel secondo command (sour chan1) è specificato che vogliamo acquisire la forma d’onda presente sul canale 1. Le due successive queries (pre?;data?) richiedono appunto il preambolo e i dati relativi alla suddetta forma d’onda.
Frame 1 (Fig. 2.3): successivamente, tramite il modulo read gpib, vengono acquisite, e in seguito salvate in una stringa di testo, le informazioni richieste.
Frame 2 (Fig. 2.4): si utilizza nuovamente il modulo write gpib per richiedere preambolo e dati alla forma d’onda presente sul canale 2.
Fig. 2.4 Frame 2
Frame 3 (Fig. 2.5): anche le informazioni relative alla seconda forma d’onda sono acquisite e salvate in una stringa di testo.
Fig. 2.5 Frame 3
I dati relativi alle forme d’onda possono essere inviati dall’oscilloscopio al server in 3 differenti formati: BYTE, WORD e ASCII. Nel formato BYTE è trasmesso 1 byte per ogni campione quindi la lunghezza della stringa di dati è 2000 byte. Nel fornato WORD vengono trasmessi 2 byte per ogni campione, quindi la stringa di dati sarà lunga 4000 byte. Nel formato ASCII i campioni sono convertiti in formato numerico prima di essere inviati; in questo caso sono trasmessi 13 byte per ogni campione, quindi la lunghezza complessiva della stringa di dati è 26000 byte.
In questo progetto è stato scelto il formato byte in modo da minimizzare la grandezza del pacchetto di dati da trasferire e di conseguenza il tempo di acquisizione fra strumento e server e fra server e client nonchè il traffico sulla rete. Questa scelta inoltre ci ha permesso di realizzare un’applicativo sul server più semplice in quanto non è stato necessario gestire la comunicazione
