Appendice A
Il linguaggio SCPI
Introduzione
Per porre rimedio ad una situazione di confusione che si era venuta a creare nei primi anni '60 quando esistevano una larga varietà di interfacce e protocolli di comunicazione non standardizzate per il controllo tramite computer degli strumenti di misura, nel 1975 l'Institute of Electrical and Electronic Engineers (IEEE) approvò la normativa IEEE 488.
IEEE 488 definisce un protocollo standard per la trasmissione di dati fra strumenti e computer. Più precisamente tale normativa definisce un protocollo per lo scambio di informazioni tra strumenti e computer senza specificare il significato dei dati scambiati. Come conseguenza le industrie inventarono estensioni al protocollo dipendenti dallo specifico strumento, così nei primi anni '80 si iniziò a sentire l'esigenza di uno standard che permettesse di specificare anche la semantica dei dati scambiati via IEEE 488.
Nel 1987 la IEEE propose "IEEE 488.2 - 1987, Codes, Formats, Protocols and Common Commands for Use with IEEE 488.1-1987". Questo standard definisce le regole che devono soddisfare gli strumenti e i controllori di un sistema di misura, unitamente all'organizzazione della comunicazione e pure il formato e le specifiche di alcuni comandi frequentemente usati. Ogni industria di strumentazione era lasciata libera di definire invece il nome e gli effetti di altri comandi, e così è possibile che due strumenti simili e conformi allo standard IEEE 488.2, possano presentare comandi sintatticamente diversi. Per ovviare a tale inconveniente i principali costruttori hanno fondato un consorzio, il quale ha definito un'estensione del protocollo IEEE 488.2, lo standard SCPI (Standard Commands for Programmable Instruments). L’idea base dello standard consiste nel definire istruzioni associabili a blocchi funzionali nei quali si può pensare sia suddivisibile un qualsiasi strumento. Tale approccio presenta parecchi vantaggi. Innanzi tutto è possibile descrivere in modo uniforme una grande varietà di funzioni e strumenti. Vale a dire che lo SCPI rende compatibili, dal punto di vista della programmazione, strumenti di una stessa classe o strumenti aventi le stesse funzionalità. Ad esempio per una misura di tensione in continua su Oscilloscopi di case costruttrici diverse o anche impiegando un multimetro, si utilizza sempre la stessa istruzione cioè: SENSe:FUNCtion "VOLTage:DC", in modo analogo per la misura di frequenza mediante un Counter o un Oscilloscopio si userà il comando: SENSe:FUNCtion "FREquency". Si parla talvolta di coerenza di programmazione "verticale" per indicare l'utilizzo
dello stesso comando per controllare dispositivi appartenenti alla stessa classe (nell’esempio precedente la classe degli strumenti Oscilloscopi). Viceversa la coerenza "orizzontale" di programmazione consiste nell’uso dello stesso comando per controllare una funzionalità simile in strumenti di classi diverse.
Per quanto riguarda le risposte che gli strumenti inviano all'host computer, si osserva che il formato della risposta di uno strumento compatibile SCPI ad una particolare richiesta è ben definito, riducendo così lo sforzo di interpretazione dei dati o dello stato del dispositivo in quanto il formato dei dati e le informazioni sullo stato sono forniti in un formato indipendente dal particolare dispositivo dialogante.
Un ulteriore vantaggio associato allo standard SCPI è di ridurre il tempo di sviluppo dei programmi di implementazione dei comandi degli strumenti sui dispositivi compatibili SCPI, fornendo un linguaggio di programmazione facile da interpretare e ben strutturato. In particolare per un impiego remoto dello strumento, semplici comandi SCPI comportano per l’utilizzatore, un controllo della strumentazione SCPI facile e veloce, mentre un controllo della strumentazione tradizionale spesso fornisce parecchi comandi dettagliati ma complicati.
Il linguaggio è progettato per essere espanso in futuro con nuovi comandi mantenendo la compatibilità con i comandi già definiti; infatti non appena un costruttore propone un nuovo strumento, il linguaggio di programmazione viene aggiornato in modo da rimanere compatibile con gli strumenti SCPI esistenti. Il Consorzio SCPI analizza annualmente le proposte di estensione dei comandi dello standard, proposte che possono essere inoltrate sia dai membri del Consorzio sia da altri enti interessati. Le revisioni dello standard, pubblicate annualmente, hanno validità immediata e diventano parti permanenti del linguaggio, per cui ogni copia di SCPI è caratterizzata dall'anno di emissione di quella versione. La proposta di un nuovo comando può essere accettata se rispetta le regole di "Syntax and Style" e se non esiste un comando che controlla la stessa funzionalità.
L’SCPI risulta essere estremamente versatile e adatto alle più diverse applicazioni e può essere utilizzato su interfacce IEEE 488.1, IEEE 488.2, VXI Bus, RS232C e altre.
Ovviamente, dal punto di vista della programmazione l'uso dello standard SCPI riduce notevolmente lo sforzo di sostituzione di uno strumento SCPI con un altro SCPI rispetto a strumenti non compatibili con tale standard, ma non risolve le problematiche associate all'accuratezza, alla risoluzione e alle funzionalità diverse degli strumenti.
Organizzazione del linguaggio SCPI
Il linguaggio SCPI è definito da una grammatica rappresentata mediante un albero, vale a dire da una struttura gerarchica; ogni stringa comando è formata dalla successione di parole che si incontrano percorrendo l’albero dalla radice ad una foglia terminale.
Il carattere ":" indica il passaggio nell’albero ad una foglia sottostante e separa le parole nel comando. Ad esempio, il comando: SENSe:CURRent:DC:RANGe:AUTO ON è rappresentato, nell’albero SCPI, dal percorso evidenziato nel grafico sottostante:
LIV. 0 SCPI Sottalbero TRIGger LIV. 1 INPut DISPlay SENSe TRIGger
LIV. 2 COUPling MENU RESistance CURRent DELay LIV. 3 NAME AC DC
LIV. 4 RANGe LIV. 5 AUTO
Le parti del comando associate a ciascuna foglia nell'albero sono dette anche "parole chiavi". Ognuna di queste occupa un diverso livello nell’albero. Comandi corti sono formati da parole chiavi di alto livello e forniscono maggiore generalità all'istruzione. Viceversa un comando formato da molte parole chiavi sostituisce nello standard una istruzione di funzionalità più complessa e maggiormente legata alle caratteristiche dello strumento considerato. Inoltre, ad ogni parola chiave si può associare un sottoalbero, il quale si può interpretare come un set di comandi dello strumento caratterizzati da una funzionalità comune. Ad esempio, il sottoalbero TRIGger raccoglie tutte le istruzioni che riguardano il blocco funzionale di sincronizzazione degli eventi. In particolare una foglia terminale può considerarsi un sottoalbero degenere che individua un solo comando. In questa ottica conviene considerare ogni strumento come un insieme di blocchi funzionali che si scambiano dati o messaggi di controllo; ogni blocco rappresenta una particolare funzione dello strumento e lo standard SCPI definisce quindi un albero per la generazione di comandi in corrispondenza di ogni funzione indicata nei blocchi.
Il modello generale di uno strumento programmabile è il seguente: - Signal;
- Data bus Signal Routing Measurement Function Format: è il blocco di condizionamento del segnale. I comandi associati a questa funzionalità hanno in comune la parola chiave ROUTe del linguaggio SCPI. Tali comandi adattano il segnale alle caratteristiche richieste nella porta di ingresso o nella porta di uscita dello strumento. Il blocco Measurement Function può essere scomposto nei sottoblocchi: INPut, SENSe, CALCulate. Tale blocco di misura esegue inizialmente un condizionamento del segnale d’ingresso (blocco INPut) tramite le funzioni di filtraggio del segnale (FILTer), di offset (OFFSet), di amplificazione (GAIN) e di attenuazione (ATTenuation).
Successivamente il blocco SENSe converte i segnali fisici in dati numerici da inviare all'host computer; le funzioni tipiche implementate da "SENSe" sono quelle di definizione del tipo,
dell’ampiezza, della risoluzione del segnale da misurare. Tale blocco è presente in tutti gli strumenti programmabili che misurano grandezze ed è caratterizzato da un ampio numero di sottosistemi. Il flusso di dati viene in seguito elaborato (blocco CALCulate) per fornire grandezze derivabili da quelle principali, in genere più semplici da utilizzare o di immediata interpretazione e per convertire unità di misura.
- Trigger Memory: il blocco trigger permette di sincronizzare le operazioni dello strumento. Si distinguono nello SCPI associati a tale blocco funzionale quattro sottoalberi di comando: TRIGger, ARM, INITiate e ABORt. Il blocco Memory è associato ad un set di comandi di gestione della memoria del dispositivo. Esso definisce le operazioni di salvataggio dei dati all'interno dello strumento. La memoria dello strumento può essere inaccessibile all'operatore, oppure può essere solo letta o ancora può essere accessibile sia in lettura sia in scrittura.
- Signal;
- Data bus Signal Routing Signal Generation Format: i blocchi INPut, SENSe, CALCulate sono associati agli omonimi sottoalberi dei comandi.
Strumenti che utilizzano sorgenti interne di segnale sono costituiti da blocchi funzionali di generazione del segnale (Signal Generation), i quali possono essere a loro volta scomposti in tre sottoblocchi: CALCulate, SOURce e OUTPut.
Il blocco di OUTPut esegue il condizionamento del segnale generato ed è costituito dalle funzioni di filtraggio, di offset, di attenuazione e di guadagno. Esso è presente in tutti gli strumenti del tipo "sorgente di segnale".
Il blocco di SOURce genera un segnale analogico a partire da parametri opportuni o da dati numerici. Tale blocco è presente in tutti i generatori di segnale e contiene un gran numero di funzioni secondarie a seconda del tipo di segnale da generare.
Infine il blocco CALCulate permette la conversione dei dati numerici cambiando l'unità di misura.
I blocchi OUTPut, SOURce, CALCulate sono associati agli omonimi sottoalberi dei comandi.
Uno strumento può implementare solo alcune delle funzionalità del modello mostrato in precedenza, restringendo al minimo i comandi accettabili. Ad esempio un voltmetro con un solo ingresso può implementare istruzioni SCPI relative ai blocchi di Measurement Function, Trigger, Format senza necessariamente interessare il blocco Memory o Signal Routing.
Pertanto un voltmetro può essere descritto dal sottoinsieme: - Signal Measurement Function Format;
Descrizione di alcuni sottoalberi
-
DISPlay Sottosistema:il sottosistema DISPlay controlla la presentazione testuale, la parte grafica e le informazioni della traccia. Le informazioni della traccia includono dati di misurazione e dati provenienti dall’interazione dell’utente con il pannello dello strumento. Le foglie principali del sottoalbero DISPlay sono: MENU, WINDow, GRAPhics, STATe, TEXT, TRACe.-
FORMat Sottosistema: il sottosistema FORMat raccoglie un vasto insieme di differenti rappresentazioni di dati per il trasferimento numerico e ordinato di informazioni. Le foglie principali del sottoalbero sono: DATA, SREGister. Il comando associato alla foglia DATA fornisce l'impostazione di configurazione dati. Viene specificato il tipo e la lunghezza dei dati. I tipi di dati validi sono: ASCii, INTeger, UINTeger, REAL, HEXadecimal, OCTal, BINAry, e PACKed. Il parametro <length> da specificare con questo comando è opzionale per tutti i tipi; il suo significato è dipendente dal tipo selezionato. Un esempio di implementazione del comando FORMat:DATA. L'input sottosistema controlla le caratteristiche del segnale all’ingresso dello strumento. In particolare i sottoalberi principali associati a tale sottosistema sono: ATTenuation, COUPling, FILTer, GAIN, IMPedance, OFFSet, POSition.-
MEASure Sottosistema: Lo scopo del gruppo di istruzioni MEASure è l'acquisizione di dati usando un insieme di istruzioni di alto livello. Il gruppo di istruzioni MEASure ha una dualità; si distinguono comandi e richieste caratteristiche. Diversamente, con il sottosistema CONFigure, posizionato allo stesso livello di MEASure, si hanno delle forme distinte di richieste e di comandi. Le istruzioni del sottosistema MEASure si riferiscono alle caratteristiche del segnale quando viene misurato, esse sono strutturate per permettere all'utente di controbilanciare l’intercambiabilità del controllo nel processo di misurazione. MEASURE fornisce una completa capacità operativa dove lo strumento è configurato; l'effettuazione di una misura fornisce, mediante operazioni sul segnale misurato, i valori di determinati parametri associati. Spesso è richiesto un più preciso controllo della misurazione. Perciò MEASURE è integrata provvedendola di due comandi: CONFigure e READ. CONFigure svolge la parte della configurazione della misura e READ svolge l’acquisizione dei dati post elaborati e parte dell’elaborazione della misura. Si può operare una configurazione generica della misurazione utilizzando CONFIGURE e quindi modificare la misurazione cambiando le funzioni dello specifico strumento. Il READ poi, completa il processo di misura. Il sottosistema READ è suddiviso in due ulteriori comandi: INITiate[:IMMediate] e FETch?.INITiate[:IMMediate]. Il sottosistema FETCH opera la funzione post elaborazione dati. Su un singolo set di dati acquisiti si possono implementare molte istruzioni FETCH. Per fare un esempio, in un oscilloscopio si possono acquisire moltisegnali di misura che contengono parecchie informazioni, come la frequenza del segnale, il voltaggio AC e DC. Un segnale transitorio può essere catturato usando MEASURE, READ o INITIATE. FETCH permette di ottenere ciascuna caratteristica dei differenti segnali senza riacquisire una nuova misura. MEASURE fornisce la compatibilità migliore tra gli strumenti perché non è richiesta la conoscenza dello strumento per compiere l’operazione. CONFIGURE/READ è meno compatibile se la riconfigurazione dello strumento è compiuta tra le operazioni CONFIGURE E READ. Questo perché la riconfigurazione dipende dallo strumento specifico. FETCH è ancora meno compatibile perché la conoscenza dello strumento è necessaria per determinare se l’informazione è stata acquisita dallo stesso. Per fare un altro esempio, un oscilloscopio può catturare sia il tempo di salita sia l’ampiezza dell’impulso in una singola acquisizione. Se l’ampiezza dell’impulso fosse acquisita attraverso un comando MEASURE, sarebbe possibile misurare il tempo di salita.
Se l’ampiezza dell’impulso fosse misurata con un cronometro, le informazioni sul tempo di
salita non potrebbero essere disponibili senza operare un’altra acquisizione dei dati. Perciò FETCH non potrebbe essere usato. Cambiando alcune parti dell’acquisizione di uno strumento, i dati di misura esistenti potrebbero essere invalidati. Per esempio la sequenza: INITiate;CONFigure:VOLTage;FETCH:VOLTage? potrebbe generare un errore perché il dato è stato invalidato dal comando CONFIGURE. Riconfigurando il display o i blocchi del tracciato non si avrà questo effetto.
-
SENSe Sottosistema: I comandi SENSe sono organizzati in molte sezioni. Ciascuna sezione o sottosistema tratta controlli che riguardano direttamente lo strumento specifico, posizionati nel dispositivo e non riferiti invece alle caratteristiche del segnale diretto. Questi comandi sono relazionati attraverso il nodo SENSe. Il nodo SENSe può essere opzionale in particolari strumenti. Il motivo per il quale SENSe viene reso opzionale è di permettere a dispositivi che dispongono di sensori primari di accettare comandi brevi/corti. Il nodo SENSE non può essere un optional se SOURce o ROUTe sono optional anch’essi, poiché solo un nodo a un dato livello può essere un optional. Per esempio, un tipico calcolatore può scegliere di fare il nodo SENSE optional, dal momento che i comandi più frequentemente usati sarebbero sotto il sottosistema SENSE. Se il calcolatore contiene anche sia la funzione SOURce sia la funzione ROUTing, queste dovrebbero essere controllate attraverso i loro rispettivi nodi. Un nodo optional come SENSE implica che il dispositivo accetterà i comandi con o senza il nodo optional e si avrà lo stesso risultato. Il dispositivo è implementato per accettare il nodo optional, se inviato senza errori. In alcuni casi, un sensore può contenere sorgenti dipendenti o funzioni sensorie. L’aggiuntiva funzionalità dipendente sarà posta come sottonodi SENSE o SOURCE. Inoltre i nodi opzionali (SENSE, SOURCE e ROUTE) non sono ammessi se questa funzionalità dipendente esiste in un dispositivo. Altrimenti potrebbe verificarsi conflittinell’interpretazione dei comandi, per esempio tra SENSE e SOURCE se SOURCE diventa un optional. Il sottonodo FREQuency di SENSe contiene parecchi comandi che hanno complessi accoppiamenti. Fra gli altri include i comandi START, STOP, CENTER e SPAN.
-
SOURce: I comandi SOURce sono divisi in molte sezioni. Ciascuna sezione o sottosistematratta con i controlli che direttamente interessano diversi blocchi del dispositivo, e non sono invece relazionati con le caratteristiche del segnale diretto. Questi comandi sono referenziati attraverso il nodo SOURce. Il nodo SOURce può essere un optional in un dispositivo particolare. La ragione per cui SOURce è opzionale e per permettere a dispositivi che sono sorgenti primarie di accettare comandi più corti. Il nodo SOURce non può essere opzionale se lo sono anche il SENSe e il ROUte, perché solo un nodo ad un dato livello può essere opzionale. Per esempio un tipico alimentatore di potenza può scegliere di rendere il nodo SOURce opzionale, dal momento che i comandi più frequentemente usati saranno sotto il sottosistema SOURce. Un nodo optional, come SOURce, implica che il dispositivo accetterà e svilupperà i comandi con o senza tale nodo avendo lo stesso risultato. Il dispositivo è implementato per accettare il nodo optional, se inviato senza errore. In alcuni casi, un SOURce può contenere sorgenti dipendenti o funzioni sensorie. Allora l’aggiuntiva funzionalità dipendente sarà collocata come sottonodi SENSE o SOURCE. Inoltre, non sono ammessi i nodi optional (SENSe, SOURce o ROUTe) se questa funzionalità dipendente esiste in un dispositivo. Altrimenti potrebbero verificarsi conflitti nell’interpretazione dei comandi per esempio tra SOURce e SENSe se a SENSe fosse permesso di essere un optional. I sottonodi principali di SOURce sono CURRent, POWer, VOLTage, FREQuency e RESistance. Questi sottonodi contengono molti set di comando che hanno complessi accoppiamenti.
Sintassi e stile dei comandi SCPI
Tutti gli strumenti SCPI devono rispettare le specifiche fisiche di IEEE 488.2.
Comandi obbligatori per IEEE 488.2
Alcuni comandi già definiti nello standard 488.2 devono essere obbligatoriamente gestiti da uno strumento compatibile SCPI. Tali comandi sono i seguenti:
- *CLS CLEAR STATUS COMMAND
- *ESE STANDARD EVENT STATUS ENABLE COMMAND - *ESE? STANDARD EVENT STATUS ENABLE QUERY - *ESR? STANDARD EVENT STATUS REGISTER QUERY - *IDN? IDENTIFICATION QUERY
- *OPC? OPERATION COMPLETE QUERY - *RST RESET COMMAND
- *SRE SERVICE REQUEST ENABLE COMMAND - *SRE? SERVICE REQUEST ENABLE QUERY - *STB? READ STATUS BYTE QUERY
- *TST? SELF-TEST QUERY
- *WAI WAIT-TO-CONTINUE COMMAND
Questi particolari comandi prendono il nome di Common Commands e sono inviati dal controller ai vari dispositivi. Essi devono obbligatoriamente iniziare con il carattere ASCII "*" e sono formati da tre caratteri maiuscoli, eventualmente seguiti da un punto di domanda quando il comando è una richiesta di informazioni al dispositivo.
Spesso tali comandi interessano i bit dei registri del dispositivo, quindi conviene prima di descriverli parlare dei registri di stato nello standard 488.2 i quali definiscono lo stato dello strumento. Le informazioni sullo stato di un dispositivo possono essere fornite tramite due modalità distinte. La prima è basata sull’uso di registri nei quali viene indicato se rispetto ad una situazione di riferimento si è verificato una variazione.
E’ possibile anche avere la successione degli stati di un dispositivo utilizzando una struttura di accodamento (output queue) nella quale vengono sequenzialmente memorizzate tutte le variazioni di stato che si verificano. In tal modo si ha come informazione aggiuntiva l’evoluzione dello stato del dispositivo.
Ad ogni strumento è imposta una struttura interna minima per indicare il suo stato, che prende il nome di struttura standard, nella quale alcuni parametri sono obbligatori, mentre altri sono lasciati alla libertà del progettista in modo da permettere la rappresentazione anche di situazioni dipendenti specificatamente dal tipo di strumento utilizzato.
Descrizione di alcuni common command
*CLS : Il comando Clear Status azzera i bit del registro di stato e i bit del registro di stato degli eventi. Azzera pure tutti i bit collegati a code ad eccezione della Output Queue.
*ESE : Il comando Standard Event Status Enable imposta i bit del registro dello Standard Event Status Enable. Il parametro di questo comando è definito come <Decimal Numeric Program Data>. Questo numero è di tipo integer decimale ed è espresso in base binaria nella rappresentazione dei bits dello Standard Event Status Enable Register. Ad esempio per settare il bit 5 (Command Error) e il bit 2 (Query Error) il comando inviato allo strumento dal controller sarà: *ESE 36.Il parametro inviato al dispositivo deve essere nel range tra 0 e 255 altrimenti si verificherà un Execution Error.
*ESE?: L'Event Status Enable Query legge i contenuti dello Standard Event Status Enable Register (SESER). In risposta a questa richiesta il dispositivo invierà il contenuto del SESER nel formato integer con valore compreso tra 0 e 255.
*ESR? : L'Event Status Register Query legge i contenuti dello Standard Event Status Register. Leggendo questo registro azzera i suoi bits e invia un numero intero che convertito in notazione binaria rappresenta in modo ordinato i valori dei bit del registro. Questo numero in notazione decimale deve essere compreso tra 0 e 255.
*OPC : Il comando Operation Complete chiama il dispositivo per impostare il bit "operazione completa" (bit 0) nello Standard Event Status Register quando sono state completate tutte le operazioni in sospeso.Dopo l'esecuzione del comando lo strumento è in stato Operation Complete Command Active (OCAS) e ritorna nello stato Operation Complete Command Idle State (OCIS) ogni qualvolta nessuna operazione è in sospeso e nello stesso tempo il valore del bit OPC è 1. Gli eventi seguenti forzano lo strumento in OCIS:accensione dello strumento, esecuzione di *CLS, esecuzione di *RST.
*OPC? Il comando Operation Complete Query chiama lo strumento per impostare il carattere ASCII '1' nell'output queue quando completa tutte le operazioni in sospeso. Un dispositivo è nell'Operation Complete Query Active State (OQAS) dopo che ha eseguito *OPC?. Lo strumento ritorna all'Operation Complete Query Idle State (OQIS) ogni qualvolta non vi è nessuna operazione in sospeso e nello stesso tempo imposta un "1" nel output queue.
*STB? : Al comando Status Byte Query richiesto dal controller, il dispositivo risponde inviando il byte del registro di stato nel quale in questo caso il bit 6 assume il significato di Master Summary Status, MSS, ed è ottenuto logicamente con modalità simili a quelle del bit RQS.
*RST : Il comando di Reset riporta lo strumento nello stato di accensione. Lo stato di accensione è specificato nel manuale del dispositivo; il progettista definisce i parametri da assegnare allo strumento quando viene inviato tale comando che corrisponde alla configurazione iniziale. Non è permesso lasciare l’inizializzazione del comando *RST indefinito. In particolare per non rischiare di produrre condizioni pericolose devono essere rispettate alcune regole generali:
o Lo strumento, dopo il comando *RST è configurato per effettuare misure automatiche.
o Il comando *RST imposta lo strumento nello stato di attesa di un comando che dia inizio alla misura
o Dopo il comando *RST gli strumenti dovrebbero porsi nelle seguenti condizioni:
• Il Trigger è inattivo.
• Il campo d’ingresso è posto in "AUTORANGE" o alla minima sensibilità.
*IDN? : L’Identification Query legge dal dispositivo la sua stringa di identificazione. La stringa di identificazione è suddivisa in quattro campi separati da virgole. Il primo campo
è il nome del produttore, il secondo è il nome del modello, il terzo non viene utilizzato (sempre a "0"), il quarto è un codice di revisione contenente tre numeri. Il primo numero è il numero di revisione del firmware per il processore principale dello strumento; il secondo è per il processore ingresso/uscita e il terzo è per il processore del pannello frontale. Ad esempio per un alimentatore HPE3631A il formato della stringa di identificazione sarà: HEWLETT-PACKARD, E3631A, 0, X.X-X.X-X.X.
*SRE : Il comando Service Request Enable abilita i bit contenuti nel registro del Byte di stato. Il parametro del comando deve essere di tipo integer in notazione decimale. La conversione del parametro in notazione binaria deve rappresentare i valori dei bit nel Service Request Enable Register. Ad esempio per settare il bit 4 (Message Available) il comando da inviare sarà *SRE 16.
*SRE? : Il Service Request Enable Query richiede il contenuto del registro di abilitazione del Byte di stato. Lo strumento risponde con un valore decimale, che corrisponde alla somma ponderata in modo binario di tutti i bit impostati nel registro.
*TST?:Il Self-Test Query esegue un test automatico completo dello strumento. Il risultato è "0" se il test automatico passa e "1" o un altro valore diverso da 0 se il test fallisce. In questo caso viene generato un messaggio di errore con ulteriori informazioni sul motivo del fallimento.
*WAI : Il comando Wait to Continue ordina allo strumento di attendere il completamento di tutte le operazioni pendenti prima di eseguire altri comandi attraverso l’interfaccia.
Notazioni dello standard SCPI
Nel manuale SCPI si fa ampio uso di diagrammi di flusso di sintassi e di tavole. Sia i diagrammi sia le tavole sono impiegate per rappresentare le notazioni dello standard SCPI. In questo paragrafo si evidenzieranno entrambi.
La tavola di comandi è utilizzata per definire una serie di comandi SCPI associata ad una radice. Una tavola definisce i comandi, le loro relazioni gerarchiche, i parametri se ve ne sono, e i commenti sui comandi.
La tavola è divisa in tre colonne: KEYWORD (Parola chiave), PARAMETER FORM (Finestra Parametri), e NOTES (Note).
La colonna KEYWORD provvede a specificare il nome del comando. Il nome attuale del comando consiste di uno o più parole chiavi SCPI definite in una struttura gerarchica. In un tale sistema ad albero parole chiavi nello stesso livello vengono rappresentate incolonnate e allineate. Viceversa nodi appartenenti a differenti livelli corrispondono nella tavola a parole chiavi collocate
diversamente; parole a livello più basso nella gerarchia sono posizionate via via più a destra e nodi più vicini alla radice più a sinistra.
Un particolare comando comporta la specifica dell'intero percorso. Questo percorso è rappresentato nelle tavole mettendo il nodo più alto della gerarchia nella parte più a sinistra e gli altri via via più a destra.
La parentesi quadra indica una parola chiave opzionale. Quando il programmatore citerà il comando con tale parola chiave, l'esecuzione di questo avrà lo stesso effetto nel caso che quest'ultima venga omessa. Un tale nodo è chiamato nodo di default.
La colonna PARAMETER FORM indica il numero e l'ordine di parametri in un comando ed il loro valore. Un comando può permettere l'uso di definiti tipi di parametri SCPI.
Nella colonna PARAMETER FORM una certa quantità di caratteri ha significato speciale: • le parentesi angolate (<>) stanno ad indicare il tipo di parametro.
• le parentesi quadre ([]) sono usate per includere uno o più parametri opzionali nel controllo di uno strumento.
• la barra verticale ( | ) è usata per separare parametri alternativi.
La forma interrogativa di un comando si ottiene con l'aggiunta di un punto interrogativo all'ultima parola chiave. Tuttavia non tutti i comandi hanno una forma interrogativa, mentre altri esistono solo in quest'ultima sintassi.
