Hi Toni,
The two machines do have a lot in common, and we have even discussed making a special “watercolor” edition of the AxiDraw that would include the paint pans and water dishes.
There are several potential issues with using the WaterColorBot extensions for Inkscape. First, the left three inches of the plotting are are (by default) reserved for the water dishes and the paint pans. These values — both the offset distances and the location of the various dishes — are set in the wcb_conf.py configuration file.
Since you likely will want to operate in the “dip pen” mode — refreshing ink only, but not dipping in water also — you change the “paint” location (where your ink is located) to be near the left hand side of the plotting area, and reserve less distance (maybe one inch, instead of three) for paint dishes.
Second, the total travel area will be less on the AxiDraw than on the WaterColorBot. You’ll want to edit the page width ( N_PAGE_WIDTH ) to be lower, so that the AxiDraw doesn’t run off the page to the right. Note that (0,0) is the upper left corner of the paper, but the “parking” position — the home corner — is (-3 inches,0).
Next, the resolution in terms of motor steps per inch, set by the F_DPI_16X parameter, will be different on the AxiDraw. Although I have not checked it, I believe that the correct factor will be about 2874 steps per inch, however this does depend on the exact method that you use to compensate for the final factor below. In order to check, you may wish to draw an object of known size on your screen and ensure that the printout is the right size.
Finally, the WaterColorBot uses independent motors for X and Y motion, but the AxiDraw uses a mixed-axis geometry, where the two motors turning together drive the carriage in the X direction, but the two motors turning in opposite directions drive the carriage in the Y direction. While this can be somewhat complex to deal with properly (and cover all possible cases), we’ve built a little “cheat” into the firmware that does allow a rather quick adaptation. If you find the place in wcb.py where the motor movement command is sent (search for **’SM’**, quotes included), you can replace the SM with XM, and that should do the trick. If the motion is not going in the right direction, use the “reverse motor” options in the Options tab to compensate.
When testing things like this, be ready to press the pause button quickly, should anything go wrong– and it most likely will at some point.
