LabView Stack Trace or Call Stack / Tracing

[geirove]

Hello,

I am using LabView 8.0.

I am becoming utterly frustrated by not being able to see **who** is calling the code where I set a break point. All programming languages with a Debugger can show you WHO called a method / function when you set a breakpoint there, but not LabView ?

I have developed an error in a system whereas "some code" is setting an unwanted state of a switch, I can set a breakpoint there and see that it happens, but I cannot find out who the caller is !

Please help !

Geir Ove

[Darren]

Assuming you're not dealing with dynamic VI calls, you can view the call stack ring in the toolbar when a breakpoint is hit in a VI. It's normally the font ring, but when you have a running VI that is paused at a breakpoint, it becomes a call stack ring, with a top-down list of the VI call hierarchy all the way down to the VI with the breakpoint.

-D

[Tomi Maila]

What about placing a "call chain" node next to the break point and placing a probe to it?

EDIT: Darren gave a better answer while I was posting mine.

[PJM_labview]

And for a 3^rd way:

View>Browse Relashionships>This VI Callers

Note: same restriction that Darren mentioned (no dyn call).

[Aristos Queue]

QUOTE(PJM_labview @ Feb 14 2007, 03:54 PM)

Note: same restriction that Darren mentioned (no dyn call).

Just to clarify -- "no dynamic calls" does not apply to the dynamic dispatch VIs of LabVIEW classes. If you call into a dynamic dispatch subVI, the call stack will show up just fine, thank you. I think it also works when you use the Call By Reference Node, but I don't know for sure. I assume that PJM_labview and Darren are talking about VIs running with the "Run VI" method. Those are definitely not in the call stack because the Run VI method is equivalent to kicking off a new top-level VI.

[Darren]

Wow, I didn't know the menu ring worked with Call By Reference nodes. But I just tested and apparently it does.

-D

P.S. - In my original post, I mentioned that the order is "top-down"...actually, the top of the hierarchy of calls appears at the bottom of the list, and the direct caller of the VI with the breakpoint is at the top.

[geirove]

Thanks everyone. BUT I am trying to track the Source of an Event:

I have SubVi's that use the "Property Value (signalling)" to fire Events in the Top VI: I am setting a breakpoint in the Top VI and it will break when someone is setting a Value for e.g. a Button by e.g. writing a True value to "Property Value (signalling)" in a SubVi.

Problem is I will not get any Stack trace the way suggested here for the Events .... -

A solution anyone ?

Geir Ove

[PJM_labview]

QUOTE(Aristos Queue @ Feb 14 2007, 04:09 PM)

...I assume that PJM_labview and Darren are talking about VIs running with the "Run VI" method...

Yes, this is why I meant.

QUOTE(geirove @ Feb 14 2007, 04:23 PM)

Thanks everyone. BUT I am trying to track the Source of an Event:

I have SubVi's that use the "Property Value (signalling)" to fire Events in the Top VI: I am setting a breakpoint in the Top VI and it will break when someone is setting a Value for e.g. a Button by e.g. writing a True value to "Property Value (signalling)" in a SubVi.

Problem is I will not get any Stack trace the way suggested here for the Events .... -

A solution anyone ?

Geir Ove

Ah, I see. I only have one suggestion in this situation, and you are probably not going to like it. Find in your code all the SubVIs that invoke the "Property Value (signalling)" and wrap it in a subVI. This way you will be able to set a brake point in this VI to see who is calling it.

PJM

[Chris Davis]

Another suggestion might be to use the caption property of your control as a method to display where the call was made from. Not easy either, but it might be the quick fix you are looking for.

[Aristos Queue]

QUOTE(geirove @ Feb 14 2007, 06:23 PM)

Thanks everyone. BUT I am trying to track the Source of an Event:

That's a very different thing than the caller of a breakpoint. When an event executes, there is no caller per se -- the event fires off into space and is caught by someone, but the code that fired the event is long since finished firing it off and has gone on to other tasks. This is true in any programming language, but is especially true in LV where multiple threads of operation are always in play (as opposed to C/C++/Java/etc where extra threads are only spawned when user explicitly asks for it). Debugging event systems generally requires that you include information in the event that records the source of the event. In LV, you might be using user-defined events. If so, make your data a cluster... part of that cluster is the data that you actually want to transmit. But also in the cluster, include a string. When you fire the event, set the string using the Call Chain primitive. That way, when you catch the event in the event structure, you know from whence the event came.

The Value (signaling) method of throwing an event doesn't allow you to do this. So the other common trick is to take the string from the Call Chain primitive and add it to a Queue. When you catch the event, dequeue the string. Since events are caught in order that they are fired, you can be guaranteed that the item at the front of the queue is the string for the event you just caught.

Here's a VI to show you how to detect where a Value (signaling) event is coming from. I've used name strings for the two loops instead of the Call Chain primitive so that I could put the whole demo on one VI diagram -- it makes it easier to understand what's going on. The semaphore locking is necessary to make sure that each loop does its value signaling and enqueueing without the other loop jumping in to do its own value signaling and enqueuing (possibly multiple times) in between.

VI is saved in LV8.2

[Yair]

Crosspost.

QUOTE(Aristos Queue @ Feb 15 2007, 08:31 AM)

So the other common trick is to take the string from the Call Chain primitive and add it to a Queue. When you catch the event, dequeue the string. Since events are caught in order that they are fired, you can be guaranteed that the item at the front of the queue is the string for the event you just caught.

That is assuming you are following the recommendations and not monitoring the same event in more than one event structure, in which case only one structure will be able to dequeue and the other will either time out, get stuck or dequeue the next element.

(and please don't lecture on not monitoring the same event in more than one structure. I haven't done this myself, but this is not something I'm ruling outright if it would be appropriate and the necessary precautions are taken).