le 08-20-2014 10:02 AM
Bonsoir à tous,
Dans mon cas, il s'agissait juste d'un copier/coller de la commande d'un projet à un autre pour un transfert de data via liaison TCP (1Projet Client / 1 Projet Serveur) par soucci de rapidité pour coder la réception de données, les deux projets étant hébergés sur mon poste, je n'avais pas fait attention au lien avant de changer les sources de poste pour un essai croisé.
Donc, comme tu l'as si bien soulevé, après compilation, la def de type n'était pas inclus dans le build, ce qui peux justifier le problème.
Par contre, ce que je ne m'explique pas, c'est que cette commande fait parti d'un VI appelé dynamiquement. Or via un fichier INI je peux sélectionner les VI'S qui seront chargé ou non par mon exécutable, et c'est la que les choses se compiquent : Même sans charger dynamiquement le VI responsable du problème, l'exécutable "crash".
Donc même si nous n'appelons pas un VI, je suppose que l'exécutable "préalloue" la totalité de la mémoire à son lancement afin de pouvoir gérer une charge complète en cas d'appels de tous les VIS contenus dans son code.
Une autre curiosité est apparue, suite aux interrogations soulevés avec Titou, j'ai voulu réaliser le test d'une compilation avec l'option "Déconnecter toutes les def de type" activée, et là surprise.... Echec de la construction pour manque de mémoire...
Ce qui me fait me poser pas mal de question, quand à la gestion de la mémoire sous labview 2011 / Windows XP...
A noter que mon projet comptabilise environ 4500 VIS dont 2000 Vis suceptible d'être appelés dynamiquement, avec différents protocoles (profibus, gpib, usb, tcp, udp, rs232, rs485,....), donc assez complexe ^^.
Je pense qu'il y a du boulot à faire pour optimiser l'allocation de la mémoire car je gère pas pas mal de variable globale, variable locale, registre à décalage et autres.
A titre d'information, après compilation, il n'est pas rare de voir le processus "labview.exe" consommé plus de 1Go de ram via le gestionnaire de tâches windows.
Je reviendrais vers vous, si je trouve une solution miracle pour optimiser facilement la gestion de la mémoire.
le 08-20-2014 10:37 AM
salut,
Michael87000 a écrit :
Je pense qu'il y a du boulot à faire pour optimiser l'allocation de la mémoire car je gère pas pas mal de variable globale, variable locale, registre à décalage et autres.
A titre d'information, après compilation, il n'est pas rare de voir le processus "labview.exe" consommé plus de 1Go de ram via le gestionnaire de tâches windows.Je reviendrais vers vous, si je trouve une solution miracle pour optimiser facilement la gestion de la mémoire.
FGV, AE, DVR, OOP
Contrôle, Indicateur VS Locale VS Globale VS Noeud de propriété
Pourquoi utiliser indicateur puis locale puis noeud de propriété
FGV : Functional Global Variable
AE : Action Engine
OOP : Object-Oriented Programming et structure
SM – QDMH
DVR : Data Value Reference
Luc Desruelle | Mon profil | Mon blog LabVIEW | Auteur livre LabVIEW : Programmation et applications - G Web
Certified LabVIEW Architect (CLA) & Certified TestStand Developper (CTD) | LabVIEW Champion
MESULOG - LinkedIn site | NERYS - NERYS Group
| directeur CEO MESULOG
| CODIR - NERYS group
08-21-2014 03:01 AM - modifié 08-21-2014 03:08 AM
Desruelle_luc a écrit :
salut,
FGV, AE, DVR, OOP
Contrôle, Indicateur VS Locale VS Globale VS Noeud de propriété
Pourquoi utiliser indicateur puis locale puis noeud de propriété
FGV : Functional Global Variable
AE : Action Engine
OOP : Object-Oriented Programming et structureSM – QDMH
DVR : Data Value Reference
Quand je parle d'optimisation de la gestion mémoire, je faisais bien référence à la démarche que tu cites. La présentation disponible dans ton lien est vraiment très intéressante. Dommage de ne pas avoir pu assister le jour de la présentation, la discussion devait être vraiment intéressante. Malheureusement, cette méthodologie, que je "vénère" aussi n'a pas été appliqué au commencement de ce projet, cela est chronofage de segmenter du code existant afin de le commenter et l'éclaircir.
A titre d'anecdote, j'ai quelque exemple de code spaghetti si tu le souhaites, du genre connecteur 8*6*6*8 au lieu de l'utilisation de cluster pour regrouper les datas semblables....
Je pensais à terme m'orienter vers les DVR, mais je ne suis pas encore très familier avec cette méthode, mais dans le cadre d'appel dynamique, j'ai dans l'idée que ce serait le plus propre en terme de gestion de la mémoire.
Cordialement,
MC
le 08-25-2014 07:21 AM
bravo pour la solution et bonne suite
@+
Luc Desruelle | Mon profil | Mon blog LabVIEW | Auteur livre LabVIEW : Programmation et applications - G Web
Certified LabVIEW Architect (CLA) & Certified TestStand Developper (CTD) | LabVIEW Champion
MESULOG - LinkedIn site | NERYS - NERYS Group
| directeur CEO MESULOG
| CODIR - NERYS group