[Windell Oskay]

My suggestion was to use the plot mode, possibly in combination with the res_home and/or res_plot modes, not to use the layers mode.

Using the plot and res_plot modes should be sufficient to walk through an entire file, in order, with programmatic pauses and moves, without ever moving back to home during the sequence. (In a sense, using Layers mode is an “opposite” strategy to manage flow through the document.)

Additionally there does appear to be a bug that the programmatic pauses are not working with the layers mode. (I can see what the issue is and I will log a bug for it; should be an easy fix in the next release.)

There is not a “Get_X_Y_Position” feature at present; for subtle reasons this is a little more tricky that it might seem. We’ll look into the best approach, it may be to read out the paused position from a file.

Here is a “quick and dirty” way for you to implement that yourself:
(1)
Open up the main axidraw.py script from your python installation in a text editor. (Mine via homebrew is at: /opt/homebrew/lib/python3.9/site-packages/axidrawinternal/axidraw.py)

(2) In resume_plot_setup(), after the self.f_curr_y = [...] line, (Line 496 as of AxiDraw 3.1.0) add this line with the same indent, then save.
self.user_message_fun(str(self.f_curr_x) + ', ' + str(self.f_curr_y))

(3) With that added, the res_plot and res_home modes will both print out the initial position when they run. You can thus use:

axicli paused_file_name.svg -m res_home -v to print out the position where the plot was paused.

• This reply was modified 2 years, 10 months ago by Windell Oskay.
• This reply was modified 2 years, 10 months ago by Windell Oskay.

[Windell Oskay]

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.

[Windell Oskay]

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:
https://wiki.evilmadscientist.com/AxiDraw_Layer_Control

If you collect the output SVG that the CLI can return, that SVG contains a plotdata element 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_home mode *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_plot mode 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.

[Windell Oskay]

Great; that looks like an approach that would work!

[Windell Oskay]

The AxiDraw software reads SVG. The syntax that we use is properly namespaced SVG, while versions with equals signs or hyphens are not.

[Windell Oskay]

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.

[Windell Oskay]

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.

[Windell Oskay]

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.

[Windell Oskay]

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.

[Windell Oskay]

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:

import serial
import time
ser = serial.Serial("/dev/cu.usbserial-FTE55RTK", baudrate=19200)
time.sleep(3)
header = b'\xFF'
command = b'A0'
data = b'ABCDE'
space = b' '
ser.write(header + command + data + space)
time.sleep(10)
ser.close()


[Windell Oskay]

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.

[Windell Oskay]

Those fonts are used by Hershey Text.

[Windell Oskay]

You can read a little bit about them in the AxiDraw user guide. And yes, they are available to AxiDraw owners.

[Windell Oskay]

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.

[Windell Oskay]

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.

[Author]

Posts