Bonjour,
Je reviens vers vous pour faire suite à la précédente discussion " Paramétrage de mymodbus pour piloter une carte relais".
Le plugin en version stable et béta fonctionne bien et j’arrive à lire/écrire sur les deux équipements. Merci aux développeurs.
Cela dit, pour information et par souci du détail, (j’ai compris que la béta devait passer en stable sur la fin d’année) la log contient des erreurs qui sont toujours les mêmes elles ne semblent pas avoir d’impact apparent. Vous les trouverez en pièce attachée. mymodbus.txt (9,3 Ko)
Ces erreurs n’apparaissent que si un 3ème équipement, qui fonctionne sous TCP/IP, est actif. Il génère lui même une erreur systématique.
De ce fait, il y a deux équipement avec l’ID 1 mais sur deux réseau différents. Est-ce un pb potentiel ?
Ces logs sont en version stable. La version bêta est une réécriture complète du plugin. Ces erreurs n’apparaissent pas en bêta normalement. Vous pouvez tester et me faire un retour SVP ?
Bonsoir Michel,
Le passage en béta ne semble pas transparent pour les équipements.
J’ai donc installé la version béta sur une machine de préprod et je suis en train de recréer les commandes.
Sur l’équipement en TCP/IP je butte déjà sur deux premières erreur asyncio.exceptions.TimeoutError et Modbus Error: [Connection] Not connected[AsyncModbusTcpClient** (voir la log en pièce attachée) mymodbus.txt (798 Octets)
Une idée de la cause de ces erreurs ?
Je reviens de toutes les façons vers vous une fois que j’aurai avancé sur les tests.
Bonne soirée
Quelques lignes (2 bonnes dizaines) de log avant seraient les bienvenues pour me faire une meilleure idée, idéalement les lignes du démarrage du démon aussi. De même qu’une capture de la config de l’équipement et des commandes.
Là, comme ça, je ne sais pas comment quoi que ce soit est configuré (et ma boule de cristal est en panne ).
Bonjour Michel,
Désolé j’ai voulu faire rapide mais c’était un peu trop « court », j’en conviens.
Ci-joint la log demandée (j’ai modifié la clé API): mymodbus.txt (90,6 Ko)
J’ai aussi trouvé des warnings dans la log mymodbus_packages: mymodbus_packages.txt (8,0 Ko)
Ainsi que les copies d’écran de l’interface Ethernet-Modbus, de l’équipement tcp et ses commandes:
J’ai l’impression que ça vient de la passerelle. Avec Modbus Doctor, tu arrives à faire ces lectures ? Si ce n’est pas le cas, il faut commencer par faire en sorte que la passerelle soit bien configurée.
L’utilisation du port 26 est bizarre, le port standard est 502.
Bonsoir Michel,
J’ai pu avancer sur différents aspects:
côté équipements RTU, cela fonctionne j’ai réussi à faire la transcription des commandes
côté équipement TCP/IP, j’ai trouvé l’origine de mon pb. L’équipement était électriquement éteint lorsque j’ai fait les tests. C’est ballot
Par contre, je rencontre des différences significatives au niveau des valeurs des commandes.
Dans le WE, je vais conduire, en suivant ta recommandation, des tests avec Modbus Doctor et je reviendrai vers toi
Bonne soirée
Bonjour Michel,
Ci-après les résultats de mes tests dominicaux:
La bonne nouvelle est que j’ai réussi à retranscrire les équipements et leurs commandes en version béta et que tout fonctionne.
A signaler quelques sauvegardes d’équipement qui bloquent sur une erreur 500 puis qui passent après un deuxième clic ???
Pour mémoire le réseau Modbus comporte à ce jour 3 équipements (2 en RTU: carte entrées et carte relais; 1 en TCP/IP: VMC).
Dans ma configuration, le démon refuse de démarrer si tous les équipements sont actifs. Donc je le démarre avec seulement la carte entrées puis j’active les deux autres équipements. Je peux reproduire cette anomalie sans problème. Je n’ai pas encore compris l’origine du problème.
De plus, le log contient beaucoup de message d’erreur qui ne semblent pas bloquants ?? J’ai fait de multiples tests de modification des paramètres sans pour autant arriver à supprimer ces erreurs
Ci-joint les configurations des équipements et le log du plugin
Il serait intéressant pour moi d’avoir le log en debug du plugin qui contient ce moment-là ET le log http.error pour comprendre ce qu’il se passe et le corriger.
De la même manière, le log du plugin et debug au moment du lancement du démon sans succès serait utile.
En mode série (RTU ou non) le fait de garder la connexion ouverte alors que le polling est long (> 5 secondes) peut causer des problèmes.
Par ailleurs, sur la carte de sortie, si l’option « inverser les octets » est cochée, il est possible de remplacer 256 par 1 et 512 par 2.
Est-ce que vous pourriez détailler les configurations des 3 équipements histoire que j’ai un aperçu complet SVP.
Bonsoir Michel,
J’ai appliqué vos recommandations sur l’inversion d’octets et le fait de ne pas garder la connexion ouverte. J’ai beaucoup moins de messages effectivement. Voir la log ci-après: mymodbus.txt (35,5 Ko)
Vous trouverez ci-après les logs de démarrage avec 1 ou 2 équipements. Avec 2 le démon ne redémarre pas. mymodbus-démarrage-1-equipements.txt (35,6 Ko) mymodbus-démarrage-2-equipements.txt (34,4 Ko)
J’ai reproduit l’erreur 500 en créant « from scratch » un nouvel équipement. Le log ci-après. http.error.txt (614 Octets)
Enfin les configurations des 3 équipements:
Que ce soit avec un ou 2 équipements série, l’exception de pymodbus ne me plait pas.
[2023-11-05 20:47:27][INFO] : Serial lost connection.
[2023-11-05 20:47:27][DEBUG] : Client disconnected from modbus server: None
[2023-11-05 20:47:27][ERROR] : Exception in callback SerialTransport._call_connection_lost(None)
handle: <Handle SerialTransport._call_connection_lost(None)>
Traceback (most recent call last):
File "/var/www/html/plugins/mymodbus/ressources/_pyenv/versions/3.9.16/lib/python3.9/asyncio/events.py", line 80, in _run
self._context.run(self._callback, *self._args)
File "/var/www/html/plugins/mymodbus/ressources/_pyenv/versions/3.9.16/lib/python3.9/site-packages/pymodbus/client/serial_asyncio/__init__.py", line 427, in _call_connection_lost
self._serial.flush()
AttributeError: 'NoneType' object has no attribute 'flush'
Je ne suis pas sûr de la source de cette exception.
Merci, il va y avoir un correctif.
C’est ce dont je me doutais, c’est la même interface série utilisée par MyModbus. Le démon démarre donc les lectures sur les 2 exclaves Modbus en même temps et ça ne fonctionne de toute évidence pas. Comme les log ne montre pas le moment du démarrage du démon, je ne sais pas.
Pourriez-vous désactiver le plugin MyModbus puis l’activer et garder les messages log du démarrage SVP ?
Un bon essai serait de modifier le paramètre « Temps entre la connexion et la première requête » sur un équipement série et le passer à 10 secondes pour induire un décalage entre le polling des l’équipements.
Suite à la mise à jour de cette beta 24 je n’arrive plus à redémarrer mon demon. Je ne sais pas si c’est spécifique à ma config où plus général, mais un conseil, attendez d’avoir une confirmation de Michel avant d’appliquer cette mise jour.
Bonjour, j’ai appliqué cette mise à jour sur une install. (Modbus RTU) Après la mise à jour du plugin. J’ai voulu relancer le daemon … KO.J’ai relancé l’installation des dépendances puis tenter de redémarrer le daemon KO. Je n’avais pas le temps d’approfondir le disfonctionnement. (Désolé)
J’ai donc fait « machine arrière » en restaurant un backup. qui a redémarré sans problème avec une version V2.0 beta 20.
Je conseille de temporiser l’installation de cette dernière version. @Michel_F saura certainement nous orienter au mieux.
Merci !
Le correctif vient d’être trouvé et est sur github. La mise à jour auto du market de ce soir va corriger le problème à moins que Bebel27 ne pousse manuellement plus tôt. Je vais lui envoyer une demande dans ce sens.
Solution : plugin / mymodbus / core / class / mymodbus.class.php ligne 528 à 537 à remplacer par ces lignes (une ligne est supprimée)
Ancien code :
Bonjour Michel,
Je viens de mettre en préproduction la dernière version. J’ai pu vérifié qu’elle intégrait bien le correctif ci-dessus. J’ai relancé l’installation des dépendances pour faire bonne mesure
Je n’ai pas modifié les paramétrages des équipements indiqués lors des tests précédents.
Les constats:
le démon démarre maintenant sans problème quelque soit le nombre d’équipement sur le réseau RTU.
Par contre, je ne peux plus piloter la carte relais (à noter: la carte entrées fonctionne toujours).
J’ai fait le test suivant: j’ai désactivé tous les équipements hormis la carte relais et j’obtiens le log ci-après lorsque j’essaie d’activer un relais. Curieusement des messages d’erreur concernant la carte d’entrées apparaissent aussi dans ce log alors que l’équipement n’est pas actif. mymodbus-2.txt (9,4 Ko)
Globalement, il y a toujours beaucoup de message d’erreur dans le log en debug, notamment sur PyModbusClient (voir ci-après). mymodbus.txt (33,8 Ko)
J’ai aussi des erreurs dans le log des packages, suite à l’installation. mymodbus_packages.txt (1,6 Ko)
Je ne sais pas comment pymodbus réagit avec des tentatives d’ouverture de connexion sur différents esclaves modbus mais avec la même interface série et en plus en même temps. Je n’ai pas la possibilité de tester ça chez moi et je ne sais donc pas si 2 équipements MyModbus distincts utilisant la même interface série fonctionnent.
Vous est-il possible de tester avec un seul équipement qui regroupe les commandes des équipements actuels ?
C’est parce que j’ai supprimé le test qui empêchait le démon de démarrer si 2 équipements utilisent la même interface série. Mais en réalité, je ne sais pas si ça peut fonctionner…
Oui, ça n’a pas l’air de fonctionner franchement bien chez vous…
Vraiment très étrange ces messages :
pyenv: no such command `init'
pyenv: no such command `local'
pyenv: no such command `exec'
pyenv: no such command `exec'
pyenv: no such command `exec'
Pour réinstaller pyenv, il faut :
désactiver le plugin
supprimer le répertoire plugins/mymodbus/ressources/_pyenv
réactiver le plugin ce qui devrait réinstaller les dépendances (ça prend du temps) sinon, les réinstaller "manuellement’’
Par ailleurs, je vais me repencher sur le plugin, notamment les paquets à installer et ferai sans doute une autre mise à jour prochainement
Bonjour Michel,
Je viens de faire le test avec un équipement unique comprenant un échantillon de commandes de mes équipements physiques. Cela fonctionne sans problème et je n’ai plus de message d’erreur.
A noter: un équipement désactivé continue de générer des erreurs
Si vous avez besoin d’infos, de log n’hésitez pas.
Cela tendrait à prouver qu’effectivement avec le plugin actuel une même interface série ne peut piloter plusieurs équipements. Je comprends mieux pourquoi ID de l’esclave est maintenant au niveau de la commande alors qu’il était précédemment au niveau de l’équipement.
Cela dit, dans mon cas (qui n’est probablement pas celui de tout le monde) j’ai actuellement 3 esclaves sur mon réseau et je vais bientôt passer à 6. Si je mets toutes les commandes dans un même équipement j’aurai de l’ordre de 200 commandes, ce qui n’est pas très pratique en terme de maintenance et qui limite rapidement l’usage de MyModbus sur un réseau unique, alors que c’est un protocole industriel très fiable.
De plus, les paramètres de connexion (vitesse, parité, etc.) ne sont pas toujours les mêmes et dépendent des esclaves avec parfois l’impossibilité de les modifier.
Certes, il est aussi possible de multiplier les réseaux physiques avec des convertisseurs différents, mais je n’ai pas fait de test en ce sens.
Enfin, concernant pyenv, je l’ai réinstaller à la main, sans difficulté.
En conclusion, s’il existait une solution pour piloter plusieurs équipements sur une même interface série, ça serait vraiment super.
Si vous analysez la faisabilité de cette solution, faites m’en part car cela orientera mes choix à l’étape de mise en œuvre suivante.
Encore merci pour votre aide et vos précieux conseils
K’sin
).
