Forum Replies Created
-
Posts
-
The error message is unrelated to that in the other issue.
The issue that you’re having is from running an old version of the EggBot software, not updated for macOS 10.15 and newer. Update to the current version, available from here: https://wiki.evilmadscientist.com/Installing_software
We do have a “Process Illustrator SVG” extension, as part of the AxiDraw Utilities, that does specify a recommended export process for the document that includes using the Artboard — which I think may be the part that sets the SVG size.
In any case, the Hatch Fill extension isn’t handling some special case of SVG dimensions or viewbox.
I can reproduce the issue. It appears to be something with the document setup, that Hatch Fill is not handling correctly.
It’s easiest to reproduce by using the “crosshatch” option, as the perpendicular hatches are at different spacing.
If I copy the graphics to a new Inkscape document, Hatch Fill works correctly. If I copy a working object into that document, Hatch Fill has the same issue here.
I’d suggest trying our recommended AI SVG export/import path and see if that resolves it; I’m frankly surprised that Hatch Fill works at all on this documument.
It is possible to some extent by using custom code, and people have done so.
However, there is quite a bit of subtlety to the problem and our best understanding is that we cannot presently add a feature that would work reasonably well in a reasonable variety of cases. (If we did, we would have done so already, of course; it is a very common feature request.) As one starting point, consider that the Z stage cannot (in general) be moved in sync with X and Y for the simple reason that its speed does not (in general) match that of X and Y motion. As another, consider that there isn’t really straightforward graphical method for varying the color of a path within SVG.
Obviously, if you’re working one particular use case, that’s an entirely different matter. It’s a fair bit of work even for a specialized case, and so we don’t generally advertise it as a capability.
Finally, you might be aware that we *are* working towards a future solution for variable pen height. Our efforts on this topic are directed there, instead.
We do have a command line tool available for AxiDraw owners. We do not have a publicly available one.
You can use different pen-down heights for different layers, but the AxiDraw is fundamentally a 2D pen plotter; there is only very limited support for controlling the third axis.
I don’t recall what the current draw is; it’s only a 150 mA regulator. You *could* swap in a larger regulator.
We’re not familiar with that EggBot derivative, and can’t offer any support for it.
If it’s a 5 V (red) Alpha Clock Five, then there’s ample spare 5 V, and you’re welcome to tap some to power a linear regulator. If it’s a 9 V (blue or white) Alpha Clock Five, then there isn’t much spare 5 V available, and I’d recommend that you step down from the 9 V directly to make the 3.3 V that you need.
I’d also advise caution interfacing the 5 V I/O from the Alpha Clock Five to the ESP.
Ah– you can run 64-bit Ubuntu on RPi 3 and 4: https://ubuntu.com/download/raspberry-pi
That said, an old mac is an OK solution too. We’re currently supporting the latest Inkscape/AxiDraw software back to macOS 10.11; that will probably be changing to a minimum of 10.13 in the next major Inkscape update.
We’ve always recommended to preferentially use the CLI for plotting on the Pi and to try and avoid Inkscape there. Given that the differences are getting stark, I’ll start recommending that more strongly.
It looks like the RPi hardware is 64-bit compatible, but the OS is lagging behind (see, e.g., https://forums.raspberrypi.com/viewtopic.php?f=117&t=275370 ).
Is there any other effect of this, other than the on-screen rulers/coordinate display being inverted?
I’m not certain that I fully understand the issue that you’re describing, but I suspect that it’s one of these three. If it *isn’t*, please say so, and help me understand exactly what the situation is.
(1) In Inkscape’s Preferences, under the “Interface” heading, there’s an option: “Origin at upper left with y-axis pointing down”. If you check that (and restart Inkscape), the (0,0) corner of your document will be located in the upper-left corner of the page on your screen. This *only* changes the labeling of the on-screen coordinates and rulers; it does not affect the document or how it prints. However, it may help you to visualize the plot if the coordinates look reasonable to you.
(2) You may be seeing the normal results of “auto-rotation”: see section 6.3 “Document orientation” in the AxiDraw user guide. Documents that are taller than they are wide are normally rotated, 90 degrees counterclockwise, when they are plotted, to reconcile the wider-than-tall plot area with portrait-mode artwork. You may prefer to disable this behavior and work only in landscape mode (or otherwise model the full plot area of the machine in your document).
(3) You may be expecting auto-rotation, but in the other direction. If you’re expecting clockwise rotation but seeing counterclockwise, then it will feel like there’s an extra 180 degree rotation in there. There’s a hidden option in the axidraw_conf.py configuration file that you can use to rotate the other way: set
auto_rotate_ccwtoFalse. This file can be found in the Inkscape User Extensions folder — with the location visible in the Inkscape Preferences System heading. In the CLI, you can use a copy of this file with the--configoption to specify that (and your other defaults).Finally, you might want to consider using Preview mode, with rendering enabled: It will show you the plan for how the machine will plot a given file, including how it travels from and to the home corner at the beginning and end of the plot. In many cases, this can help to resolve any ambiguities that you’re seeing. Preview mode is available both in Inkscape and the CLI.
Good tip!
It’s also possible to redirect Inkscape itself to use a different python version: https://wiki.inkscape.org/wiki/Extension_Interpreters#Selecting_a_specific_interpreter_version_.28via_preferences_file.29The
penup()command raises the pen, if the pen is down. It does not raise the pen if it is already raised.The
pendown()command lowers the pen, if the pen is up. It does not lower the pen if it is already lowered.I will also note that your
ad.options.pen_pos_up = 80command needs to be followed by anupdate().If you aren’t using the
penup()/pendown()commands in the usual way — to lift and lower the pen between two independent states — then you might consider something like the following (which could be wrapped up as a function in your python script):ad.options.pen_pos_up = 80 ad.options.pen_pos_down = 80 ad.update() ad.penup() ad.pendown()That will set the pen up and pen down positions to be the same, and leave it in the pen-down logical state.
