I have an an exe running right now for an extended time. I am going to do remote debugging but currently have an LED to let me watch program flow. After an extended periord of time, maybe a couple hours, the exe completely freezes. I cant use the stop button and i have to force quit the entire application. Is this common behavior? After i quite the application i was also having issues refreshing the com ports on my computer.
Can you post any code? Usually I see this kind of thing when there's a memory leak (i.e. unbounded growth of arrays or opening too many references without disposing of them.).
Your question is too vague... We need more information.
In addition to posting code I recommend checking out the memory profile tool which can be used in source (Tools >> Profile >> Performanec and Memory), or on an EXE that has debugging enabled when building.
But honestly for the worst of memory leaks that can't be detected I usually resort to trial and error with the binary search method. Disable half the code and see if the memory is stable. Then isolate where the issue is coming from. A few times I've found bugs with an NI function, and a few times I discovered unexpected behavior.
And no this isn't normal, there are LabVIEW applications that run 24/7 for years without any issues.
EDIT: After looking at your source I don't see any places where memory usage should increase forever. Does this happen when you are running in source? If so probe around when this happens, you might just end up in a loop you can't get out of.
If you're building this into an EXE, you're going to want to change the architecture a bit.
Your files get set on startup so essentially when you turn this into an EXE you're just pumping default values in.
How do your file sizes look? I think your Full log and SIC log may be growing unbounded. Keeping large files in memory can cause sluggish interfaces.
Another question is whether you're using USB COM devices. Based on power management settings, Windows can power down USB ports which can wreak havoc on NI trying to handle that over VISA.
Does your device send a termination character? If so, use that. The bytes at porth method is wrong about 99% of the time. I see in one case where you write a command then immediately read how many bytes are at the port and see if it matches "DONE" (after you've cleanned off some white space which may include termination characters. Suppose there are only 2 bytes at port "D" and "O" when you check it? You read 2. It doesn't match. then you read more. Perhaps the "N" "E" and a termination character. They won't match either. Now you are stuck in that while loop.
Put some indicators in your VI and other logging functions that will help you debug to see what parts of the code are executing, and what aren't.
So Full Log is looking like 5MB after 50 cycles. This application could run a while. SIC LOG is much smaller. How should i handle that and handle opening log at startup?
Also, Yes i am using USB Devices. Do i need to change setttngs in windows? because that was a suspision of mine.
I do have a CR as my termination Char from that COM device. All COM ports have some sort of termination char to parce the code so i get the entire string im looking for, but as you say it actually just got stuck in that loop looking for "DONE", first time ive seen that. What would be the proper way to search for "DONE"?