- Ce sujet a 9 réponses, 3 participants et a été mis à jour pour la dernière fois 10 années, 12 mois da
.
-
Post
-
J'ai acheté des modules d'E / S Trycom distribués et je souhaitais les utiliser pour construire un système domotique. En pratique, j'aimerais connecter les commutateurs aux entrées numériques 16 du module TRPC26, tandis qu'aux sorties 16 du module TRPC24, j'aimerais connecter les sorties de contrôle utilisateur (lampes, appareils, etc.).
J'ai pensé à utiliser votre module CPU SLine pour la gestion logique de l'installation, est-il possible de gérer ces modules d'E / S distribués via le protocole Modbus depuis votre CPU?
le module TRPC26 utilise la commande modbus Statut de bobine de lecture 01 pour lire l'état des 16 entrées numériques, tandis que le module TRPC24 utilise la commande modbus 15 Force plusieurs bobines pour écrire des sorties numériques 16. Utilisation du bloc fonction ModbusRTUMaster (Extrait manuel), il est possible de lire les entrées du module TRPC26 et d'écrire les sorties dans le module TRPC24.
J'ai créé un programme sur SLine qui lit cycliquement les 16 entrées du module d'entrée et les prend en charge dans 16 variables BOOL (TRPC26Input [0..15]), copie 16 variables BOOL (TRPC24Output [0..15]) sur le 16 sorties logiques du module de sortie. Les deux modules ont été connectés au réseau RS485, il est nécessaire de définir l'adresse 0x01 (par défaut) au module d'entrée logique, l'adresse 0x02 au module de sortie logique, voir poster.
Dans le programme, vous trouverez un programme d'échelle Logique, qui place l'entrée DI0 des modules d'entrée sur la sortie DO0 du module de sortie. Vous pouvez ajouter toute la logique dont vous avez besoin en ajoutant des lignes à ce fichier et / ou en ajoutant d'autres programmes au projet.
Le programme TRPComm exécute la lecture et l'écriture cycliques des modules d'E / S, des programmes InputRead e OuputWrite, ils échangent les bits de lecture et d'écriture avec les modules TRP afin que les variables BOOL soient ordonnées en fonction de l'E / S du module. Imprimer le programme, téléchargement du programme.
Étant un système domotique, je vous recommande dans les fichiers InputRead ed OutputWrite pour renommer les variables de support d'E / S distribuées en utilisant des noms qui sont mnémoniques pour votre système.
Pour les entrées TRPC26Input [0] peut devenir PlsLuceSalone, TRPC26Input [1] peut devenir PlsLuceCucina, Etc.
Pour les sorties TRPC24Output [0] peut devenir CdoLuceSalone, TRPC24Output [1] peut devenir CdoLuceCucina, Etc.Je demande des précisions sur l'exemple IOOverTRP qui a testé avec succès sur différents fabricants de IO Modbus.
Je réalise actuellement des tests de communication avec un Siemens S7-200 utilisé comme esclave Modbus du SlimLine. Le seul changement que j'ai fait pour pouvoir lire l'esclave Modbus susmentionné était de définir FCode= 16 # 03 et régler le paramètre Adresse d'une manière appropriée.
J'ai rencontré la situation qui peut être déduite de la comprendrec'est-à-dire, le tableau TRPC26Read il n'est pas évalué correctement. En effet par la fenêtre Montres seul le bit le moins significatif du tableau est correctement évalué tandis que l'affichage% MW100.0 indique que la communication a réussi.
Nous devons comprendre la différence entre FCode 16 # 01 (Lire l'état de la bobine) e 16 # 03 (Lire le registre de détention).
La commande 16 # 01 lit l'état des contacts logiques, c'est-à-dire les variables booléennes, puis lit 16 variables Points = 16, comme dans mon programme TRPCom, les 16 valeurs BOOL consécutives du tableau sont valorisées TRPC26Read.
La commande 16 # 03 effectue la lecture des mots (bits 16) de la mémoire, puis lit la variable 1 Points = 1 comme dans votre exemple, une seule variable USINT de programme est évaluée. Comme vous pouvez le voir % MW100.0 il est valorisé avec la valeur 16 # 0005 qui est la valeur présente dans l'automate Siemens.
Si votre problème est de diviser une variable USINT en 16 variables BOOL, vous pouvez utiliser des blocs fonctionnels WordToByte e ByteToBit (Extrait manuel).
J'ajoute une astuce qui peut être utile pour comprendre l'adressage des systèmes SlimLine. SlimLine est basé sur un processeur ARM qui utilise le stockage de données dans le little-endian, commence par l'octet le moins significatif et se termine par le plus significatif.
Donc, comme vous pouvez le voir dans l'exemple la % MW100.0 il est valorisé avec la valeur 16 # 0005, donc à l'emplacement avec l'offset 0 du tableau TRPC26Read attribué à la même indiirizzo% de MW100.0 correspond LSB de la valeur de mot, tandis que la location avec 1 décalage correspond MSB.
Puisque la valeur du mot 16 est # 0005, son LSB sera différent de zéro, c'est-à-dire TRUE, tandis que son MSB sera égal ou c'est-à-dire FALSE. Si la valeur du mot avait été 16 # 0101, nous aurions eu à la fois MSB et LSB à la valeur TRUE.
Je voulais des éclaircissements sur le codage utilisé par le SlimLine pour les données réelles. J'ai en pratique à traiter comme un nombre réel à virgule flottante (32bit) acquis via MODBUS-RTU auprès d'un S7-200 plc FCode= 16 # 03 e Points= 2.
D'après le manuel LogicLab, la seule spécification concernant le type réel est qu'il a la plage -3.4E38 - + 3.4E38 tandis que le format utilisé par le S7-200 est "REAL 32 bits IEEE 32 bits flottant nombre à partir de + 1,175495E- 38 à + 3,402823E + 38 de -1,175495E-38 à -3,402823E + 38 "
Je m'attendais à ce que l'encodage soit identique mais je ne peux pas mémoriser la valeur acquise dans une variable REAL, j'attache screenshots, J'espère que les tests effectués sont clairs.
Le format utilisé pour les variables REAL est IEEE 754 comme indiqué dans questo poste, vos captures d'écran montrent qu'il s'agit du même format utilisé par le S7-200. En fait, dans ce format de représentation, la valeur REAL 2.0 est au format hexadécimal 16 # 40000000 (comme vous pouvez le voir dans la fenêtre de mise au point sur S7-200).
Attention! Lors de la lecture de variables 32 bits via Modbus, il faut faire attention à la finalité des données, en fait le protocole Modbus ne spécifie pas dans quel ordre les deux parties 16 bits des données 32 bits doivent être renvoyées. Par conséquent, il est possible que dans certains systèmes, la partie la plus significative soit retournée avant la partie la moins significative ou vice versa.
Su SlimLine comme déjà mentionné dans d'autres articles, le little-endian qui commence par l'octet le moins significatif et se termine par le plus significatif, et d'après ce que je vois, c'est le même type de représentation que Siemens utilise dans le S7-200 (utilise probablement un processeur ARM). En fait, si vous remarquez dans le% MW100.16 qui est le premier registre lu par modbus, vous trouverez la partie la moins significative du nombre et dans le% MW100.18 la partie la plus significative.
Donc votre erreur n'est que dans l'inversion des mots dans la conversion WordToDouble.
J'ajoute une astuce, car le format de représentation du S7-200 est le même que celui du SlimLine, pour avoir la valeur en REAL il suffit de définir une variable REAL à l'adresse DB100.16 où le FB modbus supporte les registres lus par le S7-200 pour pouvoir l'utiliser dans votre programme sans avoir à utiliser le WordToDouble.
MyVariable AT% MD100.16: REAL; {DE: "REAL variable lue depuis S7-200"}
Oui, bien sûr, la solution que vous avez proposée est faisable, en questo poste vous pouvez trouver un exemple de gestion de SlimLine Modules d'E / S distribués via Modbus. Une fois les modules acquis, vous prendrez en charge les E / S sur les variables de mémoire du SlimLine accessible depuis Modbus. Le PC peut être connecté en Ethernet et l'état des entrées acquis via modbus TCP, en utilisant par exemple un logiciel SCADA (Voir le message), une application développée avec ProfilabExpert (Voir le message) ou une application développée ad hoc avec le langage de programmation que vous connaissez. Si le développement du protocole modbus TCP est trop complexe, vous pouvez développer un protocole de communication adapté à vos besoins (Voir le message). Si vous avez seulement besoin de voir l'état des cloches, comme alternative au PC, je recommande d'utiliser un panneau de commande écran tactile qui a déjà la gestion native du protocole modbus TCP, de plus, si vous le souhaitez, vous pouvez gérer le son du buzzer et également consulter l'historique des interventions des cloches. Le panneau peut également gérer des fichiers historiques, vous permettant d'avoir un rapport sur les interventions des cloches liées à la date / heure.
- Vous devez être connecté pour répondre à ce sujet.