01-14-2015 05:57 PM
You could do a text search to try to find the name of the file that isn't being found.
01-14-2015 07:26 PM
Here's what I ended up doing:
Put about a gabillion probes on different case structures that had file references in them. Hit run (normal speed) and counted loop iterations of all 8 main loops. They stopped at the second iteration. If I hit continue on the error, one loop would run like crazy while another error threw... 8 clicks of Continue and they were all running.
There are two case structures in each that have file references in them, so I case-structured out 7 of the 8 main loops and ran the one slow with highlight execution - it stopped when it got to the second case structure. In it was a subvi, in a subvi, which had a file reference that was one character off -- and that reference had been copied 8 times.
Long story short, I need to go back and put in some error handling in this thing, but the highlight execution and probes really helped. I was hoping for a quick and easy 'click here for verbose logging' like Windows, but it worked.
Thanks all.
01-14-2015 07:33 PM
This sounds like a situation where a breakpoint or conditional probe might have been more useful. They would allow the program to run at full speed until execution reaches a certain point (breakpoint) or a particular condition is met on a value (error boolean = True). The program pauses, you turn on highlight execution then let it resume.
Hardcoding file paths can have its drawbacks also, as you discovered.
Lynn
01-14-2015 07:57 PM
Just glad you were able to hunt it down. 🙂