Re : Temps de boucle labview windows 7

[__KB__]

Bonjour,

J'utilise labview 2014 sous windows.

J'ai un module multimetre cdaq dans un châssis relié à un PC via un switch.

Je dois surveiller 8 mesures analogiques et lorsqu'un seuil est dépassé je dois effectuer un traitement d'alarmes.

Pour le moment pour faire simple j'effectue les 8 mesures en mode 1 point. Le tout dans une boucle cadencée par une tempo de 5 ms.

Le traitement des défauts se fait dans une autre boucle cadenceé à 5 ms.

Je dois évaluer le temps max de traitement des défauts en cas d'alarme.

Il y a beaucoup d'inconnues pour évaluer ce temps max me semble t il :

- d'entrée windows7 n'est pas deterministe, il partage les ressources selon les besoins.

- la configuration matérielle à aussi son importance : selon que l'on est un processeur récent ou vieux le temps de traitement peux fluctuer.Idem pour le reste disque dur, ram....

- il y a aussi là complexité du logiciel dans lequel les mesures sont surveillées.

Par conséquent il est difficile d'évaluer un temps maximum de traitement d'une alarme tant il y a de paramètres qui rentrent en jeu.

Que pensez vous de mon analyse ?

Il m'a été suggere d'utiliser des interuputions si un seuil d'alarme est dépassé : est ce que je me trompe en disant que ces mécanismes ne sont pas programmable sous Labview ?

Alors effectivement je peux optimiser mon code en définissant des niveaux de priorités différents pour les VI d'acquisition et de traitement des défauts.  Oui je peux utiliser des boucles while cadencées. Et encore oui je peux modifier le niveau de priorité d'exécution de mon appli sous Windows.

Le même problème se pose à moi pour un équipement relié par RS232.

Je dois évaluer le temps max de traitement si en interrogeant l'appareil un seuil est dépassé. 

A ce stade pour un seuil analogique je pense qu'il peux y avoir 100 ms de traitement et 1 s pour de la RS232. Ces temps peuvent fluctuer selon l'environnement windows.

Que pensez vous de cette analyse et quelles sont vos critiques ?

Merci

[ouadji]

Bonne analyse.

Le temps maximum pour réaliser une tâche x comprend d'offfice le temps (retard) entre le moment où Windows reçoit la "demande" ... et le moment où il décide, suivant ses priorités, de lui accorder du temps machine. Il n'est pas possible d'évaluer un "temps maximum de retard" sous un OS multitâches tel que Windows.

Tu peux éventuellement, avec un grand nombre de mesures ... faire une estimation statistique ... (toute relative)

Ce qui n'empêchera pas Windows, s'il estime cela nécessaire, de prendre à l'occasion 100 fois cette durée.

Pour moi, une telle "évaluation" est impossible.

Je ne confierais certainement pas ma vie à un soft qui fonctionne sur base d'un temps de réponse "estimé" de Windows.

Juste mon avis.

[__KB__]

Merci Ouadji.

De ton coté as tu connaissances de programmation Labview d'interruption sur un niveau analogique ?

Encore merci.

[ouadji]

frapper à la porte de Windows via une interruption hardware n'y changera rien.

Windows prendra bonne note de la demande ... et la mettra sur la pile "des choses à exécuer".

il y répondra, suivant le niveau de priorité de cette interruption et surtout des priorités qu'il aura attribuer à chaque tâche "en attente".

à moins que de "hacker" complètement Windows, tu n'arriveras pas à dépasser la priorité des interrupions, par exemple ... venant de la souris. (et bien d'autres)

Non, Labview ne permet pas de manipuler directement les interruptions. (le C non plus)

Il faudrait pouvoir accéder au circuit qui les gère ... le I/O APIC ... et "ça", c'est du très très bas niveau (avec une part de terrorisme )

Il faut de l'assembleur pour ça ... et une sacrée connaissance du fonctionnement interne de la machine.

[__KB__]

Merci 

[ouadji]

Pas de quoi.

Les interruptions ... on peut y laisser une vie.

Dans une vie précédente    j'ai été fou (à lier) d'assembleur.

J'ai hacké Windows, détourné les interruptions, reprogrammer ce I/O APIC, détourné la table des services de Windows ...

Au départ du "mode protégé" de Windows, je suis passé en mode réel, et je suis revenu en mode protégé ensuite.

J'ai même fait tourner du code en mode réel, avec interruption software (construire une nouvelle table d'interruptions mode réel, etc, etc, un truc de fou)

Mettre le mode protégé de Windows OFF et y revenir ensuite ... avec en sortie un PC qui fonctionne comme si rien ne s'était passé

ça ... c'est un truc de fou. 

C'était juste de l'amusement, car ce genre de choses est inutilisable en pratique pour faire quoi que ce soit.

(mis à part de la bidouille dans son coin)

bonne suite et bon code !

[Desruelle_luc]

bravo!

[ouadji]

oui ... ça remonte à environ 5 ans.

J'utilisais un magnifique debugger en mode noyau (Syser).

Ce debugger, que l'on pouvait considérer comme le succèsseur de SoftIce (Numéga) était une petite merveille.

C'est un chinois qui développait ça. J'étais souvent en relation internet avec lui pour lui signaler tel ou tel bug.

Il y avait encore du boulot, mais Syser devenait réellement un debugger kernel haut de gamme.

Malheureusement ... très malheureusement ... le gars à abandonné le projet il y a environ 2 ans. (une grosse perte)

Maintenant, à part WinDbg, il n'existe plus rien comme véritable debugger mode noyau.

Et WinDbg ... je n'aime pas. Il faut 2 PC, un pour le debugger, et l'autre pour la cible (ou éventuellement un seul PC avec une machine virtuelle, VMWare, VirtualBox ...)

J'ai joué avec le HPET  aussi (pas évident non plus ça, j'y suis arrivé après beaucoup de recherches ... et d'écrans bleus)

Via le HPET, je pouvais déclencher des interruptions avec une période parfaitement stable et donc passer au dessus de Windows.

Je me souviens avoir généré un signal parfait de 15Khz, invariant quelque soit mon activité en avant plan sous Windows.

C'est Windows qui ralentissait ... mais 15Khz était prioritaire.

Tous ça, et bien d'autres choses (inutiles) pendant 15 ans d'assembleur (mais quel plaisir !)

Je retrouve le même plaisir de programmer avec Labview ... plaisir que je ne rencontre pas (peu) avec le C.

L'assembleur ... terminé !

trop difficile de "sortir" un résultat ... pour visualiser un résultat, il faut aller voir en mémoire via le debugger.

Créer une interface pour afficher un échiquier en assembleur ... je n'y pense même pas !

voilou.