Code taking increasingly long to Run a Loop

[BrendanWH]

Hi I am extremely new to LabVIEW and cant seem to figure out how to fix a bug I've found in my code. The code is being used to create a data acquisition program that will be using a chassis with 6 thermocouple cards so up to 96 TCs. Right now using the program everything seems to run fine setting the wait ms function to 1s gives a sample rate of 1s and logs the data appropriately. The problem however is that if i leave the program running for a day or more to simulate long term temp testing it becomes increasingly longer between samples and logged data. The code here is by no means finished but this seems like a major issue to fix sooner rather than later. From investigating the code with the highlight tool it seems to be getting slowed down by the loop that converts the numeric value to a string but this is a requested feature by engineering and techs in order to reduce confusion. Anything done in a method not deemed best practice in the code can be mentioned and I would happily fix it though different versions of this file have fixed some issues already. I apologize if this issue is something already reviewed in the forums though I could not seem to find anything close enough to resolve the issue unless its a memory issue. 

[BrendanWH]

one example of something fixed is the file name in is now in the loop that runs after start is hit. 

[AlbanR · Accepted solution]

Hello BrendanWH,

The fact that the code slows down with time indicates a memory problem somewhere with the data incrasing.

For what I see of you code, my first thought would go to the TDMS record because this is the only place in your code where the data is stored (and in the waveform chart, but there is a 1024 points limit so it seems fine to me) :

Have you check its size after a day or more ? If it is more than a few hundred Mo, then you should insert a function that automatically create a new file (with incremented name like FILENAME_01.tdms) after X records, or when the files size is X Mo.

There is an other point with files : when you use the Open function, if the file is big, it can take some time to execute. My suggestion is that  you open it before your loop, and you close it after (or/and when you create a new file a suggested). That way, the file is always in memory and you add your value to it. It can still takes some time if the file is really big.

I do not see why your conversion loop would take more time over time since there is always the same number of channels to read.

In general, I recommand you to use subVIs in you code for readability (for initialization by example).

Edit : even a few hundred of Mo can be pretty big to use with a read software, I recommand you not to go this high.

Regards

[aputman]

• Use a proper program structure.  Event loops are made to be used to handle multiple events but that event structure can only handle this one event.  After Start Test button is pressed, that structure is no longer accessible.  I suggest to find a good state machine architecture (I personally like JKI State Machine). 
• Why do you open and close the TDMS file in every loop iteration?
• Don't use absolute path constants (c:\users\brendanh\....) because these paths likely don't exist on other machines.  There is a VI called Get System Directory that will return a path to the user's My Documents folder.  From there you can build a path for storing the files. 
• I don't understand what you are doing in the bottom case structure with while loop.  Are you checking if a file exists by opening it?  There is a function in the Files palette called "Create File with Incrementing Suffix".  I think this is what you are attempting to do.
• Don't use Detected Probes control as a data transfer method.  Use the wires directly and change the control to an indicator for display.  No need for the local variable. 
• ...

[BrendanWH]

Okay thank you AlbanR! that could be the issue the only reason I mentioned the conversion loop for the numeric was because that was something I couldn't really find anything similar too and made from scratch with zero references so I assumed it may be wrong and when ever I used highlight execution it always seemed to be hung up there. Is there an easy way to check the size of a file?

[AlbanR]

There are file functions such as "Get File Size" in the advanced file functions.

About your code, Aputman is right, if you want to make a clean code, these are points I suggest you to correct. That way, it would be more scalable, have less bugs and work on multiple computers.

Edit : i don't know why my first answer disapeard...

[BrendanWH]

aputman, thanks for the tips! I will look into "proper program structures" and I am aware that that loop is no longer accessible afterwards we were using it in that matter so that once the settings were updated it locked out that tab and the settings you selected to remove the possibilities of some errors. and as for the absolute path that isn't going to be the final path its just set to that right now so i can easily view files and make sure things are doing what I want them to do. The general plan as far as file path goes was to either save it to a network location(if possible) or do what you were explainign where it would get saved to that hardware's local documents folder. When the program is all said and done it will not include that but thank you. and yes the bottom case structure was doing that i was unaware of the create file with incrementing suffix function haven't run across it until you mentioned it here.

[BrendanWH]

Thanks getting back from a vacation I had left the system running for a week to test the long term stability and all seems to be running extremely smooth. Just for reference I'll explain that originally the TDMS file writing was structured the way it was because it allowed users to open the file while the test was running to see the data up to when they opened the file in excel. This made it so that they could view historical data in the long term with all the user friendly excel functions and such. But moving it outside of the loop makes much more sense so thank you this seems to have fixed the code, I now understand that closing and opening the increasingly large file was what was causing the system to slow down so much. Ive made some other improvements based on the other users inputs but network software issues make it so I cant download 3rd party State Machines so I will just further explore their structures based on examples again. Thanks for giving the solution but also thank you to the other user for their input as well it is much appreciated!

Thank you,

BH

[AlbanR]

Glad it solved your problem.

I figured out that opening the file was the intention behind the structure. I did it a few times, but it is often problematic (like the problem you had), so now I make myself clear that the file cannot be openned while running.

It is not really user friendly so you can think of solutions to display some long term statistics so that users can be aware of how their tests are running. In the end, it is usually not a real need.

Have a good day

[BrendanWH]

Yeah, now that the problem was identified to be that specifically we are taking that option out even thought it was requested and liked, if it doesnt work it doesnt work. The next step being worked on is exactly what you mentioned adding in some long term statistics displays such as max values, averages over certain time frames and delta values for temp over the last 60 minutes. Once again thanks for all the help best of luck with all your LabView programs in the future!