01-27-2025 03:15 PM
Hey Fancy Folk,
As the title states, LV is becoming non responsive on code that has worked for several years - and to the best of my knowledge has not changed - but has recently become unresponsive. I have 0 idea how to share this code (I can strip out the section that's faulting if needed, but I don't know how I'd actually get my massive input cluster properly initialized to share), so I am not asking "why isn't this working?!?!" Instead, I am trying to figure out what tools are available to me to monitor my code to troubleshoot why it is crashing.
My code is being ran out of 2015 LV dev environment on win7. Thus far, I have been using probes and breakpoints to narrow things down to 1 of 2 cases in my initialization loop. Everything in the init section is a preallocated clone reentrant VIs (I have 4 stations so write once to update all) and both cases have popups in them (both popups are set to the "dialog" option for window appearance), so I cant probe those lines without my FP of my main code becoming unresponsive. Correction, I am unsure how I would properly do this with preallocated clones and modal windows.
I know there are things like desktop execution toolkit and other debugging tools. I have never had to use them before so I don't know what I don't know. I'm hoping someone could point me in a direction to start learning about the debugging tools (NI or windows) to see why my code becomes unresponsive. My best guess is I'm calling something that causes the code to hang, but I have 0 idea how to verify that or know where to start looking.
Thanks,
Matt
Solved! Go to Solution.
01-27-2025 04:14 PM
Hi Matt,
@Matt_AM wrote:
LV is becoming non responsive on code that has worked for several years
@Matt_AM wrote:
[...] troubleshoot why it is crashing.
You have to be more precise:
- Does it become unresponsive (meaning the application hangs and does not respond to user inputs) or does it crash (e.g. with an error message, then aborts execution)?
- Are you talking about a VI running within LabVIEW, about a LabVIEW-built executable, or about the LabVIEW IDE itself?
@Matt_AM wrote:
I have 0 idea how to share this code (I can strip out the section that's faulting if needed, but I don't know how I'd actually get my massive input cluster properly initialized to share)
@Matt_AM wrote:
Thus far, I have [narrowed] things down to 1 of 2 cases in my initialization loop.
If you think you have narrowed it down to a specific VI (your "initialization loop"), then you can still share it with its subVIs (if possible). You can attach a zip file to your comment, which is more convenient with lots of files. Even without "properly initialized" data and some missing dependencies, we can still have a look at the general structure of the code and maybe guess what's wrong.
@Matt_AM wrote:
I am trying to figure out what tools are available to me to monitor my code to troubleshoot why it is crashing.
@Matt_AM wrote:
Thus far, I have been using probes and breakpoints to narrow things down
You actually named the best ones yourself!
Also DETT (Desktop Execution Trace Toolkit) is for far more advanced debugging. It is for example to detect memory leaks or buffer allocations. In your case, it is probably just something that waits indefinitely and blocks everything else.
@Matt_AM wrote:
[...] both cases have popups in them (both popups are set to the "dialog" option for window appearance), so I cant probe those lines without my FP of my main code becoming unresponsive. Correction, I am unsure how I would properly do this with preallocated clones and modal windows.
If you have a reentrant VI, the best way to debug it would be to put a breakpoint at its beginning. When it is reached, LabVIEW will automatically open the correct clone instance, which will allow you to put probes.
If you have a modal dialog that prevents you from showing their diagram, I would advise you to temporarily configure them to "floating" mode instead of "modal". This will allow you to navigate between the windows without being blocked.
Regards,
Raphaël.
01-28-2025 08:47 AM
@Matt_AM wrote:
both cases have popups in them (both popups are set to the "dialog" option for window appearance), so I cant probe those lines without my FP of my main code becoming unresponsive. Correction, I am unsure how I would properly do this with preallocated clones and modal windows.
Thanks,
Matt
There's a front panel property 'behaviour' you can set at runtime making them modal only when called (don't forget to reset them) at the end of the dialog. For clones you'll have to set a break point in original before starting and you'll get the clones to pop up. 🙂
01-28-2025 09:00 AM
Don't forget to consider the hardware if you haven't already. Unless you updated the software or OS since the issue started, there's not much chance of functional code just going bad.
Have you made any changes to the hardware environment the code runs on?
If there are multiple computers involved, is this happening on all of them?
Have you checked Task Manager for High CPU or memory usage?
If you're on a network, has your IT department made recent changes or updates?
01-28-2025 09:14 AM
Just FYI on some basic debugging techniques:
LabVIEW Debugging Techniques - NI
Monitor Execution Time and Memory Usage in LabVIEW VIs - NI
Nice video from Darren if you have the time (~30 Min):
Built-in LabVIEW Debugging Tools - NI Community
01-28-2025 12:38 PM - edited 01-28-2025 12:45 PM
Fancy Folk,
Good news, I figured things out. And it was an issue with how I was checking to see if files existed or not. I will answer people’s responses after my explanation, and I thank you for taking the time to help me with this issue. I ended up grabbing the windows event viewer for the hang but it didn’t help too much. I ended up trying to init the massive input cluster with only the relevant info then step through the 2 cases that I thought were my issue (ends up it was in one of those 2 cases, so at least my hunch was correct!)
Issue and how I solved it:
I was using the “Recursive File List.vi” to find all the files in a directory that contained the pattern “[SN]*tdms” to find all the log files for the UUT (the test is a 3 mo test and I limit the file size of my log tmds to 250 MB). There were a lot of files in the “top level log file directory” and I believe that using the Recursive File List.vi isn’t returning an ack or something to windows, which is making the program hang (Windows “whites out” the screen and I see the (Not Responding) in the top left of the window EDIT: I only waited about 1 min before closing the program, it may have become responsive again after a few minutes, but I am impatient 😅). I changed my code around to use the “get folder names” and search against pattern [SN], then if that folder is found, build a path and search that sub directory for all file names of pattern [SN]*tdms. See image below (Note, the True case is passing an empty array of paths since the rest of my code relies on this array to know if it should load or create a new save file).
Answering questions:
The code was hanging, I was seeing Not Responding in the top left of the window. EDIT: additionally, the windows event viewer was giving me an "Application Hang" error, event ID 1002, Task Category 101 for Application Path C:\...\Labview.exe.
I am running my code out of the LV 2015 IDE (allowed me to debug and update on the fly).
I ended up figuring out how to initialize my massive input cluster (this code was built before I knew OO, which would have made things easier, but I’m not redoing it again :D) and did narrow it down to specifically the “Recursive list file names.vi”
Understood Floating vs Modal, thanks for the tip!
There have been changes to hardware, but it was only sensors (new loadcells) and not NI hardware. My “verify test primitives” that I also use to scale the LC and brakes ran fine for all 4 stations.
There is only 1 computer running all 4 stations. Its become a rats nest of notifiers and randevous during init, but each station/”Top Level” loop only has the controls I care about. There is 1 section in my code where it takes all the “FP controls” and gives that data to the proper loop.
Task Manger CPU and RAM usage showed less than 50% for both.
The PC is on a local network that isn’t connected to the outside world. The network is just for backing up test data and make backups of the PC.
Again, thank you all for helping and offering advice, I really appreciate it!
01-28-2025 02:19 PM
Interesting! And thanks for the detailed reply letting us know how you figured it out. It makes these forums much more helpful to future poor souls dealing with similar issues. Kudos to you!
01-28-2025 03:04 PM
Thanks bud, I try.
My favorite part about troubleshooting is find the exact question I had with a response 2 months later saying "nvm, figured it out" with no more details 🙃. Honestly though, I know I use these forums a lot to help figure out issues and I want to give back how I can. I try to make sure all my posts have some sort of "closure" of "this worked or didnt and heres what I did for future users".
If you want useful posts, you have to make useful posts, and I'm doing my part.
01-29-2025 04:23 AM
Instead of the first file listing you can use 'Check if File or Folder exists', but your solution should work well.
01-29-2025 08:06 AM
@Yamaeda wrote:
Instead of the first file listing you can use 'Check if File or Folder exists', but your solution should work well.
Which one would be more efficient? From my understanding, the yellow blocks are "the LV primitives" and I'm a bit hesitant with 'Check if File or Folder exists' being a "white block macro" since the original method I used was also a "white block macro". I understand there's a big difference between check if files exist and list recursive functionality wise, but the wound is still a bit fresh.
Is there a built in way to see execution time for an algorithm? IIIRC, there are some sort of 'tick' 'tock' vis that can be used to get the execution time of an algorithm. If not, I could do a 3 pane flat sequence structure with the 1st and 3rd pane being a high res clock and middle pane being the algo to check things.
Thanks,
Matt