Michael Aivaliotis Posted October 16, 2007 Report Share Posted October 16, 2007 Ok, this may be a bug, I (or LabVIEW) may be retarted, or fill in the blank. How do you debug callback VI's? I assumed that you could just put a breakpoint in the callback VI and the instance would break, but it doesn't. Any ideas? Quote Link to comment
Darren Posted October 16, 2007 Report Share Posted October 16, 2007 What kind of "callback" VI are you referring to, i.e. how specifically is the VI being called? -D Quote Link to comment
Michael Aivaliotis Posted October 16, 2007 Author Report Share Posted October 16, 2007 QUOTE(Darren @ Oct 15 2007, 12:09 PM) What kind of "callback" VI are you referring to, i.e. how specifically is the VI being called?-D Using the Register Event Callback node. Quote Link to comment
Darren Posted October 16, 2007 Report Share Posted October 16, 2007 I'm trying to figure out why the breakpoint isn't being hit when the callback VI executes. In the meantime, I found a potential workaround (that requires access to scripting). You can put a BDWin.Open property in the callback VI to cause its diagram to open on the first call of the callback. On any subsequent calls, you can probe wires and the probes will return the wire values. This method won't work if you are only interested in debugging the first call of the callback VI. I'll post here when I find out more about why the breakpoint doesn't work. -D Quote Link to comment
Dean Mills Posted October 16, 2007 Report Share Posted October 16, 2007 I am trying to remember, but I think you can turn off the reentrancy, turn on debuging, open the diagram and fake it. I have very vague memories of debugging a callback VI like this. Not using a breakpoint but just opening it, its diagram and using probes. Dean Quote Link to comment
bbean Posted October 17, 2007 Report Share Posted October 17, 2007 QUOTE(Dean Mills @ Oct 15 2007, 04:25 PM) I am trying to remember, but I think you can turn off the reentrancy, turn on debuging, open the diagram and fake it. I have very vague memories of debugging a callback VI like this. Not using a breakpoint but just opening it, its diagram and using probes.Dean Dean's right. Don't forget to return settings to normal after your done debugging. Sometimes not having reentrancy on can screw up some events. I also use the attached tool to record event occurrences as they happen to a file. Quote Link to comment
Darren Posted October 19, 2007 Report Share Posted October 19, 2007 After I did some investigating, it seems like a breakpoint in a callback VI *should* be fired whenever debugging is turned on and reentrancy is turned off on the callback VI. Unfortunately, this isn't happening. I've filed a CAR (4EH9RQF2) on this issue. For now, I see three possible workarounds: (1) use the BDWin.Open property to open the callback VI diagram and probe wires on non-initial runs, (2) stick file I/O in the diagram of the callback VI to write debugging info to disk when it executes, and (3) the callback execution recorder utility posted earlier. -D Quote Link to comment
Wolfram Posted October 23, 2007 Report Share Posted October 23, 2007 I prefer not to process any callback in the callback VI itself. What I do is to fire events of any callback into a single queue, by which queue element is a cluster of an enum [state or callback name] and a variant [hold the data]. An existing centralized queue state machine will than process all events of all callbacks. Make the enum "state" as type def for easy and fast adding of new states. Wolfram Quote Link to comment
Thang Nguyen Posted January 31, 2008 Report Share Posted January 31, 2008 QUOTE(Darren @ Oct 15 2007, 02:13 PM) I'm trying to figure out why the breakpoint isn't being hit when the callback VI executes. In the meantime, I found a potential workaround (that requires access to scripting). You can put a BDWin.Open property in the callback VI to cause its diagram to open on the first call of the callback. On any subsequent calls, you can probe wires and the probes will return the wire values. This method won't work if you are only interested in debugging the first call of the callback VI.I'll post here when I find out more about why the breakpoint doesn't work. -D Could you please tell me where I can find the BDWin property node? I am currently working on the callback VI with ActiveX, and I have no clue how it works. Thank you so much, Thang Nguyen Quote Link to comment
LAVA 1.0 Content Posted January 31, 2008 Report Share Posted January 31, 2008 QUOTE(Michael_Aivaliotis @ Oct 15 2007, 02:23 PM) Using the Register Event Callback node. I feel your pain, Mike... I had a strange bug that I assumed was a race condition. The value would get set without being triggered.. I fixed something else, unrelated, and it worked fine. There was a discussion about this on the NI forum. But I must admit that I'm still a novice with these Callback Events.. Quote Link to comment
Ton Plomp Posted February 1, 2008 Report Share Posted February 1, 2008 QUOTE(Michael_Aivaliotis @ Oct 15 2007, 08:04 PM) ..... but it doesn't. Any ideas? A pop-up, or a logfile Ton Quote Link to comment
Darren Posted February 1, 2008 Report Share Posted February 1, 2008 QUOTE(Thang Nguyen @ Jan 30 2008, 10:04 AM) Could you please tell me where I can find the BDWin property node? As I mentioned in my previous post, this property requires access to VI Scripting. Search around on the LAVA forums for more information on VI Scripting. -D Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.