Using AxiDraw as WaterColor bot

Home Evil Mad Scientist Forums AxiDraw Using AxiDraw as WaterColor bot

Viewing 10 posts - 1 through 10 (of 10 total)
  • Author
  • #20685

    Hi, since the control-board is the same and only the motor configuration differs, is it possible to use Inkscape Watercolor bot extension with the AxiDraw? I’d like to use AxiDraw to write Chinese characters with a real-brush and would need it to re-ink the brush in the same way the watercolor bot dips the brush in the color. Which configuration file would need to be changed ?
    Thanks for your help

    Windell Oskay

    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 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 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.


    Dear Windell, thanks a lot, your solution works like a charm. I had the minor problem that first I needed to update the firmware, which thanks to the related wiki-article is easy.
    Then the X-axis was out-of-scale. Changing the N_PAGE_WIDTH value did the trick, even though I was a bit astonished that this value has an effect on the motor travel, I thought it only limits the page width.


    In the meantime I started drawing my first characters. One little problem I observed is that the re-inking is done strictly by distance. It would be better, if the current path is at least finished before re-inking, otherwise the natural flow is interrupted. Can I put this on the development wish list :smile:

    Windell Oskay

    I’m glad to hear that it’s mostly working.

    There is an old feature request for that, still open here:

    Dipping before every path is a little “iffy” as a general technique, because individual paths may be hours long, and if there are a lot of short paths, then it will spend an absurd amount of time re-dipping, and (with a brush at least) that can lead to too much ink on the page as well. It really needs to have some smarter mechanism (or at least a lot of choices) to overcome this.


    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 (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

    Windell Oskay

    There are several different possible meanings to the “new axidraw software” — if you can clarify which specific software package(s) you mean, or what feature is that you’re looking for, that might be helpful.

    AxiDraw does not use a CoreXY geometry, but it does have mixed axes. It is possible to modify AxiDraw software to work with the WaterColorBot (and vice versa) — it has been done quite a few times. However, the AxiDraw software does not have built-in support for features like brush washing or automatic re-inking.


    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 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!


    To complete my question. My modification of the so far (lines 158/9 and 2174/5):

    motor_dist1 = delta_x_inches
    motor_dist2 = delta_y_inches
    delta_x_inches_rounded = motor_dist1_rounded
    delta_y_inches_rounded = motor_dist2_rounded

    and of course adapting the plotting area in the config file..

    Is there any other element of the code that needs modification (especially when printing a svg-file) using another setup/axes-movements?

    Windell Oskay

    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.

Viewing 10 posts - 1 through 10 (of 10 total)
  • You must be logged in to reply to this topic.