[S7-1500] vitesse trame modbus

[roudy]

Bonjour,
Je suit en train de mettre en place une communication MODBUS avec plusieurs interlocuteurs.
Pour cela je vais séquencer mes demandes, une par une.
J'ai déjà fait cela, il y a quelques temps, en effectuant une demande toutes les 200ms (avec des MB_CLIENT)
Quelqu'un a-t'il un retour d'expérience pour savoir à combien je peut descendre en vitesse ? sans défaillance.
Sachant que ma longueur de lecture ou écriture est de 50 mots environ.
Merci d'avance

[dpo]

ben.....ça dépend des interlocuteurs
j'ai eu des soucis parfois avec du matériel où il fallait un temps considérable entre deux requêtes
ensuite ça dépend de l'importance du rafraichissement, as-tu besoin des infos très rapidement ou non.
Quand j'ai une équipement il m'arrive de faire lecture sur front montant du bit à 1hz et écriture sur front descendant.
Normalement il vaudrait mieux prendre en compte le compte rendu d'une trame avant d'en lancer une autre

[roudy]

Dans un précédent projet j'avais 12 interlocuteurs de 3 types, je faisais des RW cycliquement, beaucoup d'informations, mais peu d'informations à risque pour le process. J'avais calé à 200 ms et, ça passait pour tout le monde.
Ici, j'ai des données sensibles pour le process, en gros en face (société tiers) ils ont des capteurs et moi, j'ai la pompe.
En vrai, il faudrait un seul capteur bien placé ...!
C'est quoi un temps considérable pour toi ?

[MiGaNuTs]

Bonjour,

ça dépends de beaucoup trop de choses pour avoir une réponse 'fixe'.

Déjà c'est du Modbus TCP ou RTU ?

En RTU il n'y a que les trames modbus qui se partagent la bande passante du bus, du coup tu peut réduire le délai inter trame au "minimum avant que ça plante" puis rajouter quelques ms de sécurité sans que ça mette la grouille avec les autres communications.

En Ethernet si tu utilise uniquement les bits de compte rendu et que tu spam le réseau de requêtes, c'est pas impossible qu'a un moment tu plante le reste des échanges qui ont lieu sur ton réseau.

Dans les deux modes (TCP et RTU donc) il y'a des esclaves/serveurs qui n'aiment pas trop qu'on leur envoie une nouvelle requête dès qu'ils ont répondu a la précédente, et il y'en a auxquels ça ne pose aucun problème.

Et enfin, comme dit @dpo, parfois tu a besoin d'une fréquence de rafraichissement rapide et d'autres fois c'est moins critique.

Le seul conseil commun a tous les cas de figures c'est d'utiliser les bits de compte rendu de com' et de mettre un délai entre tes trames, genre 100ms au début, et selon comment ça se comporte et si tu en a besoin tu réduit (ou tu augmente si tes esclaves sont peu performants, mais ton rafraichissement va être dégueulasse). Si tu est en Ethernet je te déconseille de descendre en dessous de 20 ms, alors qu'en RTU si tu a beaucoup d'esclaves tu peut mettre seulement 5. Mais ce sont des valeurs arbitraires et subjectives, ça peut marcher différemment pour ton projet.

[roudy]

Merci de ce retour.
Je sais que je n'aurais pas de réponse fixe.
C'est du TCP, je dédie un FB MB_CLIENT à chaque échanges donc théoriquement je ne planque que celui que j'utilise.
Et comme, je les enchaine intelligemment R1, R2, R3, R4, R5, W1, W2, W3, W4, W5 (R:pour Read, W:pour Write, le chiffre étant mon destinataire)
Il me faut 10 x 200ms =2 sec pour faire le tour, et je n'interroge (en RW) un même interlocuteur que toutes les demi-périodes.
Après j'ai jamais poussé pour surcharger la communication, ni planter un interlocuteur.
Et j'ai aussi peut être eu de la chance avec mes interlocuteurs qui étaient pas trop sensible.

[dpo]

Ici, j'ai des données sensibles pour le process, en gros en face (société tiers) ils ont des capteurs et moi, j'ai la pompe.
En vrai, il faudrait un seul capteur bien placé ...!
C'est quoi un temps considérable pour toi ?

Si sensible pense alors à gérer correctement le defaut com : que doit-il se passer si l'automate qui a le capteur ne répond plus !

sur un équipement de pesage, je ne pouvais pas enchainer rapidement lecture et écriture
En cas de besoin d'écriture (demande de RAZ d'un compteur interne à l'équipement, je devais
arrêter la lecture
attendre
envoyer l'écriture
attendre
relancer la lecture

avec 1 secondes à chaque attente et cadence à 1 sec pour les lectures

[Sbukx]

Salut,
Sur une installation qui échangeait en Mdb/TCPIP, avec plusieurs appareils de pesage je lançais plusieurs requêtes de lecture simultanées et ensuite d'écriture cadencées à 200ms et ça fonctionne très bien.L'automate gère très bien le flux des requêtes pour cette installation. Mais je pense que ça dépend aussi des équipements que tu as en face.

[dpo]

Mais je pense que ça dépend aussi des équipements que tu as en face.

En effet il n'y a qu'une référence d'un équipement qui m'a posé ce genre de problème