Longueur d'historique et gestion de mémoire

[cyprien11]

Bonjour à tous,

Dans le but d'instrumenter un peu mon labo, j'ai créé un programme qui me permet de contrôler une pompe et j'enregistre son débit et la pression qu'elle me donne. De plus, je fais l'acquisition de 3 températures et de deux poids sur lesquels je fais des calculs pour avoir un débit.

Mon programme a donc trois parties : 

- la partie acquisition + calcules (+ voyants seuils), échantillonnée toutes les secondes, où on retrouve aussi un "Construire une table" puis aller chercher une valeur de poids X minutes plus tôt pour lisser mon débit. J'ai donc 3 températures + 1 débit pompe + 1 Pression + 2 poids + 2 débits massiques.

- la partie traçage de graphique, toutes les secondes aussi. J'ai trois graphiques, la pression sur l'un, les 2 débits massiques sur le deuxième et les 3 T° sur le dernier.

- la partie archivage de données sur 3 tables + écriture sur Excel.

Je rencontre aujourd'hui 2 problèmes :

1/ Mes graphiques ont tous une longueur d'historique de 7200 points (donc 2h avec un échantillonage de 1s, ce que je désire aujourd'hui). Or sur mon graphique Pression (1 seule courbe), j'enregistre pendant 4/5h; sur mon graphique débits massiques (2 courbes) j'enregistre pendant 2h30 environ; sur mon graphique T° (3 courbes), j'enregistre pendant 2h10 environ. Savez-vous d'où peut venir mon problème? Le nombre de courbes sur une graphique (déroulant) influence-t-il la longueur d'historique?

2/ Mon ordinateur sur lequel tourne ce programme (sous forme d'application) finit par avoir beaucoup de mal à réagir lorsque l'appli tourne depuis un certain temps. Je me demandais ainsi si, sur un graphe déroulant, les valeurs qui sont effacer avec la longueur d'historique étaient complètement effacées ou bien gardées en mémoire même si non affichées (ce qui entrainerait encore plus de lag). De plus, avez-vous des pistes pour m'aider à avoir un programme plus léger?

Je mets mon code en pj, désolé de vous montrer cette horreur, j'ai fais de mon mieux (c'est mon premier vrai pgm sous labview).

Merci pour votre aide.

Cdt,

[Desruelle_luc]

salut il est en LV 2015. Sur mon PC j'ai LV 2014 au max. Tu auras plus de réponses avec un code dans une version plus basse. Tu peux faire une sauvegarde en .... 2011

[Michael.C]

Bonjour,

IL y a plusieurs choses qui nont pas dans ton programme.

A mon sens, il serait bon de refaire le travail avec une structure Producteur/ Consommateur, mais bon je peux comprendre qu'à ce stade, cela représente trop de travail.

Mais voilà les points qui sont à mon sens à corriger au minimum :

- Cabler les cluster d'erreurs.

- Ne pas laisser une boucle "while" avec une constante qui ne pourrait s'arrêter que sur une fermeture brutale de la fenêtre par l'utilisateur.

- Regrouper les signaux identiques (débit / Pression / Thermocouple) dans des clusters pour limiter le nombre de fil à l'écran.

Ton problème de ralentissement vient effectivement d'un souci de tableau qui grandit au fur et à mesure. cela ne vient pas de ta partie affichage, mais de ta philosophie de sauvegarde.

Au lieu d'écrire les données dans un fichier au fur et à mesure, et de ne garder que les dernières valeurs en cours en mémoire, tu réécris complètement à chaque fois le fichier, cela entraine donc un ralentissement de ton programme au fil du temps (dû à la taille des données à écrire, et à la taille des tableaux en mémoire). L'autre point négatif de cette méthode, c'est quand cas de buffer overflow, tu risques de perdre la totalité de tes mesures.

Quand tu ouvres labview, et que tu fais nouveau, tu as des modèles de conception de proposé, je t'encourage vivement à regarder le modèle producteur /Consommateur qui t'apporterait une réelle qualité de code te permettant de maintenir celui-ci dans le temps.

Bonne soirée,
Michael

[cyprien11]

Bonjour,

Merci pour vos réponses.

Il ne m'est pas possible d'enregistrer mon VI sous labview 2011à cause de VIs Express.

Je vais corriger les points cités, et surtout m'intéresser aux variables dans les clusters, j'en ai beaucoup entendu parler sur la toile mais je n'y voyais pas vraiment l'intérêt. J'ai déjà essayé de regrouper des boucles pour supprimer des variables locales (qui apparemment peuvent faire du mal à la mémoire vive). 

En ce qui concerne le modèle Producteur / Consommateur, je vais me noter ça dans un coin. Je pense que j'ai encore besoin de pas mal de recule pour pouvoir m'y plonger vraiment.

De plus, on m'a demandé de communiquer avec un débitmètre avec un connectique DB9 to usb avec un protocole RS485 Modbus RTU. Pourtant, malgré tous les posts à se propos ainsi que vos conseils et les tutos (tous lus), je n'arrive toujours pas à comprendre comment ça marche. Surement un nouveau post d'ici peu ^^

Merci pour vos conseils.

Cordialement,

[Michael.C]

Le modèle de conception est assez intuitif quand on regarde les exemples ;).
Pour les clusters, l'intérêt est de pouvoir regrouper des données dans un seul afin de clarifier tes diagrammes, mais aussi et surtout tes connecteurs de VI. En effet tu peux faire passer tes 8 Thermocouples via 1 connecteur au lieu de 8 ;).

Sinon pour le DB9to USB, cela signifie que tu as un UART dans ton produit, donc tu vas dialoguer à l'aide de driver VISA. Pour le modbus RTU, il y a des librairies existantes qui font bien le travail, après il ne te reste plus qu' à connaitre la table des registres pour savoir où lire et/ou écrire tes commandes.

[cyprien11]

Pour les clusters, c'est bien compris, je vais m'efforcer de les utiliser le plus possible, que ça devienne automatique.

Je me suis intéressé au modèle de conception. C'est toujours pas ça, j'ai l'impression que c'est fait pour retarder/filtrer une acquisition (avec une lite d'attente), un horodatage fait ceci très bien non? Je pense bien que je n'ai pas compris l'intérêt du coups j'ai plusieurs questions : 

   - Mon producteur met une donnée dans la liste d'attente, ensuite mon consommateur va regarder la liste et rentrer la donnée dans une table/un graphique, puis je détruis la liste d'attente. Cela veut-il dire que la seule mémoire utilisée était l'unique donnée, qui se retrouve détruite à la fin? Je fais donc de l'affichage mais aucune mémorisation? Du coups, plus de lag?

   - J'utilise une boucle par appareil, puisqu'il peut arriver à l'avenir que l'echantillonnage soit différent, et je ne veux pas qu'un problème sur un instrument arrête mon acquisition sur un autre. Puis-je vraiment utiliser ce modèle de conception sachant que j'utiliserais plusieus producteurs et plusieurs consommateurs?

En ce qui concerne mon débitmètre ModBus, j'ai du UART, donc je dois utiliser des VISA. Or je dois communiquer en Modbus, quelle est la place des VISA ici?

J'ai téléchargé la librairie effectivement, mais je dois que le ModBus est tellemnt différent de ce que j'ai déjà fait que je n'arrive pas à voir comment ça marche. Rien que le maitre/esclave, mon PC est forcément le maître et mon débitmètre l'esclave pouisque c'est le PC donne des ordres et mon débitmètre des infos. Doit-il y avoir un maître dans mon programme? dois-je juste mettre un esclave, donc mon débitmètre? Puis-je seulement lui demander un débit, lui donner une consigne? Quelle est la place de la tame dans tout ça? Celle des registres? 

http://www.alto-instruments.fr/Actu/data/upimages/30-Gaz_DebRegMassique-Smart-ManuelCommunicationNum...

En page 15, j'ai le registre "lire débit" 0x0000..0x0001 et "consigne" 0x0006..0x0007, dois-je faire un programme par demande? dois-je lire toutes les données entre 0x0000 et 0x0007 et filtrer ce que je veux? 

En bref, je vois pas, en voyant les exemples j'ai l'impression que le diagramme est vide, mais je ne vois pas non plus où est la lecture de tel truc.

[Michael.C]

Bonjour,

Ca fait beaucoup de question en un seul poste :).

1er : Modèle de conception Producteur /Consommateur.

Ce modèle est utilisé en aquisition/traitement car cela permet de maintenir un temps d'acquisition stable et indépendant de ton traitement. La boucle productrice va acquérir les données de ton ton module à un temps T, et si ton consommateur (traitement et/ou sauvergarde) prends un temps T+dT, les données d'acquisition ne seront pas perdu puisque ton buffer FIFO sera là pour sauvegarder celle-ci pour traitement ultérieur. Bien sur il faut que le dT entre tes deux processus ne soit pas trop grand, sinon ton buffer grossira dans les capacités de ta machine, et tu auras donc une perte de données au bout d'un moment.

Dans le cas (comme toi) où tu as plusieurs appareils, tu peux mettre en place plusieurs boucles productrices qui viendront remplir au fur et à mesure le meme buffer pour traitement.

2eme : Le modbus est un protocole de communication. Il s'agit d'un formatage de trame particulier, généralement basé sur une communication RS485. Ce type de bus permet d'avoir plusieurs équipements connectés sur le même réseau avec des identifiants modbus différent. Une résistance de terminaison 120Ohm est généralement nécessaire en entrée (souvent sur la carte PCI) et en fin de ton bus (au niveau du dernier équipement connecté).

3eme : Pour le cablage, il te faut regarder la documentation de ton équipement, qui t'expliquera comment brancher ton équipement dans un réseau modbus.

4eme : "lire débit" 0x0000..0x0001 et "consigne" 0x0006..0x0007-> Cela signifie que ton débit est stocké en mémoire sur deux octets, il te faut donc lire les deux registres et les assemblés pour obtenir la valeur finale (Palette numérique / Manipulation). Idem pour consigne.

J'espère t'avoir éclairci la chose.
Bonne soirée.

Michael

[cyprien11]

Merci pour le temps que vous me consacré, cependant j'ai encore du mal.

1er : Modèle de conception Producteur/Consommateur.

Je comprends que c'est quelque chose d'apprécié dans la communauté. Cependant, j'ai un problème quant à son utilité dans mon cas. Je n'ai aucun problème d'acquisition de données et d'écriture de celle-ci dans un graphique. De plus, les graphiques me servent à faire de la surveillance. Si je me retrouve avec un dT, qui risque d'être important sur 6h par exemple, je n'ai plus de visuel sur ce qu'il se passe. Je n'ai pas encore mi de régulation sur mon système donc en cas de dérive, je risque d'avoir un problème si je ne la vois pas.

Je m'étais intéressé à ce modèle de conception puisque mon PC ramait au bout d'un certain temps (mon application tourne de 9h à 18h). C'est à dire qu'il n'était presque plus utilisable à part pour faire tourner l'application et après un certain point, au lieu d'écrire une valeur toutes les secondes et écrivait 4 valeurs toutes les 4 secondes (mais je n'avais donc pas de perte de donnée). 

J'avais cru comprendre que ce modèle pouvait me permettre d'y gagner côté mémoire vive, est-ce vraiment le cas?

2eme : Pour le RS485, le jeu de résistance ... je me suis mi au jus, j'ai eu quelques soucis dernièrement avec un autre débitmètre, avec lequel j'ai d'ailleurs abandonné le partie com.

3eme : Pour le câble, je ne devrais pas avoir de soucis, il m'a été fourni, d'un côté en DB9 pour mon équipement, de l'autre en USB pour mon PC, il y a normalement même la résistance du RS485 dedans. Driver installé, je retrouve mon COM sur NI Max.

4eme : Ok pour le double octet, une chose dont je me doutais mais au moins c'est clair maintenant. Est-ce donc cela que je dois entrer dans "Number of inputs"? 

Maintenant, imaginons que la lecture de mon débit se trouve au registre "0x0000..0x0001" et que la lecture de ma pression se trouve au registre "0x4000..0x4001". Dois-je mettre un module "Read Holding Register" avec en "Starting Adress" : "0" et en "Number of inputs" : "4002" et donc par la suite faire tri dans tout ça? Ou bien dois-je mettre deux modules "Read Holding Register" en série avec chacun son adresse de début et le nombre d'entrée à lire?

Suis-je sur la voie de la compréhension?

[Michael.C · Accepted solution]

Bonsoir,

Le ralentissement de ton application est du à l'augmentation de la mémoire utilisée. Pour avoir une application qui a une réactivité stable dans le temps, il te faut écrire régulièrement les données dans un fichier, et les retirer de la mémoire tampon.

Personnellement, mon application peut tourner 1 mois (jamais fait plus) sans aucune baisse de performance avec des acquisitions multi-appareils et multi-réseaux.

Pour la communication, le raisonnement est simple, quel est l'intérêt de remonter 4000 octets pour 4 utiles.....

Il faut toujours raisonné pour utiliser la méthode la plus rapide. Dans ton cas, il sera mieux de faire 2 appels remontant 2 octets chacun, qu'un seul appel remontant 4000 octets. En plus, tu risqueras moins de te prendre les pieds dans le tapis pour la gestion des données derrières.

Bonne soirée.

Michael