[Windell Oskay]

Just because a USB cable works on other devices does not necessarily mean that it will work on the EBB. Different USB devices use different wiring within the cable, and we regularly see cases meeting your description where it *was* the cable or usb adapter.

Assuming you purchased the EBB from us, you could return it to us for inspection or repair, or you might consider trying a new cable.

[Windell Oskay]

Try restarting the computer, and then connect to the EBB with USB only, without any extra power to the board.

If you can’t make a good connection, then try a different USB cable, USB adapter, or USB port. The most likely situation by far is that the USB cable (or adapter, etc) isn’t properly wired for this.

[Windell Oskay]

I see that you’ve written to us by email as well, and I’ve followed up with you by email.

[Windell Oskay]

There is no way to “feed paper into the machine” — but that’s correct, there is not a feeder.

[Windell Oskay]

The AxiDraw is commonly used for letters, but there is not an available feeder attachment.

[Windell Oskay]

First, turn power off, and don’t turn it back on again until you’ve double checked everything.

The vast majority of issues when you’re getting started happen as the following, in order of how common they are:

* Missing or incomplete solder joints. Check for any solder joints that look dry, cracked, or blobby. Solder joints should form a neat, shiny meniscus without gaps or blobs.

* Short circuits — accidental bridges between neighboring pins or solder dust that makes connections between things.

* Components in the wrong locations

* Missing components

* Components backwards

If it were here on the bench in front of me, those are the things that we would be checking.

[Windell Oskay]

We’ve just released software version 3.2, which fixes the bug with programmatic pauses in layers mode. It also changes the initialization sequence when enabling the motors such that the QS EBB command can be used to read out the position.

Here are two short python scripts, usually runnable on a Mac CLI as:
python3 report_pos_inch.py or python3 report_pos_mm.py that will print the XY position after being paused:

https://bcdn.evilmadscientist.com/scratch/report_pos_scripts.zip

[Windell Oskay]

I’m sorry to hear about the trouble. (It looks like you emailed the exact same thing to us as well.)

My first question is whether you are using the original power supplies, and whether you are using any kind of voltage adapter. Second, which software are you using to drive the machines? And, would you also please check which firmware version the different machines are on, perhaps the one that is failing the most, versus one other? (You can query it with the Config tab of AxiDraw Control, for example.) Finally, do all of these machines have USB Micro B connectors, rather than USB Mini-B connectors?

The quality of servo motors seems to vary a lot, often even from the same manufacturers, and we’ve seen servo motors that last for both days (under strenuous use) and years (under light use), but hours definitely indicates that something is wrong.

The usual things that can increase servo life are those that reduce the load on the servo: Ensuring that there’s no added stress (via weight or rubber bands for example), ensuring that the slide moves completely freely, and minimizing the pen-up to pen-down travel distance.

It is possible that there’s a problem with that particular EBB driver board, such it should be replaced. It’s also possible that adjusting the servo timeout value (if you’re using the regular AxiDraw software) can make a significant difference, or potentially moving to a different servo driver pin could make a difference. There may be some interaction between the power switching on the control board and certain servo motors as well.

[Windell Oskay]

The voltage regulator on the Alpha Clock Five is only rated for 150 mA, total. A Raspberry Pi Zero can draw up to about 250 mA, even if it’s not driving any external devices that use power. You might consider using an external switching power supply, driven by the 9 V, to power the Pi.

[Windell Oskay]

Is this a blue/white Alpha Clock Five, or a red one?

[Windell Oskay]

Yes. And, since plot is the default mode, you don’t need to specify it.

Yes, layer order is “bottom to top” in Inkscape’s display. That matches order of creation (putting “one thing on top of another”) and is equivalent to performing actions in the order in which they appear in the SVG file.

[Windell Oskay]

Let me give a more full example, in case that helps.

Here’s a test file: https://evilmadscientist.s3.amazonaws.com/scratch/reverse_and_joins5_pause.svg

Its layer names, bottom to top, are “2”, “!”, “1” and “layer 3”.

I can start to plot it with:
axicli reverse_and_joins5_pause.svg -o output.svg

That plots layer “2”, alone, and then stops, just as you had pressed the pause button.

We then resume the file with:
axicli output.svg -m res_plot -o output2.svg

That plots layers “1” and “layer 3”, resuming from where it was paused, without returning home.

You can also test these workflows in preview mode, with preview rendering turned on, to see which parts of the file are plotted each time that you do so.

[Windell Oskay]

The exclamation point on a new layer acts almost exactly as though you had manually pressed the pause button: It stops the plot at that point.

So, what you would do is put “FRAGILE” on a layer, then add a new layer on top of that, with a name like “! Pause after fragile”.

[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, 2 months ago by Windell Oskay.
• This reply was modified 2 years, 2 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.

[Author]

Posts