Liens HTTP qui n'aboutissent pas!

Bonjour la communauté,

J’ai un problème récurrent lorsque je suis en paramétrage de l’IPX. Les liens HTTP n’aboutissent pas toujours.

Je m’explique : Quand je change d’onglet (IPX800 - EXTENSIONS par exemple), ou lorsque je clic sur une flèche “ALLER A”, parfois rien ne se passe. Ca mouline dans le vide. Il faut que j’actualise la page web pour revenir sur le lien demandé !

Pire ! parfois lors d’une de ces actions (ci-dessus expliquées), j’entends l’IPX “rebooter” !!!

D’après GCE, il s’agirait d’un problème réseau interne.

J’ai entièrement revu mon réseau et toutes les jarretières ethernet ont été remplacées par de catégorie 7 ou 8. Mais rien n’y fait !!!

Perso je pense plus à un soucis de perturbation électro-magnétique qui me génèrerait ces problèmes.

Quelqu’un aurait il eu ce genre de soucis ?

Merci pour vos aides !

jppouma

Bonjour Jean-Pierre,

le problème du chenillard a été constaté sur quelques IPX800.
Il me semble qu’une proposition de correction sera proposée lors de la prochaine màj.
@Kevin_GCE
Par contre, je n’ai jamais eu de reboot intempestif, je pense que les 2 problèmes sont indépendants.

Le chenillard est sans doute lié aux objets de la page en cours d’affichage. Il suffit d’une IO mal configurée, d’un objet faisant référence à une variable qui n’existe plus, des connecteurs fantômes, … pour que les requêtes sql se perdent.
Souvent un F5 sur la page ou un changement d’onglet résout le pb comme vous l’avez constaté.

L’outil de @michel94 peut aussi être utilisé pour « nettoyer » la configuration en supprimant ces variables ou références en erreur.
:gear: Utilitaire IpxBrowser pour IPX800 V5 - Cartes Ethernet IPX800 - GCE Electronics
Bonne journée

1 « J'aime »

Merci pour la réponse fgtoul. Dans un premier temps je vais faire un essai avec l’utilitaire de michel94.

J’ai eu aussi un problème très gênant ces derniers temps, un plantage du bus powered EBX. Plus aucune réponse sur mes X-8R, ni par appuis sur les extensions en relais cmd ni par API. Obligé de faire un hard reset de l’IPX (retour usine).

C’est pour cela que je pense à une perturbation électro-mécanique… mais comment la détecter et l’éliminer ???

Bonjour Jean-Pierre,

voici un peu de lecture.

Bonne journée

1 « J'aime »

Merci Philippe pour ta réponse ! petit détail : si j’utilise le bus v5 (RJ45) et le bus v4 (filaire), je mets ma résistance à la fin du bus filaire ? on est d’accord ?

Petite remarque sur le chenillard… j’ai un script PHP qui interroge l’IPX via l’API (49 ressources) toutes les minutes, peut il être en partie la cause de ce dernier ?

je crois qu’à ce sujet il y a discordance au sein des équipes GCE. Il est possible qu’utiliser les 2 types de bus sur la v5 génère des collisions au sein même de la V5. Perso je resterais en bus V5 de bout en bout, avec un EBX-Connect pour terminer avec le bus V4.

1 « J'aime »

En fait, j’utilise le bus v5 avec un EBX-Connect ET le bus v4 de l’IPX v5… si je suis ton raisonnement, il faudrait que je laisse tomber le bus v4 de l’IPX, et tout câbler à partir de la conversion avec l’EBX-Connect ?

oui, je pense qu’il ne faut utiliser qu’un seul type de connecteur de bus sur la V5. Donc je préconise de mettre les extensions qui sont sur le Bornier EBX V4 derrière l’EBX-Connect.

1 « J'aime »

ce serait très intéressant d’avoir un retour sur la résolution ou non par cette méthode, car aujourd’hui il y a beaucoup de doutes à ce sujet.

OK… C’est ce que je vais faire ! Je ferai un retour une fois le câblage terminé… et quelques tests faits !

et en ce qui concerne ma remarque sur le chenillard

Petite remarque sur le chenillard…

j’ai un script PHP qui interroge l’IPX via l’API (49 ressources) toutes les minutes, peut il être en partie la cause de ce dernier ?

Qu’en penses tu ?

non je ne pense pas que le script externe mette l’ipx à genou, mais pour s’en assurer, il faudrait afficher les valeurs de DIAG de la V5 sur un dashboard.
Dashboard à importer :
DEBUG.zip (1,0 Ko)

1 « J'aime »

Je viens d’importer le dashboard et le ‘Heap Free’ semble bien chargé : 85500 / 86300 !

c’est au contraire une très bonne valeur. Plus elle est haute, mieux c’est.

1 « J'aime »

OK :+1: Quelles sont les valeurs à surveiller principalement ?

dans ton cas, la charge du bus EBX, ainsi que le cycle. Plus les valeurs sont petites mieux c’est.
Pour l’impact par le script, peut être les paramètres relatifs à l’APP, Le rule Engine (cycle et période)
Toutes les minutes, tu dois voir l’impact du script qui fait grimper les jauges. Si les jauges redescendent assez vite dans le vert, c’est ok. Si elles se maintiennent dans le orange, l’ipx est effectivement impactée, reste à savoir par quoi (script, config lourde, …)

Toutes ces valeurs sont très faibles voir nulles !

1 « J'aime »

donc IPX 100% opérationnelle et prête à accueillir d’autres développements :slight_smile:
Tout cela nous conforte donc dans l’idée qu’il s’agit bien de problèmes de câblage.

1 « J'aime »

Bonjour Jean-Pierre,

Je suis tout à fait d’accord avec @fgtoul sur ce point, c’est la 1ère chose à tester, avant la résistance.

Bonne journée

1 « J'aime »

Bonjour

Alors moi aussi j avais le bus V5 et mis sur l IPX le bus V4

Au début pas de soucis et ensuite dégradation

J ai enlevé le bus V4 et depuis ca marche

Bonne journée

Bonjour,
récemment j’avais mis un clignotant en place sur une V5 pour envoyer des trames modbus, clignotant toutes les TA=100 ms, TB=100ms
Cela a généré des comportements erratiques de l’ipx alors que les valeurs de Diag étaient correctes.

  • Websock disconnected sur le Liveview
  • Dashboard disconnected
  • IPX Reboot
  • Chenillard
  • etc.

J’ai rallongé le Clignotant à TA=500 ms, TB=500 ms et le comportement de l’IPX est redevenu normal.

Je pense qu’il faut vérifier si des objets clignotants envoyant des trames (Push, Modbus, …) ne sont pas trop optimistes.

Bonne journée

2 « J'aime »