Discussions au sujet de NI LabVIEW

annuler
Affichage des résultats de 
Rechercher plutôt 
Vouliez-vous dire : 

Problème d'acquisition de données


MartinRJ a écrit :

 

Le laser envoie les mesures en permanence et quand j'ai un front montant codeur j'enregistre mes mesure

 


Je ne pense pas que l’UDP soit équivalent à une acquisition sur déclenchement externe. Si lorsque tu as un front montant sur la voie A de l’encodeur tu fais la lecture d’une trame UDP, alors je pense que plus la vitesse de rotation sera rapide, et plus le décalage risque d’être important.

 

Je m’explique, tu notes que le laser transmet en permanence des trames de position, en UDP, à 500 Hz. Soit une trame toutes les 2ms. As-tu mesuré la vitesse de ta boucle logicielle ? Si l’exécution du code n’est pas au minimum de 2ms alors il y a une « mémorisation » de trames Ethernet (par la carte), et donc quand tu viens faire la lecture UDP de la position laser , alors tu vas décoder une ancienne trame, et donc mémoriser une ancienne position.

Non ? (en UDP si il y a un port d'écoute ouvert alors la carte réseau mémorise les trames qui arrive sur le port)

 

or lorsque je regarde ton code, il me semble que tu fais une acquisition numérique, avec attente sur un front montant du signal A de l’encodeur. Déjà tu n’as pas synchronisé la lecture UDP après la lecture numérique, mais en parallèle. Donc si tu reçois une trame UDP avant le trigger, elle sera « lue » dans le buffer de la carte réseau. Mais en fonction de la valeur de la locale « trigger », valeur de la boucle N-1, la trame sera décodée et mémorisée dans le registre à décalage ou perdue (cas False).

 

Donc par rapport à ton idée, il faudrait synchroniser la lecture UDP après le trigger numérique, donc gérer le flux de données LabVIEW pour forcer le code de lecture UDP à attendre l’exécution du code de lecture numérique. Par exemple pourquoi ne pas « chaîner » la gestion d’erreur ?

 

Mais si j’en reviens à ma première interrogation, cela ne synchronise toujours pas la lecture UDP (buffer de la carte réseau en pooling) avec une position précise.

banniere Luc Livre NXG Champion.png

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

0 Compliments
Message 11 sur 15
1 215 Visites

MartinRJ a écrit :

Cela veut dire que si on a un codeur avec 36000 points par tour on aurait 36000 acquisitions puisque l'acquisition attend un front montant du signal codeur (A+). Nous avons besoin d'enregistrer 180 par tour. C'est pour cela qu'avec le logiciel Unilink on peut modifier le nombre de points qu'on veut sur la sortie du variateur. (Sortie émulation codeur)


Non.

Dans mon idée, pour synchroniser une acquisition en fonction de position angulaire, il faudrait utiliser une carte compteur, et un déclenchement externe.

Tu câbles ton encodeur sur une carte compteur, qui génère un latch tous les N traits du codeur. Le latch numérique est utilisé pour le trigger externe du laser.

Dans cette idée, tu as réalisé l’acquisition pour N traits codeurs, et tu reçois une trame UDP uniquement sur l’acquisition.

 

Je ne sais pas si ton laser peut faire un déclenchement sur source externe.

Il te faut brancher ton encodeur sur une carte compteur, et pas faire un trigger numérique.

Dans cette idée tu peux être en retard, sur ta boucle logicielle, car c'est la carte réseau qui fait le buffer.

Non?

A+ luc

 

banniere Luc Livre NXG Champion.png

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

0 Compliments
Message 12 sur 15
1 215 Visites

Tout d'abord, merci pour ces élements de réponses.

 

Nous avons en effet mesuré la boucle logicielle pour vérifier que nous ne prenons pas de retard à ce niveau là. Voici le justificatif :

 

tfghfh.png

 

Il semblerait que se soit toujours la première valeur qui dépasse le seuil de 2ms, sinon le reste des valeurs se fait dans les temps. La perte d'une seule valeur à chaque foi serait donc compréhensible et surmontable. Cela dit nous en perdons plus.

 

Pour rappel du matériel utilisé, nous avons :

- Un profilomètre laser

- Un moteur avec codeur

- Une carte d'acquisition : NI USB 6501 (USB, 24-ch, 8.5 mA) ==> Ne peut-elle pas être utilisée en tant que carte compteur ?

 

Pour ce qui est de la synchronisation : Je ne pense pas que le problème vienne de là. Je m'explique, le laser nous envoie une trame en temps réel. Et c'est nous, qui lorsque nous souhaitons avoir des valeurs (à chaque °), prenons une "photo" à un degré connu de la trame obtenue.

J'ai peut-être mal compris vos explications sur la synchronisation, non ?

 

Dans ce cas, auriez-vous un exemple de synchronisation à nous présenter ?

 

 

0 Compliments
Message 13 sur 15
1 211 Visites

je ne sais pas comment vous avez mesuré le temps de 2ms mais

le point N°2 a un temps de 10ms

le point N°3 a un temps de 0ms

le point N°4 a un temps de 0ms

le point N°5 a un temps de 0ms

le point N°6 a un temps de 0ms

 

les points 3 à 6 sont étranges, non?

banniere Luc Livre NXG Champion.png

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

0 Compliments
Message 14 sur 15
1 203 Visites

sinon je ne connais pas "unilink", mais si je vous comprends il fait un peu le travail d'une carte compteur, avec un latch numérique configurable pour 90 trig/tour. (ok)

 

si je refais le calcul:

  • le moteur a une vitesse de 910 deg/s, avec unilink qui fait un latch 90 latch/tour. alors nous avons 360/(910*90) soit un latch trigger toutes les ~4.3ms (si je ne me trompe pas?)
  • il y a des trames UDP à 500 hz, soit à 2ms. soit 2 trames UDP pour ~1 latch

 

1) Il y a 2 trames UDP, pour 1 latch codeur. Comme la carte réseau va mettre dans son buffer toutes les trames UDP transmise, j'ai le sentiment qu'il n'y a plus de correlation entre l'attente du trigger et la lecture UDP (pas de flush buffer UDP).

 

2) Mon autre remarque vient du code, dans lequel la lecture du trigger (attente latch numérique) est en paralléle de la lecture UDP. Comme il y a des données UDP, alors la fonction LabVIEW va retourner "immédiatement" cette trame, alors que la fonction DAQmx lecture numérique va attendre le latch à ~4.3ms. Comme le code de traitement UDP utilise la locale "trigger" alors il va utiliser la valeur de la boucle N-1, et pas N.

 

Donc j'ai le sentiment qu'il y 2 effets, une dé-corrélation entre les 2 mesures, et un décalage lecture UDP qui se réalise avant le wait trigger.

 

banniere Luc Livre NXG Champion.png

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

0 Compliments
Message 15 sur 15
1 201 Visites