Forum Replies Created
Consider placing something between the base of the machine and the surface that it’s sitting on. A table can sometimes act like an acoustic amplifier. Maybe a couple of soft sponges or washcloths, for example.
In a way, yes, by either “properly using” or “hacking” the pause and resume capabilities, depending on exactly what you need. We’ve helped a few other people build workflows around this.
You can force the AxiDraw to pause — just as though you had pressed the pause button — by adding a layer that has a name beginning with an exclamation point. It will stop where it is at, and then raise the pen. That’s part of the AxiDraw Layer Control syntax:
If you collect the output SVG that the CLI can return, that SVG contains a
plotdataelement that includes the position where it was paused as well as the “current” machine position.
If you use manual walks to return the AxiDraw to the position where it was paused, you can directly use the resume capability, without any modifications to the file, to resume from that point.
If you use manual walks to end up at Home, you can then plot in
res_homemode *with preview enabled* and collect the output SVG: That will update your SVG to show that the “current” machine position, as saved in the SVG file is now Home. From there, you can use
res_plotmode to continue plotting from that point. This would require only adding one empty layer (per pen change) to your SVG file,
(And the hack part: If you use manual walks to end up at a new position that isn’t Home, you could modify the file to indicate the new current position to resume from.)
Two alternate approaches that you might consider:
(1) If the pen change operation can be coded as graphical information, or perhaps graphical plus some layer control codes, then consider building those into the file. SVG is pretty easy to code by hand, if that helps.
(2) The AxiDraw Python API can both plot SVG (doing all of the things that I listed above) as well as do more complex moves in interactive context. Note that if you switch back and forth between Plot and Interactive contexts, it will assume that you’re starting at (0,0) for each. But, it makes it much easier to read out the actual position, so doing complex moves and then returning home might be easier.January 31, 2022 at 1:39 pm in reply to: problems in group element with attribute when using “colon” #29751
Great; that looks like an approach that would work!January 30, 2022 at 1:32 pm in reply to: problems in group element with attribute when using “colon” #29746
The AxiDraw software reads SVG. The syntax that we use is properly namespaced SVG, while versions with equals signs or hyphens are not.January 29, 2022 at 11:38 pm in reply to: problems in group element with attribute when using “colon” #29744
Both the crash ( SAXParseException ) and the stackoverflow link should be pointing you in the correct direction: You shouldn’t use a “bare” colon if you’re using any frameworks that recognize the SVG tree, since they will conflict with any declared namespaces.
What to do about it depends a lot on what you are actually doing, and at what stage it’s crashing.
If you’re seeing a crash while building the file, then you’re probably using some sort of framework that parses or otherwise understands an SVG (XML) tree. In that case, you need to either register the namespace and build the namespaced object correctly, or (with a very different approach) build the SVG by simple string concatenation, in which case you can use colons directly.
If you’re seeing the crash while loading the SVG into something else (trying to parse it after you made it), it sounds like you didn’t add the right namespaces to the file.
There isn’t any mention of webhooks in the AxiDraw Merge manual, so I’m not sure what it is that you’re referring to there.
Webhooks may be added to AxiDraw Merge in a future release, but there is not currently any plan for a CLI version of AxiDraw Merge. In most cases, if you’re building automations, we would recommend to use the Hershey Advanced CLI (or the Python library), in combination with the AxiDraw CLI (or the Python library). *That* workflow does already exist and does support webhooks.
If this a new AxiDraw, please contact support directly; the servo on a new AxiDraw shouldn’t fail in just a couple of days, so we’ll have some specific follow up questions.
More typically, servo motors last some months or even years, but it’s not unheard of to wear one out in a couple of weeks if you’re pushing it really hard. If it’s only lasting a couple of days, it sounds like something is wrong, or you just got one that failed early for some reason.
You can improve servo life by taking care that the pen slide moves freely, without any friction– which means not over-tightening the pen screw amongst other things, avoiding extra weights or rubber bands, and minimizing the distance between the pen-up and pen-down positions.January 5, 2022 at 4:22 pm in reply to: python: Trouble with connecting via pyserial/FTDIfriend #29713
I don’t think that you need time between individual writes — my example doesn’t have them — but my script has time added for the reset after starting communication, a different word (so that HELLO WORLD isn’t confusable with the word I’m writing) and a “display” delay time after writing the text before the restart.January 5, 2022 at 4:19 pm in reply to: python: Trouble with connecting via pyserial/FTDIfriend #29712
On an M1, I would say (to start with) that any pyserial version less than 3.5 is absolutely, positively unreliable, and I personally would not even try on 2.7. The IDE and virtual environment shouldn’t cause any issues so far as I know off hand.
That you are able to communicate on Processing does very much suggest that this is a software-specific issue.
In Python3, the following works reliably for me:
ser = serial.Serial("/dev/cu.usbserial-FTE55RTK", baudrate=19200)
header = b'\xFF'
command = b'A0'
data = b'ABCDE'
space = b' '
ser.write(header + command + data + space)
January 5, 2022 at 3:00 pm in reply to: python: Trouble with connecting via pyserial/FTDIfriend #29709
If it’s working *sometimes* or partially, then I’d suspect an electronics or reset issue first.
Are things acting stable and reliable otherwise?
If you have auto-reset enabled, you may be resetting the device when you open communication– I don’t see a delay there, so make sure that you’re waiting a moment for reset to complete before trying to send data.
Those fonts are used by Hershey Text.
You can read a little bit about them in the AxiDraw user guide. And yes, they are available to AxiDraw owners.
If you’re an AxiDraw owner, we have AxiDraw Merge, which doesn’t quite work with the process you’re describing, but has different workflows that are more optimized for rendering text with stroke fonts and then plotting. There is also the Hershey Advanced CLI and Hershey Advanced python library, which do not perform mail merge nor operate the plotter, but can be used for batch processing in various ways.
As for the question about converting “standard fonts” into stroke fonts, there isn’t any straightforward way to do that. Outline fonts do not contain any data that represents the “visual centerline” of the font, so there generally has to be some degree of human-generated artistic effort to draw the apparent centerline when creating the stroke font.December 8, 2021 at 9:31 am in reply to: Can I install Inkscape and AxiDraw plugins on my computer? #29645
Inkscape 1.0 and newer does not _ever_ need XQuartz. I would recommend that you remove each version of XQuartz and Inkscape from your computer, and make sure that they are fully removed. Then, and only then, install Inkscape 1.1.1.
If Inkscape 1.1.1 asks you for XQuartz, please show me exactly what the message looks like so that we can try to figure out what’s going wrong.
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