le 01-15-2016 07:13 AM
dans ton lien.....
Luc Desruelle | Mon profil | Mon blog LabVIEW | Auteur livre LabVIEW : Programmation et applications - G Web
Certified LabVIEW Architect (CLA) & Certified TestStand Developper (CTD) | LabVIEW Champion
MESULOG - LinkedIn site | NERYS - NERYS Group
| directeur CEO MESULOG
| CODIR - NERYS group
le 01-15-2016 07:13 AM
c'était rigolo 🙂 A+
Luc Desruelle | Mon profil | Mon blog LabVIEW | Auteur livre LabVIEW : Programmation et applications - G Web
Certified LabVIEW Architect (CLA) & Certified TestStand Developper (CTD) | LabVIEW Champion
MESULOG - LinkedIn site | NERYS - NERYS Group
| directeur CEO MESULOG
| CODIR - NERYS group
03-20-2016 08:16 PM - modifié 03-20-2016 08:27 PM
Un µ-nugget Le tunnel (simple) conditionnel.
bien utile pour "mémoriser" dans une boucle le fait que ce tunnel a reçu au moins une fois l'info "true".
à noter, que contrairement à la méthode du "SR+or" , l'info n'est pas disponible "dans" la boucle, mais uniquement en sortie.
(mais quand on a uniquement besoin de l'info en sortie, c'est pas mal, c'est plus simple, et ça tourne tip-top)
Je me doute bien que le code ci-dessus se solutionne uniquement avec la fonction "or array elements".
Il s'agit d'un code minimum pour "montrer". 😉
le 03-20-2016 11:24 PM
le timeout du forum m'oblige à reposter pour une petite ajoute :
le code ci-dessus permet de réaliser cette fonction dans une boucle ou le parallélisme a été activé.
En effet, dans une telle boucle (// activé) les SR sont interdits.
le 04-18-2016 05:59 PM
(à destination de ceux qui débutent ... pour les autres, autant leurs expliquer la porte AND)
objet : L'éternel problème des boucles multiples qui tournent en parallèle.
on doit :
- les cadencer (temporisation de boucle)
- pouvoir toutes les stopper d'une manière fiable et facile (surtout fiable !!)
- et le "must", avoir un arrêt instantané de toutes les boucles. (soit, lors de l'arrêt, pouvoir interrompre la tempo interne en cours.)
une façon toute simple (de faire tout ça) : utiliser un Notifier (avec lequel il n'y aura jamais de "Send Notification")
Dans chaque "slave" (de 1 à n), le "Wait on Notification" permet de cadencer la boucle via son timeout.
Le "Master" permet de stopper toutes les boucles en supprimant la Reference du Notifier.
Sans Reference, chaque "Wait on Notification" se retrouve en "erreur 1122" (Ref invalide) ...
suite à cette erreur, la tempo (Wait on Notification, qui est la tempo de boucle) est interrompue,
et l'erreur étant câblée sur le Terminal d'arrêt, la boucle stoppe instantanément.
(même si la tempo interne était de 3hr)
Il existe beaucoup de façons de solutionner le "problème" des boucles multiples en //.
avantages : Cette solution du Notifier permet de faire tout en même temps (et surtout, elle offre la possibilité d'interrompre la tempo de boucle)
Il n'existe pas 50 solutions qui permettent de cadencer et de stopper instantanément les boucles malgré leur tempo interne.
le 04-18-2016 07:44 PM
(suite et fin)
on peut même rendre les boucles totalement indépendantes.
x boucles sur le même BD, ou chaque boucle dans un VI distinct.
dans ce cas :
- un "Obtain Notifier" pour chaque boucle. (avec le même nom)
- pour le "Release Notifier", placer " force destroy? " à True.
Il n'est pas possible de déterminer quelle boucle créera le Notifier.
Le flux de données n'étant pas défini entre chacune des boucles, le séquencement exact est indéterminé.
Chaque "Obtain Notifier" cherchera la présence du Notifier ... s'il le trouve, il s'y connecte, s'il ne le trouve pas, il le crée.
Le Notifier sera crée ... par le 1er "Obtain Notifier qui sera exécuté.
Chaque "Obtain Notifier" (chaque boucle) obtiendra une Référence distincte pointant vers le même Notifier.
Mais avec "force destroy? = True", le "Release Notifier" détruira toutes les References associées au Notifier.
"force destry? = True" n'est pas nécessaire dans le cas précédent, car là, il n'y a qu'une et une seule Référence associée au Notifier créé.
04-19-2016 01:24 AM - modifié 04-19-2016 01:25 AM
Merci pour ce bel exemple.
Perso, je n'aime pas utiliser la génération d'une erreur de cette manière car cela déclenche en moi un sentiment "méthode brutale". Est-ce grave docteur ? Du coup, et même si cela alourdit un peu ton exemple et n'apporte rien à son fonctionnement, j'ajouterais l'envoi d'une notification d'arrêt avant de fermer la référence.
Juste un avis pour partager nos manières de faire et alimenter la discussion.
le 04-19-2016 02:48 AM
Personnellement, cela ne me choque pas, j'utilise depuis longtemps cette méthode avec des "queue", dnas le cadre de boucle producteur/consommateur.
A la destruction de la FIFO, cela stoppe toutes mes boucles Whiles, et je peux soit les cadencés, soit les bloqués avec un timeout à -1.
Ainsi pas de perte de charge CPU inutilement 🙂
le 04-19-2016 03:44 AM
Bonjour JB,
" j'ajouterais l'envoi d'une notification d'arrêt avant de fermer la référence "
(sous réserve d'avoir bien compris le fond de ton idée)
Donc ... en sortie du "Master", tu fais un "Send Notification" ... et pour terminer ce "Master", un "Release Notifier".
Tu envoies un "Send" et juste après tu fais un "Release" ... le "Release" détruira la (ou les) References et le Notifier lui-même.
Et tu comptes sur le "Send" (avant le "Release") pour stopper toutes les boucles_slave plus proprement.
Question :
Dans les boucles_slave, la Référence du Notifier sera-t-elle toujours valide pour recevoir la Notification qui vient d'être envoyée ?
Vu que tu as fermé cette Référence juste après le "Send".
J'ai testé en boucle ta proposition : (un "send" avant le "release")
comme ceci,
Si tout fonctionne bien, l'indicateur "While globale" doit s'incrémenter en continu, toutes les 2 sec. (temps du cycle)
Si la While "se bloque" ... c'est qu'il y a un soucis.
Je te laisse tester ce code. le compteur "While globale" arrivera-t-il jusque 10 ?
par contre, ceci fonctionne sans problème ... car le Notification "à le temps" d'arriver avant que la Référence ne soit détruite.
Avec le code (du bas) qui est en train de tourner chez moi, "While globale" est à 260 et ça continue.
(Par contre avec le code du dessus, je ne suis jamais arrivé à 5)
Qu'en penses-tu JB ?
04-20-2016 02:22 AM - modifié 04-20-2016 02:32 AM
Mon code ressemblerait à ceci :
L'arrêt me semble plus maîtrisé ainsi mais je suis bien conscient que cela fonctionne très bien sans envoyer une notification d'arrêt.
Le but est le partage des manières de faire.