Discussions au sujet de NI LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

obligé de fermer LV

Solved!
Go to solution

Bonjour à tous,

 

Passionné d'assembleur, mais petit nouveau avec LV

Ceci-dit, LV est un outil absolument fabuleux!

 

J'ai remarqué ceci (voir mon fichier .vi ci-joint)

 

Dans cet exemple, totalement simpliste et absurde, Labview perd "la main" ...

impossible d'arrêter la séquence avec le bouton "abort execution".

Unique slution, couper l'alim du PC ou détruire LV dans le gestionnaire de tâches.

Oui, cet exemple est simpliste et aburde, en effet ... ici j'ai reproduit le "problème" dans une séquence "minimum".

Cependant, j'ai eu identiquement le même problème avec un diagramme beaucoup plus complexe.

 

Pour moi, il s'agit ici, non d'un bug, mais d'une lacune dans LV, cela ne devrait pas être possible.

Il n'est pas concevable avec un programme d'une telle envergure (labview) d'être dans l'impossibilité de reprendre la main,

et ce, qu'elles que soient les circonstances et/ou diagrammes.

 

C'est une question de principe, voir même une des bases dans le développement d'un produit.

Quelles que soient la situation, une application ne doit jamais perdre la main.

 

J'aurais aimé soumettre ce type de situation directement à NI, mais en tant qu'utilisateur d'une version d'évaluation,

je n'ai droit à aucun accès "direct" ... dommage.

 

voila, merci à tous, qu'en pensez-vous ?

 

 

 

 

Message 1 of 20
(4,686 Views)

Bonjour,

 

Effectivement ce ' petit problème ' m'arrive aussi de temps en temps.

Mais avant de passer par le gestionnaire des taches pour 'killer' labview, j'essaye toujours le 'CTRL + point'.

Dans votre exemple ca marche, il faut appuyer sur entrer, puis sur ctrl - point, et au bout de quelques essai (j'avoue faut être rapide Smiley Tongue) on arrive a arrêter la séquence !

 

Cdlt,

 

 

Message 2 of 20
(4,676 Views)

Le raccourci clavier de fab1 marche très bien.

Le problème n'est pas propre à LabVIEW à vrai dire...

Ouvrir une fenêtre "MODALE " car c'est ce qu'est la pop-up de votre exemple dans un thread tournant en boucle aura le même comportement en LabVIEW, Visual C++, Delphi ou autre ...

La fenêtre prendra la main sur tout le reste et rendra difficle l'utilisation des raccourcis clavier de l'IDE.

Slts

Pierre R...

Certified LabVIEW Developer
Message 3 of 20
(4,667 Views)

CTRL+point n'a aucun effet chez moi, même en étant "rapide".

 

Concernant la réponse de Mr pierreR ... oui, mais ...

Il s'agit en effet d'une fenêtre modale en boucle.

Cependant, en appuyant sur le bouton "ok" de cette fenêtre, et donc "entre deux fenêtres", labview reprend (une fraction de seconde) la main.

A ce moment, Il est tout a fait possible de détecter que l'on se trouve dans une boucle comportant une fenêtre modale,

et donc dans une situation où l'utilisateur n'a plus aucun contôle extérieur.

Dans ce cas, pourquoi ne pas afficher une fenêtre d'avertissement avec une possibilité d'interrompre cette boucle.

Dand le cas de Visual C++, Delphi, et autres ... il ne s'agit pas de la même situation.

On exécute un code compilé et rien, en arrière plan, entre deux fenêtres, ne reprend la main.

Labview peut, lui, aller un pas plus loin, et être configuré pour éviter ce type de "cul de sac".

Je persiste (et signe), il n'est pas concevable qu'un outil de développement comme Labview se retrouve dans une situation ou l'utilisateur doive jongler avec le clavier, voir killer le processus, pour sortir d'une impasse.

 

Il est tout a fait possible de trouver une solution élégante à cela.

L'utilisateur ne craindrait plus de créer par distraction ou par erreur, une boucle infinie comportant une fenêtre modale.

Je demande aux Développeurs de Labview d'y réfléchir, merci.

 

 

0 Kudos
Message 4 of 20
(4,650 Views)

On pourrait aussi demander aux fabricants de marteaux de prévoir un système pour qu'on ne puisse pas se taper sur les doigts avec !

Cordialement,


Micaël DA SILVA
Message 5 of 20
(4,637 Views)

Bonjour,

 

J'ajoute également qu'en principe toute boucle doit être "cadencée" pour éviter de puiser toutes les ressources. Dans ce cas là il reste plus de temps pour killer la boucle Smiley Very Happy

 

J'ai mis en pièce jointe un vi qui peut s'averer utile pour killer un vi LabVIEW. Il ne fonctionnera pas dans votre cas car ce sous-vi garde la priorité, mais dans beaucoup de cas il fonctionne dès que c'est une fenetre que l'on a réalisée et qui est modale.

 

Pour terminer avec un avis personnel, je ne pense pas que ce soit au langage d'éviter une boucle infinie mais bien au dévelpopeur Smiley Wink

Cordialement,

Simon D.
CLA | Certified LabVIEW Architect
CTA | Certified TestStand Architect
Message 6 of 20
(4,631 Views)

from Micael_

"On pourrait aussi demander aux fabricants de marteaux de prévoir un système pour qu'on ne puisse pas se taper sur les doigts avec!"

 

Dans le même ordre d'idées, les "probes" labview sont inutiles, ainsi que le "step by step",

et plus généralement toute forme de debugger ou d'assistance au développement est inutile.

 

from SimonD

je ne pense pas que ce soit au langage d'éviter une boucle infinie mais bien au dévelpopeur

 

Parfaitement d'accord avec vous.

Cependant il ne s'agit pas ici d'un problème de boucle infinie.

Même avec un bouton "stop" sur le boucle "While", cela n'y changerait rien.

Le problème est que vous n'avez plus accès aux commandes de Labview.

 

Mais au delà de toutes ces remarques, la mienne était beaucoup plus globale.

Dans mon cas de figure, je ne suis pas en train d'exécuter le fichier ".exe" du projet,

mais bien une simple "maquette" du projet, en cours d'éléboration, et ce dans un environnement

sécurisé, d'aide et d'assistance au développement ... Labview.

Et dans la mesure ou je me retrouve bloqué, forcé de rebooter le PC pour sortir d'une impasse,

là ... j'estime que Labview a échoué dans sa fonction ... celle de m'aider.

Tout ceci, quelle que soit mon erreur, car c'est justement là le but d'un environnement

de développement ... pouvoir faire des erreurs, et pouvoir les corriger.

Ce n'est pas un bug au sens du code, mais c'est un bug au sens de la fonction globale proposée par Labview.

 

Il ne s'agit pas ici d'une critique négative, labview est un outil fabuleux.

C'est juste le constat d'une petite imperfection, d'une amélioration possible.

Il y a moyen d'implémenter une solution élégante à ce problème.

 

 

 

 

0 Kudos
Message 7 of 20
(4,615 Views)

Bonjour,

 

En C#, quand on fait "pareil" on a bien la main sur le compilateur / débuggeur. D'après moi, cela vient du fait que Visual Studio créé un nouveau processus et que donc celui-ci n'est pas lié au processus du débuggeur.

 

Alors qu'en LabVIEW il me semble que cela est organisé en threads (UI Thread notamment) qui sont tous regroupés dans la même processus, ce qui fait qu'il faut arrêter tout le processus pour de nouveau obtenir la main.

 

Après avant de critiquer purement ce "défaut" il faut se mettre à la place des développeurs (Jeff Kodosky si tu nous lis :D) et se demander pourquoi ils ont procédés de cette manière.

 

LabVIEW est basé sur le framework Qt et permet une inter-opérabilité entre les différents OS dans devoir modifier de façon significative le code pour les différents OS cibles. Cela vient peut etre de la.

 

Quand vous cabler deux icones entre elles, il y'a tout un procédé de gestion de la mémoire qui est est mis en place lors de l'exécution. Donc je pense que les ingénieurs n'ont pas choisi cela au hasard et ont surement du penser à ce "bug".

 

Ce n'est que mon avis personnel 😉

 

Voici un code "équivalent" en C# :

 

using System;
using System.Windows.Forms;

namespace WindowsFormsApplication1
{
    static class Program
    {
        [STAThread]
        static void Main()
        {
            while(true)
            {
                MessageBox.Show("Dans l'os","ok");
            }
        }
    }
}

 

Da Helmut
Voir le profil de Maxime M. sur LinkedIn - View Maxime M.'s profile on LinkedIn
Message 8 of 20
(4,603 Views)

merci Helmut O'Brian pour cette "vue" différente ... très intéressant.

 

Ceci étant dit, je ne "critique pas purement ... ", (bêtement)

Une fois de plus, Labview est un outil absolument remarquable.

 

Mais ...

si je place une fenêtre modale dans une boucle,

je suis bon pour rebooter mon PC.

Pour un produit de cette envergure, cela fait tache.

 

Une application pour laquelle il existe des situations (ne fusse qu'une seule)

où la seule solution est de killer l'application elle-même.

Désolé, mais en tant que développeur, ça me fait froid dans le dos.

C'est une question de principes (d'éthique) de développement.

 

Je ne peux imaginer que les ingénieurs/développeurs de labview puissent être au fait de ce cas de figure

sans y apporter une solution. Vendre un produit plusieurs milliers d'euros/dollars, en se disant que l'utilisateur

devra probablement rebooter son PC de temps en temps ... mais bon, c'est pas grave, ça n'arrivera pas souvent,

et de toute façon "on" ne sait rien y faire.

 

Je vous vois sourire ... moi aussi. Smiley Wink

 

 

0 Kudos
Message 9 of 20
(4,590 Views)
Solution
Accepted by ouadji

Non mais là on frise le Troll !!! 🙂

 

Primo un tel cas ne devrais pas se produire, sauf erreur de développment.

 

Secundo : La diférence entre LabVIEW et les autres environnement est l'extrême imbrication de l'environnement de développement/debugger avec le VI.

 

Quand à ton problème une solution existe bien et elle est tres fonctionnelle :

Maintenir Ctrl+Shift+. enfoncé en cliquant sur le bouton de la pop-up et le VI s'arrete bien tout seul pas besoin de rebooter ... Donc perso je ne vois pas de problème.

Cela fait 10 ans maintenant que je développe en LabVIEW et en toute honneteté je n'ai jamais été confronté à ton problème.

 

L'idéal etant bien sûr de développer un IDE capable de détecter les possibles erreurs de programmation du développeur avant même qu'il les fasse...

 

LabVIEW à bien de bugs et autres imperfections là n'est pas la question... mais celle que tu remontes n'en est pas une... il faut savoir se servir des raccourcis clavier de LabVIEW et tout se passe sans problème...

 

 

Pierre R...

Certified LabVIEW Developer
Message 10 of 20
(4,570 Views)