LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Debug executable breaks after abort

I have an issue which cropped up at some point (so far I haven't been able to find exactly which change brought this about) where my debug-able executables run fine, I can abort and subsequently run them fine, until I connect from the development environment (localhost or remote, no difference). As soon as I do this the run button breaks. If it was running, it will stay running, but the abort and pause buttons no longer seem to function. It it was aborted before connecting, the arrow remains broken and the button does not function.

 

Worse, I can't really troubleshoot the issue, since clicking the broken Run button to "List Errors" from within the development environment, generates no perceptible response of any sort. 

 

This is a fairly complex program, with classes and dynamic dispatch and many other things going on, if that offers any clue.

 

Has anyone come across this before? Any idea what could be causing it? Failing that, any idea how I can get to the bottom of it when LabVIEW doesn't want to list the errors for me?

0 Kudos
Message 1 of 7
(2,251 Views)

When you click the "Abort" button, expect bad things to happen.  I'm guessing this is one of them.  Technically, it is probably similar in concept to when you click the abort button, any open COM ports remain open an you can no longer access them.  Closing the executable should release the runtime, which should clean up after itself.

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
0 Kudos
Message 2 of 7
(2,230 Views)

I haven't had this problem but going off of memory I seem to recall a developer I worked with who did.  This was at least 3 years ago and since it wasn't me with the actual problem, I'm only about 75% sure I am remembering what happened correctly, and even if I am it may or may not apply to your situation.

 

The first thing I remember was that I think it was a 3rd party DLL that caused the problem.  It was either loading it wrong, or from two different places on disk, or two different versions of it... something like that.  While I can't guarantee that's your problem, it's something you could check for, i.e. check that all DLLs that your EXE uses are available to the debug environment and the same version, etc.

 

The second thing I think I remember is the broken run arrow issue being one where yes, it wouldn't say what the problem was, but if you started to open up subVIs that didn't have a problem then they would have a working run arrow.  So there was a sort of a process to follow.  Open up the main VI, see that it's broken, then one by one open subVIs.  In theory some should work, some won't.  Continue tracing subVIs down the line and hopefully you can narrow it down to one VI or at the very least one class or class hierarchy that breaks, to focus where you check on what changed.  If you know some very simple subVIs in your program that you can get to that aren't class members or have anything other than standard LabVIEW functions on them, you could go to them and see if they have a working run arrow to check and see if this option is available to you.

Message 3 of 7
(2,227 Views)

Well, I tried that, and I did manage to dig down to a broken VI with only 3 sub-VIs. Problem is, all 3 of those sub-VIs will run fine. But, there is a dynamic dispatch situation in one of them, so maybe that's something to look at. 

0 Kudos
Message 4 of 7
(2,176 Views)

And I do believe that lead me to a solution.

 

Essentially, I had a grandchild class overriding the grandparent class VI, but with no intermediate parent class override for that VI. By adding an explicit parent-class override VI (which merely calls the grandparent VI), this problem went away.

 

Not sure why that's needed, but I suppose this solution is acceptable. 

0 Kudos
Message 5 of 7
(2,158 Views)

I spoke too soon with that last post.... the solution I described does not, in fact, work. 

0 Kudos
Message 6 of 7
(2,148 Views)

Does the VI in question have anything that's a relatively new addition to LabVIEW?  Like channel wires, VIMs, Sets/maps, etc.?

 

Or any calls to DLLs?

 

Or any code in disable structures (conditional or diagram disable)?

 

Those seem like the things most likely to break weirdly in a situation like this.

 

Any chance you can post actual code?

0 Kudos
Message 7 of 7
(2,142 Views)