Francois Aujard

Hello and thank you for your reply @Rolf Kalbermatter I found out why the files are open in memory and it was my code that caused it. When I start the machine I open and read all the configuration files. Then I update a sensor offset and rewrite all the files. I see 2 improvements to make in this part of my code: - Don't rewrite all the files when there is only one modified. We agree it's a bit silly. - Redo the offset only once at PC startup (not at each program startup). And come to think of it, there's really no need to update it in the *.ini files OK, so that's good. So I didn't just read the *.ini files at startup, I also wrote them. Now, I think @LogMAN 's explanation is right. Windows keeps the files in its cache and only writes them when there is enough to write, right? Why would these files stay open in the resource monitor all the time, sometimes? It's not often, but I've seen it happen. I like the idea of disabling file buffering in the Vi NI Config Close. What do you think about it? If Windows didn't save the files, it would be fine, but it empties them completely in case of a crash.... In this case, a power failure... I'm going to keep investigating my code to see if somewhere I have a loop that would write the files permanently (I don't really believe it). The Vi that is used to write the files is the one I pasted in this post and unless I'm mistaken I close the references... Or maybe there's still something I didn't understand about references... Thank you for your help 🙏

No, I saw your message after... I will try your suggestion...

Files that crash are queried less often. Only once at startup. The other one is read at startup and maybe written from time to time. Thank you very much for your help, I am beginning to understand better what can happen... The Vi labviews are actually not very good 😉 Last night before shutting down the machine I looked at the resource monitor and surprise, all my files are in memory (see picture) I changed my call from Vi to dynamic and no problem . The files appear in memory and then disappear. I was happy , I put back as it was before to validate that I had maybe the problem and no more problem either ... In fact Windows sometimes keeps the Vi in memory without writing them and sometimes not... And if I have a power cut while it decided to keep them in memory, it's screwed. My files will be lost on the next reboot. I will try your solution to force the writing of the files. I have seen that there is a memory management vi, do you think it will help me?

Hello everyone and sorry for my late reply, I have a lot of work and machinery to deliver at the moment. @LogMAN, I have test to add false in the input option "write file if changed" of the Vi "close config data", but I have the same problem again... after a power crash 😤😭 I will read the link you past in your last message https://learn.microsoft.com/en-us/windows/win32/fileio/file-caching and try to understand the text. I am not very good at english... I think it's a good way to solve my problem. For the moment the problem appears only when I have crash power.... One interesting thing, I have another parameter file that uses the config data Vi. This one I run by dynamic call and close it at the end and the call reference and I have no problem with this file. The vi that crashes and that I sent is inserted in my code, at the beginning, but it is not called dynamically. Is it a coincidence that this one crashes and not the other one called dynamically? @Antoine Chalons I will look at the vi in VIPM. I have often hesitated to redo the Vi of config data which I find very slow but practical. Since my crash files I have big doubts about these Vi NI. I will test the ones you suggest, thank you

Thank you for your replies @Antoine Chalons attached to this mail the Vis in labview 2017 version. I use the basic NI Vis (Open config data, read key, close config data, etc...). You can look in my Vi, I open, read and close... I don't understand what's happened...😰 @LogMAN I use the write condition only when I do a calibration of my sensors, and I was not in this case. And I never write 20 files in the same times... It's very strange... I have doubts about the config files Vis... ERR - Section en erreur V1.vi RW Parametres d'une voie.vi

Hello everyone, I work on windows 10 (64bits) - labview 2021 (32 bits). Yesterday during a bench test, the power supply crash and my computer too. When I restart my program, I realise that all the *.ini files (20 files!!!) I read with the Vi attached are empty..... I just used the read function of the Vi, at the beginning of my program. That's it. How is it possible that my 20 *.ini files are deleted? As if Windows had kept them in memory, I have big doubts about the Vi reading config files. Does anyone have an explanation? My code is unstable? what happened? Has this ever happened to you? Thanks for your help... Translated with www.DeepL.com/Translator (free version) ERR - Section en erreur V1.vi RW Parametres d'une voie.vi ConfigAnaIN.ini

In fact with IMAQdx, I want to create a 15s frame buffer, at a rate of about 60fps. A priori the image data I'm trying to store must be a reference. So it can't work. If I convert the reference to a Variant I have the same problem. And if I flatten it into a string, my execution time becomes too long... Does anyone have an idea or an advice?

Hello, I have a GiGe camera Basler. I have created a ring acquisition like the exemple IMAQdx with circular buffer. I load an image every 15ms and I add it in a Vi type FGV (cf. Stock Images.png). In the FGV vi, I create 2 tables. One is for the timestamps and the seconds is for the images. I use the timestamp table juste for keep the last 15s. If my test crash I save the images table. If I use the Vi to look at the timestamp of my image table, it is not the same timestamp as when I added the image in the table (cf. Save Images.png). Why? The propreties IMAQdxReceiveTimestampHigh and IMAQdxReceiveTimestampLow are not attached to the images? I hope you understand my English 🙂 (thank you deepl) François A.

Hello @Rolf Kalbermatter, Just to be sure, that I understand well your previous post. The first case in the attached picture automattillcy close the child reference (CameraInfo ; Parameters and StreamGrabber) or I need to close all childs references before close the parent reference?

Je fermerais toutes les références comme vous me l'avez conseillé. Je vais également surveiller la mémoire du PC lorsque je manipulerais les références ActiveX et .NET. Je ferais tourner mon Vi 1000000 de fois et si la mémoire Windows augmente, c'est que j'ai pas tout bien fermé 😉. Concernant les FGV suis d'accord avec vous. J'utilise aussi les file d'attente, par contre je n'utilise pas les notificateurs. J'utilise les évènements dynamiques qui font pour moi la même chose mais en mieux je trouve. Merci beaucoup @Rolf Kalbermatter pour toutes ces informations. Merci également pour le temps que vous avez pris pour me répondre. J'aurais encore plein de questions, mais qui n'auraient rien à voir avec les fermetures de référence.

the underlying object may however use tons of memory! Qu'est ce que vous voulez dire? La mémoire utilisée par l'appel d'une API n'est pas supérieur à la mémoire utilisée par le logiciel propriétaire de l'API? Ce que je veux dire, par exemple : si j'ouvre SolidWorks, ou que j'ouvre Solidworks via Laview par appel d'API. La mémoire utilisée sera la même? Evidement il y aura une partie en plus pour Labview dans le 2eme cas, mais la quantité de mémoire utilisée pour SolidWorks c'est la même non? Yes, aside for real UI programming I consider use of locals and globals a real sin! Ah oui carrément ! Vous n'utilisez jamais de variables globale ou local ? Vous faites que des FGV? Merci pour vos réponses a mes questions 🙂

There are other memory leaks actually in your code. First you assign the instance refnum for the originally opened Camera object to the NET Camera local control then you Open a new reference to a new camera object and assign it to the same local control, losing the original refnum object, so you can never again close it yourself (LabVIEW eventually will when your code hierarchy in which you executed the Constructor goes idle, but that is typically only when you finish your program. Generally using locals (or even worse globals, shudder) to store refnums is a very bad idea. It makes proper life time control of objects rather hard and error prone. En fait il y a deux contrôles différents "Camera" et "ICamera". Ils se ressemblent mais pointent sur 2 variables locales différentes. Les variables locales (tout comme les globales) sont quand même très pratiques, et pour ce genre d'opération cela ne prend quasi rien de mémoire. Sauf erreur de ma part, un référence à un activeX n'est qu'un pointeur? J'évite ce genre de variable lorsque je dois manipuler des gros tableaux de données. A ce moment la je préfères utiliser des FGV. Ici c'est un code d'essai pour prendre le contrôle d'une caméra GigE mais cela ne marche pas comme je le veux. Que ce soit en .Net ou une Dll. Il y a des class que je ne peux pas avoir, je ne sais pour quelle raison... Il y a aussi des choses que je ne comprend pas bien en regardant les exemple en C# ou C++... C'est très intéressant, mais le temps passe et si j'y passe plus de temps cela ne sera pas rentable pour l'entreprise (dommage). Je vais commander le module "Vision Acquisition Sofware" pour 575€ cela ne vaux pas le coupe de s'embêter....

Merci @Antoine Chalons et @Rolf Kalbermatter pour vos réponses rapide 🙏. J'utilise la version de Labview 2021, et je ne savais pas que l'on pouvait renter un tableau sur un "Close référence". Merci pour l'info 😄! Je suis très autodidacte sur Labview, avec tout ce qui va avec le bon et le moins bon... J'ai commencé sur la version 5.1 et je dois dire qu'il y a eu quelques évolutions entre la version 5.1 et la version 2021. J'ai une autre question sur les ActivesX ou .NET. Doit-on fermer les références que l'on utilise pas mais qui doivent être ouvertes quand même je suppose. Si je suis le conseil de @Rolf Kalbermatter il vaut mieux les fermer dans le doute. Il existe un moyen pour voir si on ferme bien tout ce qui doit-être fermé, pour éviter les fuite mémoire? Cordialement

Bonjour je suis nouveau sur ce site, Je reprenais le code d'un collègue qui me met le doute sur les fermetures de références. C'était déjà pas toujours très clair pour moi mais la c'est la grosse interrogation. Sur l'image jointe : - Sur la partie supérieure les références des clusters, et des clusters formaté en slide (strict), sont fermés a la fin du Vi. Cela sert a quelque chose cela? Pour moi c'est inutile. - Sur la partie inférieure, c'est un appel ActiveX de Solidworks. La j'ai un doute, avant j'aurais fait comme cela, mais maintenant je me demande si c'est vraiment utile de fermer toutes les références qui découlent de la référence ouverte au démarrage (ISldWorks). Juste la fermeture de la référence ouverte au démarrage suffit, non? Cela sert a quelque chose de fermer les références intermédiaires? Merci