Bonjour,
Je souhaite connaitre la difference entre un projet Labview normal et un projet temps réel.
Je vous remercie,
PieElectro
Bonjour,
Je souhaite connaitre la difference entre un projet Labview normal et un projet temps réel.
Je vous remercie,
PieElectro
Salut,
Ça, c'est une très vaste question. Alors, dans les grandes lignes (on complètera sûrement mes explications) :
1 - LabVIEW fonctionne sous Windows. Windows n'est pas un système temps réel, en ce sens qu'il ne garantit pas le déterminisme temporel des tâches (si tu as une boucle LabVIEW qui tourne à 100 Hz et que tu ouvres Access en même temps, les processus vont "se battre" pour accaparer les ressources de l'ordinateur).
2 - Le temps réel (RT) fait donc directement appel à la notion de déterminisme dans l'exécution. Comme on ne peut garantir l'exécution déterministe de tout et n'importe quoi (en particulier les accès au disque, au réseau, ...) il faut isoler un processus critique (par exemple, une boucle de régulation)
3 - Le processus étant choisi (c'est à dire correctement étudié, testé, prototypé par le concepteur), il faut le faire tourner sur une machine RT. Une machine RT est par exemple un PC équipé d'un système d'exploitation RT (donc, pas Windows, National Instruments a choisi PharLap) et sur lequel fonctionne un environnement de développement et d'exécution TR (ici, donc, LabVIEW RT).
4 - Une application LabVIEW RT comprend donc un ensemble de processus non-critiques (supervision, IHM, affichage, ...) tournant sur une machine Windows et processus critique (en général, un boucle de traitement), qui est en fait un VI qui va être téléchargé sur la cible temps-réel (la machine RT) via en général une liaison Ethernet.
Donc, pour réumer : pour faire fonctionner une application LabVIEW RT, il faut (au moins) deux machines : le superviseur et la machine RT. Depuis peu, NI a sortit l'hyperviseur (!!) qui consiste a n'utiliser qu'une machine (un quad-core) et a faire tourner windows sur le premier cœur et PharLap sur les trois autres.
Voici pour les grandes lignes.
J'ajouterai ceci : une application RT n'est pas un programme qui fonctionne a toute vitesse. Il s'agit d'une application qui fait tourner un processus critique de façon stable et garantie (déterministe).
Si il y a d'autres questions ......
A+
B.
Salut,
La reponse est simple: dans un projet Temps Reel, tu maitrise le temps car il n'y a pas d'interference exterieure à ton programme.
Par exemple, sous Windows, tu ne peux pas avec une valeur temporelle fiable à moins de 10 ms. Ainsi, si tu envoies une commande et que tu dois avoir une reponse en 2 ms, tu ne pourra pas en etre sûr sous WIN à cause du multitaches.
Il y a 2 solutions à ce probleme: deporter la gestion du temps sur des cartes specifiques (tu programme à l'avance les reponses et les delais, puis la carte execute) ou avoir carrement un systeme Temps reel.
voila pour un resumé grossier.
a+
L'urgent est fait, l'impossible est en cours, pour les miracles, prévoir un délai et un bon thermos.
Quant aux MP techniques, autant les poster sur le forum approprié car, là, ils auront des réponses.
Je vous remercie de vos réponses.
J'ai créé un VI (dans un projet Real-Time) faisant mon application et j'aimerais sortir mes signaux de mon interface(crio).Mais apparement il n'est pas possible de sortir directement car il faut cadencer avec une boucle de temps sur la sortie.
Pourriez vous m'apporter des explications sur ce point.
Je vous remercie.
PieElectro
Salut,
Qu'appelles-tu "sortir mes signaux" ? Si c'est vers le PC superviseur, le processus de sortie des signaux ne sera pas RT.
C'est quoi "crio" ?
Peux-tu être plus précis sur ce que tu veux faire ...
Merci
B.
Ok je vais essayer d'être plus preçis.
J'ai generé un signal sinusoidal et j'utilise une interface CompactRio.Je souhaite obtenir le signal que j'ai generé en sortie d'un de mes modules CRIO.
Si on relie le sinus à l'etiquette de sortie du CRIO que l'on veut, il y a un probléme de données et apprement il faut creer une boucle de temps.
Ceci n'empeche pas de compiler mais le signal en sortie n'est pas propre même à tres basse fréquence.
Je vous remercie.
Pie Electro
Salut,
Autant pour moi, crio, j'avais pas percuté que c'était le CompactRIO
Pour ta sortie, s'agit-il de la fameuse sortie numérique dont tu nous as parlé ???
Comment relis-tu ensuite ce signal ? Vers quelle interface ? Une entrée numérique du CRio ?
Il y a peut-être un problème de synchronisation entre écriture et lecture, ou bien au niveau des paramètres du buffer d'acquisition ...
Je reste on line
Bonjour, j'éspere que le week end c'est bien passé pour tout le monde,
Concernant Labview, c'est un signal analogique que j'aimerais sortir de mon Compact Rio.
De plus je souhaiterais connaitre la difference entre le mode Scan Engine et Real-Time et comment fait-on pour se mettre dans une configuration ou dans une autre.
Je vous remercie
PieElectro
Bonjour,
Voilà mon gros probléme!!!
J'ai generé un signal sur labview et je souhaite m'en servir en pouvant le récuperer sur mon interface Compact Rio avec une sortie Analogique.
Labview a bien reconnu l'interface, mais quand je demande de relier la sortie de mon signal à l'entrée AO0, un petit point rouge apparait sur l'étiquette AO0 pour m'informer que les données entre mon signal et ma sortie Compact Rio ne sont pas compatibles.
Connaissez vous une solution?
Merci
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Partager