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. 😀

[expertnovice]

Thank you, I'll try that and see if I can't find where it's thrown. 

[expertnovice]

It is a very large project with many subVI's. The original developer did use type defs where appropriate and a fair amount of error monitoring which has helped me in the past. Though if I were able to upload the entirety of the project to this forum it'd be likely to cause plenty of grievances I'm sure. 

I've been able to track down errors previously, but those were generated using error handling and would force execution to end. My current error is only in the "debugger window" and occurs every 1 ms essentially freezing my program. This along with the oddity of when it occurs really put me at a loss as to where to even begin.

Someone else also flagged my verbiage regarding "stop execution". I think y'all are onto it here - this project was built to be run as an app by users of the equipment, there is no "stop execution" button. When the equipment is not in use the program idles and when done for the day I believe they would just close the runtime engine. I'm having to add features so I'm running the VI itself. To "stop execution" I'm using the abort execution (red stop sign) button. Which I'm understanding may cause unexpected behavior upon the next execution?

Thanks for the response, I've seen you active elsewhere in these forums and wondered when you would find your way to one of my posts. 

[expertnovice]

I'm glad decided throw your guess in - that's exactly what I'm doing. And unfortunately no stop button on the front, I believe when this was used folks would just exit out of the runtime engine from the idle state. I'm currently adding features so I'm running the main VI. I'll have to consider how I can add that stop button.

Thank you for pointing this out, I'm a new (serious) user of Labview still don't have an appreciate for implications below the surface level of what's going on. You're right about the original developer, he admitted as much to me in one of our few conversations. Such is the nature of our game I'm afraid. 

[expertnovice]

This is standard Labview running off Windows 11 IoT. The PXIe 8842 controller was ordered from NI with Windows already deployed on it. From there I'm interfacing with several other DAQ/IO modules in the PXIe chassis itself along with some external devices. 

Other folks have pointed out that where I said "stop execution" I should have said "I abort execution" which may explain my problem. Currently no other way to halt execution of the VI. Though I've realized the version of the VI I am building off of does not have this problem so it's been introduced by me which does significantly help to narrrow down the problem. 

[Kyle97330]

If you're using the "stop sign" that's likely the cause, yes.

Let's say there's... "something" in your code that gets checked and updated every 1 ms or so, in a loop.

While the details of this "something" are impossible to just guess, imagine it's timed something like this:

1 us: Read current state from a global as a starting point

1 us: Modify state such that the value in the global is invalid now

997 us: do other stuff

1 us: write back a new valid state value to global

If that's the case, then 99.7% of the time when you press the abort button, the loop ends before it can write back a new, valid state.

The ideal solution would of course be to have a proper shutdown process for everything.  I'd start by finding all loops the code is running while it's active, and adding code that stops all of them on some sort of global signal.  If there wasn't already shutdown code for some things because the original author never created code to shut down gracefully, you'll need to add it after those loops.