6. Sincronizzazione delle misure

La sincronizzazione delle misure è uno dei punti più importanti da tener presente quando si scrive un'applicazione di controllo remoto. Trascurare questo aspetto del programma si traduce in comportamenti imprevedibili, risultati irripetibili e molta frustrazione. Un chiaro segno di sincronizzazione impropria delle misure si ha quando è necessario inserire pause fisse nell'applicazione per farla funzionare.

Definiamo innanzitutto la Sincronizzazione delle misureper le finalità del presente capitolo:

Gli strumenti di misura odierni sono dispositivi complessi con sistemi operativi propri. L'applicazione di misura non deve preoccuparsi continuamente dello stato dello strumento. La sincronizzazione delle misure è il metodo con cui ci si assicura che, in punti importanti del programma (SyncPoints), lo strumento si trovi nello stato previsto.

Un esempio di sincronizzazione della misura con un oscilloscopio e un dispositivo in prova che genera un segnale non periodico:

Dall'immagine precedente si nota che nel programma ci sono sezioni inattive che devono attendere che lo strumento si aggiorni. Si noti che questi periodi di inattività hanno una durata dinamica. Devono adattarsi alle diverse condizioni (ad esempio, la velocità del PC, i diversi tempi di assestamento e di acquisizione dello strumento). Come si può ottenere questo risultato? Il modo migliore è lasciare che sia lo strumento a dirvi quando è pronto. I diversi metodi di sincronizzazione vengono presentati dopo le note seguenti.

Note aggiuntive:

• Utilizzare sempre uno strumento di acquisizione (oscilloscopio, analizzatore di spettro, misuratore di potenza...) in modalità di acquisizione singola. Solo così si può essere certi che i risultati delle misure provengano dall'ultima acquisizione completata e non da quella precedente o da quella non ancora completata. Ma soprattutto: qualsiasi metodo di sincronizzazione funziona correttamente solo in modalità di acquisizione singola.
• Le impostazioni di base e quelle del trigger non devono essere sincronizzate. L'unico punto chiave importante arriva alla fine, quando ci si deve assicurare che tutte le impostazioni siano state applicate (SyncPoint 'SettingsApplied').
• Dopo l'arrivo del trigger, l'oscilloscopio avvia l'acquisizione della forma d'onda. Il programma deve attendere che essa sia terminata (SyncPoint ‘AcquisitionFinished’).
• La lettura della forma d'onda dopo questo SyncPoint assicura che il risultato provenga dall'acquisizione più recente.

Panoramica dei meccanismi di sincronizzazione

Nei quattro capitoli seguenti vengono presentati diversi meccanismi di sincronizzazione, dal più semplice al più complesso:

• Interrogazione (query) *OPC?
• Polling del byte di stato (STB)
• Attesa di una richiesta di assistenza (SRQ)
• Evento di richiesta di assistenza (SRQ)

Sincronizzazione di interrogazioni *OPC?

È il metodo di sincronizzazione più semplice e più frequentemente utilizzato.

Quando si invia la query *OPC? a uno strumento, la risposta viene ritardata fino al termine di tutte le operazioni in sospeso. Pertanto, i periodi di inattività del programma si verificano durante le operazioni di lettura VISA, in cui il programma attende che lo strumento risponda alla query *OPC?. Non è la risposta in sé che conta, ma piuttosto il ritardo che essa genera.

Importante! Trattandosi di una interrogazione *OPC?, non bisogna dimenticare di leggere la risposta dello strumento con la funzione VISA Read(). In caso contrario, lo strumento genera l'errore "Query interrotta" dall'interrogazione successiva. Questo aspetto è importante non solo per l'interrogazione *OPC?, ma per tutte le interrogazioni.

A questo punto dobbiamo menzionare un parametro aggiuntivo: il timeout VISA. Il timeout VISA fornisce il meccanismo che consente di definire il tempo massimo di attesa nelle operazioni di lettura VISA prima che queste terminino con un errore di timeout VISA. Poiché questo valore è individuale e dipende dalla durata dell'attività corrente, assicurarsi di impostare il timeout di VISA in modo appropriato: un timeout troppo piccolo potrebbe generare errori indesiderati durante le operazioni regolari, mentre un timeout troppo grande rende il programma non reattivo in caso di errore reale.

Vantaggi:

• Semplice ed efficace nella maggior parte dei casi.
• Non utilizza alcun canale di controllo della sessione ( vedere il metodo di polling dell'STB), quindi funziona anche con connessione RawSockete seriale.

Svantaggi:

• Blocca la comunicazione con lo strumento finché non risponde. Questo può essere critico per le operazioni di lunga durata, quando l'applicazione diventa non reattiva.

Sincronizzazione del polling del byte di stato (STB)

Questo metodo è utilizzato dai driver dello strumento Rohde & Schwarz. Se si utilizzano comandi SCPI diretti, gli esempi di implementazione sono riportati alla fine di questo capitolo. Diamo un'occhiata, innanzitutto, al diagramma di flusso che illustra la procedura. La spiegazione viene fornita di seguito.

Per spiegare il diagramma di flusso, è necessario analizzare il Sottosistema di statodello strumento - una struttura gerarchica di registri con quello principale in cima chiamato Byte di stato(STB). Si tratta di un registro a 8 bit definito nello standard IEEE 488.2. Ciascuno dei suoi bit ha un significato diverso e serve come summary flag (contrassegno riepilogativo) per i registri lungo la catena gerarchica dei registri di stato. La struttura completa del sottosistema di stato si trova in qualsiasi manuale d'uso del controllo remoto di uno strumento Rohde & Schwarz (cercare il termine "byte di stato" o "Status Byte"). L'immagine seguente mostra il registro dei byte di stato più il secondo registro Registro di stato degli eventi(ESR):

• La prima operazione del diagramma di flusso imposta il filtro ESEsu 1 (Bit 0 = 1). Ciò significa che a noi interessa solo ESR Bit 0 - OPC. È sufficiente inviare questo comando una volta, dopo aver avviato la connessione o dopo il comando *RST.
• L'operazione successiva interroga il valore del registro ESR con il comando *ESR?. Questo registro è un registro EVENTO: il suo valore viene cancellato alla lettura. In questo modo si resetta l'ESR Bit 0 - OPC a 0.
• L'operazione successiva invia il comando che si desidera sincronizzare. Nel nostro caso si tratta del comando SCPI SINGche attiva l'oscilloscopio per un'acquisizione singola. *OPC (senza il punto interrogativo!) alla fine della stringa indica allo strumento: dopo che tutti i comandi di questa stringa sono stati eseguiti e terminati, impostare ESR Bit 0 - OPCa 1. Per questo motivo, prima è stato necessario reimpostare il valore a 0. Altrimenti potrebbe essere stato impostato a 1 da alcune azioni precedenti, e il ciclo di polling dell'STB terminerebbe in modo errato dopo la prima iterazione.
• L'operazione successiva è il loop di polling dei byte di stato. Si interroga il byte di stato fino a quando il Bit 5 - Riepilogo dello stato dell'eventoè impostato a 1. Il valore del byte di stato può essere recuperato in due modi diversi: con il comando SCPI *STB?, oppure con una funzione speciale VISA chiamata ReadSTB(). Qual è la differenza? *STB? è un comando SCPI standard che utilizza i buffer I/O VISA. La funzione ReadSTB() comunica attraverso un canale separato chiamato Control Channel, e non interferisce con la comunicazione SCPI standard di scrittura/lettura. È inoltre ottimizzato per ottenere tempi di risposta più rapidi. Si consiglia di inserire un ritardo di polling progressivo all'interno di questo ciclo. Ad esempio: nessun ritardo per i primi 10x, poi 1ms di ritardo per i successivi 100x, 10ms di ritardo per i successivi 1000x e così via... Per evitare loop infiniti, i driver dello strumento Rohde & Schwarz utilizzano un timeout chiamato OPC Timeout.
• Al termine del loop, il bit 0 ESR - OPC viene nuovamente azzerato con il comando SCPI *ESR?

Vantaggi:

• Non blocca la comunicazione con lo strumento. È possibile inviare parallelamente comandi SCPI e ricevere risposte.
• Adatto per impieghi di lunga durata. Ad esempio, autoallineamenti o autotest.

Svantaggi:

• Più complesso da implementare.
• Non funziona con le connessioni RawSocket e seriale, poiché queste non supportano la funzione del canale di controllo VISA ReadSTB().

Metodi avanzati con richiesta di assistenza (SRQ, Service Request)

Attesa di una sincronizzazione della richiesta di assistenza (SRQ)

Questo metodo è simile alla precedente sincronizzazione del polling dei byte di stato, ma invece del ciclo di polling STB, utilizza una funzione VISA WaitOnEvent()configurata per attendere l'evento di richiesta di assistenza. Esempi di questo tipo di sincronizzazione sono disponibili alla fine di questo capitolo.

Per utilizzare il meccanismo, è necessario:

• Eseguire un'impostazione una tantum dopo il reset di *ESE 1;*SRE 32(vedere l'immagine precedente Registri del sottosistema di stato dello strumento). In questo modo, il filtro ESE reagisce al bit OPC ESR come nel metodo di sincronizzazione precedente con il polling STB. "*SRE 32" imposta il filtro SREper generare una Richiesta di assistenzase il bit Riepilogo dello stato dell'evento del registro STB è impostato su 1.
• Prima di inviare il comando di sincronizzazione, attivare l'evento di richiesta di assistenza con la funzione VISA EnableEvent().
• Inviare il comando per sincronizzarsi con ;*OPCalla fine.
• Richiamare la funzione VISA WaitOnEvent(). Attende fino all'arrivo dell'evento di richiesta di assistenza o alla scadenza del timeout.
• Disattivare l'evento di richiesta di assistenza con la funzione VISA DisableEvent().

Vantaggi:

• Rispetto al metodo precedente, non è necessaria l'implementazione del loop di polling dell'STB.
• IO Trace è più breve e più leggibile.

Svantaggi:

• L'applicazione in LabVIEW e MATLAB non può essere interrotta durante l'esecuzione di VISA WaitOnEvent(). Questo può essere un problema nel caso di comandi che richiedono molto tempo per essere completati, come ad esempio per l'interrogazione *TST? dei selftest.
• Non supportato con la connessioni RawSocket e seriale.

Sincronizzazione di evento di richiesta di assistenza (SRQ)

L'idea principale è quella di iniziare il lavoro di uno strumento e concentrarsi su qualcos'altro. Quando lo strumento ha terminato il compito, VISA richiama una funzione a scelta dell'utente. Questa funzione è chiamata Event handler (Gestore di eventi).

Esempi di questo tipo di sincronizzazione in C# e LabWindows/CVI sono disponibili alla fine di questo capitolo.

Per utilizzare il meccanismo di sincronizzazione degli eventi di richiesta di assistenza, è necessario:

• Eseguire un'impostazione una tantum dopo il reset di *ESE 1;*SRE 32(vedere l'immagine precedente Registri del sottosistema di stato dello strumento). In questo modo, il filtro ESE reagisce al bit OPC ESR come nel metodo di sincronizzazione precedente con il polling STB. *SRE 32imposta il filtro SRE per generare una richiesta di assistenza se il bit Riepilogo dello stato dell'eventodel registro STBè impostato a 1.
• Prima di inviare il comando di sincronizzazione, è necessario registrare la funzione di callback con la funzione VISA InstallHandler()e abilitare il meccanismo di richiesta di assistenza con la funzione VISA EnableEvent().
• Inviare il comando per sincronizzarsi con ;*OPCalla fine. Al termine dell'esecuzione del comando, VISA richiama la funzione registrata.

Vantaggi:

• È possibile eseguire altre operazioni nel frattempo.
• Ideale per applicazioni multi-threading.

Svantaggi:

• Più complesso da implementare.
• Non supportato con la connessioni RawSocket e seriale.
• Non supportato in LabVIEW e in MATLAB.

Esempi di comandi SCPI diretti

Esempi di attività di misura con la sincronizzazione delle interrogazioni *OPC? , più:

• sincronizzazione del polling STB
• Attesa di sincronizzazione della richiesta di assistenza
• Sincronizzazione degli eventi di richiesta di servizi (in Python, C# e LabWindows/CVI)

Esempi di driver dello strumento

Esempi dell'attività di misura sopra descritta:

Altre risorse

Ulteriori informazioni sulla sincronizzazione delle misure sono disponibili qui:

• 1EF62: Suggerimenti e trucchi per il controllo remoto di analizzatori di spettro e di rete
• 1GP79: I dieci suggerimenti più importanti di programmazione SCI per i generatori di segnali