Accueil > Forum > Programmation IEC 61131 (LogicLab) > Questions sur l'utilisation du bloc fonction ModbusMaster
marqués: XUnifié
- Ce sujet a 14 réponses, 6 participants et a été mis à jour pour la dernière fois 3 années, 3 mois da Sergio Bertana.
-
auteurPost
-
Novembre 15, 2016 à 1: pm 18 #36074EmilianoPartecipante
En référence au bloc ModbusMaster, dans le manuel de programmation CEI 61131-3 LogicLab, les codes d'erreur qui peuvent être capturés via la fonction SysGetLastError sont mentionnés. En particulier, les erreurs lors de la réception de la trame de réponse aux messages émis par le maître qui sont signalées par 10007500 ~ 7 (c'est-à-dire de 0 à 7) mais sans associer les différents cas. Dans mon cas particulier, j'obtiens l'erreur 10007505 mais je ne comprends pas à quelle condition il se réfère (mauvais caractère, mauvaise longueur, CRC, etc.).
D'après ce que j'ai compris de la lecture du manuel, chaque fois qu'un cycle de lecture / écriture est effectué, à la fin du cycle, la sortie «Terminé» est déclenchée, que l'action réussisse ou non. Cependant, il est possible d'avoir des indications en ce sens au moyen des valeurs prises par les sorties «Ok» et «Fault». Mais en cas d'échec du cycle, la prochaine tentative de lecture / écriture est-elle effectuée directement par le bloc ModbusMaster ou est-il nécessaire d'effectuer une nouvelle commutation de l'entrée Enable?
Si la même zone de mémoire doit toujours être lue dans un seul esclave, en maintenant l'entrée "Enable" toujours active, les cycles de lecture sont effectués directement par le bloc ModbusMaster ou en alternance l'entrée Enable doit toujours être implémentée pour activer plusieurs cycles?
Novembre 15, 2016 à 2: pm 18 #39752Sergio BertanaAdministrateur du forumEn fait, nous n'avons pas signalé toutes les erreurs, indiquant généralement que l'erreur est dans la transmission ou la réception du paquet également parce que plusieurs fois l'erreur donne une indication incorrecte de ce qu'est réellement le problème. Dans votre cas, l'erreur 10007505 indique la réception d'une réponse d'un ID de nœud différent ou la réception d'un code de fonction autre que celui demandé. La meilleure façon de comprendre où se situe le problème est d'activer l'espionnage (Sujet).
En ce qui concerne la lecture consécutive, la sortie de OK refusé à l'entrée Activer, définissant éventuellement une période de Retard si vous souhaitez interposer un temps entre les commandes. Le FB a été conçu pour permettre la cascade et ce sujet traitons le sujet.
La réponse à votre dernière question est implicite dans la réponse précédente.
Décembre 8, 2016 à 7: pm 58 #39778SilvioPartecipanteJ'essaye de configurer un NetlogIII pour la communication en modbus RTU avec un variateur ABB ACS580 connecté sur le bus de terrain RS485. Dans LogicLab, j'ai utilisé les blocs Sysfopen et ModBusMaster. La première question concerne la numérotation des ports, je n'ai pas trouvé d'informations sur les manuels, le bus de terrain correspond à COM2, correct?
Une fois le programme chargé, l'onduleur confirme que la connexion est correcte, aucune erreur et indique qu'il reçoit et envoie correctement des données sur le modbus alors qu'il est sur l'automate la variable SysGetLastError me donne l'erreur 10007506 et depuis la console Telnet Toolly j'affiche l'erreur «Cadre de réponse trop long».
J'essaye de lire un mot de 16 bits sur un registre de mémoire. J'ai revérifié les câbles, la polarité, la vitesse et le bit de parité du bus sur les deux appareils et tout est correct. Il n'y a pas d'autres appareils sur le bus, la résistance de terminaison est active à la fois sur le variateur et sur l'automate tandis que la polarisation est également active sur le variateur.
Décembre 9, 2016 à 7: 32 am #39779Sergio BertanaAdministrateur du forumSur XTarget_12 (à partir du firmware SFW184B000), le FB a été créé pour ouvrir le port série SysSerialPort ce qui permet, en plus de l'ouverture, également de régler les paramètres de communication. Bien qu'il soit correct d'utiliser le Sysfopen Je vous suggère d'utiliser le nouveau FB (si nécessaire, mettez à jour le firmware sur le NetlogIII Voir la FAQ). La porte Fieldbus est le port COM2, l'erreur 10007506 que vous voyez comme indiqué dans le manuel fait référence à une erreur de réception.10007500~7 Errore in ricezione frame risposta (Carattere errato, lunghezza errata, CRC).Maintenant, vous me dites que dans Telnet avec Toolly, vous voyez "Cadre de réponse trop long", cela signifie que vous l'avez activé SpyOn et vous espionnez la communication Modbus avec le variateur. Ensuite, la trame de demande envoyée et la trame de réponse reçue sont affichées, si vous cochez ces frames suivant la spécification Modbus, vous verrez probablement qu'un certain nombre de registres ont été demandés dans la demande et que plus de données ont été reçues dans la réponse que prévu. Pourquoi cela se produit-il, je devrais voir le rapport d'espionnage sur Toolly, mais en général, vous êtes sûr d'avoir réglé le mode de communication correctement (vitesse de transmission, parité, bits), vous êtes sûr d'utiliser le bon code de lecture et d'utiliser le bon adresse du registre (rappelez-vous le décalage de 1) Le FB ModbusMaster dit: "Selon les spécifications Modbus, l'adresse envoyée dans la trame de données est (Address-1)” En effet, qui est conforme Modbus ajoute 1 à l'adresse reçue, mais beaucoup devices ils ne s'additionnent pas, vous devez donc ajouter 1 à la valeur de Adresse transmis au FB. Si vous m'envoyez un printscreen de l'écran Toolly peut-être que je peux être plus précis.
Décembre 9, 2016 à 10: 11 am #39780SilvioPartecipanteEn attendant, merci pour la réponse rapide et complète, un support exceptionnel!
Dès que je peux faire un test avec le bloc SysSerialPort, j'ai eu quelques doutes sur la différence entre les deux blocs. Sur la console de Toolly, je vois que le paquet envoyé et reçu coïncide:| Tx | 02 04 9 44 00 01 5F BC
| Rx | 02 04 9 44 00 01 5F BC
| Er | Répondre trop longtempsModBusMaster: Type: 0; Noeud: 2; FCode: 16 # 03; Adresse: 40005, Points: 1; IFTime: 286; Timeout: 500; Retard: 1000.
(Je m'excuse mais je n'ai pas trouvé comment joindre des images au forum ...)L'adresse n'est pas un problème car j'ai une série de registres adjacents donc au plus je devrais lire une donnée différente de celle voulue.
Décembre 9, 2016 à 12: pm 54 #39781Sergio BertanaAdministrateur du forumMerci pour les compliments ... aujourd'hui un jour de pont et puis sans appels téléphoniques, vous avez plus de temps pour le forum. La trame modbus envoyée ne me revient pas. Le nœud est 02, mais le code de fonction est 04 et non 03 comme vous l'avez défini. L'adresse du registre comme vous le voyez est 9C44 qui correspond à 40004 (jeu d'adresses -1), demandez un registre 00 01 et le CRC est 5FBC.
Mais la réponse est fausse, elle ne doit pas du tout coïncider avec la requête, il semblerait qu'un écho fait par le variateur ne doit absolument pas se produire, car le FB attend la réponse qui devrait être du type 02 04 02 xx xx CRC. Autrement dit, vous avez demandé un registre et le lecteur répond avec 02 octets suivis de leur valeur et du CRC.
Vous pouvez essayer d'espionner avec un port RS485 en parallèle sur la ligne de communication pour voir si après la trame de demande il y a une trame d'écho et ensuite réellement la trame de réponse. Après la première trame reçue, le FB la vérifie et en cas d'erreur il abandonne en attendant la commande suivante et ne vous montre donc pas la trame correcte possible qui suit.
La raison de l'erreur est évidente 7 octets de réponse sont attendus et à la place 8 arrivent.
Décembre 10, 2016 à 7: pm 45 #39783SilvioPartecipanteJ'ai effectué le test avec le FB SysSerialPort mais sans succès. Le variateur m'indique qu'il n'y a aucune activité sur le bus et qu'il n'échange pas de données, tandis que sur l'automate le module FB ModBusMaster me donne l'erreur 10007010.
Si à la place, j'essaie à nouveau avec le Sysfopen Je récupère l'échange de paquets avec l'erreur déjà mise en évidence. J'ai également vérifié sur le manuel du variateur s'il y a la possibilité d'une réponse d'écho mais je n'ai pas trouvé de trace donc je ne peux pas expliquer la réponse. J'ai aussi réessayé en abaissant la vitesse du bus à 9600 mais sans succès, le câble n'est pas au top mais vu qu'il ne fait même pas 2m de long je ne pense pas qu'il y ait de problèmes d'interférences.
Décembre 12, 2016 à 7: 37 am #39784Sergio BertanaAdministrateur du forumL'erreur indique-t-elle que la valeur File n'est pas définie, mais avez-vous passé la valeur File du FB SysSerialPort au FB ModbusMaster? Sur des longueurs aussi courtes, le câble n'a normalement aucun problème, maintenant pour comprendre le problème, le seul est d'espionner communication sur RS485 ou envoyer des commandes Modbus depuis Toolly (voir le dernier article de ce sujet) ou avec un programme de simulation Modbus par exemple le meilleur Modulateur Maître Modbus.
Mai 3, 2019 à 6: 03 am #47386StefanoPartecipanteJ'ai un problème avec Toolly en pratique après l'authentification, la commande SpyData me répond qu'elle n'est pas active. Pourtant, j'ai configuré le SpyOn du ModbusMaster FB sur TRUE, pourquoi? Où ai-je tort?
Mai 3, 2019 à 6: 05 am #47390Sergio BertanaAdministrateur du forumLe FB ModbusMaster est-il exécuté?, Dans quelle tâche avez-vous mis l'exécution dont je me souviens qu'elle doit exister dans la tâche Back.
Le paramètre File est-il correctement défini, fait-il référence à un FILEP valide?Mai 3, 2019 à 8: 45 am #47392StefanoPartecipanteOk Merci, c'était l'emplacement du programme qui n'était pas dans Back. Maintenant, je vois les données envoyées et reçues ...
June 7, 2019 à 6: 43 am #47976RuboxPartecipanteJ'expérimente l'utilisation du ModbusMaster FB sans succès. J'ai un objet qui accepte les communications Modbus TCP. La connexion à l'objet est réussie, le paramètre de fichier sortant n'est pas NULL. L'utilisation du programme Modbus Master Simulator a recommandé un autre article ... il me lit correctement les données.
Je règle les paramètres dans le FB de connexion TCP et Modbus Master de la même manière que dans le programme de simulation. J'obtiens l'erreur 10007506: Je suppose que j'ai mal défini les données et combien de registres à lire ... est-ce possible?
Les données que j'essaie de lire sont une valeur dans le registre de nombres 5 définie comme un entier binaire 32 (c'est une température).
Je définis une variable DINT dans LogicLab, je définis les autres paramètres, l'adresse moins un, donc je lui donne 4, mais j'obtiens toujours cette erreur. J'ai essayé de définir la variable d'une manière différente (INT, USINT, etc ...) mais rien.
Je sais que je fais une erreur triviale parce que l'objet communique en modbus, mais je ne comprends pas où je me trompe.
June 7, 2019 à 6: 46 am #47979Sergio BertanaAdministrateur du forumUtiliser l'espionnage est la solution qui vous permet de comprendre où vous vous trompez. Nous en parlons d’abord dans cet article ou, si vous cherchez, vous trouverez de nombreux sujets sur la console espion (article).
Décembre 3, 2020 à 9: 26 am #58390MarcelloPartecipanteJe reprends ce post pour comprendre la différence des erreurs de type 10007500-7. Je vais t'expliquer. j'en ai un SlimLine Cortex M7 [MPS054B110], via une connexion TCP / IP, j'interroge un appareil modBus qui me renvoie 8 BYTE sur 4 adresses différentes pour composer des valeurs flottantes (REAL). La demande se produit en continu et il m'arrive de manière absolument aléatoire (j'ai tout vérifié: heure, contemporanéité avec d'autres fonctions, etc.) qu'après 2-3 jours ou après 5, la communication soit interrompue générant l'erreur 10007505.
La seule façon de redémarrer la communication est de redémarrer le SlimLine. Pensant que cela pourrait être un problème avec l'appareil, j'ai connecté un PC à l'appareil lui-même et avec un petit programme en Python, je l'ai surveillé pendant 2 semaines consécutives mais la communication ne s'est jamais arrêtée. En détail, que signifie cette erreur en plus du générique «Erreur de réception de la trame de réponse (mauvais caractère, mauvaise longueur, CRC)»?. Pouvez-vous penser à d'autres tests à réaliser?
Décembre 3, 2020 à 9: 34 am #58393Sergio BertanaAdministrateur du forumL'erreur que vous mentionnez apparaît si vous manquez des caractères dans la chaîne de réponse, cela pourrait être un problème similaire à celui signalé dans les derniers messages de ce sujet. Utile pour comprendre le problème serait d'avoir un rapport d'espionnage de communication avec Toolly.
Parce qu'il fonctionne pendant un certain temps puis se fige est très étrange, bien sûr en utilisant le ModbusMaster FB qui utilise le IFTime pour diviser les paquets Modbus, il suffit que le périphérique esclave, pour une raison quelconque, fragmente la réponse sur plusieurs paquets TCP pour que cela puisse générer le problème.
Comme recommandé dans la rubrique que je vous ai liée, je vous propose de remplacer le FB de gestion Modbus par la nouvelle version ModbusMaster_v1 qui a été entièrement repensé, éliminant le contrôle sur le temps intertrame, le paquet est complètement reniflé et vérifié le rendant indépendant des temps.
-
auteurPost
- Vous devez être connecté pour répondre à ce sujet.