How to determine the position in code after pause/abort

[AlexHofi]

Hi there.

I've been searching for this for quite a while now, but I didn't find a solution, although I might just have looked in the wrong direction.

Problem is: I'm trying to find a way to see where my program was (i.e. which part of the code it was execution) the moment I click on pause or abort. (Like the "pause" button present in most modern IDEs, when pressed, it halts the tread and jumps to the code-line or ASM-instruction the CPU was executing).

The reason: I'm using LabView to control a few instruments to do some measurements on OPVCs. During long measurements involving multiple parameter-sweeps and hence numerous reconfigurations of both function generators and scopes, the program sometimes stops, or better "stalls".
That is, the front panel's still responsive, but the measurement stops. I don't know whether the problem is related to my program or the scope (it's a LeCroy 434 Wavesurfer) or the FG (a Tabor series) - but I cannot find out either because I don't know what the program did last. FYI: when watching the program's execution using the Execution Highlighting tool, the error doesn't show up, so I guess it's some sort of timing issue.

I'm currently installing the Execution Trace toolkit in the hope it will help, but still, any help would be great!

Thanks in advance

Alex

[Mark_Yedinak]

You can also use the profile tool to see what VIs are being run the most as well as which are using most of the time. Without seeing your code it is impossible to say what might be the issue but this does sound like an issue with your code and not the scope.

[LV_Pro]

Another way is to write messages to the operator interface, or a debug file, to show what is happening. If this is running in the Windows environment, a way we use here is to have a sub-vi that writes to a Windows "kernel32.dll" call "OutputDebugStringA" which we then monitor with a free MicroSoft utility "Dbgview.exe" we then drop this sub-vi throughout our program to show what is occuring at each location.

The pause does pause execution, but it will not send you to the last the thing that is executing, as LabVIEW may be doing parallel execution that could have no actual meaning, the execution not being, by definition, sequential.

You can also place "probes" in the diagrams, to watch what is executing, and these can be conditional, to pause the program at a point when certain criteria are met.

To paraphrase a major contributor here, "using the abort button to stop your program is like using a tree to stop your car, it can have unintended consequences"

[AnalogKid2DigitalMan]

Putnam:

Thanks for the tip, even though I have used DebugView to assist in dll calling issues, I never knew that you could call it's dll in other applications.

I will give it a try shortly!

-AK2DM

[AlexHofi]

---

@LV_Pro wrote:

Another way is to write messages to the operator interface, or a debug file, to show what is happening. If this is running in the Windows environment, a way we use here is to have a sub-vi that writes to a Windows "kernel32.dll" call "OutputDebugStringA" which we then monitor with a free MicroSoft utility "Dbgview.exe" we then drop this sub-vi throughout our program to show what is occuring at each location.

---

Hmmm, well - I've been using OutputDebugString in my C/Pascal-Style programs very often, but I didn't think about it this time -  thanks for the hint!

---

To paraphrase a major contributor here, "using the abort button to stop your program is like using a tree to stop your car, it can have unintended consequences"

---

That's doubtlessly true - but if you've got no other possibility left?

But - as labview IMHO doesn't expose the number and properties of the threads it creates, you might be right; the "exeution position" within the block diagram might not be as well defined as I thought it would be.

I'll try the OutputDebugString-Approach and the Execution Tracer toolkit as well. Thanks for your hints!

[LV_Pro]

Do you have any other means to stop your program currently? I know that, particularly when we are trying to get a program to run and some part goes off into "La La Land", so that any "stop signal" set else where in the program has no effect, ideally there should be a signal from the user interface that signals other loops, etc., to "gracefully stop" (home mechanical parts, closing out files correctly, inserting the reactor control rods, things like that), which doesn't happen with the "Abort". But, as alluded to before, sometime what has stopped responding will never get a "normal" programmatic message to stop. Had to go to the next level, just today, of using Task Manager to stop a process that was keeping my program from closing. Even more possible repercussions that the Abort!

[AlexHofi]

---

@LV_Pro wrote:

Do you have any other means to stop your program currently?

---

Yes, in theory... in the last few minutes I reviewed some code I wrote months ago when starting with the development and saw some possible dead-locks with the UI. I have two "Stop"-Buttons, one that stops the measurement and one that exits the wohle program, the latter via an event, the first get's polled in the measurement loop via reference. I read elsewhere that this might not be the best way of doing it, as accessing the UI outside the main event loop might cause some problems.

I've got some spare lab-time today and will look into this again, unfortunately I cann't test the OutputDebugString-Thingy on my development machine as it's on linux.

Anyway, it's quite exciting that I finally found a board where peopple really try to helpt, even if the questions ask might not be as constructive as theay could/should be. Thank you very much for that!

[Mark_Yedinak]

---

@AlexHofi wrote:

---

@LV_Pro wrote:

Do you have any other means to stop your program currently?

---

Yes, in theory... in the last few minutes I reviewed some code I wrote months ago when starting with the development and saw some possible dead-locks with the UI. I have two "Stop"-Buttons, one that stops the measurement and one that exits the wohle program, the latter via an event, the first get's polled in the measurement loop via reference. I read elsewhere that this might not be the best way of doing it, as accessing the UI outside the main event loop might cause some problems.

I've got some spare lab-time today and will look into this again, unfortunately I cann't test the OutputDebugString-Thingy on my development machine as it's on linux.

Anyway, it's quite exciting that I finally found a board where peopple really try to helpt, even if the questions ask might not be as constructive as theay could/should be. Thank you very much for that!

---

Generally it is best to keep UI elements out of your processing code. Not only will a property node force execution to the UI thread it also tightly couples your UI and processing tasks. The prefered method is to use some type of messaging to the processing tasks. This can be implemented using queues, notifiers or user events. Your processing tasks now have a defined interface for interacting with them which makes reuse of the code easier. It is also more maintainable since you can completely change the UI without requiring a change to the processing code.