problème d'éxécution de multi-thread sous labview

[bastien049]

bonjour,

2 applications (.exe) sont lancées en parallèle ( fonctionnant en même temps)

1 contenant une fonction trigger avec un paramètre de declenchement sur seuil avec un delai d'attente de 30s.

1 contient une boucle testant des boutons en façade (cadencé a 100ms).

le but est de commander une charge via l'application 2 et de mesurer et de détecter le niveau sur la voie afin de déclencher une acquisition des données.

Le probléme est le suivant :

lorsque l'application contenant la fonction trigger est en attente de declenchement alors toute modification des états des boutons de la deuxième application ne sont pas pris en compte. donc la charge n'est pas commandée et le seuil jamais atteint.

peut on remedier a ce problème ?

peut on définir un ordre de priorité dans l'execution de deux applications distinctes (aucun lien entre les applications (.exe), aucun appel en commun) ?

toutes pistes afin de résoudre se problèmes sont les bienvenues, merci

[bastien049]

est-ce que quelq'un a une ID sur la question ?

pour ma part je pense que le fait que l'on soit en attente de déclenchement bloque le processus LABVIEW mais g pas de solution a l'heure actuelle (sinon je ne posterai pas me diriez vous)

en tout cas merci de jeter un coup d'oeil.

[bastien049]

bon je vois que ma question intéresse énormément de monde mais j'ai vraiment besoin d'une réponse ou d'un début de piste. je suis technicien et j'ai un peu d'expèrience sous labview mais comme vous devez l'avoir vécu aussi, quand on a un problème d'ordre soft et que l'on nous donne pas les moyens alors t'es tout seul au monde.

donc je vous resume de nouveau le problème :

je fais l'acquisition d'un signal sur une carte d'acqui PC6110, sur laquelle je veux détecter un seuil de déclenchement. ceci est fait par une 1ere application. tandis qu'une deuxieme application commande une charge via une carte DIO. l'événement a détecté est en faite un seuil de consommation de courant qui est la résultante de la commande de la charge.

le souci :

c que lorsque je lance l'acquisition du signal et que je suis en attente de l'événement, je ne peux plus commander ma charge via la deuxième application car l'appui sur les boutons en face avant ne sont pas pris en compte. l'impression que j'en ai est que le processus est bloquer tant que le VI  "AI Start" n'a pas détecter l'événement ou que le time out ne soit actif.

je pense que c un problème intéressant qui peut mettre en évidence une limite a l'utilisation de labview.

merci pour votre support. 

[nfk]

En faite de ce que j'ai compris tu a 2 appli qui utilise le même périphérique, a priori c'est une question d'ordre je pense à l'utilisation de sémaphore pour donner accés soit à l'une soit à l'autre appli, mais vu que c'est  deux appli différente débutant sur labview, pour communiquer entre 2 appli je vois pas comment on peu faire.

De mon côté pour le moment c'est plus simple j'utilise une appli et je voudrais utilisé un thread pour éxcéuté uen boucle en parallèle. mais j'ai  pas trouvé les fonction threads dans  labview. Si tu peu m'aider....

@+

 

Message Edité par nfk le 04-12-2006 04:19 AM

[nfk]

En cherchant pour moi j'ai peut-être trouvé ta réponse dans l'aide de labview "multitâche dans Labview"

---

Utilisation des systèmes d'exécution dans les applications multithread

Les applications multithread comportent six systèmes d'exécution que vous pouvez assigner en sélectionnant Fichier»Propriétés du VI, puis Exécution dans la boîte de dialogue Propriétés du VI. Vous pouvez sélectionner les systèmes d'exécution suivants :

• interface utilisateur — Gère l'interface utilisateur. Son comportement est le même que ce soit pour les applications multithread que pour les applications monothread. Les VIs peuvent s'exécuter sur le thread d'interface utilisateur, mais le système d'exécution alterne entre le multitâche coopératif et les réponses aux événements de l'interface utilisateur.
• standard — S'exécute dans d'autres threads que l'interface utilisateur.
• E/S d'instruments — Empêche VISA, GPIB et E/S série d'interférer avec les autres VIs.
• acquisition de données — Empêche l'acquisition de données d'interférer avec les autres VIs.
• autre 1 et autre 2 — Disponibles si certaines tâches de l'application requièrent leur propre thread.
• identique à l'appelant — Pour les sous-VIs, s'exécute dans le même système d'exécution que le VI qui a appelé le sous-VI.

---

 

[Lunik]

J'ai pas l'impression que les options dans  systèmes d'exécution dans les applications multithread ne change jamais le comportement de l'application  quelle que soit l'option choisi