le 12-12-2024 04:54 AM
Bonjour à tous,
Après différents essais d'architecture logicielle pour piloter un banc de gaz synthétique, j'en suis venu à considérer l'architecture producteur/consommateur d'évènements via un exemple fourni par labview (2020). Le vi en question est joint à ce message; il comporte néanmoins des structures à diagrammes désactivés afin que le code puisse s'exécuter en l'absence des appareils pilotés par Flowbus sur port série (RDM bronkhorst).
Le principe de l'application est de piloter 3 régulateurs de débit (N2, O2, H2) afin de réaliser des mélanges à façon de O2 et/ou H2 dans une matrice N2.
L'utilisateur saisit le débit total à produire, la consigne en concentration volumique pour O2 et H2.
Lors de la modification d'une consigne, les événements utilisateurs (modification débit total, modH2, modO2) déclenchent le code adéquat dans la boucle consommateur. Jusque là tout va bien.
je veux cependant pouvoir visualiser dans le graphique déroulant, la valeur de consigne saisie ainsi que le retour d'informations du régulateur de débit (cela me permet de qualifier le décalage entre la consigne théorique et ce qui se passe en pratique). Ne sachant pas trop comment faire cette mise à jour régulière des informations en face-avant dans la boucle consommateur, j'ai ajouté une condition Timeout dans la boucle d'évènement => ça fonctionne mais est-ce vraiment la bonne option?
Autres interrogations:
Cette manière de procéder est-elle académique? Y-a-t-il mieux d'un point de vue algorithmique?
Information complémentaire : ce programme est une version simplifiée, à terme je dois pouvoir piloter entre 15 et 20 de ces appareils de manière simultanée, pouvoir lancer un enregistrement en continu à 1Hz des valeurs de consigne et des valeurs mesurées, etc etc ... Je me pose donc des questions sur l'opportunité d'utiliser un thread par appareil et donc de paralléliser l'exécution => mais comment envoyer les valeurs de consigne calculées dans la boucle consommateur aux threads des bons appareils (variable globale ? pipes ?) et que tout ça ne se téléscope pas?
merci de m'avoir lu
le 12-16-2024 09:28 AM
12-17-2024 08:06 AM - modifié 12-17-2024 08:10 AM
Ce n'est pas idéal mais c'est améliorable. Tu pourrais éventuellement déplacer ce qu'il y a dans ton timeout dans la MHL (message handler loop). De manière générale, il faut exploiter le cluster de données.
Exemple :
- 1 nouveau message StartAcq qui appelle un nouveau message Acq, et active un bool dans "données" (par exemple AcqActive)
- Le message Acq qui fait l'acquisition et s'appelle lui-même sous condition que AcqActive=true
- 1 nouveau message StopAcq qui met AcqActive à false.
Remarque : il faut que le message Acq contienne une attente de 10ms.
MAIS, dans la structure producteur-consomateur (EHL MHL en anglais), il est généralement recommandé d'éviter que les messages s'appellent eux-même. Juste pour info concernant les bonnes pratiques (que perso je ne respecte pas toujours).
Comme l'a dit Ben, je te conseille d'essayer DQMH. C'est très ressemblant en fait. Mais DQMH permet par script de créer une "helper loop". C'est généralement ce qui est utilisé dans ce genre de situation. Une helper loop est une boucle suplémentaire dédiée à une seule tâche. Typiquement une acquisition de signal.
Regarde ce lien intéressant pour illustrer mon propos :
https://hampel-soft.com/blog/dqmh-actors-self-messaging-or-helper-loops/
12-17-2024 08:15 AM - modifié 12-17-2024 08:17 AM
Information complémentaire : ce programme est une version simplifiée, à terme je dois pouvoir piloter entre 15 et 20 de ces appareils de manière simultanée, pouvoir lancer un enregistrement en continu à 1Hz des valeurs de consigne et des valeurs mesurées, etc etc ... Je me pose donc des questions sur l'opportunité d'utiliser un thread par appareil et donc de paralléliser l'exécution => mais comment envoyer les valeurs de consigne calculées dans la boucle consommateur aux threads des bons appareils (variable globale ? pipes ?) et que tout ça ne se téléscope pas?
Oui alors clairement il faut que tu utilises DQMH. Il s'agit de créer des modules autonomes clonables qui ont chacun leur thread dédié (clonable). Ton gain en temps et en arrachage de cheveux sera énorme.
Il faut juste se plonger dedans, mais la documentation est relativement complète.
Fais moi confiance, même si tu doutes.
le 12-17-2024 08:59 AM
Merci pour ces retours très riches en informations; je vais donc m'atteler à la documentation du Framework DQMH pour y transposer mon programme 👍