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.
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é.
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 ???
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.
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 EBXV4 derrière l’EBX-Connect.
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)
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, …)
donc IPX 100% opérationnelle et prête à accueillir d’autres développements
Tout cela nous conforte donc dans l’idée qu’il s’agit bien de problèmes de câblage.
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.