Debugging the debugger advice

[expertnovice]

After I stop execution of my VI, if I attempt to run again without closing out and reopening the VI I get an error in the debugger window every 1 millisecond "error in wait4value: index array is corrupted". I then must stop execution, close the VI, and reopen upon which I can run my VI once before getting this debugger window again which essentially freezes LabVIEW. I do not know what "wait4value" is. I inherited this LabVIEW project and do not see a sub VI with that name, but at the same time have had no hits in searching the internet for this. 

I do not have to close LabVIEW, just my VI between successful runs. 

I have no clue how to go about debugging this - any tips?

LabVIEW 2019 running on a Windows 11 PXIe 8842

[Kyle97330]

I'd start by doing a search through all the code.

Load your project that contains the main VI you run at the start.  Add in anything called dynamically if that happens in the code (i.e. something loaded by path, rather than a direct subVI call).

Then just do a "control-F" to open up the Find window, and select "All VIs in application instance", and search for "wait4value".  If you get no hits on that, try other elements of the debug message, like "index array is corrupted".  The hope is that you will eventually track down a VI somewhere that sends that debug string out as a message to your debugger window.

[altenbach]

It seems to me this is LabVIEW RT (and not a plain LabVIEW problem). Can you explain in more detail your setup?

[Bob_Schor]

The Good News is most of the long-term LabVIEW users accessing the Forum will be able to open your LabVIEW 2019 code and (possibly) understand where your code is going astray.  The Bad News is you failed to include your code, so we "don't have a clue" to suggest what might be going astray.

I'm guessing (because you describe it as an "inherited LabVIEW Project") that a fair amount of code (hopefully with a lot of carefully-written sub-VIs, wide use of TypeDefs for project-specific Data Structure and Variables, proper use of the Error Line to not only "flag errors", but to help you sequence computations that need to be run sequentially (run the Error Line from "Computation 1" to "Computation 2" to ensure that "1" gets done before "2").

Ideally, we need to see the VI that seems to be causing the problem -- maybe even the entire Project.  But you might be able to do some of this yourself.  Do you know how to use the LabVIEW Debugging Tools?  Do you know about "Probes" (which you can put on a Wire and when the value on the wire changes, an indicator will be updated to the new Wire value) and "Breakpoints" (which, when encountered, (temporarily) stop program execution)?  Playing around with carefully-placed Breakpoints and Probes can let you narrow down where in your code the values in the Wire(s) appear to be wrong.

Are there colleagues around who know LabVIEW?  Try a code review with them -- walk them through your code and explain what the code should be doing.

What do you mean by "After I stop execution of my VI"?  Is this the same as "After my Program finishes and removes itself from memory"?  Does this mean LabVIEW exits and the program effectively "leaves memory", or you somehow (how?) temporarily stop the Program from executing (such as wiring "True" to the "Stop" control of a While Loop to get the Loop to exit and nothing is wired to outputs from this Loop)?

Bob Schor

---

[rolfk]

Without actually seeing the VI in question we can only make wild guesses. And as you can see they go in many different directions including that it may be on a realtime hardware. I throw in another one. Does stop execution mean that you press the abort button in the toolbar? If so that is not a stop but an abort. It’s similar to stop your car by running it into a wall or tree. A sure way to stop it but with potentially quite a bit of collateral damage in the form of unclosed resources, locked internal application states that your program logic forgets to try to unlock on startup, etc. etc.

Your program should have a stop button on the front panel that causes all it’s loops to end execution and do any cleanup tasks needed to close any resources, resets controls and internal states to a sane value. And ideally your startup procedure is also programmed such that it can deal with some of the internal states not being in their default value.

it sounds like the program you inherited was written by someone knowing enough LabVIEW to be dangerous with it but not quite enough to realize how dangerous they can be. 😀

And you have some learning to do to get there and some more to get beyond that. 😀