Dans la partie précédente de l'article, nous avons examiné l'étape de démarrage de la conception du système. Maintenant, je veux vous dire quel type d'appareil est sorti à la fin.
Partie 1
Partie 2
Lors de la discussion de la première partie, la question de la mesure de la tension et du courant a été soulevée. J'ai donc décidé de le couvrir plus en détail. Comme je l'ai écrit plus tôt, les capteurs de tension et de courant de notre circuit sont des transformateurs. Un transique miniature BV 201 0145 est utilisé pour mesurer la tension, et pour le capteur de courant AC-1020:
Les tensions en sont supprimées, qui sont numérisées par l'ADC intégré au microcontrôleur. La partie analogique est représentée ci-dessous:
Le capteur de courant est chargé à travers la résistance R3. La diode Zener VD3 protège contre les surtensions soudaines causées par de courtes surtensions. Les résistances R2, R4 définissent le "point zéro" autour de 1,8V. La même chose est faite pour le transformateur de tension. Seulement il y a un diviseur sur les résistances R8 et R10, car le transformateur dans notre cas produit une tension nominale de 12 V.
Nous numérisons à une fréquence de 1000 Hz pendant 200 ms. Sur la base des valeurs obtenues, nous calculons le RMS. Nous effectuons un calcul rapide des valeurs au carré directement dans l'interruption. Une fois que 200 échantillons ont été accumulés, le calcul final utilisant des nombres à virgule flottante est effectué dans la boucle principale du programme.
Pourquoi vous devez mesurer RMS et la meilleure façon de le faire est bien décrit ici dans cet article .
J'ai déjà écrit plus d'une fois que lors du développement de nos appareils, nous essayons toujours d'utiliser au maximum les composants électroniques les plus courants, afin, d'une part, de réduire le coût, et d'autre part, de ne pas avoir de problèmes avec leur approvisionnement lors de la production de la série. Dans cette conception, toutes les résistances utilisées ont une tolérance de 5%. Naturellement, en raison d'une telle erreur, les produits après la production présentaient une erreur importante lors de la mesure de la tension et du courant. Cette erreur a été éliminée sur un banc d'étalonnage automatisé. Le "stand", bien sûr, sonne un peu fort, mais il remplit sa fonction comme il se doit. Le stand se compose des éléments suivants:
- Ensemble de trois lampes halogènes 500 W
- Capteur de courant décrit ci-dessus
- Compteur d'électricité Energomera CE102M
- Convertisseur USB-RS-485
- Disjoncteur
Nous utilisons le compteur comme exemple de compteur pour la tension secteur et le courant de charge. Le modèle CE102M est très pratique car, d'une part, il est connecté avec seulement deux fils au convertisseur USB-RS-485 (il y a son propre convertisseur d'alimentation à l'intérieur du compteur), et, d'autre part, il ne nécessite pas la saisie du numéro de série pour lire les données. Cela semble être une bagatelle, mais ils ajoutent de la commodité à l'utilisation du compteur.
Le protocole d'échange est bien décrit dans le manuel du fabricant. Il n'y a donc pas eu de difficultés avec la mise en œuvre du logiciel.
En passant, vous pouvez écrire un petit article séparé sur les compteurs. À un moment donné, j'ai travaillé en étroite collaboration avec eux, par conséquent, certains de nos appareils prennent en charge quatre modèles populaires: Incotex-SK "Mercury 206", Energomer "CE102", Energomer "CE102M" et IEK "STAR 104/1".
La vue générale du stand s'est avérée comme suit:
Pour l'automatisation, un programme simple a été développé qui lit les données du compteur, contrôle les relais intégrés du contrôleur et sélectionne automatiquement les coefficients du compteur de courant et de tension:
nous utilisons généralement des codes-barres pour les numéros de série de nos appareils. Il est très pratique de les saisir à l'aide d'un lecteur de codes-barres:
mais dans ce cas, l'appareil a été commandé et le client a demandé d'exécuter le numéro de série simplement sous la forme de grands chiffres sur le panneau avant.
Le programme d'étalonnage enregistre toutes les données dans notre système interne. Il enregistre qui, quand ce qui a été vérifié et la liste de paramètres correspondante. Les plus importants sont le numéro de série et l'adresse MAC.
Au fait, sur les adresses MAC. Nous les achetons sous la forme de puces 24AA025E48-I / SN de Microchip. Lorsqu'ils sont achetés en gros, ils sont peu coûteux et très faciles à utiliser. L'adresse MAC est lue via l'interface I2C.
Maintenant, pour la connexion avec le serveur. Au début du développement, nous avions déjà la fonctionnalité principale. Il s'agit d'un simple service Web écrit en ASP.net et d'un programme serveur distinct pour communiquer avec le matériel. Chaque contrôleur transmet un paquet de données via le protocole UDP une fois par minute. Le logiciel serveur les analyse, stocke les données dans la base de données (avec "décimation" jusqu'à une fois par heure) et se souvient en outre de l'adresse IP externe et du port d'où provient le paquet. Ceci est nécessaire pour contrôler le contrôleur à partir du serveur.
Puisque, en fait, 100% des appareils sont situés derrière NAT, il est nécessaire de prendre en compte certaines particularités. Le principal est que certains NAT ont un petit délai d'attente pour allouer un port externe au client (moins d'une minute). Le pourcentage de tels, selon nos statistiques, n'est pas très grand, mais cela conduit en tout cas à la nécessité de réduire l'intervalle d'envoi des données de surveillance du contrôleur au serveur pour "maintenir" le port dédié.
J'écrirai tout de suite pourquoi nous utilisons des connexions UDP et non TCP, bien que notre appareil, bien sûr, ait une implémentation des deux protocoles. Le choix d'UDP n'est justifié que par la facilité d'utilisation et les faibles coûts de calcul tant du côté contrôleur que du côté serveur. Oui, cela ne garantit pas la livraison des paquets de données, mais vous devez comprendre que cela est facilement implémenté par un protocole de couche supérieure qui s'exécute sur UDP. De plus, lors de la transmission de données de surveillance, la perte de plusieurs paquets par jour est absolument insignifiante, d'autant plus que lors de la sauvegarde dans la base de données, nous "éclaircissons" et ne sauvegardons les données qu'une fois par heure. Mais lorsque le contrôleur est télécommandé, par exemple, lorsque le relais est activé / désactivé en mode manuel, le système «demande-réponse» fonctionne et plusieurs tentatives d'envoi d'une commande sont effectuées.
De plus, via le serveur, nous avons implémenté une mise à jour à distance du "firmware" des contrôleurs. Cela fonctionne également sur UDP. Certes, la mise à jour fonctionne en mode semi-automatique. Néanmoins, il n'est pas bon de l'exécuter dans la machine à un moment arbitraire, car cela peut entraîner un problème dans le travail des utilisateurs finaux. Imaginez à quel point ils seront surpris si en plein jour le relais Ethernet déconnecte une partie de la charge et redémarre :-)
En conclusion, je voudrais dire qu'au cours des deux dernières années, nous avons produit près d'un millier d'appareils de ce type. Tous sont en ligne. Environ deux mille autres contrôleurs communiquent également en permanence avec notre serveur. En général, tout fonctionne assez régulièrement. Bien que, bien sûr, nous élargissions constamment les fonctionnalités. Par exemple, nous avons récemment publié une foule. application de contrôle à distance de nos appareils via Internet. Mais écrivez sur lui la prochaine fois ...