Community Documents
Overview
Run time debugger that runs in a seperate thread from your main program. Allows you to pause and step through your program on a computer without Labview development system.
Whats included:
-All required vi's
-Labview project file
-Labview library file
-.mnu file to place in your directory
-custom .ctl file for a labview silver variety button
Description
Hey guys, I'm back and this time I've decided to upload an entire project library that I have been using for over a year now and has really decreased my debugging time when running code on computers that do not have labview development system.
There's quite a bit to go over so let's start with what the debugger looks like:
This is a seperate panel that will be opened if and when you choose to activate the debugger (I made the background dark blue to easily distinguish it from other frontpanels).
The blank area is a rich textbox and text is stored in a tree hierarchy. For example:
Data can be sent to the debugger in different levels: Header, subtest, layman, step, data. You don't need to make use of all these levels and the nomenclature is more geared to my specific application but is arbitrary. Each entry is also paired with a timestamp represented by number of seconds since the debugger was opened. If the levels are implemented correctly, you can easily hide and view information for different sections of a program.
Also, data can be stored in different colors as seen above. The default color is black, but any color can be used by appending "&&%d" to the end of the end of your string and wiring a colorbox constant into the "format into string vi". For example sending "error&&16711680" will add a line with the text "error" in red. Here I've picked blue to represent any data being transfered over GPIB.
Buttons
-Play: allows your code to execute normally and displays all debug info
-Pause: Will stop your code from executing the next time it reaches a debug node at the "step" level
-Next: When the debugger is paused, will allow your code to continue to the next node and then automatically pause again
-Print: Will write all text to a previously specified text file
-Close: Closes the debugger and allows your code to resume normally
The best part about this library is that you only need TWO different vi's to run this debugger in any program, as shown below:
Open Debugger
Pretty simple, opens the debugger. There is one input where you can specify where the text is stored if you hit the print button. This vi is not the debugger itself, it remotely opens the debug panel in a new thread. Generally, I place this vi in an event structure to be called when a button is pressed but a case structure also works.
Note: there is a mysterious boolean input on the top of this vi, just leave it alone but do not delete it. (For some reason, because no vi in this library calls the debugger directly, labview automatically excludes it when you build the library. I could not figure out why because I placed it in the 'always include ' section. So I tried placing it in a case structure within the open vi with a false constant wired to it so Labview would know to include it, but to no avail. Finally, I got labview to include the vi by changing the constant to a control. It's a bit sloppy, I know, but ultimately harmless.)
Debug Node
This is the vi that you will use the most. Just place these anywhere along your error line. If the debugger is not open, they do absolutely nothing and your code will execute as if they were not even there. If the debugger is open, each node will add a line to the debugger textbox. In the example above, "This is step 3", displayed in pink, will be added at the second lowest level. "Step" is the only level that the debugger will pause on. In other words, if you press pause, your test will continue to flow past any nodes at the Header, Subtest, or Data levels. You can also use this node to clear the entire debugger or pause the debugger programatically.
If an error reaches any node, the test will automatically pause and report the error's source in red. You can resume the code by pressing play but nodes will remain inactive until a node is reached with no error.
The Debugger is only as effective as you make it
The more nodes you place, the more resolution you have in terms of feedback from the test. Also, the more descriptive, the better. If you wanted you could have every node just use its default level: "step", and what you would have is a straight list of all your debugger notes. However, by making use of different node levels, you can quickly narrow in and view a small section of your program.
Example:
This is an example of what the output would look like with different node levels in the order they appear in your test.
Nodes:
Header1: Header
Run for loop: Sub Test
Iteration0: Step
Output=1 Data
Iteration1: Step
Output=8: Data
Iteration2: Step
Output=5: Data
Condition x has been triggered: Data
Header2: Header
Output:
Header1
Run for loop
Iteration0
Output=1
Iteration1
Output=8
Iteration2
Output=5
Condition x has been triggered
Header2
All of the sub nodes contained under "Run for loop", for example, can be hidden or expanded with one click
Here is the debugger button that I created and decided to include as debug.ctl:
feel free to use this as your control.
Future Development
Depending on the amount of feedback I get, here's a couple of things I was thinking of improving:
-Make the debugger resizeable. Right now it is not
-Allow users to control step names, number of steps, debugger color, pause conditions
-Right now the scroll bar is pretty choppy if large blocks of text are sent as one line
As always, feedback is appreciated and I hope you guys find this as useful as I have.
Steps to Implement or Execute Code
- Download Debugger.zip
- Extract the files and copy Debugger.llb and dir.mnu into C:\Program Files\National Instruments\LabVIEW 2012\user.lib\Debugger (or your equivalent directory)
- The dir.mnu file will allow you to access the vi's from the block diagram palette under the User Libraries category
- Place Debugger_Open.vi somewhere like an event or case structure to control whether the debugger runs during execution
- Place as many nodes as you feel are necessary along your error line and feed useful information into them
- Run your program as normal
Requirements
Software
Labview 2012 or higher
Hardware
none
