Conception - multi boucle

[crocky]

Bonjour,

Je viens vers vous car j'ai besoin de conseils.

Dans la plupart de mes programmes, je dois réaliser des multiples boucles imbriquées les unes dans les autres (je vous joint un exemple)

J'utilise principalement des boucles WHILE et/ou FOR, avec des structures séquences.. A noter que dans l'exemple du dessus, j'ai plusieurs event avec des boucles imbriquées de la sorte.

Ce programme fonctionne, cependant, il est relativement difficile de le maintenir, ou bien de le faire évoluer.

Quelle est la meilleure façon d'aborder ces multiples boucles? Y a t'il une façon plus élégante et compréhensible de réaliser ces fonctions ?

Si vous avez besoins d'informations supplémentaires ou autres, n'hésitez pas.

Cordialement,

CrocKy

[CoHorte]

Vas voir du côté des machines à état "JKI State Machine" - des vidéos sont accessibles sur YouTube.

Cette machine à états évoluée devrait simplifier la structure de ton code.

[crocky]

Salut,

merci de ta réponse. Je vais aller regarder de plus prés..

Crocky

[ouadji]

le conseil de CoHorte est fondé et pertinent et ma remarque n'est en rien une critique à son méssage.

[petit énervement] 

Cependant, à chaque fois que l'on parle "machine à état" .... on revient constamment avec cette "histoire" de  "JKI State Machine".

Il faut tout de même noter que cette "JKI State Machine" n'est pas le pilier du monde ... et est avant tout une "machine à état" ... tout simplement.

... et qu'il est ... "également" ... possible de cabler une machine à état soi-même (la seule et unique façon de réellement apprendre)

sans pour autant se sentir obligé de passer inéluctablement par ce "prêt-à-coder" ... qui en soi, n'a rien de spécialement magique.

[/ petit énervement]  

[Desruelle_luc · Accepted solution]

Salut à tous et salut ouadji!!! Sympa de te lire, cela me permet de finir mon yoga... zen. 

Je suis un peu d'accord avec toi.

Même si j'aime beaucoup la machine à états de JKI, je pense que NI propose des modèles de projet, depuis LabVIEW 2012, qui sont indispensables à connaître, et même à utiliser.

Un modèle de projet avec machine à états (simple), évènementiel, ou plus évolué « QMH » et même le fameux « Actor Framework ».

Alors pour débuter, je conseille de commencer par les modéles de NI, très bien fait, très bien documenté, livré avec lvproj,….

J’avais écrit un truc dessus…

Partie 1/3 : Créer des modèles de projet personnalisés avec le gestionnaire de projet LabVIEW - Pour...

[…] Il est livré quelques modèles, ou Framework, avec LabVIEW, dont les fameux QMH (Queue Driven Message Handler) ou modèle Gestionnaire de messages dans une file d'attente (GMF) en Français et l’Actor Framework.

Même si l’Actor Framework est passionnant, il reste difficile à utiliser pour les non-spécialistes. Le Queue Driven Message Handler, plus connu sous le petit nom de QMH ou QDMH, est un incontournable qui est très simple d'utilisation.

La structure proposée par QMH repose sur un modèle éprouvé d’une structure producteur – consommateur, dans lequel :

Ø  (la boucle productrice) la structure évènementielle capture les actions utilisateurs, sur la face-avant, et produit le « message » via une FIFO

Ø  Le message est un cluster composé d’un état « case » et une donnée facultative Data de type variant

Ø  (la boucle consommatrice) la structure consommatrice, basée sur un modèle de machine à états, dépile sur apparition les données de la FIFO. Le message définit une transition vers l’état avec la donnée associée. Le "case" de la structure "Message" est une chaîne qui correspond à un des sous-diagrammes de la structure Condition . Par conséquent, la lecture du message provoque l'exécution du sous-diagramme correspondant de la structure Condition. Ce sous-diagramme est appelé diagramme de message car il correspond à un message.

[…]

j'avais écrit un autre truc sur les frameworks

VIII. Structure de programme (FrameWork)

d'autres liens indispensables de National Instruments sur la gestion de machine à états

Gestionnaire de messages dans une file d'attente

Mais je conseille d'utiliser le QMH... perso je l'utilise même pour un CLA....

A+ à tous

[crocky]

Bonjour,

Je vais effectivement commencer par bien maitriser les machines à états NI et je verrai ensuite pour les modéles QMH ou l'actor framework

Merci pour ces infos.

Je reviendrai vers vous si j'ai d'autres questions.

CrocKy

[Desruelle_luc]

salut, et avec plaisir! A+

[Rodéric_L]

On utilise beaucoup le QMH (version In House), et je le recommande vivement pour les gens qui ne dépassent pas le niveau Core III de LabVIEW. D'une manière générale, cumuler les avantages des Files d'attentes et des SMs (State Machines) est toujours une bonne idée

Pour ma part j'ai une architecture dérivée du MVC (Model View Controler) que j'utilise un peu partout à base d'events et de FIFOs et je ne suis jamais tombé sur un cas ou ça ne fonctionnait pas.

[Lablasc]

Bonjour à toutes et à tous,

Je sais que le sujet a été passé en résolu mais j'ai une question sur ce même sujet et sur vos messages concernant les QMH.

(Si jamais je dois créer un nouveau sujet, il n'y a pas de souci je le ferai. C'était pour ne pas créer un doublon inutile si cela n'était pas nécessaire.)

La notion de QMH revient très souvent sur le forums, et je me pose la question de savoir si elle est adaptée à "toute forme" de code.

Je m'explique : pour un code séquentiel, qui n'a besoin de collecter les paramètres utilisateur qu'en début de programme, je ne vois pas l'intérêt d'une telle structure (quand je dis ça ce n'est pas une critique et j'ai peut-être loupé quelque chose)

Par exemple, en ce moment je travaille sur un programme où les étapes seront toujours les mêmes :

- sélection des paramètres utilisateurs

- lancement des mesures

- ajustage si besoin

- nouvelles mesures si besoin

- enregistrement des données

A part pour collecter en permanence l'état du bouton stop en permanence, dans ce cas là je ne vois quel serait le plus d'une telle structure. 

Mais je suis peut-être complètement à coté de la plaque.

Je serai intéressé de lire vos retours par rapport à ce point-ci.