Où sauvegarder lors d'une acquisition

[kriss00]

Bonjour à tous,

Alors voila une question qui me taraude depuis pas mal de temps sur l'acquisition DaqMx et la sauvegarde des données.

Un besoin récurrent de pas mal de gens dans le monde des mesures physiques est d'utiliser excel comme gestionnaire de données. Hors depuis labview, l'accès n'est pas idéal.

Je travail sur un vi relativement imposant dans lequel je dois faire différentes acquisitions depuis un compactDaq. Pour la sauvegarde des données, on m'a demandé essayer de le faire avec excel.

Je vais donc essayé de résumer tout ca en 3 questions :

 - Quelle est la meilleur solution pour faire la sauvegarde des données d'une acquisition qui va à 0.5s max sans perte de données (sauvegarde à chaque écriture) et sans perte du référenciel temporel, ce que j'ai eu (Le sous-Vi qui enregistre dans excel à chaque boucle devient trop lent si le pc rame pour x raisons et l'on passe la durée entre les échantillons)  ???

 - Ce que j'aime dans excel, c'est la visibilité des données, avez vous trouvé une autre alternative à un pauvre fichier texte ??? ou suis-je obligé d'enregistre dans fichier texte et de tout transferer dans excel à la fin de l'acquisition ??

En gros je veux arriver à faire une acquisition parfaitement fiable au niveau de l'acquisition des données et avoir dans mon fichier la typologie tout simple :

Temps      Voie 1

00:00:01     32

Et que je sois sur que le "32" est bien était pris à 00:00:01 ! car j'ai l'impression des fois qu'il écrit un peu quand il a le temps.

Merci d'avance et dsl pour ce message un peu long ! j'ai besoin de conseil !

[Phil_IngeniaSystem]

Bonjour,

Je te conseille dans un premier temps de bien séparer ton acquisition de ta sauvegarde, c'est à dire de faire ton acquisition dans une boucle et de faire ta sauvegarde dans une autre. Utilise la structure "producteur/Consommateur", avec les files d'attentes tu stockes tes mesures et la boucle consommateur vient vider la file d'attente et écrire tes mesures dans ton fichier. Celà te permet de faire tes acquisitions sans que la sauvegarde ne pose problème.

Pour le fichier Excel, il y a le toolkit NI Report generation toolkit for Microsoft Office qui fonctionne très bien et qui est très simple d'utilisation.

[Olivier_L]

Bonjour,

Effectivement, comme le dis philippe, il vaut mieux différentier l'acquisition de l'écriture des données pour ne pas avoir de ralentissement de l'acquisition.

Deuxièmement, nécessitez-vous d'utiliser chaque point acquis, ou pouvez-vous faire une acquisition bufferisée? Il faut savoir que dans le cas d'une acquisition bufferisée, ce n'est pas le PC qui décidera quand mesurer le point, mais l'horloge de la carte, du coup vous n'avez plus à vous soucier de savoir si le point est acquis au bon moment, car il l'est!!

Ensuite, pour l'enregistrement de fichier, utilisez-vous le toolkit Report Generation, ou l'activeX Excel pour écrire vos données? Si c'est le cas, il est alors tout à fait possible que vous observiez des lenteurs à l'utilisation active.

Il faut comprendre qu'un fichier excel est un simple fichier texte, dont les données sont séparées par une virgule ou une tabulation (en fonction du type de fichier). Il est alors très simple d'utiliser les fonctions d'écriture sur fichier texte (ascii) avec le formattage et la mise en page qui va bien. Vous n'aurez ensuite qu'à l'ouvrir avec Excel à la fin de votre programme pour une question d'affchage.

Cordialement,

[kriss00]

Merci à vous deux pour vos réponse, et un merci tout particulier à Phil pour l'architecture Produteur Consommateur que je connaissais mais n'avait jamais utilisé donc pas pensé à l'utiliser. Je l'ai mis en oeuvre et ca va déjà beaucoup mieux !

A Olivier :

j'ai besoin de conseil alors voila ce que je veux faire :  L'utilisateur choisi la durée entre chaque point d'acquisition (environ tout les 0.5s à plusieurs heures). Ensuite il aura un visuel s'il le souhaite du fichier qui ce rempli avec le temps et la valeure associée. Donc tout simple !

J'ai utilisé pour cela :

 - la tipologie habituelle voie AI tension par exemple puis horloge d'échantilonnage en mode continu et avec un échantillons

 - Ensuite avant l'entrée en la boucle while je lance la tâche et dedans je fais l'acquisition d'un tableau de waveform sur N voies et un échantillons sur chaque voies

La partie ActiveX marche bien même si elle peut des fois faire quelques ralentissement.

Ce que tu dit à propos d'une acquisition bufférisé m'intéresse beaucoup. Peux tu développer ? Savoir si ce que je fais est ce qu'il faut faire ! et si non comment faire ta méthode ??

Labview est formidable car on peut vite faire quelque chose mais aussi faire vite n'importe quoi !

Merci d'avance

[Olivier_L]

Bonjour,

Si tu utilises le mode d'acquisition continue, c'est alors que tu utilises la méthode que j'ai appelé bufferisé. Celle non bufferisé etant "Un point, sur demande".

En revanche, je te conseille de définir un buffeur de plus d'un point sur la fonction de cadencement (entrée échantillons par voie), car de cette manière, le driver va créer un buffeur de réception des acquisitions faites par la carte. Dans le cas où tu voudrais aller un peu plus vite, le buffeur sera à même de gérer l'arrivée des points.

Ce qui n'empêche pas de ne lire qu'un point lors de l'appel de la fonction DAQmx Lire.vi

Un autre conseil, c'est par rapport au timeout que tu utilises pour la fonction de lecture. Tu as dit que le temps entre 2 points peut parfois être très long. Or, si tu mets un tiemout trop court, la fonction te retournera une erreur, mais si tu le mets très long, c'est ton programme qui risque de ne pas réagir tant qu'un point n'est pas disponible. Cela peut être très gênant si tu es obligé d'attendre 1h entre le moment ou tu appuyes sur ton bouton stop de ta boucle while, et le moment où ta fonction s'arrête et te permet de réellement quitter la boucle.

Pour pallier à ce problème, je te conseille d'utiliser un petit Timeout, mais de venir tester le code d'erreur -200284 (equivalent au timeout) et de ne pas utiliser la donnée issue de la fonction de lecture lorsque cette ereeur apparait, mais de néanmoins continuer à exécuter ta boucle.

Ca, plus la structure producteur/consommateur...je pense que tu es sur la bonne voie.

Cordialement,

[kriss00]

Merci pour ta réponse.

Effectivement je fais comme ca. Tout me semble ok mais j'ai une dernière question qui n'a rien à voir :

J'ai beau utiliser des sous-vi à la pele ou des clusters, mon programme est quand même gros. Je voudrai bien d'ailleurs mettre des parties de mon acquisition en sousvi mais je vois pas comment faire à cause des variables, noeud de propriété...etc

Y a t-il d'autres manière ? des astuces ?

[Phil_IngeniaSystem]

Bonjour,

Utilise les références de tes controles ou indicateurs pour les mettre à jour dans tes sous-vi. Voir ci-joint un exemple simple

Bon courage

[kriss00]

Merci c'est effectivement une astuce de plus.

Une toute dernière question : le fait de faire des sous-Vi permet une meilleur lisibilité du diagramme mais quel est l'impact sur le programme en lui même ? Car avec les sous-vi on peut utiliser plus de noeuds de propriété ou variable ou encore les références de contrpoles et d'indicateurs comme tu le dit. Et le programme doit gérer l'appel d'un autre vi.

[Phil_IngeniaSystem]

Ci-joint la copie de l'aide LV :

What is the importance of using subVIs?

Large block diagrams are hard to read and maintain. Identifying commonly reusable snippets of code and replacing them with a subVI saves space and simplifies future updates to the code, because you will only have to edit the subVI once, instead of each individual instance. Also, if you break the VI into subVIs, the code for the top-level VI is smaller, and the code and data of the subVIs reside in memory. In some cases, you might see lower run-time memory usage.