Changer la taille du buffer_LabVIEW

[KNouch]

Bonjour,

Je ne connais pas LabVIEW autant que je le souhaiterais c'est pourquoi j'ai besoin d'aides.

Voici mon problème :
Je dois acquérir des données en continu et les enregistrer dans des tableaux (tout en continu), et cela pendant une durée définie par l'utilisateur. Celui-ci entre également (sur la face avant) la fréquence d'échantillonnage du DAQ qu'il souhaite.
Lorsque je lance l'acquisition, le programme fonctionne plutôt bien mais au bout d'un moment j'ai ce message d'erreur
L'erreur -200279 s'est produite à : DAQmx Read (Analog 1D Wfm NChan NSamp).vi:2
Raisons possibles :
Tentative de lecture d'échantillons qui ne sont plus disponibles. L'échantillon demandé était auparavant disponible, mais il a été écrasé depuis.

Vous pouvez éventuellement corriger ce problème en augmentant la taille du buffer, en lisant des données plus fréquemment ou en spécifiant un nombre fixe d'échantillons à lire au lieu de lire tous les échantillons disponibles.

J'ai essayé de lire les données plus fréquemment mais l'erreur persiste.
Comme je dois lire les données en continu la dernière solution n'est pas possible. Il faut donc que j'augmente la taille du buffer...mais comment ?

Je ne sais pas comment ni quand changer la taille du buffer.
J'ai besoin de votre aide !

[losaque]

Salut,

Es tu aller voir ICI. Cela parle de ton problème et, de ce que j'ai vu, il y a des conseils pour les résoudre.

Mon premier message de 2012 est tombé sur toi alors Bonne Année à Tous

Losaque

[KNouch]

Merci pour le lien, j'ai pu voir quelque détail intéressants. Cependant mon problème n'est pas résolu.
Pour réaliser ce que montre l'exemple sur le lien il faut Générer le code NI-DAQmx de l'Assistant DAQ. En faisant cela, mes entrées et sorties sont décâblées et lorsque je les recâble le programme ne fonctionne plus comme avant, certaines fonctions ne sont pas effectuées comme la lecture des données de la carte sur des graphes déroulants...
Je ne comprends pas pourquoi...

Je suis ravie que ton premier message de 2012 s'adresse à moi ^^
Bonne année également

[losaque]

Re,

Le plus simple serais de nous mettre ton programme en pièce jointe pour que l'on vois ton comment tu as conçu ton code.

Pourquoi prend tu N échantillon ? Obligation/Nécessité ? Je n'ai jamais eu besoin de prendre N échantillons d'un coup mais j'essayerais de t'aider quand même.

Et merci pour tes vœux

Losaque

[KNouch]

Je ne prends pas N échantillons mais des échantillons en continu. Le nombre peut varier suivant la demande de l'utilisateur, c'est une contrainte. Il faut pouvoir suivre les courbes en direct.
Dans le fichier joint, l'Assistant DAQ n'est pas généré en code NI-DAQmx mais le programme fonctionne (jusqu'à environ 3 minutes, ce n'est pas suffisant à mes attentes.

[Nightmare Theater]

Bonjour KNouch,

J'ai regardé un peu ton programme et c'est assrez déstabilisant. C'est bein docummenté, agréable à lire, mais ca ne ressemble à de la programmation LabVIEW. Si je devais tenter un pronostique, je dirais que tu as une bonne maitrise du C mais n'a jamais suivi un cours de labVIEW.

Une notion importante à LabVIEW est le flot de donnée, or l'utilisation de variables n'y répond pas (ton programme ressemble aux premiers que j'ai réalisé sous labVIEW, avec les déclarations d'éléments de front panel au début et l'utilisation systématique des variaböles).

Pour en revenir à ton problème, deux choses me dérangent particulièrement dans ton programme (en dehors des variables): l'utilisation de VI Express pour tes mesures devrait être remplacé par des VIs "classiques" et l'écriture dans un fichier devrait être réalisée dans une boucle parallèle via la strcture dite "producer/consumer" (Principe, example).

Et j'en profite aussi pour vous souhaiter une bonne année à tous

Cordialement

[losaque]

Tout d'abord : Désolé pour le pavé et sans doute redondante avec Nighmare, mais je l'ai écrit en parallèle.

Je récapitule (dis moi si je trompe) :
Avec le code que tu viens de nous fournir, le programme commence normalement mais au bout de 3 minutes, tu as l'erreur -200279 qui apparait ? C'est bien ça ?


As tu essayé de diminuer la "Vitesse du simulateur (en Hz)" et le "Nombre de points souhaité, par cycle", afin de voir si l'erreur apparait toujours ? Si oui, le programme a-t-il duré plus/moins longtemps ?

As tu regarder ta charge processeur et RAM de ton PC au moment du plantage. Je dit ça parce que tes tableaux peuvent faire ralentir tout le système si ils contiennent beaucoup de données. Attention aux exécutions longues durées.

Sinon, félicitation pour la clarté de ton programme (code et aération du diagramme).
Par contre, prend l'habitude de toujours mettre une temporisation dans tes boucles While (5 ms suffise). Cela permet à ton processeur de respirer un peu et de pouvoir s'occuper des autres taches (Explication).

Quand tu génère le code Daqmx, il faut que tu branche ce qu'il y a dans le .zip en PJ entre ta sortie de boucle de lecture Daqmx-Lire et Désassembler des signaux.

Je viens de réaliser autre chose ATTENTION : tu utilises des variables locales tout en écrivant dans les terminaux dans une même séquence (Séquence 0 avec les tableaux finissant par (fixe diff). LabView utilise l'exécution parallèle, donc tu lis tes variables locales avant de les avoir remplies avec les bonnes valeurs. Je te conseil de mettre de ne pas utiliser de variable locale dans se cas et de tout remplacer par des fils.

Losaque

[KNouch]

Ton pronostique est à peu près bon "Nightmare Theater", on m'a beaucoup plus appris le C que LabVIEW et c'est bien pour cela que je cherche de l'aide.

Quand tu dis que j'utilise les variables à répétition, ça veut dire qu'il y a un moyen de l'éviter ?

Qu'appelles-tu "VIs classique" ?

Pour la structure dite "producer/consumer", je n'ai pas franchement saisi le principe

[Nightmare Theater]

Je vais essayer d'être concis car le temps me manque (rdv dans 20 mins):

déjà, pas de soucis pour l'aide, on est là pour ca. En parallèle je ne saurais que te conseiller de t'inscrire à un cours donné par NI (ild oit bien y avoir ca aussi en France, en Allemagne ils aides souvent à saisir les principes fondamentaux de la programmation LabVIEW).

Concernant les variables, il y a presque toujours un moyen des les éviter. L'idée de la programmation avec flot de donnée et que chaque entrée est reliée à une sortie. Si tu regardes les exemples livré avec LabVIEW, presque qucun n'utilise les variables. A là place d'écrire depuis un controle dans une variable puis de lire la variable pour travailler els données, il est possible de relier directement le control aux opérations sur données. L'utilisation de variables peut entrainer des complications comme l'a décrit losaque car tu n'a plus de controle sur ton flot de donnée ni sur l'ordre d'execution des instructions.

Ce que j'appelle "VI Classique" sont els VIs sans le pourtour bleu (appelés VI Express qui sont là théoriquement pour simplifier la vie des développeurs mais qui au final sont assez peu performants et beaucoup plus durs a débugger). Tu peux regarder les exemples pour l'acquisition de données DAQmx dans "LabVIEW Example Finder" pour avoir une idée de la marche à suivre.

L'idée de la producer/consumer est de différencier l'acquisition de données et leur sauvegarde (entre autre). En séparant les taches les plus lentes (comme l'ecriture des données sue le disque dur) et celles demandant le plus de précision (comme l'acquisition) il est possible de les faire fonctionner en parallèle et de manière asynchrone. La lecture de données ne sera pas ralentie par l'écriture des données sur le disque vu que les deux fonctionneront en parallèle et les données mesurées seront empaquetées dans un buffer (sur le pc celui-ci, pas sur la carte d'acquisition, donc plus facile a définir et potentiellement plus important) avant d'être retravaillées et sauvegardées.

Je sais pas si j'ai été clair mais je dois filer.

Bonne soirée à vous

[KNouch]

Merci à vous deux pour vos conseils.

J'ai remplacé toutes les variables locales par des fils quand c'était possible.
J'ai aussi simplifié et supprimé des tableaux qui n'étaient pas utiles.
Pour ce que j'ai à réaliser, les tableaux de moyenne ne sont utiles que lorsqu'on demande l'enregistrement donc j'ai changé leur emplacement (nouvelle version en PJ).

Tout aurait du fonctionner, ou plus ou moins...Mais en observant les performances du PC, il arrive très très rapidement à 100%
En désactivant un par un tableaux, graphes, et partie enregistrement, j'ai déduit que la construction des tableaux demande énormément "d'effort" au PC, comme vous me l'aviez suggéré.

Le problème est que j'ai besoin de toutes toutes toutes les données sortant de la carte d'acquisition.
Que puis-je faire pour soulager la charge processeur tout en gardant toutes les données ?

Je vais tester de remplacer l'Assistant DAQ par ses VIs classiques.
Je vous tiens au courant de l'évolution demain sûrement.

Cordialement

[KNouch]

J'ai oublié de répondre à certaines questions...

Losaque, tu ne te trompes pas, avec le premier code j'ai l'erreur -200279 au bout d'environ 3 minutes (++).
En revanche, je n'ai pas pensé dire que les conditions pour mes essais étaient 10 Hz (vitesse simulateur) et 100 points.
Sachant que la vitesse n'excèdera pas 25 Hz et le nombre de points 100.
Le temps peut atteindre plusieurs heures.

[losaque]

Salut,

Comme je te le disais un peu plus haut, tu va avoir un problème de stockage de données avec tes tableaux. A 2500 point par tableau, et comme tu as 5 tableaux, cela te fait 12500pt/s à écrire dans tes tableaux. Ça commence à faire beaucoup si on parle de durée de test pouvant aller jusqu’à plusieurs heures, déjà qu'au bout de 5 minute j'étais à 1 millions d'échantillons à traiter, sur chaque tableau.
Je viens de faire une petite simulation de ton acquisition (en simplifié) pour confirmer mes suppositions et je trouve le même problème que toi, mais au bout de 5-6 minutes (ça dépend des performance du PC).

Il va donc falloir que tu sauvegarde tes données au fur et à mesure de leurs acquisitions dans un fichier pour soulagé ta charge de processeur/RAM. Pour éviter que tes acquisition ne soient ralenties par cette sauvegarde, je te renvoi vers ce qu'a dit Nightmare : le Producteur / Consommateur. Pour une application de ce type, je ne vois pas d'autre solution.

Pour avoir la base du VI, tu peux utiliser Fichier => Nouveau => VI => A partir d'un modèle =>Structure => Modèle de conception => Producteur/Consommateur (Donnée).

[KNouch]

J'ai modifié tout mon programme en enlevant les tableaux qui finalement n'étaient pas nécessaires, ainsi que les variables locales remplacées par des fils connecteurs. Il fonctionne en effet beaucoup mieux.

Le Producteur/Consommateur par contre ne m'est pas franchement acquis, j'ai donc opté pour une autre solution : une Structure à séquences déroulées. Dans la première se fait l'acquisition des données et dans la suivante se fait l'enregistrement (sans condition) des données acquise, donc à chaque cycle.

Tout fonctionne à merveille ! Bon nombre de points acquis, bon nombre de fichier créé et pas de signal d'erreur.
Trop beau pour être vrai, ceci n'est valable que lorsque que la durée d'acquisition est prévu pour 1 minute (ou moins).
Dans le cas échéant : signal d'erreur au bout de 20 secondes, perte d'acquisition et création de fichier à chaque boucle... Bref, tout l'inverse...

Quelqu'un aurait-il une idée de la source du problème, une solution ..?

[losaque]

Salut,

Tu peux nous mettre la nouvelle version de ton programme stp ? Que l'on ait une petite idée de ta nouvelle organisation.

Merci d'avance,

Losaque

[KNouch]

Voici la nouvelle version.

En espérant que ça aide un peu