Les boutons et objets HMI Weintek disparaissent : dépannage Modbus

5. Comprendre les paramètres Local Device et Remote Device

Ne passez pas tous les PLC Ethernet en “Remote”.

Dans l'architecture documentée d'EasyBuilder Pro :

• UN Local Device est connecté au HMI local.
• UN Remote Device est connecté via un autre HMI.

Ainsi, “Local” ne signifie pas que l'adresse PLC est simplement une mémoire interne HMI. Un périphérique connecté en Ethernet peut faire partie de la configuration des périphériques du HMI local.

Le manuel explique ces différences dans ses sections de configuration des périphériques locaux et distants. Suivez la topologie de communication réelle et les instructions du pilote sélectionné. Weintek EasyBuilder Pro V6.10.01, Chapitre 5, sections 5.2.2–5.2.3

Après une conversion de projet ou un changement de périphérique, confirmez que les objets concernés font référence à l'entrée de périphérique prévue. Des réglages corrects sur une entrée ne répareront pas des objets pointant toujours vers une autre.

6. Vérifier interverrouillages et visibilité lorsque les lectures sont valides

Si les valeurs requises sont lisibles, examinez les conditions d'affichage de l'objet.

Par exemple, le manuel EasyBuilder Pro documente Hide when disabled pour l'interverrouillage d'un objet Set Word. Lorsque sa condition configurée n'est pas satisfaite, l'objet est masqué. Les autres types d'objets disposent de leurs propres paramètres de sécurité et de visibilité. Weintek EasyBuilder Pro V6.10.01, Chapitre 13, page 13-22

Vérifier:

• Si le masquage est activé.
• Quelle valeur contrôle la condition.
• Si cette valeur est valide et actuelle.
• Si la comparaison correspond à l'état machine prévu.
• Si l'utilisateur actuel dispose des privilèges requis.
• Si l'apparence de l'objet change avec son état.

Un objet masqué peut se comporter exactement comme prévu. Confirmez le comportement attendu avec le propriétaire du projet avant de le modifier.

Ne supprimez pas un interverrouillage ou une restriction de privilèges pour restaurer la visibilité sur une machine en fonctionnement. Corrigez une erreur de configuration identifiée via le processus de modification approuvé.

7. Séparer les problèmes de connexion des problèmes de requête

Si aucune lecture pertinente ne réussit, examinez la connexion. Si certaines lectures réussissent, donnez la priorité aux requêtes en échec.

Pour Modbus TCP, vérifiez l'IP de destination, l'interface LAN sélectionnée, la route, le port serveur configuré et la disponibilité du service Modbus prévu.

Pour Modbus RTU, comparez l'interface COM sélectionnée, le numéro de station, le format série et le brochage du câble avec la documentation de l'équipement. Inspectez ou modifiez le câblage uniquement dans le cadre de la procédure de maintenance sûre applicable.

Pour le flux de connexion plus général, voir Weintek HMI « PLC No Response » : corrections série et Ethernet.

N'interprétez pas un ping réussi, un voyant de liaison ou une indication générale « connecté » comme preuve que le registre de l'objet manquant est lisible. Vérifiez cette transaction précise.

8. Examiner les requêtes d'arrière-plan sans supprimer les fonctions de production

Un avertissement de communication peut persister même lorsque la page affichée semble normale.

Examinez les fonctions d'arrière-plan qui font référence au même périphérique, comme la surveillance des alarmes, l'échantillonnage de données, les macros et les transferts de données. Identifiez les adresses obsolètes ou mal mappées par le diagnostic et l'examen du projet.

Ne supprimez pas les fonctions d'alarme ou de surveillance de l'application en production pour faire disparaître un message. Si un test d'isolement est nécessaire, réalisez-le dans une copie contrôlée du projet et conservez la configuration d'origine.

De même, augmenter un timeout n'est approprié que si les preuves montrent que des réponses valides arrivent trop tard. Cela ne corrige ni une adresse incorrecte ni une condition de visibilité.

9. Vérifier la réparation avant de revenir au fonctionnement normal

Modifiez une cause identifiée à la fois, puis compilez et déployez selon le processus de maintenance habituel.

Confirmez que :

1. L'objet prévu apparaît dans les bonnes conditions.
2. Son état affiché correspond à la valeur réelle du périphérique.
3. Les objets qui fonctionnaient auparavant continuent de fonctionner correctement.
4. Le comportement de connexion et d'interverrouillage reste intentionnel.
5. Les avertissements de communication ne réapparaissent plus pendant la séquence de fonctionnement concernée.
6. Toute fonction de commande est testée uniquement selon une procédure d'essai machine approuvée.

Lorsque nécessaire, vérifiez le comportement au démarrage et à la récupération de communication pendant un essai planifié. Restaurez les paramètres d'accès au diagnostic selon la politique du site et enregistrez le projet corrigé.

Si le problème reste non résolu, fournissez au support la version du projet, la configuration de l'objet, la table de registres du serveur et une requête en échec capturée. Ces détails sont plus utiles que « l'écran est vide ».