Discussions au sujet de NI LabVIEW
Erreur DAbort 0xF50EFD7B in MemoryManager.cpp
Résolu !
Pour le SCC, pourquoi ne pas mettre un serveur SVN et TortoiseSVN?
Gratuit, et si tu ne peux pas mettre le référentiel sur un serveur, tu peux toujours le mettre sur un PC qui est sur le réseau.
Il n'est pas trop tard dans la vie du projet
les vi's dynamique ne sont pas un obstacle au SVN. je ne comprends pas vraiment ta remarque .../... appel à vi dynamique incompatible avec la séparation du code compilé .../... Si le vi dynamique n'est pas modifié (?)
Pour info, je gère 2 projets de +6000 vi's, l'un lance au démarrage 32 vi's dynamique, cela n'est pas incompatible avec le logiciel SCC.
je sais que tu es en LV2011, mais as-tu quand même regardé
403235 — DAbort 0xF50EFD7B in MemoryManager.cpp when auto-indexing a 2D waveform.
The following items are the IDs and titles of a subset of issues fixed between LabVIEW 2012 SP1 and LabVIEW 2013. If you have a CAR ID, you can search this list to validate that the issue has
been fixed.
comme tu fais de l'acquisition.
Michael87000 a écrit :En quoi la gestion de la mémoire est différente entre une application en mode run time et en mode développeur ?
Pourquoi un code peut s'exécuter correctement en mode développeur sans aucune mise en garde et erreur, et faire un échec critique dès le démarrage en run time ?
Pour avoir un début de réponse du block diagram vers le code machine : LabVIEW Under the Hood: The Evolution of the Compiler bonne lecture
ou CLUG Oct 2013 Dr Richard Thomas: LabVIEW Compiler Under the Hood.pptx
Michael87000 a écrit :
"Ne séparez pas le code compilé des VIs que vous avez l'intention de charger ou d'exécuter en utilisant le moteur d'exécution LabVIEW."
http://zone.ni.com/reference/fr-XX/help/371361H-0114/lvconcepts/saving_vis_compiled_code/
Or sans réaliser la sépration du code compilé, comme tu dois le savoir, la modification d'un vi va impacter ses voisins rendant obsolète l'intérêt d'un SCC.
Salut, ta remarque m'a interpellée, et je comprends mieux ta position sur l'utilité d'un logiciel SCC. En effet, si je change un sous-vi et que l'ensemble des appelants sont modifiés suite à la recompilation, quel sera la finalité du logiciel SCC? Tu te poses la bonne question.
Je vous propose un exemple, à faire, un Main.vi et un subvi.vi
Si je modifie le code de subvi.vi, en ajoutant 2+2, le subvi.vi est en étoile, je sauvegarde, mais le main.vi n’est pas en étoile, pas de changement sur le disque.
Tous les changements dans un sous-vi, n’imposent pas une modification disque des appelants.
oui : Ne séparez pas le code compilé des VIs que vous avez l'intention de charger ou d'exécuter en utilisant le moteur d'exécution LabVIEW.
Non : même si suite à une modification dans un sous-vi, LabVIEW recompile le sous-vi et aussi les appelants, cela n’impose pas qu’il y aura une modification dans les appelants.
Bonne suite
@+
salut à vous, j'ai eu le problème une fois... je m'en rappelle mais plus vraiement pourquoi!
si je cherche une explication, nous pourrions imaginer un TypDef qui est connu dans le projet, en direct ou en dépendance ou en conflit, mais qui n'est "ajouté" dans le build de l'exe. Donc l'exe va "crasher".
Par exemple, j'ouvre un vi avec un typdef qui n'est pas dans un dossier du projet. Il est en dépendance. Si le vi est dynamique, la défintion de type ne sera pas dans le build de l'exe, donc probléme de build.
Pour moi sélectionner cette option n'est pas une bonne idée, en l'état de l'analyse.
il faudrait en savoir plus. En effet, récupérer dans un projet un vi d'un autre projet, avec définition de type, n'est pas un problème.
Par contre comment? : save as? juste utilisation?
Y-a-t-il des conflits dans le projet? des dépendances?
Cette défintion de typ est-elle dans le projet? dans le build de l'exe?
Attention si chargement dynamique que l'ensemble du code soit dans l'exe.
A+
