Escolha um intervalo de sondagem do medidor de energia equilibrando a taxa útil de atualização da medição, a capacidade do barramento serial, o tempo de resposta do dispositivo e a atualidade exigida pela aplicação. Sondar mais rápido do que o medidor pode atualizar pode retornar valores repetidos enquanto consome capacidade de comunicação. Sondar demasiado lentamente pode perder mudanças úteis ou deixar um painel desatualizado. Calcule um orçamento de transações, teste a rede real sob condições normais e de falha de dispositivos, e defina como os carimbos de data/hora e a qualidade dos dados são armazenados. Não existe uma configuração universal de um segundo que seja adequada para todos os instrumentos, gateways e tarefas de monitorização.
Este guia foca na programação de aquisição após uma conexão documentada funcionar. Comece com a guia de configuração do medidor de energia Modbus para verificação da interface e do mapa de registos. Exemplos numéricos abaixo descrevem uma rede hipotética, não a velocidade de resposta ou configurações suportadas de qualquer modelo BY194.
Pergunte qual ação os dados coletados devem suportar. Relatórios de consumo rotineiro, exibições para operadores, revisão de demanda e investigação de perturbações têm necessidades de temporização diferentes. Uma tendência destinada a mostrar um padrão operacional horário não requer o mesmo arranjo de aquisição que uma investigação de uma transiente curta. Defina uma idade máxima aceitável dos dados para cada uso antes de escolher um intervalo de comunicação.
Separe a atualidade do armazenamento histórico. Uma exibição para operador pode atualizar-se frequentemente enquanto o historiador armazena um resumo documentado em um intervalo mais longo. Por outro lado, um historiador pode receber registros frequentes que são meramente duplicados de uma atualização de medidor interno mais lenta. Registe onde cada atualização, transferência e agregação ocorre para que a resolução aparente do sistema não seja confundida com uma nova informação de medição.
Verifique se a aplicação requer um gravador adequado em vez de registos polled comuns. O guia do gravador de qualidade de energia explica o papel dos instrumentos capazes de eventos. Um ciclo de software rápido não converte um medidor de painel em um gravador de formas de onda nem prova conformidade com um padrão de medição de qualidade de energia.
Solicite o mapa de registos exato, tamanhos de leitura suportados, comportamento documentado de atualização de medição e quaisquer restrições de comunicação para a configuração fornecida. O série CNBYG BY194 fornece um ponto de partida relevante para o produto. Sua aparência no painel frontal não estabelece um intervalo de sondagem mínimo, função de instantâneo atômico ou buffer histórico.
Distingua amostragem interna, atualizações de janela de cálculo, atualização de exibição, disponibilidade de registos e sondagem externa. Essas etapas podem operar em relógios diferentes. Um medidor pode calcular uma medição internamente antes que um registo de comunicação a exponha, e um gateway pode adicionar outro cache. Pergunte qual carimbo de data/hora, se houver, identifica a medição em vez do momento em que o software a recebeu.
Quando o temporizador publicado estiver incompleto, mantenha a incerteza e execute uma observação de leitura apenas aprovada. Meça os tempos de resposta e o comportamento de valores repetidos sem afirmar que a resposta mais rápida observada é um mínimo garantido. Inclua carga representativa e o caminho final do gateway, pois uma conexão de bancada pode comportar-se de forma diferente da instalação de produção.
Para RTU serial, comece pelas caracteres enviados e recebidos. O Protocolo de aplicação Modbus define as estruturas relevantes de pedido e resposta, enquanto o guia de linha serial Modbus define o enquadramento e o temporizador. Use ambos juntamente com as instruções do dispositivo; a aritmética de mensagens sozinha não é uma especificação completa de desempenho.
Para uma leitura hipotética da função-03 de dez registos, uma solicitação RTU ocupa oito bytes e uma resposta normal ocupa vinte e cinco bytes, incluindo o endereço do quadro serial e CRC. Assumindo onze bits transmitidos por carácter e 9.600 bits por segundo, o tempo combinado na linha é 33 × 11 / 9.600 segundos, ou cerca de 37,8 milissegundos.
Este é um componente inferior do orçamento de transação. Adicione o tempo de retorno real do dispositivo, o silêncio entre quadros necessário, atrasos do conversor ou gateway e a sobrecarga de agendamento. O guia serial descreve lacunas RTU baseadas em caracteres a velocidades de transmissão mais baixas e tempos recomendados fixos acima de 19.200 bits por segundo. Não leve o cálculo do tempo de carácter para cada configuração serial sem verificar a sua aplicabilidade.

Estime o tempo de serviço para cada grupo de pedidos agendados, não apenas para cada medidor. Um único instrumento pode precisar de várias leituras de registos não contíguos. Por outro lado, registos contíguos compatíveis podem às vezes ser agrupados dentro de limites documentados. O mapa e o comportamento do dispositivo determinam se o agrupamento é adequado; nunca cruze regiões não suportadas apenas para reduzir o número de pedidos.
Use Tcycle ≥ soma dos tempos de serviço da transação mais margem planeada como uma verificação de capacidade para um segmento serial sequencial. Num teste ilustrativo, doze transações com uma média de oitenta milissegundos requerem cerca de 0,96 segundos antes de margem adicional ou tentativas. Um ciclo de um segundo deixaria, portanto, muito pouco espaço para variabilidade normal. O valor de oitenta milissegundos é um exemplo de entrada que deve ser substituído por dados observados e especificados do projeto.
| Item de orçamento | Como estabelecer | Porque é que isso importa |
|---|---|---|
| Tempo de linha de pedido e resposta | Comprimentos do quadro, formato serial e taxa de transmissão | Estabelece a ocupação de transmissão |
| Retorno do dispositivo | Especificação aplicável e respostas medidas | Adiciona tempo antes do início da resposta |
| Temporização entre quadros | Requisitos RTU aplicáveis e comportamento do driver | Previne que os quadros sejam fundidos ou interrompidos |
| Atraso do gateway ou conversor | Teste de caminho final e instruções do equipamento | Adiciona tempo de buffer e tradução |
| Grupos adicionais de registo | Lista de etiquetas aprovadas e mapa | Multiplica transações por leitura |
| Permite tentativa e tempo limite | Teste de dispositivo falhado e política de qualidade do site | Controla a degradação durante falhas |
| Margem de agendamento | Variabilidade observada e requisito da aplicação | Previne que variações normais criem backlog |
A tabela é uma estrutura de planeamento derivada da estrutura do protocolo e da abordagem do sistema medido. Não contém valores garantidos de desempenho do medidor. Recalcule-a sempre que o número de dispositivos, agrupamento de registos, taxa de transmissão ou disposição do gateway mudar.
Agrupe quantidades pelas decisões que suportam. Informação de configuração de mudança lenta geralmente não necessita da mesma frequência de leitura que a exibição de potência atual de um operador. Evite ler repetidamente todo o mapa quando um grupo menor documentado responde à questão imediata. Isso reduz a ocupação desnecessária do barramento enquanto preserva as informações necessárias para a tarefa.
Mantenha a agrupação de registros tecnicamente válida. Medidas que ocupam vários registros devem ser adquiridas de acordo com os requisitos de coerência do fabricante. Lê-los juntos não garante automaticamente uma captura interna simultânea. Se a aplicação depender de quantidades sincronizadas, pergunte como o instrumento expõe e carimba essa captura.
Para várias portas seriais ou repetidores, documente quais caminhos podem operar de forma independente e quais compartilham um gargalo de gateway. O software pode lançar solicitações simultaneamente sem criar mais capacidade em um segmento half-duplex. Coordene os clientes para que a atividade paralela da aplicação não se torne transações sobrepostas em uma linha compartilhada.
Um timeout pode dominar uma varredura. Numa rede hipotética, três dispositivos indisponíveis, cada um recebendo três tentativas com um timeout de um segundo, consomem aproximadamente nove segundos antes do overhead de transação comum. Esse atraso pode fazer medidores saudáveis parecerem desatualizados, mesmo que seus próprios tempos de resposta não tenham mudado. Inclua o comportamento de falha no orçamento de aquisição desde o início.
Defina limites de tentativas, recuos e verificações de recuperação de acordo com os requisitos da aplicação e o comportamento documentado do dispositivo. Evite tentativas infinitas imediatas contra um endereço silencioso. Uma política de falha limitada pode continuar a coletar de medidores saudáveis enquanto marca explicitamente o dispositivo indisponível. O atraso de recuperação aceitável depende do propósito de monitorização e deve ser acordado durante a comissão.
Teste a restauração assim como a falha. Confirme que um medidor recuperado reentra na programação normal sem causar uma explosão de solicitações históricas enfileiradas. Preserve a sua transição de qualidade e verifique qualquer contador cumulativo antes de calcular o consumo durante o período em falta. O guia de rollover e reset do contador fornece as verificações de continuidade relacionadas.
Distingua um carimbo de hora de medição do dispositivo, carimbo de hora do gateway e carimbo de hora de recepção do host sempre que esses campos existirem. Se apenas o tempo de recepção estiver disponível, rotule-o de acordo. Uma resposta bem-sucedida pode conter dados em cache ou inalterados, portanto, o sucesso na comunicação não deve ser apresentado como prova de que uma nova medição independente foi feita nesse instante exato.
Use um relógio apropriado para agendar intervalos decorrido. A documentação do tempo Python descreve um relógio monotônico que não retrocede quando o relógio do sistema é ajustado. Isso suporta um agendamento robusto de tempo decorrido; carimbos de data/hora do calendário permanecem necessários para associar leituras a eventos do mundo real. Outras plataformas precisam de uma escolha de relógio equivalente documentada.
A sincronização de relógios é uma tarefa separada. O guia de sincronização de tempo do medidor explica por que carimbos de hora comparáveis requerem uma base de tempo conhecida. Um ciclo de sondagem corretamente agendado não consegue reparar um relógio do dispositivo que está errado, e um relógio corretamente sincronizado não pode garantir capacidade de comunicação suficiente.
O Lição de amostragem do MIT explica por que observações esparsas podem esconder alterações. Esse princípio geral é útil, mas a sondagem de registo não é automaticamente equivalente a amostrar uma forma de onda bruta. Filtragem interna, janelas de cálculo, cache e integração podem alterar o que o número retornado representa.
Não afirme que sondar duas vezes mais rápido do que uma frequência de evento específica garante a captura desse evento. Estabeleça o que o medidor realmente mede e publica, e se oferece a função de evento requerida. Para investigações transitórias ou harmônicas, escolha instrumentação adequada e um método de medição documentado, em vez de prometer mais do que os registos comuns podem fornecer.

Mantenha a lista final de dispositivos, grupos de pedidos, configurações seriais, distribuição de resposta medida, duração do ciclo, política de tentativas e requisito máximo de idade dos dados. Compare os resultados dos testes com as decisões pretendidas de exibição e relatório. Registre qualquer lacuna entre o requisito e o desempenho demonstrado, incluindo as condições sob as quais essa lacuna ocorre.
Realize um teste de carga normal, um teste de dispositivo indisponível e um teste de restauração através do caminho de comunicação final. Verifique se os valores desatualizados estão visivelmente marcados, se dispositivos saudáveis continuam a atualizar-se e se o historiador não transforma valores conhecidos repetidos em observações aparentemente novas. Essas verificações tornam o intervalo uma configuração do sistema verificada, em vez de um padrão arbitrário.
A palestra sobre amostragem do MIT OpenCourseWare explica as limitações das observações discretas. Use-a para o conceito subjacente, confiando nas especificações reais do medidor e nos testes de comunicação para o intervalo de aquisição.
Não. Avalie o comportamento de atualização do medidor, a contagem de pedidos, a capacidade do barramento, os atrasos de resposta e a frescura requerida. Verifique a configuração final sob condições normais e de dispositivo falhado.
Isso não altera a precisão subjacente da medição do medidor. Leituras mais rápidas podem melhorar a frescura da observação, mas a interpretação de energia acumulada ainda depende das unidades documentadas, da integração e do comportamento do contador.
Não assuma isso. Registos comuns podem representar quantidades médias ou em cache. Investigações de transientes requerem instrumentação adequada com capacidade de eventos e um método de medição documentado.
Marque explicitamente a qualidade e a idade dos seus dados, utilize tentativas limitadas com retrocesso exponencial, e continue a recolher dados de dispositivos saudáveis onde o design do sistema permita. Verifique a recuperação antes de usar os valores restaurados nos relatórios.