Introduction
While coding in Xill IDE, it is relatively easy to test every single line of your robot, thanks to the built-in debugging tools. This can be used in two ways:
- While building a robot, to make sure that every new code part works as expected, thus preventing bugs
- For debugging, when you already noticed that there has to be a bug somewhere (on runtime errors, for example)
Stepping through the robot, line by line or until a breakpoint, enables the user to check all variable contents at any point in the code, which aids the debugging process greatly.
Basic usage
If you are totally new to Xill and its IDE, here's the only paragraph you really need right now.
To gently step through a robot (like the one from the first Xill tutorial) and see the variable contents for every step, first open the Debug panel (with the little arrow at the right bottom). Then, to add a breakpoint, click in the grey area left to the first line that contains an expression. Usually, that line starts with var [name] = . Now click play and you should see your robot pause. In this paused state, click the 'step into' button whenever you like, to proceed to the next expression. Inspect the variable contents in the right pane. See below if you can not find the buttons.
This is a good strategy to follow any code example on the site. But read on if you want to know more about breakpoints, the buttons and robot state.
Buttons and debug panel
The green outlined parts of the IDE interface in this picture are the elements used for debugging.
- Buttons for stepping through lines (see table below)
- Area where breakpoints are set
- Debug panel for checking the values of variables
Overview of the buttons:
| Icon | Name | Shortcut | Purpose |
|---|---|---|---|
|
|
Run | F6 | Run the robot. |
|
Pause | F7 | Pause the robot. |
|
|
Stop | F8 | Stop the robot. |
|
|
Step over | F10 | Step over the execution of the current line. |
|
|
Step in | F9 | Step in the execution of the current line. |
|
|
Remove all breakpoints |
Remove every breakpoint | |
|
|
Select breaking log levels |
Select what types of (console) messages pause the robot |
Breakpoints
A breakpoint can be set by clicking the area just left from the line numbers. A breakpoint (shown by a red dot) will then appear on that line, or disappear if there was one already. Breakpoints are only effective on lines with an expression. When the execution of a robot reaches a line with a breakpoint, the robot will pause.
Robot status
A robot can have four states:
- Ready - hasn't run since the robot was opened last
- Running - is running right now
- Stopped - has been run completely (finished), or stopped manually
- Paused - was running, but is now waiting for user input to continue running
Which one is currently the case, is visible in multiple ways. You will notice icons changing, but there's also a status bar at the bottom, explicitly showing the status.
The paused state is the relevant one for debugging, because variables can then be inspected. Yellow highlighting shows exactly where the robot has paused:
There are several situations that will cause the robot to enter a paused state:
- The user clicks the pause button
- The execution of the robot hits a line with a breakpoint
- A message is triggered, and that type of message is selected as breaking (see the tutorial about console/logging)
Step in and step over
These buttons can only be used in the paused state. The difference is that 'step over' will execute a function call as a whole, without pausing (unless there's another reason to pause; see above), while 'step into' will always pause at the next executed code line.
Try out these buttons for yourself. In the above example (under 'Robot state'), if you step in, you will step to line 5. If you step over, the robot will enter the 100 seconds wait time and enter 'stopped' state immediately after.
Instruction stack position
At the top of the debug panel is a drop down menu that enables you to 'look back' to the upper scope. While in a function, this can be used to view the variables in scope of the function call. If we take the above example again and add another assignment of the variable test in the doTest function, you can see that Xill allows shadowing:
In scope of the function, test has been assigned a new number. However, if you change the instruction stack position with the drop down menu, you will see that the variable still has its old value 1 in the outer scope:
Good luck debugging.