La IHM ne peut pas se connecter à l'automate via Ethernet
Cette boîte rouge sur l'écran. Vous savez, celle-là. « Communication échouée. » Ou « Impossible de se connecter à l'automate. » Quelle que soit la formulation utilisée, cela signifie la même chose : rien ne fonctionne.
Je vais vous dire quelque chose que vous n'aurez peut-être pas envie d'entendre. Ce n'est pas un problème de débutant. J'ai vu des ingénieurs de contrôle de quinze ans fixer cette boîte pendant des heures. Moi y compris.
Un cas réel qui me fait encore secouer la tête
L'année dernière. Un gars expérimenté que je respecte. Quatre heures perdues.
D'abord, il a échangé les câbles. Trois d'entre eux. Puis il a redémarré tout - IHM, automate, même le switch. Rien. Ensuite, il a commencé à modifier la logique de l'IHM. Il a réécrit une partie du script. Convaincu que c'était son code.
Voici où son esprit s'est dirigé. Première hypothèse : problème réseau. Deuxième : problème de configuration HMI. Troisième : erreur de logique logicielle. Vous remarquez ce qu'il n'a jamais vérifié ? Le côté automate. Pas une seule fois.
La cause réelle ? Le port Ethernet de l'automate était désactivé. Une seule case à cocher dans la configuration matérielle. Quatre heures. Un clic.
Je vous raconte ça non pas pour l'embarrasser. Je vous le raconte parce que c'est exactement comme ça que la plupart d'entre nous pensent sous pression. Nous sautons les choses stupides et nous nous plongeons dans les choses compliquées. Chaque seule fois.
Pourquoi la plupart des conseils en ligne ne vous aideront pas maintenant
Vous avez fréquenté les forums. Je sais que vous l'avez fait. « Vérifiez votre câble. » « Pinguez l'appareil. » « Mettez à jour votre firmware. » Tout est correct. Rien de tout cela dans le bon ordre.
Le vrai problème n'est pas que vous ne sachiez pas quoi vérifier. Vous savez beaucoup de choses. Le problème est l'ordre. Vous sautez d'un post de forum à un autre, essayant des corrections aléatoires. Ce n'est pas du dépannage. C'est jouer avec votre temps.
Ce n'est pas un problème de connaissances. C'est un problème d'ordre.
Étape 1 — Commencez là où personne ne veut commencer
Rendez-vous devant le panneau. Pas de bureau à distance. Pas de « Je crois me souvenir ». Vos jambes. Allez-y.
Regardez l'automate. Le témoin RUN vert est-il fixe ou clignotant ? Fixe signifie en cours d'exécution. Clignotant signifie autre chose – arrêtez-vous, consultez le manuel.
Maintenant, le câble Ethernet. Tirez un peu côté IHM. Puis côté automate. Connecté ? Les deux extrémités ? Bien.
Vous vous dites : « Allons, j'ai déjà vérifié tout ça ». Je vous entends. J'ai pensé la même chose le jour où j'ai perdu quatre heures. Mais voici la vérité : sauter cette étape est la principale perte de temps dans ce travail. Je l'ai fait. Vous l'avez fait. Regardez simplement. Ça prend soixante secondes. Ensuite, on passe à autre chose.
Étape 2 — Le tueur silencieux
Adresses IP. Seules deux choses comptent réellement ici. Tout le reste est du bruit.
D'abord, même sous-réseau. Les deux sur 192.168.1.x avec le même masque ? Un chiffre erroné et ils ne se verront jamais. Peu importe la qualité de votre câble.
Ensuite, le piège 169.254. Vous voyez ce nombre sur l'un des appareils ? C'est l'appareil qui dit « J'ai demandé une adresse IP et personne n'a répondu, alors j'en ai créé une ». Auto-assignée. Signifie pas de réseau. Arrêtez tout. C'est votre problème.
Action de basculement. Levez-vous. Marchez jusqu'à l'IHM. Ouvrez sa page réseau. Notez l'adresse IP actuelle qu'elle affiche. Branchez ensuite votre ordinateur portable sur l'API et lisez sa véritable adresse IP. Ne vous fiez pas à votre mémoire. Faites confiance à ce que l'écran affiche. J'ai été brûlé par des "Je suis à peu près sûr que c'est 192.168.1.10" plus de fois que je ne veux bien en compter.
Une table qui fait réellement gagner du temps
| Ce que vous voyez | Ce qui ne va pas réellement |
|---|---|
| Délai d'attente de l'IHM, mais l'API répond au ping | Incompatibilité de protocole (Modbus vs S7 vs TCP) |
| Connexion instable (se connecte, se déconnecte, se reconnecte) | Conflit d'adresses IP – deux appareils, même adresse |
| Aucune communication du tout | Sous-réseau incorrect ou passerelle manquante |
| La IHM se connecte uniquement après redémarrage | Limite de connexion de l'API atteinte |
La contrainte négligée dont personne ne parleCette dernière ligne du tableau. Permettez-moi d'y passer une minute car les forums ne le font jamais.
La IHM ne communique pas avec l'API
Les automates programmables (API) disposent d'un nombre limité de slots de connexion. Certains n'en ont que trois ou quatre. Voici ce qui se passe – vous avez un système SCADA connecté. Deux ordinateurs portables pour la maintenance. Peut-être une caméra ou une passerelle de capteurs. Puis vous arrivez avec votre IHM. L'API consulte sa table de connexions et dit « désolé, complet ». Aucun message d'erreur. Juste le silence.
Test rapide. Redémarrez l'API. Si l' IHM industrielle se connecte immédiatement après le démarrage, vous venez de le trouver. Les slots de connexion étaient pleins. L'API vide sa table de connexions au redémarrage, votre IHM passe donc en premier. Mais la prochaine fois que quelqu'un d'autre se connecte, vous revenez à la case départ.
La solution est simple. Allez dans le programme de l'API. Augmentez la limite de connexion. Cinq minutes de travail une fois que vous savez quoi chercher.
Voici comment ces défaillances se manifestent réellement
Pas aléatoire. Pas malchance. Trois couches.
Couche physique – câbles, ports, voyants de liaison. C'est là que la plupart des gens pensent que ça commence. Mais ce n'est pas le cas. Ils commencent ailleurs et se retrouvent ici trois heures plus tard.
Couche réseau – Adresses IP, sous-réseaux, protocoles. C'est là que la plupart des gens commencent réellement. Et c'est là qu'ils bloquent parce qu'ils négligent la couche physique.
Couche ressources – Limites de connexion, capacité de l'appareil, mémoire. Celle-ci concerne les personnes expérimentées. Celles qui supposent que tout est correctement configuré parce qu'elles l'ont déjà fait cent fois.
Gardez ces trois éléments à l'esprit. La prochaine fois que quelque chose ne fonctionne pas, parcourez la liste. Physique. Puis réseau. Puis ressources. Dans cet ordre.
Une note pratique
Le matériel est déjà suffisamment complexe. Le firmware et les outils ne devraient pas compliquer les choses. StoneHMI reste simple.
Revérifiez cette adresse IP. Tirez à nouveau sur ce câble. Le problème est probablement juste devant vous. C'est généralement le cas.
