Choisissez un intervalle de sondage pour un compteur d'énergie en équilibrant la fréquence de mise à jour utile de la mesure, la capacité du bus série, le temps de réponse de l'appareil et la fraîcheur requise par l'application. Sondage plus rapide que la mise à jour d'un compteur peut renvoyer des valeurs répétées tout en consommant la capacité de communication. Sondage trop lent peut manquer des changements utiles ou laisser un tableau de bord obsolète. Calculez un budget de transactions, testez le réseau réel dans des conditions normales et avec un appareil défaillant, et définissez comment les horodatages et la qualité des données sont stockés. Il n'existe pas de réglage universel d'une seconde qui convienne à tous les instruments, passerelles et tâches de surveillance.
Ce guide se concentre sur la planification de l'acquisition après qu'une connexion documentée fonctionne. Commencez par le guide de configuration Modbus du compteur électrique pour la vérification de l'interface et de la carte des registres. Des exemples numériques ci-dessous décrivent un réseau hypothétique, et non la vitesse de réponse ou les réglages supportés par tout modèle BY194.
Demandez quelle action les données collectées doivent soutenir. La génération de rapports de consommation de routine, les affichages pour opérateurs, la revue de la demande et l'investigation de perturbations ont des besoins de synchronisation différents. Une tendance destinée à montrer un schéma de fonctionnement horaire ne nécessite pas le même arrangement d'acquisition qu'une investigation d'un transitoire court. Définissez un âge maximal acceptable des données pour chaque utilisation avant de choisir un intervalle de communication.
Séparez la fraîcheur du stockage historique. Un affichage pour opérateur peut se rafraîchir fréquemment tandis que l'historien stocke un résumé documenté à un intervalle plus long. Inversement, un historien peut recevoir des enregistrements fréquents qui ne sont que des duplicatas d'une mise à jour interne plus lente du compteur. Enregistrez où chaque mise à jour, transfert et agrégation se produit afin que la résolution apparente du système ne soit pas confondue avec de nouvelles informations de mesure.
Vérifiez si l'application nécessite un enregistreur approprié plutôt que des registres sondés ordinaires. Le Guide du registraire de qualité d'alimentation explique le rôle des instruments capables d'événements. Une boucle logicielle rapide ne transforme pas un compteur de panneau en un enregistreur d'ondes ou ne prouve pas la conformité à une norme de mesure de la qualité de l'énergie.
Demandez la carte des registres exacte, les tailles de lecture supportées, le comportement documenté de mise à jour des mesures et toute restriction de communication pour la configuration fournie. Le série CNBYG BY194 fournit un point de départ pertinent pour le produit. Son apparence en façade ne définit pas un intervalle de sondage minimum, une fonction de capture instantanée ou une mémoire historique.
Distinguez l'échantillonnage interne, les mises à jour de la fenêtre de calcul, le rafraîchissement de l'affichage, la disponibilité des registres et le sondage externe. Ces étapes peuvent fonctionner sur des horloges différentes. Un compteur peut calculer une mesure en interne avant qu'un registre de communication ne l'expose, et une passerelle peut ajouter un autre cache. Demandez quel horodatage, le cas échéant, identifie la mesure plutôt que le moment où le logiciel l'a reçue.
Lorsque la synchronisation publiée est incomplète, conservez l'incertitude et effectuez une observation en lecture seule approuvée. Mesurez les temps de réponse et le comportement en cas de valeurs répétées sans prétendre que la réponse la plus rapide observée est un minimum garanti. Incluez une charge représentative et le chemin final de la passerelle, car une connexion en banc d'essai peut se comporter différemment de l'installation en production.
Pour le RTU série, commencez par les caractères envoyés et reçus. Le protocole d'application Modbus définit les structures de requête et de réponse pertinentes, tandis que le guide de ligne série Modbus définit l'encadrement et la synchronisation. Utilisez les deux en complément des instructions de l'appareil ; le calcul des messages seul ne constitue pas une spécification de performance complète.
Pour une lecture hypothétique de la fonction-03 de dix registres, une requête RTU occupe huit octets et une réponse normale occupe vingt-cinq octets, y compris l'adresse de la trame série et le CRC. En supposant onze bits transmis par caractère et 9 600 bits par seconde, le temps combiné sur le fil est de 33 × 11 / 9 600 secondes, soit environ 37,8 millisecondes.
Ceci est une composante inférieure du budget de transaction. Ajoutez le temps de rotation réel de l'appareil, le silence inter-trame requis, les délais du convertisseur ou de la passerelle et la surcharge de planification. Le guide série décrit les écarts RTU basés sur les caractères à des débits plus faibles et un timing recommandé fixe au-dessus de 19 200 bits par seconde. Ne pas appliquer un calcul basé sur le temps d'un caractère dans chaque configuration série sans vérifier son applicabilité.

Estimer le temps de service pour chaque groupe de requêtes planifiées, pas seulement pour chaque compteur. Un seul instrument peut nécessiter plusieurs lectures de registres non contigus. Inversement, des registres contigus compatibles peuvent parfois être regroupés dans des limites documentées. La carte et le comportement de l'appareil déterminent si le regroupement est approprié ; ne jamais traverser des régions non supportées simplement pour réduire le nombre de requêtes.
Utiliser Tcycle ≥ somme des temps de service de transaction plus la marge planifiée comme vérification de capacité pour un segment série séquentiel. Lors d'un test illustratif, douze transactions moyennant quatre-vingts millisecondes nécessitent environ 0,96 seconde avant marge supplémentaire ou nouvelles tentatives. Un cycle d'une seconde laisserait donc très peu de marge pour la variabilité normale. La valeur de quatre-vingts millisecondes est un exemple d'entrée qui doit être remplacé par des données observées et spécifiées du projet.
| Élément de budget | Comment l'établir | Pourquoi c'est important |
|---|---|---|
| Temps de fil de la requête et de la réponse | Longueurs de trame, format série et débit en bauds | Établit l'occupation de la transmission |
| Rotation de l'appareil | Spécification applicable et réponses mesurées | Ajoute le temps avant le début de la réponse |
| Timing inter-trame | Exigences RTU applicables et comportement du pilote | Empêche la fusion ou l'interruption des trames |
| Délai de la passerelle ou du convertisseur | Test de chemin final et instructions pour l'équipement | Ajoute un délai de mise en mémoire tampon et de traduction |
| Groupes d'enregistrement supplémentaires | Liste et carte des balises approuvées | Multiplie les transactions par scan |
| Autorisation de nouvelle tentative et de délai d'attente | Test de périphérique échoué et politique de qualité du site | Contrôle la dégradation lors des défauts |
| Marge de planification | Variabilité observée et exigence de l'application | Empêche la variation normale de créer un retard |
Le tableau est un cadre de planification dérivé de la structure du protocole et de l'approche du système mesuré. Il ne contient pas de chiffres garantis de performance du compteur. Recalculez-le chaque fois que le nombre de dispositifs, le regroupement des registres, la vitesse de transmission ou l'agencement de la passerelle changent.
Group quantities by the decisions they support. Slowly changing configuration information usually does not need the same read frequency as an operator’s current power display. Avoid repeatedly reading the whole map when a smaller documented group answers the immediate question. This reduces unnecessary bus occupancy while preserving the information needed for the task.
Keep the register grouping technically valid. Measurements occupying several registers should be acquired according to the manufacturer’s coherence requirements. Reading them together does not automatically guarantee a simultaneous internal snapshot. If the application depends on synchronized quantities, ask how the instrument exposes and timestamps that snapshot.
For several serial ports or repeaters, document which paths can operate independently and which share a gateway bottleneck. Software can launch requests concurrently without creating more capacity on a half-duplex segment. Coordinate clients so that parallel application activity does not become overlapping transactions on a shared line.
A timeout can dominate a scan. In a hypothetical network, three unavailable devices each receiving three attempts with a one-second timeout consume roughly nine seconds before ordinary transaction overhead. That delay can make healthy meters appear stale even though their own response times are unchanged. Include fault behavior in the acquisition budget from the beginning.
Set retry limits, backoff and recovery checks according to application requirements and documented device behavior. Avoid immediate endless retries against a silent address. A bounded failure policy can continue collecting from healthy meters while marking the unavailable device explicitly. The acceptable recovery delay depends on the monitoring purpose and should be agreed during commissioning.
Test restoration as well as failure. Confirm that a recovered meter rejoins normal scheduling without causing a burst of queued historical requests. Preserve its quality transition and check any cumulative counter before calculating consumption across the missing period. The counter rollover and reset guide provides the related continuity checks.
Distinguish a device measurement timestamp, gateway timestamp and host receipt timestamp wherever those fields exist. If only receipt time is available, label it accordingly. A successful reply can contain cached or unchanged data, so communication success should not be presented as proof that a new independent measurement was made at that exact instant.
Use an appropriate clock for scheduling elapsed intervals. The Python time documentation describes a monotonic clock that does not go backwards when the system clock is adjusted. This supports robust elapsed-time scheduling; calendar timestamps remain necessary for associating readings with real-world events. Other platforms need an equivalent documented clock choice.
Clock synchronization is a separate task. The meter time-synchronization guide explains why comparable timestamps require a known time basis. A correctly scheduled polling loop cannot repair a device clock that is wrong, and a correctly synchronized clock cannot guarantee sufficient communication capacity.
La MIT sampling lesson explains why sparse observations can hide changes. That general principle is useful, but register polling is not automatically equivalent to sampling a raw waveform. Internal filtering, calculation windows, caching and integration can all change what the returned number represents.
Do not claim that polling twice as fast as a particular event frequency guarantees capture of that event. Establish what the meter actually measures and publishes, and whether it offers the required event function. For transient or harmonic investigations, choose suitable instrumentation and a documented measurement method instead of promising more than ordinary registers can provide.

Retain the final device list, request groups, serial settings, measured response distribution, cycle duration, retry policy and maximum data-age requirement. Compare the test results with the intended display and reporting decisions. Record any gap between the requirement and demonstrated performance, including the conditions under which that gap occurs.
Run a normal-load test, an unavailable-device test and a restoration test through the final communication path. Check that stale values are visibly marked, that healthy devices continue updating and that the historian does not turn repeated last-known values into apparently fresh observations. These checks make the interval a verified system setting rather than an arbitrary default.
MIT OpenCourseWare’s sampling lecture explains the limitations of discrete observations. Use it for the underlying concept, while relying on the actual meter specifications and communication tests for the acquisition interval.
No. Evaluate the meter update behavior, request count, bus capacity, response delays and required freshness. Verify the final setting under both normal and failed-device conditions.
Cela ne modifie pas la précision fondamentale de la mesure du compteur. Des lectures plus rapides peuvent améliorer la fraîcheur des observations, mais l'interprétation de l'énergie cumulative dépend toujours des unités documentées, de l'intégration et du comportement du compteur.
Ne supposez pas cela. Les registres ordinaires peuvent représenter des quantités moyennées ou mises en cache. Les investigations transitoires nécessitent une instrumentation adaptée aux événements et une méthode de mesure documentée.
Indiquez explicitement la qualité et l'âge de ses données, utilisez des tentatives limitées avec un délai d'attente progressif, et continuez à collecter à partir d'appareils sains lorsque la conception du système le permet. Vérifiez la récupération avant d'utiliser les valeurs restaurées dans les rapports.