LabVIEW takes an hour or more to exit

[anonamouse]

I am using LabVIEW Professional 2020 on a Dell optiplex with i5 and 8Gig ram running Windows 10.   There are three cDAQ chassis.  We are reading 56 thermocouples using 9211 modules, 21 dc volts using 9209 modules, another 10 dc volts with a 9205, and controlling around 40 analog volts out with 9623 modules. The program is a producer consumer with 12 while loops.  Two of the loops have event structures in them.  We are using 20 thermocouples and analog out channels to run heaters with PID control. We are also talking to 18 serial devices that control flow, switch valves, and read power consumption.  The front panel is on a nice 4K panel with 8 dynamically allocated charts in multiple tabs that plot everything. 

All the loops are stopped by the same local variable and when stopped feed an error channel wire to a big merge error function and also turn off a light so we know the loop is done.  (some take longer than others but in 10 seconds all the while loops are done.) After the merge error the data file is closed, a pop up box pops up saying the file has closed, then the program is done.  I used to be that it would then turn the background to graph-paper and you could re-start, edit, etc. One day something changed.

If the program runs 30 minutes it takes 10 minutes to get the prompt back after exit.  Yesterday I ran for 3 hours.  After an hour the program was still chewing core although everything was done.  I ran task manager.  The program is using 75 to 80 percent of CPU when running, when the final step is done the cpu activity goes to about 45 percent and LabVIEW chews core for about 1/3 to 1/2 the length of time it was running.  I thought maybe it was garbage collecting but resource monitor reported that it was waiting on threads to complete network activity.  That is a puzzle because there is no network activity going on other than the machine is connected to SharePoint.

Has anyone else seen this kind of behavior?

[Andrey_Dmitriev · Accepted solution]

Yes, it looks like garbage collection at the exit. I've got the same in the past with references. Technically it was continously growing amount of the references to dynamically opened SubVI. It was not significant memory leakage, but huge time penalty on the exit. Check in your while loops that you haven't such references, which opened again and again. Desktop Execution Trace Toolkit can catch this, but I'm not sure if you can use it with cDAQ chassis.