Discussions au sujet de NI LabVIEW
Diviser et séparer le tabeau
Résolu !
kudo pour ML927 ... pour avoir eu une idée "en dehors des sentiers battus".
Le kudo, c'est aussi pour avoir aligné les constantes "8" et "60" dans son Diagram (voir son snippet)
Aligner les constantes pour faire pile-poil propre, au pixel près ... woaw, ça c'est la classe !!! 
Merci Ouadji. Je suis malheureusement (pour moi) un peu maniaque sur les alignements ! 🙂
Note qu'il y a un raccourci clavier (CTRL + MAJ + A) qui permet de faire cet alignement très facilement.
Je ne comprends pas vraiment l'utilité de ce sous-VI (beau ou pas, d'ailleurs). Il ne sert à rien de découper un tableau pour le plaisir : ça mange de la mémoire (Delete from Array fait des copies en mémoire, sans parler des buffers pour chaque Voie_n)), ça fait du code en plus, des fils de liaison en plus (beaucoup!).
Je me poserais la question plutôt la question "Et après ?". Ces données, on va bien en faire quelque chose. Du coup, je pencherais pour une solution simple comme celle-ci
La primitive Array Subset ne fait pas de copie en mémoire. Ca prend infiniment moins de place. Et on garde un seul fil de liaison, qui adresse chaque "voie" grâce à la boucle For.
À moins que je n'aie vraiment pas compris quelque chose ^^
--Eric
Si Eric, pas d'angoisse, tu as parfaitement compris 
Utiliser une boucle ou générer n sorties // (avec ensuite les traitements // qui en découlent) ... j'ai directement souligné qu'il s'agissait là d'un choix à faire dès le départ. GSXR semble avoir fait son choix (suite, je suppose, à des contraintes qu'il est probablement seul à connaître) ... " non, je veux en sortie ces 8 tableaux (en réalité il y en a 16) ". A partir de là, le débat se referme. Mais il est vrai que la solution d'Eric est particulièrement simple et efficace (élégante même avec ce "Array Subset"). Mais cette solution faisait partie de l'arborescence "boucle", qui dès le départ a été mise off.
C'est clair, perso, je ne me suis pas posé plus de question que ça, j'ai juste répondu comme Ouadji à la question de base!
Mais j'admets que bien souvent, on devrait se demandé l'utilité de certaines démarches de programmation qui pourraient souvent trouver meilleures réponses, meilleurs codes moyennant de connaitre le but recherché par le demandeur
Bonjour à tous,
Merci pour toutes ces infos et je pensais que c'était clos ce ticket. Mais je vais essayer de vous expliquer pourquoi diviser en 8 (en réalité 16) : nous avons une carte maison qui génère un front montant périodique (160 Hz environ) et chaque voie a une période de 10 Hz(160/16) sur chaque voie on branche une thermistance. J'effectue une acquisition avec une carte DAQ et ensuite je détecte le front montant de là je sépare les voies et dans une voie il y a des données dans mon cas il y a 60 valeurs (comme elle n'est pas top notre carte il y a des dérives : j'enlève 5 valeurs au début et la fin de chaque tableau, et le chiffre 60 varie aussi chaque acquisition parfois c'est du 58, 59, 60, 61). Ensuite j'effectue une moyenne dont à chaque acquisition j'ai 16 valeurs et j'affiche sur un graphe mais bien sûr je conserve les données brutes pour l'analyse des résultats des mesures. Désolé, je ne peux donner un kudo à un sujet mais en réalité vous le méritez tous. Voilà j'espère vous donner la raison du comment et du pourquoi.
"Question ouverte (à GSXR, mais pas que ) - si demain il faut 64 voies, comment on gère ? 64 sous-tableaux ?" : 64 fois 0, je pose 0 et retiens rien, le compte est bon Eric, no worry
J'ai lu et je pense avoir compris (la ponctuation et le choix de certains mots ne rendent pas la compréhension triviale). Ceci dit, je ne vois rien dans cette explication qui interdirait l'utilisation des boucles et la nécessité absolue d'avoir des flux de données indépendants pour chaque voies. L'affichage sur un graphe, l'analyse et le traitement des données, tout ceci peut parfaitement s'accommoder d'une approche_boucle. Pire, il s'agit du sens même de l'existence des boucles. Si, en l'occurrence, il n'était pas possible de les utiliser, alors à quoi serve-t-elle ? Bien entendu, en Programmation (comme en toutes choses) il n'est jamais "obligatoire" d'utiliser telle ou telle approche. Restons donc respectueux du chois de chacun. (mais ...)
