Re : Temps d'exécution d'un vi

[vincent_amiens]

Bonjour,

Je me suis aperçu en utilisant l'outil profil (performance et mémoire) qu'un sous vi pouvait avoir un temps d'exécution de quelques µs en moyenne et de 15 ms dans le pire des cas !

Sachant que je dois lire sur le port série 1 octet à chaque milliseconde, je pense qu'à un moment ou un autre, l'exécution de mon vi risque plus long que la milliseconde et peut-être de disfonctionner (windows ayant d'autres choses à faire).

Mes questions sont :

- Y a t'il un buffer au niveau du port série qui fera que si je n'ai pas lu un octet au bon moment (quand windows me fait prendre du retard), il sera encore disponible plus tard ?

-Est ce que le fait de configurer l'exécution en priorité critique est une bonne solution pour résoudre le problème ? (je transmets alors à l'aide d'une file d'attente mes octets lu à un autre vi consommateur en priorité normal)

Cordialement.

Vincent

[ramses64]

Bonjour,
pour avoir déjà utilisé le port série dans une liaison modbus, je peux vous confirmer qu'il y a bien un buffer qui stocke les données à lire. Ce buffer doit être configurable par la palette Visa dans Labview.

Pour ma part, la lecture du port série n'a jamais été configurée en priorité critique, et je n'ai jamais eu de soucis de ce côté là.
En espérant répondre à votre question,
Cordialement,

[vincent_amiens]

J'ai fait quelques tests avec le port série en utilisant le buffer et en lisant moins vite que je ne recevais. Je ne perds aucune donnée.

Merci.

Vincent

[vincent_amiens]

Cependant, dans le cas où je lis à la même vitesse que j'émets, rien ne garantit que j'aurai un octet à chaque ms quand Windows décide de faire autre chose au même moment. Le buffer se remplira puis se videra quand Windows aura terminé et il est important pour moi d'avoir un octet à chaque ms. D'où ma question sur la priorité d'exécution.

Merci.

Vincent

[J.DECHET]

Effectivement, vous vous rapprochez des limites déterministes d'un système classique. Une requete d'écriture/lecture a de fortes chances de dépasser la milliseconde dans la continuité... Ne serait-ce qu'un appel d'un écran de veille ou d'une appli de MS office et ...

J'espère également que vos routines d'exploitation (calculs, raffraichissement d'IHM, enregistrement, ...) sont bien optimisées et pas trop gourmandes.

Jouer avec les priorités d'execution ne vous coutera pas vraiment mais ne garantira nullement l'entirère disposition de l'OS pour votre appli.

La vraie problématique est : qu'est ce qui motive réellement cette spécification de 1octet/ms?

Le matériel en face du PC? Si oui, quel genre de matériel? Du maison?

N'avez-vous aucune parade pour bufferiser vos données dans l'appareil même?

Avez-vous envisagé des solutions 'temps réel'?

Message Edité par J.DECHET le 01-27-2010 07:01 PM

[vincent_amiens]

En ce qui concerne l'utilisation des priorités d'exécution, j'ai juste constaté que le temps maximal d'exécution d'un sous-si passait de 15 ms à quelques µs avec une priorité critique (alors que je pensais que les priorités n'étaient effectives que entre différents vi au sein d'un projet LabVIEW et n'avaient aucun ascendant sur Windows).

Le sujet traite des troubles musculo squelettiques. L'application permet à un médecin d'effectuer un diagnostique en corrélant en "temps réel" les informations de position des poignets et d'activité musculaire aux gestes du patient sur son poste de travail. La partie matériel est du maison. Elle consiste en l'acquisition de 6 capteurs dont 2 échantillonnés à 1 kHz. En bref, on reçoit sur le port série à chaque ms une trame (d'une dizaine d'octets) ce qui correspond à un débit de 115200 bauds (en fait quand je disais 1 octet par ms, c'est plutôt 10 octets par ms mais aller lire un paquet de 1 ou de 10 octets consomme le même temps). L'affichage des infos des capteurs se fait dans 6 graphes réactualisés toutes les 40 ms.

Pour la vraie problématique, je pense que vous avez raison et qu'il y a moyen de bufferiser à la réception en allant lire le buffer du port série toutes les 40 ms pour traiter et affiche.

Est ce que cela fonctionnerait d'utiliser simplement une boucle de production qui lit 40 trames et qui transmet par file d'attente à une boucle de consommation qui traite et affiche ?

Cordialement.

Vincent

Message Edité par vincent amiens le 01-27-2010 03:04 PM

[J.DECHET]

Oui, le mieux est de lire plus de données moins souvent. 

Pour être honnête, je n'ai jamais eu à manipuler les fonctions avancées de VISA mais peut être qu'il y a moyen de trouver quelques astuces.

Je me contenterais de vous conseiller si ce n'est déjà fait, d'utiliser une méthode proche de celle que je propose dans ce message.

Essayez par exemple, de lire le contenu du buffer que lorsqu'il atteint une certaine taille ou au bout d'un certain temps...

[vincent_amiens]

Merci pour vos réponses. Je vais mettre en oeuvre votre méthode.

Cordialement.

Vincent

[jb65]

bonjour, 

j'ai vu dans votre commentaire que vous aviez compté le temps d'exécution  de votre VI. Je souhaiterais savoir comment vous vous y etes pris pour calculer ce temps d'exécution ?

je travail moi même sur un programme où 2 VI (VI n°1 programme principale et VI n°2 fonction supplémentaire) communiques entre eux, et je voudrais savoir combien de temps s'écoule entre chaque appel du VI n°2 ??. Par la suite conclure si ce temps est régulier ou pas ?.

merci 

[vincent_amiens]

Bonjour,

Dans la face avant ou dans le diagramme, menu Outils/Profil/Performances et mémoire.

Cordialement,

Vincent