Discussions au sujet de NI LabVIEW

annuler
Affichage des résultats de 
Rechercher plutôt 
Vouliez-vous dire : 

Erreur DAbort 0xF50EFD7B in MemoryManager.cpp

Résolu !
Accéder à la solution

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.

0 Compliments
Message 21 sur 24
2 238 Visites

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

 

https://decibel.ni.com/content/blogs/Luc_Desruelle/2014/02/12/histoire-des-fgv--functional-global-va...

 

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

banniere Luc Livre NXG Champion.png

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

Message 22 sur 24
2 231 Visites

Desruelle_luc a écrit :

salut,

 FGV, AE, DVR, OOP

 

https://decibel.ni.com/content/blogs/Luc_Desruelle/2014/02/12/histoire-des-fgv--functional-global-va...

 

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


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

Message 23 sur 24
2 221 Visites

bravo pour la solution et bonne suite

@+

banniere Luc Livre NXG Champion.png

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

0 Compliments
Message 24 sur 24
2 201 Visites