6. Sincronização de medições

A sincronização de medições é um dos pontos mais importantes a ser considerados ao escrever qualquer programa de controle remoto. Negligenciar esse aspecto do seu programa leva a um comportamento imprevisível, resultados não reproduzíveis e muita frustração. Um sinal claro de sincronização inadequada da medição é quando você precisa inserir pausas fixas no seu programa para que ele seja executado.

Primeiro, vamos definir o que é uma sincronização de mediçãopara alcançar o objetivo desse capítulo:

Os instrumentos de medição atuais são dispositivos complexos que possuem seus próprios sistemas operacionais. Seu programa de medição não precisa se preocupar com o status do instrumento o tempo todo. A sincronização de medições é o método pelo qual você se certifica de que, em pontos importantes do seu programa (SyncPoints), seu instrumento está no estado esperado.

Um exemplo de sincronização de medição utilizando um osciloscópio e um dispositivo em teste (DUT) que gera um sinal não periódico:

Na figura acima, você vê que há seções ociosas no seu programa que precisam esperar que o instrumento se atualize. Observe que esses intervalos ociosos são dinâmicos em termos de duração. Eles devem se adaptar às diferentes condições (por exemplo, velocidade do seu computador, diferentes tempos de estabelecimento e aquisição do instrumento). Como é possível conseguir isso? A melhor maneira é deixar que o instrumento lhe diga quando estiver pronto. Serão apresentados diferentes métodos de sincronização após as observações a seguir.

Observações adicionais:

• Sempre opere um instrumento de aquisição (osciloscópio, analisador de espectro, medidor de potência...) no modo de aquisição única. Somente assim você poderá ter certeza de que os resultados de suas medições são obtidos a partir da última aquisição concluída, e não da anterior ou de uma aquisição ainda não concluída. E o mais importante: qualquer método de sincronização só funciona corretamente no modo de aquisição única.
• As configurações básicas e configurações de trigger não precisam ser sincronizadas. O único ponto-chave vem no final, quando você quer ter certeza de que todas as configurações foram aplicadas (SyncPoint 'SettingsApplied').
• Após a chegada do trigger, o osciloscópio inicia a aquisição da forma de onda. Seu programa deve esperar até que tenha finalizado (SyncPoint ‘AcquisitionFinished’).
• A leitura da forma de onda após esse SyncPoint garante que o resultado seja obtido a partir da aquisição mais recente.

Visão geral dos mecanismos de sincronização

Nos quatro tópicos a seguir, apresentaremos diferentes mecanismos de sincronização, listados desde os mais simples até os mais complexos:

• Consulta *OPC? (query)
• Sondagem de byte de status (STB)
• Espera por solicitação de serviço (SRQ)
• Evento de solicitação de serviço (SRQ)

Sincronização da query *OPC?

Esse é o método de sincronização mais fácil e mais frequentemente utilizado.

Quando você envia a query *OPC? para um instrumento, ele atrasa a resposta até que todas as operações pendentes tenham sido concluídas. Portanto, os períodos ociosos em seu programa estão ocorrendo em operações de leitura do VISA em que o programa espera que o instrumento responda ao comando de query *OPC? . Não é a resposta em si o que mais importa nessa situação, mas sim o atraso que ela gera.

Importante! Como o *OPC? é uma query, você não deve se esquecer de ler a resposta do instrumento com a função « VISA Read() ». Caso contrário, seu instrumento irá gerar um erro « Query Interrupted» (query interrompida) na próxima consulta. Isso não é só importante para o query *OPC? , mas também para qualquer outro query.

Aqui, devemos mencionar um parâmetro adicional – « VISA Timeout ». O « VISA Timeout » fornece o mecanismo pelo qual você pode definir o tempo máximo de espera nas operações de leitura do VISA antes que elas terminem com um erro de tempo limite alcançado do VISA. Como esse valor é individual e depende da duração da tarefa em andamento, certifique-se de definir o tempo limite do VISA apropriadamente – um tempo limite muito pequeno pode gerar erros indesejados durante operações regulares, um tempo limite muito grande faz com que seu programa não responda caso ocorra um erro real.

Vantagens:

• Simples e eficaz na maioria dos casos.
• Não utiliza o canal de controle da sessão (consulte o método de sondagem de byte de status), portanto também funciona com conexões de soquete brutoe serial.

Desvantagens:

• Bloqueia a comunicação com o instrumento até que ele responda. Isso pode ser crítico para operações de longa duração, em que o seu programa não emita respostas.

Sincronização de sondagem de byte de status (STB)

Esse método é utilizado pelos drivers de instrumentos da Rohde & Schwarz. Se você utiliza comandos diretos SCPI, veja os exemplos de implementação no final deste capítulo. Primeiro, vamos dar uma olhada no fluxograma que descreve o procedimento. A explicação vem logo a seguir.

Para explicar o fluxograma, precisamos analisar o subsistema de statusdo instrumento - uma estrutura hierárquica de registros com o principal no topo, chamado « Status byte »(byte de status ou STB). É um registro de 8 bits definido pelo padrão IEEE 488.2. Cada um de seus bits tem um significado diferente e serve como um sinalizador de resumo para os registros na cadeia hierárquica de registros de status. A estrutura completa do subsistema de status pode ser encontrada em qualquer manual de usuário de controle remoto de instrumentos da Rohde & Schwarz - pesquise o termo « Status Byte » (ou byte de status). A figura a seguir mostram dois tipos de registro, o « Status Byte register » (registro de byte de status) e o « Event Status Register »(ESRou registro de status do evento):

• A primeira operação do fluxograma define o filtro ESEpara 1 (Bit 0 = 1). Isso significa que estamos interessados apenas no ESR Bit 0 - OPC. Você só precisa enviar esse comando uma vez, depois de iniciar a conexão ou depois do comando *RST.
• A próxima operação consulta o valor do registro de status do evento com o comando *ESR?. Esse é um registro de EVENTO - seu valor é eliminado na leitura. Isso redefine o ESR Bit 0 - OPC de volta para 0.
• A próxima operação envia o comando que você deseja sincronizar. No nosso caso, é o comando SCPI SINGque prepara o osciloscópio para uma única aquisição. *OPC (sem o ponto de interrogação!) no final da string informa ao instrumento o seguinte: após todos os comandos dessa string serem executados e concluídos, defina o ESR Bit 0 - OPCpara 1. Por esse motivo foi necessário redefinir o valor para 0 antes. Caso contrário, ele poderia ter sido definido como 1 por alguma das ações anteriores e o loop de sondagem do byte de status terminaria de forma incorreta após a primeira repetição.
• A próxima operação é o loop de sondagem do byte de status. Você consulta o byte de status até que o Bit 5 - « Event Status Summary » (resumo do status do evento)seja definido como 1. O valor do byte de status pode ser recuperado de duas maneiras diferentes - com o comando SCPI *STB?, ou com uma função especial do VISA chamada « ReadSTB() ». Qual é a diferença entre eles? O *STB? é um comando SCPI padrão que usa buffers I/O do VISA. A função « ReadSTB() » se comunica por meio de um canal separado chamado « Control Channel »(canal de controle), e não interfere na comunicação padrão de escrita ou leitura. Ele também é otimizado para obter tempos de resposta mais curtos. Recomendamos incluir um atraso progressivo de sondagem dentro desse loop. Por exemplo: sem atraso nas primeiras 10 vezes, depois 1 ,milissegundo de atraso nas próximas 100 vezes, 10 milissegundos de atraso nas próximas 1000 vezes e assim por diante. Para evitar loops intermináveis, os drivers de instrumentos da Rohde & Schwarz usam o tempo limite chamado « OPC Timeout ».
• Após a finalização do loop, o ESR Bit 0 - OPC é redefinido novamente com o comando SCPI *ESR?

Vantagens:

• Não bloqueia a comunicação com o instrumento. Você pode paralelamente enviar comandos SCPI e receber respostas.
• Apropriado para operações de longa duração. Por exemplo, alinhamentos automáticos ou autotestes.

Desvantagens:

• Implementação mais complexa.
• Não funciona com conexões de soquete bruto e serial, pois elas não são compatíveis com a função de canal de controle « VISA ReadSTB() ».

Métodos avançados com a solicitação de serviço (SRQ)

Espera na sincronização da solicitação de serviço (SRQ)

Esse método é semelhante à sincronização de sondagem de bytes de status anterior, mas em vez de usar o loop de sondagem de bytes de status , ele usa uma função « VISA WaitOnEvent() »configurado para esperar o evento de solicitação de serviço. No final deste capítulo estará disponível alguns exemplos para este tipo de sincronização.

Para usar o mecanismo, você precisa:

• Realizar uma configuração única após reinicializar *ESE 1;*SRE 32(veja a imagem anterior dos registros do subsistema de status do instrumento). Isso faz com que o filtro ESE reaja ao bit ESR OPC da mesma forma que no método de sincronização anterior com a sondagem do byte de status. O comando. *SRE 32 define o filtro SREpara gerar a solicitação de serviçose o bit de resumo do status do evento do registro do byte de status estiver definido como 1.
• Antes de enviar o comando para sincronizar, ative o evento de solicitação de serviço com a função « VISA EnableEvent() ».
• Envie o comando para sincronizar com o ;*OPCno final.
• Utilize o método call (chamar) na função « VISA WaitOnEvent() ». Ele espera até que o evento de solicitação de serviço chegue ou o tempo limite expire.
• Desative o evento de solicitação de serviço com a função « VISA DisableEvent() ».

Vantagens:

• Em comparação com o método anterior, não é necessária a implementação do loop de sondagem de byte de status.
• O traço IO é mais curto e mais legível.

Desvantagens:

• Seu programa no LabVIEW e no MATLAB não pode ser interrompido durante a execução da função « VISA WaitOnEvent() ». Isso pode ser um problema no caso de comandos que levam muito tempo para serem concluídos, por exemplo, a query de autoavaliação *TST?
• Não é compatível com conexões de soquete duro e serial.

Sincronização de evento de solicitação de serviço

A ideia principal é que você inicie a tarefa de um instrumento e possa se concentrar em outra coisa. Quando o instrumento tiver concluído a tarefa, o VISA executará uma função de sua escolha. Esta função se chama « Event handler »(manipulador de eventos).

No final deste capítulo estará disponível alguns exemplos para este tipo de sincronização em C# e LabWindows/CVI.

Para usar o mecanismo de sincronização de eventos de solicitação de serviço, você precisa:

• Realizar uma configuração única após reinicializar *ESE 1;*SRE 32(veja a imagem anterior dos registros do subsistema de status do instrumento). Isso faz com que o filtro ESE reaja ao bit ESR OPC da mesma forma que no método de sincronização anterior com a sondagem do byte de status. O comando. *SRE 32define o filtro SRE para gerar a solicitação de serviço se o bit de resumo do status do eventodo registro de byte de statusé definido para 1.
• Antes de enviar o comando para sincronizar, é necessário registrar sua função de callback com a função « VISA InstallHandler() »e ativar o mecanismo de solicitação de serviço com a função « VISA EnableEvent() ».
• Envie o comando para sincronizar com o ;*OPCno final. Após a execução do comando ser concluída, o VISA chama sua função registrada.

Vantagens:

• Você pode executar outras tarefas durante esse período.
• Ideal para aplicações multi-threading.

Desvantagens:

• Implementação mais complexa.
• Não é compatível com conexões de soquete duro e serial.
• Não é compatível com o LabVIEW e o MATLAB.

Exemplos de comandos diretos SCPI

Exemplos da tarefa de medição acima com a sincronização de query *OPC? estão disponíveis para download a seguir, também encontrará exemplos de:

• Sincronização de sondagem de byte de status
• Espera pela sincronização da solicitação de serviço
• Sincronização de eventos de solicitação de serviço (em Python, C# e LabWindows/CVI)

Exemplos de drivers de instrumentos

Exemplos da tarefa de medição acima:

Outros recursos

Mais informações sobre o tópico de sincronização de medições podem ser encontradas aqui:

• 1EF62: « Hints and Tricks for Remote Control of Spectrum and Network Analyzers »
• 1GP79: « Top Ten SCPI Programming Tips for Signal Generators »