Discussion :

[kipkoolos]

Bonjour,

Je suis stagiaire et débutant cette année sur LabVIEW, et pour faire simple je doit envoyé une commande pour une phase donné d'un signal sinusoïdale de 50hz. L'image ci-jointe montre ce que cela doit donner.

Personne dans mon entreprise ne connait LabVIEW, et je trouve le projet super inintéressant par tout les moyens même si je n'y connait pas grand chose j'y arriverait ...

Actuellement j'ai un module U2121 qui est un module d'acquisition Analogique (doc ci-jointe) qui me donne le signal carré de l'image.

En entrée j'ai un signal sinusoïdal de 50hz. La liaison est en USB. L'image jointe montre l'exemple pour une phase donner de PI (ou 90°).

J'aimerais savoir si il et possible de traité le signal pour avoir une précision minimal de 500 us de décalage de la commande par rapport à la phase demandé?

Et comment le faire, si vous avez des idées qui vous passe par la tête, lâchez tout je prends ?

Mon idée de départ était de me servir de la phase 0 qui correspond du coup aux fronts, et d'attendre le temps donner par la phase demandé par exemple pour PI (ou 90°) et pour un signal de 50hz : 1/50 = 0,02s->période ; 0,02/4 =0,005s période de phase et donc temps d'attente après un front montant pour avoir la phase PI et pouvoir envoyé la commande.

Mon gros problème c'est que cela me donne à l’oscilloscope des temps complétement faux et aléatoire alors que la simulation sur LabVIEW est correct.

Est-ce parce que le module U2121 ne suffit pas pour géré un décalage de 500us max ?

Merci d'avance pour la lecture de ce sujet et les réponses qui seront données.

[losaque]

Salut,

Tu as un VI qui te permet de détecter la phase d'un signal : Traitement du signal => Mesure sur WaveForm => Extraire des informations monotons. En faisant la comparaison des phases de tes deux signaux, tu trouveras facilement ce que tu cherche.

Pour ce qui est des 500µs, je ne me suis jamais penché sur ce problème, mais je crois savoir que windows est très loin d'être aussi précis/rapide.

Losaque

[kipkoolos]

Merci de ta réponse losaque.

J'ai oublié de précisé que l'entreprise n'avait acheté que la version de Base de Labview aucun module complémentaire mais si ta fonction est utilisable pour des temps de 500µs ou inférieur sur Windows Seven alors le financement pourra ce faire pour le module en question.

Cela me parait bizard de ne pas pouvoir descendre en dessous de la millisecondes sur Windows ou alors je n'ai pas très bien compris comment fonctionne Windows, ce qui est très probable !

[Nightmare Theater]

Merci de ta réponse losaque.

J'ai oublié de précisé que l'entreprise n'avait acheté que la version de Base de Labview aucun module complémentaire mais si ta fonction est utilisable pour des temps de 500µs ou inférieur sur Windows Seven alors le financement pourra ce faire pour le module en question.

Cela me parait bizard de ne pas pouvoir descendre en dessous de la millisecondes sur Windows ou alors je n'ai pas très bien compris comment fonctionne Windows, ce qui est très probable !

Pour faire simple, windows n'est pas un systeme deterministe: le systeme d'exploitation garde pour lui les plus hauts niveaux de priorite d'interruption. Par ailleurs, il se gave en les utilisant.

Du coup, ton processeur peux te permettre d'avoir des frequences d'execution en theorie. En pratique, selon l'humeur, les taches de fond relaisees par windows, les potentielles interruptions de l'OS, les reallocations memoires des autres applications... etc. tes 500 us pourront tout aussi bien etre 400us (rarement mais ca arrive) que 5 ou 10ms (2000% d'erreur ).

C#est pour ca aussi que sous windows, LabVIEW n'offre pas de temporisation plus rapide que 1ms: Ca n'a pas de sens (avec un systeme d'exploitation on a acces a des tempos de l'ordre de la milliseconds et sur une carte FPGA de l'ordre de quelques nanosecondes).

En bref, sous windows, pour avoir un minimum de precision dans ses temporisation, ce n'est viable qu'a partir de 5 ou 10 ms.

J'espere que ca repond a ta question concernant le poste de losaque.

[kipkoolos]

Merci Nightmare Theater pour tes explications, effectivement elle m'ont aidé à mieux cibler le problème enfin je pense.

Donc mon problème est maintenant, trouver une solution pour arriver à un temps de 500us ou moins mais pas dans le cahier des charges :

Si j'ai bien compris j'ai deux solutions :
- Changer d'OS pour un RT tel que Widows CE, compliqué à mettre en place dans l'entreprise ou je suis l'informatique est très contrôlé et protégé.
De plus si je change d'OS est-ce que LabVIEW pourra fonctionner dessus ?

- Ou changer de module d'acquisition pour un module programmable avec un FPGA, cette solution me paraît la plus simple mais du coup quel module DAQ Choisir sachant que je pourrais avoir jusqu'à 500€ d'achat je pense.

Et derrière faudra-t-il le module Real-Time ? Si oui sont coût est de + 600€ WouHouuuu trop chers !
Et faut-il aussi le module FPGA : +600€ aussi encore WouHouuu encore plus chers !!

Rassurer moi il y a des modules à moins de 500 € ? Si oui pour ce qui est des module si il sont obligatoire je vais d'abord faire les tester avec la version complète que j'ai chez moi et je pense qu'après validation du système l'entreprise voudra bien y mettre le prix mais pas avant !!

Si rien de tout cela n'est possible je reviendrais sur les bonnes vieilles cartes électronique pour faire ma détection de phase et l'enclenchement de la commande.

[Nightmare Theater]

Ben disons que la premiere question a poser est: "A quel point est-il important d'avoir exactement 500 us?" Si cette duree ne peut pas est arrondie a une valeur superieure, effectivement, windows ne peut pas garantir une telle vitesse a coup sur (c'est pas qu'il n'est pas assez rapide, juste pas assez precis. A voir selon le cahier des charges quelle est la marge d'erreur).

Ensuite, si il faut exactement 500us (ou proche de cet ordre de grandeur), quelles sont les cartes d'acquisition? Sont-ce des cartes PCI (ou PCIe) connectees sur la carte mere d'une tour? Dans ce cas, tout n'est (peut etre) pas perdu. Le seul probleme est que le module Real Time de labVIEW est necessaire, mais normalement, le hardware pourrait ne pas etre change.

Il est tres facile avec Measurment and Automation Explorer de creer une cle USB Bootable pour formater un PC et installer Pharlap (LabVIEW Real Time OS) dessus. Reste a savoir si ton entreprise a une licence pour ca (peut etre, qui sait).

Quand au reseau protege, j'ai ca aussi dans la mienne, mais pour programmer une tour qui tourne sous RT, y'a pas necessairement besoin de la connecter au reseau. Tu peux la programmer meme depuis un vieux portable, tant que les deux sont relies par un cable ethernet.

Si c'est bien des cartes PCI, , ca me parrait etre la meilleure solution car elle ne necessitent pas necessairement l'achat de nouveaux composants.

Le mieux reste de voir avec les maitres de stage afin qu'eux voient avec le conseiller vente chez National Instruments.

[kipkoolos]

Merci pour ta réponse Nightmare Theater,

500 us correspond à l'erreur maximum demandé et autorisé par le cahier des charges le but étant d'arriver à synchroniser l'entré et la sortie pour avoir un déclenchement fiable par rapport à la phase demandé.

Les cartes PCI sont installées dans le PC hors le système devra être embarqué dans une tour sur roulette qui se déplacera et changera de PC !!

On aura juste à connecter un port USB ou tout autres moyen de communication vers le PC, pour envoyé via le programme PC l'angle de la phase voulut. On envoie et hop le déclenchement se fait.

Existes-t-il des modules d'acquisitions avec un FPGA, autre que le compact RIO et ses modules (super cher), qui pourrait du coup être programmer pour respecter des temps RT ?

Sinon je croit que je vais devoir passer par un programme en C sur un PIC qui se chargera du déclenchement en tant réel et l'interfacer avec LabVIEW en USB, ce qui permettra d'envoyé par le PC la phase voulu et le Programme du PIC se chargera de faire le déclenchement au bon moment !!

Je n'ai pas encore pris le temps de contacter par téléphone un conseillé vente de NI (j'ai cru voir qu'il y avait un supplément sur l'appel fait à payé, non ? Sinon comment contacter un conseiller gratuitement?), seulement un mail envoyé aujourd'hui, en attente du coup ...