Maintenance notice: These forum archives are read-only, and will be removed shortly. Please visit our forums at their new location, https://www.evilmadscientist.com/forums/.

Using AxiDraw as WaterColor bot

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
Toni

Comments

  • edited January 2018

    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.

  • 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.
    Cheers
    Toni

  • 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:

  • I'm glad to hear that it's mostly working.

    There is an old feature request for that, still open here:
    https://github.com/evil-mad/wcb-ink/issues/24

    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.

Sign In or Register to comment.