It's bound to happen sooner or later... in spite of your best efforts and meticulous tests, something goes wrong and you need to do some serious forensic debugging on your running Zope. Here's how you can use PIDA's remote Python debugger plugin to get it done:

1. Install the debugger plugin if you haven't done so already (see Getting Started). If you were not able to install PIDA into the same Python interpreter that runs your Zope, you should still be able to use the debugger. Just copy rpdb2.py from site-packages/pida/utils to somewhere in your your Zope's PYTHONPATH, and modify the breakpoint command to reflect the new location of rpdb2.py. (I haven't actually tried this, but I'm pretty sure it will work.)
2. Open your project, then open up the code you need to debug in the editor. Let's assume we're debugging Products/MyProduct/MyClass.py.
   
3. Insert the following line to set a breakpoint at the desired location:
   

   from pida.utils import rpdb2; rpdb2.start_embedded_debugger_interactive_password()

4. Save the file.
5. Activate the debugger by selecting Language > Python Debugger from the menu.
6. In the command line at the bottom-left of the debugger panel, enter password foo (change 'foo' to whatever password you want to use to connect to the debugger).
7. Start Zope using your project's execution controller, or restart Zope if it was already running. Keep this terminal window active for now.
   
8. Browse your site or do whatever it is you need to do to cause the breakpoint to execute.
9. When the breakpoint has executed, you'll see a password prompt in the controller terminal window. Enter the password you specified in step 6.
10. Switch to the debugger plugin.
11. In the debugger command line, enter attach - this will show you a list of running scripts (meaning Python files in your product) to which you can attach the debugger.
12. In the debugger command line, enter attach /path/to/zope/instance/Products/MyProduct/MyClass.py
13. After a short pause, the debugger will display the current state of your code, and the source code in the editor will jump to your breakpoint.

At this point you can step through the code, inspect variables and objects, and everything else you'd expect from a debugger. PIDA provides a few buttons (on the right-hand side of the debugger panel) that you can use to step through the code, or you can enter help in the debugger command line for a full list of debugging commands and options.

When you're finished debugging, enter detach in the debugger command line to close the debugger connection.

You can find a bit more information about rpdb2 in the documentation for Winpdb.

Note: you cannot use PIDA's debugger to debug PythonScripts, neither through-the-web nor scripts in your product's skin layers. It's possible to make rpdb2 available to these scripts, and you can set a breakpoint that the debugger will recognize - but when you attach to the script with the debugger, you'll be looking at a blank screen.

Admittedly, this is not as quick to use as pdb, but sometimes a graphical debugger is nice. And it's not as painless to use as the debugger in Wing, but Free is nice too :)

This pretty much concludes the practical part of this tutorial - but don't stop reading yet. If version numbers mean anything, PIDA's only halfway done, and it has still got a few problems...