Francois Aujard

@hooovahh your are "sherlock holmes" 🙂. I don't know exactlly what Magna represents. I just know our hydraulic benches (taps and cartridges testers) are in West Egypt. Magna is a middleman (reseller, intermediary, I don't sure of my word)... For my problem, the patch f1 of the Labview 2021 SP1 version seems solves it. I don't know why the informaticien don't installed me the last version 😒... I think he install a ghost of a hard drive.

@HYH Thank you very much for your reply. I upgrade Labview 2017 to Labview 2021 next year, and your message does not reassure me One CEO simple stated he won't allow 2021 in his company. Who is it? Best regards

Yes I an agree with you, but it is always the same measurements with the same names. I replace the value and I never add new value. I add new value only at the begenning. A new channel voicie, OK I update my table size, but after it's just replace. I already add table size to be sure it's not increase. And the size don't increase

@hooovahh thank you for your reply. Yes it's a very simple VI, it's for that I don't understand. I do not have the problem when I make an *.exe.... it's strange... I don't understand your sentence "Like the terminals should be on the root of the diagram for subVIs"? The command "Value et noms IN" out of the IF structure? The string array does not need to be re-indexed with the element structure in place... It's an old VI. We asked a specialized company to develop our acquisition. There are a lot of things I would like to change... everything in fact and start again on a good basis. But I am running out of time... I'm not sure this FGV is a great idea. what is the best solution to combine several different acquisitions on different devices? That is the question ! Yes I work for Magna, how do you know? I make hydraulic bench for us. We have actually a cold and hot water generator and 3 endurances benches in construction ! What company do you work for?

@Gribo I don't have the same numbers of channels in the table "MESURES" (inputs channels) and "RETOUR CONSIGNE" (outputs channels). Why is suspect? This functional variable global is use in all the acquisition loops. it centralizes the measurements that come from different types of acquisitions. Example : - One loop ask diverter in Modbus and update the modbus channels - One loop ask ethernet mainboard and update the associates channels - One loop ask NI board etc...

Hello everyone, I need help figuring out what is going on and what I am doing wrong. I have benches with windows 10 and labview 2017. No problems, the benches are working fine. I want to upgrade to labview 2021, and the surprise, the memory increases.... I isolated the vi that increases the memory (Instr_FGV_MesuresVrac.vi), but I don't understand why? Can you help me and explain why? I think it this part of the code : In my general code I initialize the vi at startup and then I have 3 loops that SET always the same measurements and one that GET. There is no addition of measurement channels. I have 2 tables of 30 measures. This code is use on other computer with windows 10 and Labview 2021 and no problem, but in some computer I have problem... Best regards PB Labview.zip

@ensegre and @Rolf Kalbermatter Thank you for yours replies ! I love this forum, I learn a lot of interesting things! 🙏

@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...