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.

Hi,
I have a somehow related question: Can I use a Watercolorbot (or similar) with the new axidraw software?
I could not find a similarly easy way regarding the movement of the axes (independent as in a cartesian and not the axidraw core-xy movement). Modifying motor_dist1/2 calculation in axidraw.py (and the conversion back with delta_x/y_inches_rounded ) did work for manual movement but not for svg-printing.
I would be very happy for any hint where further modifications are necessary and how I could achieve them.
Thank you for your help, Chris

Dear Windell,
thanks for your fast reply. I should have been more precise.
Using the python API/CLI of the most recent release (Jul 2019) I print on my setup (modified WCB setup, Cartesian XY (i.e. one motor for each axis), EBB board controlling magnetic encoders on the stepper motors using PID). Using standard settings, a svg is rotated 45°, as mentioned in the code.
After modifying axidraw.py at line 2158/9 and 2174/5, i.e. the calculation of motor_dist1/2 (and its conversion back to delta_x/y_inches_rounded) I get the correct movement behavior using the manual/interactive mode using walk_x etc. However, printing an svg with this setting results in somehow erratic behavior, where the carriage walks out of bounds each time.
I’m new to this and happy for any hint where the problem might be. I would like to use the python api, since it offers smoother movements (acc-/deceleration) and far more options for automatic printing.
Thank you for your help!

The APIs and Inkscape based software use the same motion control code– there is a difference in how you can control it, but not a difference in the smoothness of motion.

At a minimum, you’ll need to modify the configuration file as well, to set the limits and resolution.

One other approach that you could possibly use would be to substitute doABMove for doXYMove — This moves as <AxisA> + <AxisB>, and <AxisA> - <AxisB>. I’m not sure that the signs are right (you might need to invert one or both), but it will rotate the coordinate system by 45 degrees.

We now have a branch of the WCB software configured to use with the AxiDraw: https://github.com/evil-mad/wcb-ink/tree/V1_axidraw

I tried the axidraw branch version but unfortunately i am getting the following message
File “wcb.py”, line 395
self.resumeMode = False
^
TabError: inconsistent use of tabs and spaces in indentation

Do you know how can I modify the file to fix it? thanks a lot