Discussion :

[123456789az]

Bonjour,


Mon besoin est le suivant : Communiquer via une com modbus TCP avec de nombreux équipements (20 mots à lire sur une trentaine d'équipements).
J'aimerais donc optimiser la com & le tri des données lues au plus possible, pour éviter d'utiliser de nombreux blocs de com
Voici mon bloc READ_VAR :




Je dois lire de ADDM('Ethernet{192.168.110.70}1') à ADDM('Ethernet{192.168.110.70}30') (1-->30 étant les numéros de l'équipement). J'ai essayé de placer une variable interne à la place de ce chiffre pour lui faire varier sa valeur, mais j'ai une erreur de compilation.


Auriez-vous une petite idée ?



Merci

[Bruce33]

Bonjour,

Vous souhaitez donner l'adresse avec une formule du style : ADDM(CONCAT_STR('Ethernet{192.168.110.70}',INT_TO_STRING(CPT)))
...sauf que cela ne marche pas à cause du formatage particulier résultant de la conversion INT_TO_STRING.
Une première solution serait de créer votre DFB pour remplacer la fonction INT_TO_STRING... Mais ce sera peut-être un peu long à développer et moins pratique.


Comme l'entrée ADR du bloc READ_VAR change de valeur, il est préférable de passer par une variable.
La fonction ADDM renvoie une adresse au format ADDM_TYPE, équivalent à ARRAY [0..7] OF INT.
Dans l'aide en ligne, on trouve la description de ces données :

On pourrait donc modifier l'octet correspondant à UnitID, c'est-à-dire l'adresse 1 à 30 dans votre cas.
Si vous choisissez cette voie, commentez bien votre programme !


Je vous suggère plutôt de créer des tableaux de données.


Cela demande un peu de préparatifs, mais c'est plus souple.
Créez des tableaux de 30 données (correspondant aux 30 esclaves) mais cela pourrait être davantage si vous prévoyez de la réserve.
Il faudra alors initialiser les adresses :
Com_Adresse[1] := ADDM('Ethernet{192.168.110.70}1');
Com_Adresse[2] := ADDM('Ethernet{192.168.110.70}2');
etc.
Je crée également des paramètres de gestion du READ_VAR pour chaque esclave. Ce n'est pas obligatoire, mais cela permet notamment de distinguer les comptes-rendus, facilitant le diagnostic en cas de problème de communication avec un esclave.
(N'oubliez pas de renseigner une valeur de timeout dans les paramètres de gestion.)


A vous de trouver l'écriture qui vous convient le mieux.
Mais pensez toujours à rendre votre programme lisible et compréhensible par tout le monde. Et facile à diagnostiquer en cas de problème.

(Précision : je n'ai pas testé sur automate tout ce qui est écrit, des erreurs sont possibles !)

[123456789az]

Bonjour,


Merci pour votre réponse. J'ai pu mettre en place la com avec l'ensemble des équipements. Ça a bien fonctionné pendant quelques semaines....Mais j'ai de nouveau un problème.
La com sur tous les équipements est OK, c'est scruté toutes les 30 secondes.



Cependant, sur la même liaison Ethernet, je communiquais avec 2 appareils de mesure supplémentaires (Socomec Diris A40).
La com avec ces 2 appareils est maintenant figée, impossible de retrouver une valeur (Même en redémarrant le Diris A40, en changeant de bloc READ_VAR). J'ai l'impression que seul le redémarrage de la carte de COM pourra arranger ça



Y'a t'il une limite à ne pas dépasser en terme d'équipement ? 2 blocs Read_var, sur 2 équipements différents, qui s’exécutent en même temps, peuvent-ils rentrer en conflit et mettre le bordel dans les échanges ?

[Bruce33]

J'ai déjà rencontré des problèmes avec des modules Diris qui remontaient beaucoup d'informations : perte de communication nécessitant un redémarrage du Diris.
Avez-vous essayé d'interroger les Diris A40 concernés avec autre chose que l'automate ? (Par exemple avec Modbus Doctor ou le simulateur Vijeo Designer...)

Il arrive aussi que la communication plante dans l'automate M340 au point de nécessiter son redémarrage.
Cela se produit notamment en cas de mauvaise gestion de la communication.
Assurez-vous que toutes les requêtes sont configurées avec un timeout (pas trop long, ce n'est pas la peine d'attendre 2 min en Ethernet).
Attention aussi si vous écrivez dans les paramètres de gestion du READ_VAR ou du WRITE_VAR (sauf pour le timeout bien sûr). Et n'utilisez pas les mêmes variables de paramètres de gestion pour des instructions READ_VAR ou WRITE_VAR traitées simultanément.

Il y a effectivement des limites aux performances du M340. La documentation n'est pas toujours très claire. A priori : 8 ou 16 transactions maximum traitées par cycle automate. Et, pour chaque port Ethernet, 500 transactions par seconde et 32 connexions de type serveur Modbus/TCP simultanément au maximum. (C'est 64 équipements maximum en IO Scanning.)
En cas de dépassement de 32 équipements, l'automate ferme la connexion qui est au repos depuis le plus longtemps. Le fait d'ouvrir/fermer régulièrement des connexions peut dégrader les performances.

Quel type de port Ethernet utilisez-vous : celui du processeur ou celui d'un module BMXNOE ?
Regardez l'écran de diagnostic du port Ethernet lorsque vous êtes connecté à l'automate : on peut y voir le nombre de connexions ouvertes, des compteurs de réception et d'émission, la répartition de la bande passante, etc.
Quel est le code d'erreur renvoyé par le READ_VAR qui interroge le Diris A40 récalcitrant ?