Forum Replies Created
-
Posts
-
Our software does not support that hardware; it specifically targets the EBB, which is why it can’t find it.
The error says that your system cannot find the EBB. Are you using an original EggBot, or some other configuration?
Here is one that we’ve written that will make some significant “first pass” optimization of path order: https://github.com/evil-mad/axidraw/issues/4#issuecomment-272845935
(We’re actively working on the next revision of this, and hope to release it shortly.)
Depending on the format of the output SVG from your program, you may need to ungroup and/or break paths apart before using our extension for maximum benefit.
Sure. Start with the text, ideally a little larger, bolder, than you need the final shapes to be. Convert the text to paths, and use the boolean operations (boolean difference, for example: http://write.flossmanuals.net/start-with-inkscape/boolean-operations/ ) to subtract the “text” from a larger shape that you’ll be filling– for example a big rectangle.
Then, select the resulting shape, and fill it using the AxiDraw Hatch Fill extension. For tight cross hatching, start with a line spacing of about 2 px, and make sure to adjust the tolerance parameter down to about 1. You’ll likely want to connect nearby ends, and inset from edges a little bit– but experiment with the fills to see what works well for you.
Sounds like you might be running into the brownout detection feature. I’d check the values of those fuse bits, and compare them to your power supply behavior.
If XY movement is working well but Z is not, and the cabling is good, then it is most likely the case that the servo motor itself has failed. Please contact our store directly ( http://shop.evilmadscientist.com/contact ) about a replacement and we’ll have some follow-up questions.
Neat; I’ve added a link to it from our documentation wiki.
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/24Dipping 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.
Hi Raph,
The behavior that you describe is consistent with the power supply not being plugged into the AxiDraw. (And plugging in the power supply wasn’t among the things that you listed.) Please double check that your power supply is (1) plugged into the AxiDraw and (2) plugged into a _working_ outlet. If it is, and you’re still seeing this behavior, we may need to send you a replacement power supply. We’ve already followed up by e-mail, so please follow up there.So far as I know, InkDraw is a specific program for HSAJET printers, and probably cannot be made to work with AxiDraw.
AxiDraw is not a wifi-connected machine; it’s driven through USB, and requires that you do have a computer connected to it.
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.
That’s no good. Please contact us directly by email or through our contact form so that we can walk through the set of things that might be going on.
The error essentially says that the document needs to have physical units — typically inch or cm units. EggBot Documents, formatted in pixel dimensions, are a good example of a document that does not have physical units.
Try creating a new document (for example A4 or letter size), by using File > Templates.On the engraver issue, please follow up with us by e-mail; we’d like to do some more in depth debugging than is straightforward through the forum.
What I had intended to suggest is that you open an EggBot File, and try to plot it _with the EggBot software_ with its engraver control enabled, but _while connected to the AxiDraw_ (and, critically, with the AxiDraw at the middle of travel in both X and Y). Would you please give that a try?
Side note: The error message that you received is normal and expected (though ugly, and nicer looking in forthcoming versions) — it’s what I’d expect you to get if you try to plot an EggBot file with AxiDraw Control.
It’s possible that there’s a hardware issue on the EggBot’s EBB driver board that is preventing the correct output signal from getting where it needs to. A thing that you could try as a test — quite non-traditional but possibly effective — would be to try driving the engraver from the AxiDraw. Place the AxiDraw in the very middle of its travel in both X and Y (halfway to the right, halfway extended), hook up the engraver to the AxiDraw’s EBB (in the same location) and try plotting with the EggBot software, to see if you can get it to run from that machine. Please let me know what you find.
