Face avant qui freeze lors du timeout d'une structure evenement

[mecatronicengineer]

Bonjour,

Je rencontre un problème de "Freeze" de la face avant du IHM et cela même en mode debug.

J'ai essayé d'analyser la cause du problème. J'ai ajouté une variable qui m'indique a peu près ou je suis dans le programme et quand l'IHM freeze, il semble que cela intervient lors du timeOut de la structure événement qui gère les commandes de ma face avant.

A priori je n'ai pas de boucle infinie et impossible de savoir ou le programme serait bloqué.

Lors de ce timeout je viens lire des données sur un driver moteur et sur un appareil de mesure pour afficher les valeurs sur des indicateurs de cette même face Avant.

Je précise que je viens de récupérer un IHM programmé en 2020 avec LABVIEW 2018 en Window 7 et que le problème n'apparaissait pas.

Aujourd'hui j'ai toujours LABVIEW 2018 mais je suis sur window 10.

Je précise également que cela n'arrive pas tout le temps. C'est assez aléatoire. Le logiciel peut fonctionner pendant plusieurs dizaines de minutes sans rencontrer le problème.

[thib_fr]

Peut être ajouter un fichier de log pour enregistrer le déroulement de l'étape timeout ?

[Loïc_fr]

Bonjour,

Même si le code source serait plus utile qu’un PNG pour investiguer plus en détail, on peut déjà relever plusieurs points importants à partir de ton image :

Beaucoup de logique métier dans la structure d’événements :
Tu interroges un instrument directement dans la case Timeout. C’est risqué, car toute attente ou blocage dans cette logique va directement geler l’interface utilisateur.
Je te recommande vivement de basculer vers un modèle Producteur / Consommateur (ou à minima une machine à états) où l’UI se contente de capter les événements et délègue le traitement à une autre boucle.

Utilisation intensive de nœuds de propriété :
Ces appels sont synchrones et bloquants, surtout sous Windows 10 où la gestion de la couche graphique est parfois plus capricieuse qu’en Windows 7.
Quand c’est possible, privilégie la mise à jour des contrôles via leurs terminaux.

Migration vers Windows 10 :
Tu mentionnes que ça fonctionnait sous Windows 7. Il est possible que certains drivers ou appels COM/ActiveX soient moins stables ou plus lents sous Windows 10.
Vérifie les versions des drivers, les droits d'accès, et les éventuelles mises à jour côté OS ou instruments.

Comportement aléatoire :
Ça peut indiquer un problème de synchronisation, de thread UI saturé, ou de communication instrument bloquante.

Loic

[mecatronicengineer]

Bonjour,

Merci à vous deux pour vos réponses.

Je vais travailler la dessus et je reviendrais vers vous.