Francois Aujard

@ensegre I have found my problem 🙂. The initialisation of a FGV use property node. I put it in other VI and this solve my problem : I use this VI a lot of years, with windows 7 and with labview 2017 and labview 2013. It's strange I have problem now. Never see the problem before, and I think that I have no visible problem before. 🤔 For information I use Dynamic call like that : Is it good according you? I am not sure I understand well the "root loop" signification... What is "CLFN" in your sentence : "CLFN configured for UI thread, for instance" Thank you for your help 🙏

Ok @ensegre but I use the Dynamical Events (shutdown for exemple), is it necessarry to delete the events structure? I have the same base for the Vi that are in loops that do not slow down... I look what is possible to arrive in the VI. Is it possible to have a problem with strict type definitions (in constant)?

@ensegre thank ou for your reply. I don't know. "UI thread" and "Root loop" are new notions for me, since your message last night. And how can we tell a VI not to run in the UI thread?

Hello, I put a spy that calculates the duration of my acquisition loops. When I move quickly the window of my spy (or another window), I have 3 Vi that slow down. There must be a difference between the Vi but I can't see it. Whether I am compiled or not, it does not change anything. I also had this when I put a path command in a new Vi. When I click on the browse button, my 3 loops slow down... I don't understand... It's very annoying because I can't develop a new Vi with my current program running, without slowing down... Even when I want to debug my program, it's the same.... - What could cause a slowdown of some of my Vi? It's as if it was Windows that decided. - I tried to change the priorities of the VI's but nothing works. I never understood how these parameters worked... Thanks for your help.

@JKSH yes, it solved my problem ! Thank you. @LogMAN No. I followed the advice of @JKSH and my problem has disappeared. It's a Labview Bug...

Not in my case... ☹️ 477650069_2022-11-1609-08-55.mp4

Thank very much @bjustice, I was sure I had checked 😵... but apparently not, that's my problem ! I'm sorry to have been so bad on this one... I'm going to stop drinking 🥴...

No the "Sick Vi" is not reentrant. For information : "Instru Vi" is reentrant with partaged copy "NI Vi", "Virtuel Vi" and "Instr Vi" are not reentrant "LFT Vi" is reentrant with preallocated copy

Hello, I had a slowdown in my system due to a type adjustment. And I don't understand why I have this type adaptation. Why is there a red dot on the local variable that reads data from the property node from a reference, and not from its own property node? I've been using this Vi for years, the clusters change but I've never had a problem adapting to the type... An idea?

Hello, I have a mystery, why this Vi (red with sick written on the inside) which has the same connector and data input type is not compatible with the others? I started from an empty VI, and copy the code. I also tried to start from a Vi that is compatible and replace the code (not the commands)... but nothing to do, as soon as I connect it to the board, the wires break. Do you have an explanation? best regards

After several attempts I finally figured this out and switched to the 64 bit version of labview... Because in the 32 bits version I was getting a memory error when I had a big buffer of images... Thank for your message @Rolf Kalbermatter

Thank you for the information, I feel I will have to do more English 🙃

Yes, 2013, 2017 and 2021 (32 bits) french. 2017 and 2021 (64bits) english. 2013 french (32 bits) => OK 2017 french (32 bits) => NO 2017 English (64 bits) => OK 2021 french (32 bits) => NO 2021 English (64 bits) => OK I think I will work with 64 bits labview version... 🤔

It's strange, because they are protected in 2017 and 2021... Perhaps the installation of 2021 have protected the 2017 Vi

How is it possible to modifiy the NI Vi as you suggest me @LogMAN? I can't on my computer... The Vi are private...

when I say once every 20 to 30 to 30 power outages, it's an order of magnitude... I didn't have fun doing it really... Lately we've had a lot of outages due to machine start-ups and especially to a bad calibration of our main line

Yes, that's why I'd like to change the Vi config so that it writes files directly to disk without going through the Windows cache. I don't often write to the config files. I can't modify the config file VIs or even copy the NI VIs they are private ... I'll end up redoing them entirely if this continues 😤.... I'm tired ☹️

Not always happen, sometimes... perhaps once in 20 or 30...

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?