ralentissement boucle while

[D1431]

Bonjour à tous,

Dans le cadre d'une application, j'ai besoin d'envoyer un notificateur toutes les 50 ms - de façon très précise. La marge d'erreur acceptée est de 1ms, le temps entre deux notificateurs envoyés ne doit donc pas dépasser 51 ms.

J'ai tout simplement placé l'envoi du notificateur dans une boucle While cadencée à 50 ms ; je me suis aperçue de plusieurs retards (certaines itérations prennent jusqu'à 300 ms !) 

J'ai donc enlevé les notificateurs de ma boucle afin de la faire tourner (vide) et de mesurer le temps des itérations ; je me suis aperçue que de façon aléatoire, certaines itérations dépassaient le temps de cadencement (52 ms jusqu'à 150 ms).

J'ai donc remplacé ma boucle While par une structure While cadencée mais là, même problème (quoique moins fréquent) : certaines itérations prennent beaucoup de temps, et dépassent les 50 ms, alors que la boucle est vide et que rien ne s'éxécute !

Je ne comprends pas d'où vient ce problème : limites LabVIEW / Windows ?

Il est impératif, pour l'application, que l'envoi de ces notificateurs s'effectue à une fréquence très précise.

En PJ un VI très simple (while cadencée et mesure du temps de boucle, si une itération est  supérieure à 51 ms : on allume un booléen).

Merci,

[ML927]

Bonjour D1431,

Tel que décrit, je pense que ton problème vient bien du fait que Windows n'est pas un OS temps-réel. Globalement, il suffit que pour une raison ou une autre Windows décide d'allouer des ressources à une autre tâche plus prioritaire, et ton cadencement est fichue.

Je ne suis donc pas sûr que tu puisses atteindre ton objectif sans cible temps-réel. D'autres sauront sûrement mieux te renseigner que moi 😉

[lulu44]

Bonjour,

avez vous essayer de mettre une priorité très haute pour la boucle cadencé?

sinon il est vrai qu'un PC n'est pas une machine temps réelle et que des séquences peuvent durée plus longtemps que prévu à cause de windows et de tous les programme qui tourne en tâche de fond. 

[ouadji]

" ... toutes les 50 ms - de façon très précise. La marge d'erreur acceptée est de 1ms "

sous Windows ... c'est tout simple ...tu oublies.

ps:

le bon vieux temps, avec mon apple II (µP 6502 - fréq. horloge de 1Mhz) , le tout sous DOS.

En assembleur je pouvais calculer les temps au cycle près ... j'avais une précision de 1 µsec.

Sous Windows, cela est devenu impossible.

[D1431]

Merco pour vos réponses, la boucle cadencée fonctionne mieux mais ne répond pas aux critères demandés (< 1ms).. Effectivement Windows pose problème..

Je vais essayer de changer de solution,

Merci,

[D1431]

Merco pour vos réponses, la boucle cadencée -priorité haute- fonctionne mieux mais ne répond pas aux critères demandés (< 1ms).. Effectivement Windows pose problème..

Je vais essayer de changer de solution,

Merci,

[Kaleck]

Un truc tout bête :

Et si tu utilises deux boucles cadencés de 100ms avec l'un d'entre-elles qui est déphasée de 50ms, tu pourrais peut-être avoir des réponses toutes les 50ms correctes non ?

Sinon voici un petit vi fait à la va-vite pour tester les retards sur les temps des boucles cadencés. Bien sûr plus la période est élevé, moins il y a d'erreurs :

[D1431]

Effectivement ça fonctionne beaucoup mieux ! Merci !