En ce qui concerne le bus EBX, il va mieux depuis que je n’utile que le bus V5. Je n’ai plus d’erreur sur mes X-8R.
Il subsiste un doute sur la prolongation de mon bus coté fil qui s’étend à plus de 15 m. Dans l’immédiat, je l’ai supprimé, les X-THL connectés ne me sont pas d’une utilité primordiale dans mon automatisme.
surtout pas
un objet clignotant par objet modbus implique des chevauchements et pertes de trames car à un moment donné il y aura au moins 2 clignotants qui vont s’activer en même temps.
En ce qui concerne les objets Modbus, il faut distinguer les Read et les Write. Les Write : c’est généralement à la demande (dashboard, scénario, …), donc pas d’objet temps pour lappel. Cependant, si une action nécessite l’écriture de plusieurs registres. Dans ce cas, il faut jouer avec un délai entre chaque écriture.
Dans mon post concernant le moteur Nema, je montre comment je crée un délai entre chaque écriture et j’ordonne les trames avec un compteur.
Les Read : Si de nombreux objets modbus Read sont à gérer, alors il vaut mieux privilégier le moteur de scénario.
Incrémenter par lien un compteur au clignotant, puis à chaque changement de valeur lire la valeur modbus
Sinon, si seulement 2 objets, alors lier les 2 objets modbus à un clignotant suffit avec un objet sur front montant, l’autre sur front descendant et une durée de 300 ms minimum.
Sur ma config pour moteur Neam, je n’ai que 2 clignotants.
1 pour 2 lectures de registres en Read-Only, avec une cadence moyenne (Ta=300ms, TB=300ms)
1 qui incrémente un compteur qui est pris en compte par le moteur de scenario pour la lecture de plusieurs registres dans le cadre de l’init d’un liveview
Les objets Write sont gérés uniquement par le moteur de scénario avec des délais.
C’est plus long à mettre en place, mais c’est fiable.
