For the purposes of debugging I've added quite a bit of serial debug messages to the firmware that can be turned on and off by including or commenting out a single line in a header (.h) file.
The Rotator talks to the driver (or serial monitor) via the USB port and to the shutter (if present) over XBee radio. Because there is only one USB port the debugging messages MUST be turned off when using the ASCOM driver or the debug messages will confuse the driver and make a right awful mess.
The Shutter only has to talk to the Rotator over XBee radio so it's USB port can always be used for debugging messages but the fact that the controller moves with the shutter means you better have a really long cable and make sure it doesn't snag on anything if you want to monitor the shutter messages directly. Thankfully, I have this problem as well so the Rotator will also display some messages from the Shutter.
To enable Rotator debugging, load up the firmware in the IDE and switch to the RotatorClass.h tab then find the line saying #define DEBUG. If this is commented out (starts with two slashes "//" then just delete the slashes (or add them in to disable). Its near the top of the file with a line number in the 30s (may be a little lower or higher as the code changes). In the screenshot it's commented out and on line 30.
You can see there is actually a conditional block that starts with "#ifdef DEBUG" and ends with "#endif". If the #define DEBUG is not commented out then the first part of the block (above the #else) is used, if it is commented out then the second part is used. This called a macro in programming parlance.
The first part says that anytime it sees a "DBPrint()" it's to substitute Serial.print() and the same with DBPrintln() and Serial.println()". The second part says that if debug is not defined to substiture the DBPrintxx() line with nothing - basically excluding the code from the compiled program. The executable file is actually smaller with debugging disabled because all those DBPrint lines are excluded.
To see the debugging in action, delete the "//" in front of #define DEBUG then click on the serial monitor icon (the magnifying class on the upper right). That will open a window that shows the serial communications to and from the Rotator. It's best to not have the IDE expanded to full screen so you can have the IDE and the monitor side by side. The IDE is a bit annoying in that the monitor doesn't dock inside the IDE and will disappear behind the IDE when the IDE is selected. Keep them side by side and you won't have that problem.
Once your windows are layed out, upload the firmware with debugging enabled and after about a 12 second delay (giving time for the XBee to boot itself) you'll see the XBee and Controller initialization messages along with the information the shutter sends to the Rotator if you have one installed and programmed. If you watch for a while messages will periodically show up about the rain sensor and, if you have one, voltage messages from the shutter. If you don't have the RG11 installed you'll still get the rain messages but it'll always say it's not raining.
At the top of the monitor window is a textbox where you can enter commands for the Rotator (and shutter). The commands are listed in all the source files near the top of the .ino file (the first tab in the IDE by default).
To enter a command, look up it up in the source then type the single letter shown in the source. For example, if you want to know the current position of the rotator (in motor steps) type "p" (without the quotes) and hit enter or click the send button. The results will be completely unspectacular with just "p0#" showing up if you haven't moved the rotator after uploading. This is the message that is actually sent to the Windows driver. The "p" tells the driver it's getting a rotator position message, the "0" is the step position (can be in the hundreds of thousands) and the "#" is the message terminator so the driver knows that's the end of the message.
Dont worry about the line ending settings, the program will accept CR, LF, CR+LF, or manually using "#" at the end of the command (needed if the monitor is set to no line endings).
For a little more excitement you can tell the rotator to go to a step position. Enter "p3000" and the rotator will go to that step position and say STOP! when it's reached the destination.
You can also move the Rotator to an azimuth using the 'g' command. To see the current azimuth just type "g" by itself and to command it to move add the azimuth you want like "g10".
It won't take long before you notice some ugly formatting. The messages meant for the windows driver end with a "#" and do not have the usual line endings like CR or LF so there's no new line after them. This is to cut down on the number of characters actually transmitted between devices (one character instead of the usual 2).
These commands are subject to conditional checks before the firmware will comply. If the rotator voltage is too low you'll see "pL#" show up and the rotator won't move. There are also checks for rain, unknown position on the shutter.
If you look at the list of commands you'll probably notice that the rotator and shutter use (mostly) the same letters for the same commands except the shutter commands are capitalized.
Some time soon I'll be re-working the debugging so that it sends the messages to the Windows driver for display in a traffic window (you'll still be able to use the serial monitor too) and enabling or disabling debug messages will be done with a check box in the driver settings form.
For now do NOT have debugging enabled when using the Windows driver, it really messes things up.
Some other useful commands
v - Rotator firmware version
V - Shutter firmware version
m - Rotator status -1 CCW, 0 not moving, 1 CW
M - Shutter status 0 - Open, 1 - Closed, 2 - Opening, 3 - Closing, 4 - Unknown (stopped but not at end switch)