- Ce sujet a 14 réponses, 1 participant et a été mis à jour pour la dernière fois 2 années, 4 mois da
.
-
Post
-
J'aurais besoin de communiquer avec l'onduleur 4 schneider ATV12 pour lui donner une commande de base, la direction de départ, la référence de vitesse et prendre d'autres données de base, absorption, fréquence, alarmes.
La communication de l’ATV12 est modbus en RS485, j’en utilise un SlimLine CPU compact ethernet, qui a un port TCP / IP et un port RS232, j'ai jeté un coup d'œil sur le forum et je ne sais pas si j'ai bien compris, mais il pourrait y avoir la possibilité d'avoir un convertisseur TCP / IP -> Modbus RS485 directement à SlimLine en utilisant divers FB? Ai-je bien compris ou suis-je complètement hors piste?
De toute autre manière, je pourrais toujours utiliser le port RS232 de la CPU mais à ce stade, je devrais mettre un convertisseur non?
Pour information, j’utilise déjà la connexion TCP / IP du SlimLine pour communiquer avec un panneau IHM weintek et un routeur.
Le système SlimLine peut faire les deux en tant que convertisseur TCP / série (Sujet) en tant que convertisseur Modbus TCP / Modbus RTU (Sujet) mais ces deux fonctionnalités ne sont pas nécessaires dans votre cas. Pour autant que je sache, vous souhaitez gérer l'onduleur à partir d'un programme API.
Pour cela, il suffit d'instancier un FB. ModbusMaster et gérer les commandes aux inverseurs (vous pouvez vous référer à cette sujet). Bien entendu, il était préférable d’utiliser un module de processeur MPS054A1 * 0 doté déjà du port série RS485 isolé, mais si vous disposez du modèle compact dans la gamme des convertisseurs Série / série vous pouvez trouver le convertisseur qui vous convient.
En ce qui concerne la connexion TCP, vous pouvez l'utiliser pour vous connecter avec tout ce que vous voulez, les seules limites sont données par la quantité de sockets que le système peut gérer (actuellement 32) et par l'utilisation de la mémoire relocalisable RMalloc. Chaque socket utilise la quantité de mémoire définie lors de sa création.
Merci pour les éclaircissements, il me reste une question: pour pouvoir gérer tous les onduleurs 4, aurais-je besoin de convertisseurs série / série 4? Ou est-ce suffisant?
Au cas où il y en aurait assez, comment devraient-ils être connectés?
La caractéristique principale du protocole Modbus est précisément de pouvoir fonctionner en multipoint, c’est-à-dire d’avoir un système maître qui dialogue sur une connexion à deux fils avec un ou plusieurs systèmes esclaves, chaque système esclave aura sa propre adresse (noeud Modbus défini).
Donc, dans votre cas, vous devrez définir une adresse différente (nœud Modbus) pour chaque onduleur, puis vous pourrez parler à tout le monde avec une seule ligne série RS485. La connexion est simplement en parallèle, les deux fils sont en parallèle sur tous les appareils (voir cette note d'application).
Parfait, très gentil comme d'habitude. Dernière question :) au lieu d'utiliser un convertisseur tcp / ip RS485 / ethernet et de connecter les onduleurs en tcp / ip auelsist pourrais-je avoir l'avantage de pouvoir accéder directement aux onduleurs via easyaccess, par exemple? alors peut-être serait-il possible de changer les paramètres à distance?
Un peu de confusion… Tout d'abord, si vous utilisez un convertisseur Ethernet / série pour communiquer avec les onduleurs et si vous souhaitez y accéder depuis l'IHM via EasyAccess, vous devez le "décrocher" du SlimLinesinon le ModbusMaster du SlimLine ça s'occupe de la communication.
Beaucoup, mais beaucoup, beaucoup mieux utilise le port série delo SlimLine pour dialoguer avec l’inveter, puis passez à SlimLine un serveur TCP sur un port TCP (supposons le port 1000). Lorsque vous vous connectez depuis Ethernet au port 1000 du SlimLine (Vous pouvez le faire à l’aide de EasyAccess). À partir du programme, vous pouvez désactiver le FB ModbusMB et permettre au FB DataStreamExch ou ModbusTCPGateway d’acheminer les données de la connexion Ethernet au port série auquel les inverseurs (Forum).
J'utilise le Modbus Master FB avec d'excellents résultats pour communiquer avec 5 onduleurs. Mais de manière apparemment aléatoire, le FB me signale une erreur que l'espionnage avec Toolly est 10007506, si je n'ai pas mal compris cela indique une erreur de réception des données, cette erreur n'interrompt cependant pas la communication, qui se poursuit sans problèmes. L'erreur sort au hasard un peu sur tous les onduleurs plus ou moins toutes les 2/4 minutes, voici le rapport de la console espion
03:23:03 (.310)|Tx|02 03 1C 20 00 01 82 63 03:23:03 (.011)|Rx|02 03 02 00 03:23:03 (.002)|Rx|Error:10007606, On Case:212, Back:51 ... 03:23:05 (.310)|Tx|03 03 1C 20 00 01 83 B2 03:23:05 (.016)|Rx|02 03 02 00 05 01 B7
Il est clair que certains caractères manquent dans la réponse mais je ne comprends pas pourquoi. La configuration du débit en bauds, etc. Je dirais qu'elle est correcte sinon je pense qu'elle ne communiquerait jamais, à la place je peux contrôler les onduleurs.
Le délai est de 100 ms, le délai est de 10 ms (mais même en l'amenant à des valeurs plus élevées de 300 ms), le problème se produit de la même manière. Quelques conseils ?
Comme vous le dites et comme vous pouvez le voir dans le rapport d'espionnage, les caractères de la réponse sont perdus dans le FB ModbusMaster le paramètre doit être défini IFTime indiquant le temps intertrame. Dans le protocole RTU, les paquets sont séparés par un temps qui varie en fonction du débit en bauds, il doit donc être réglé correctement.
Si le périphérique qui répond pour une raison quelconque insère une pause dans la réponse, le FB l'interprète comme la fin du paquet et va le vérifier, le trouvant en erreur.
Le FB ModbusMaster_v1 il a été entièrement repensé, le contrôle du temps intertrame a été supprimé, le paquet est complètement reniflé et vérifié le rendant indépendant des temps.
Vous ne me dites pas quel FB vous utilisez, je vous suggère de passer à la version v1 et de vérifier son fonctionnement, sachez que dans le passage à la v1 nous avons changé la définition d et les délais et délais, maintenant ce sont des valeurs REAL exprimées en secondes.
Merci pour la réponse rapide, je voulais essayer de mettre à jour la bibliothèque avec le FB ModbusMaster_v1 Où puis-je le trouver?
Parfait, il semble que la mise à jour vers ModbusMaster_v1 le problème a disparu.
Toujours très utile et utile comme toujours!
En errant dans le forum, j'ai appris l'existence de ce FB ACModbus, étant donné que dans certains instruments j'utilise vos systèmes pour communiquer via Modbus RS485 avec 5 onduleurs, j'aimerais avoir plus d'informations sur ce FB qui je suppose est né récemment.
Si je n'ai pas mal compris, il est "pratique" de l'utiliser lorsque vous avez besoin de lire des registres non consécutifs sur plusieurs appareils, n'est-ce pas?
Comment la communication s'améliore-t-elle? L'utilisation de ce FB pourrait-elle améliorer les performances de communication et donc aussi la vitesse?
Merci pour les explications
Comme vous l'avez dit à juste titre le FB ACModbus, La commande Array Modbus, a été créée pour faciliter la communication avec les équipements Modbus en vous permettant de définir les commandes à exécuter à travers un tableau de structures du type ACMODBUS_DATA.
L'utilisation du FB simplifie certes l'écriture des programmes car il prend en charge toutes les opérations d'ordonnancement des commandes, optimisant le passage d'une commande à l'autre, précisément dans le but d'obtenir les meilleures performances possibles.
Mais si celui qui a écrit un programme en ST en utilisant le FB ModbusMaster en programmant correctement les commandes, il a déjà implémenté toutes les stratégies possibles pour minimiser les temps où il a déjà obtenu des performances maximales et donc aussi le FB ACModbus ne pourra pas faire plus.
Je ne sais pas quelle version de la bibliothèque vous possédez, mais si vous téléchargez la dernière version depuis le site, vous trouverez sûrement le FB de gestion du maître Modbus.
Maintenant ça s'appelle ModbusMaster_v1, quiconque connaît nos bibliothèques sait qu'à chaque fois que les paramètres d'E/S sont modifiés dans un objet de bibliothèque (Fonction ou FB) le nom de l'objet est également modifié en ajoutant une version, comme dans ce cas "_v1" .
Si un objet ModbuMaster précédent a été utilisé dans un ancien projet, il peut être récupéré depuis la bibliothèque eLLabObsoleteLib.
Il va sans dire qu'en cas de révision d'un ancien projet il serait tout de même préférable de toujours utiliser les dernières versions disponibles.
- Vous devez être connecté pour répondre à ce sujet.