Forum Replies Created
Since you also emailed us with the same issue, I’ll follow up there.
We’ve followed up with the email that you already sent us.
The six “lowest” LEDs on the green ring are numbered and positioned:
If those six LEDs are the ones not lighting but you do not have any issues on the blue ring, it suggests that your connection to the “LED3” ring has a problem. Check carefully the soldering at pin LED3 as it enters the green board.
We tend to leave ours out without dust protection, so we’re probably not the best people to ask. One tip, though. If you store the AxiDraw with the arm fully right and forward, the cable guides will be at their flattest, which makes the requirements for a cover less demanding.
You might consider asking in the drawingbots discord; there are quite a lot of AxiDraw users there: https://discordapp.com/invite/XHP3dBg
This is an unrelated error.
It has to do with whether or not the correct software components are located. It has nothing to do with USB, USB permissions, or so on. It does not make sense to try things like running as root, logging out, rebooting, or unplugging the machine. Those _will not_ address this issue.
Are other Inkscape extensions working at present? You might try Extensions > Render > Gear > Gear… , for example
Can you please say:
* How you installed Inkscape 1.0
* Which version of the AxiDraw software you have installed (on the Linux side)
* The exact text of the error message you are getting
In any case, I would suggest that you unplug the AxiDraw from both power and USB until the LEDs fade (probably 5-10 s), and then connect _only_ the USB cable (until you have good communication). Wait at least 30 s before trying to access the USB port. This resets the AxiDraw, and allows time for the computer to recognize the newly-connected device.
You might also try logging out and back in, or rebooting in Linux.
A possibility is that some kind of permissions issue is preventing Inkscape specifically from accessing your serial port. You might try running Inkscape as root, or try plotting from the CLI to see if that is the case.
We have seen some cases where distributions do not allow non-root access to USB devices by default, but everything that I see about mint suggests that usually dialout is sufficient ( e.g., https://forums.linuxmint.com/viewtopic.php?t=312551 ).
Without knowing more about your situation, it’s hard to guess.
Which software are you using? How are you determining that you are “completely unable” to connect? Have you tried a different USB cable? Is there an issue with the AxiDraw itself?
We were planning a release this spring, but had to put it on temporary hold due to a few things including the pandemic. We’re hoping to try again, perhaps this winter.
At the low end, we’ve seen a cheap inkjet printer placed in front of the AxiDraw, to “print” a blank page in front of the AxiDraw.
At the high end, we’ve seen commercial robot arms ($2k – $40k) used to place paper or other materials in front of the AxiDraw.
In the middle, we’ve seen custom paper feeders and commercial sheet feeders from print shops.
The messages that you’re getting don’t *necessarily* mean that the firmware update failed. The “Firmware update appears to have failed” message in the Mac updater app is what you get if the programming sequence appears to have worked, but that there is trouble connecting to the board after. Likewise, the mphidflash messages suggest that the programming itself is going OK.
You might try manually resetting after the programming sequence finishes, or possibly disconnecting USB for a bit after. (You can and should leave power disconnected for _all_ testing until communication is working again.)
Your symptoms are also consistent with your computer being slow at recognizing a recently connected USB device, or having a somewhat slow/unreliable USB connection. You might try a different computer, a different port, or a different USB cable.
If you continue to have difficulty, it could be a hardware problem on the board itself. Which model of EggBot is this?
What kind of feedback are you getting from mphidflash?
If you’re able to enter bootloader mode, try running the firmware updater again, starting in bootloader mode.
If the AxiDraw returned to the home corner, then it sounds like the plot finished *normally* in some sense.
My best guess is that one of the following things happened:
Either (1) the software either determined that there was no more data to plot and returned home or (2) the entire plot ran, but the pen wasn’t touching down for part of it. (If you were asleep, then that allows for that second possibility as opposed to quitting in the middle.)
For (1) you should run a plot preview to make sure that everything that you expect to plot renders correctly in the plot preview. If there are parts of the document on a non-printing layer, outside the printing bounds, issues with interpreting the file or planning motion for it, or other similar things, this should catch them.
For (2), it could be that the pen isn’t touching everywhere it needs to in the file (if so, it will seem to “fade” as it more lightly touched the parts near to those missed), that the pen-lift servo motor isn’t working reliably, or that the pen ran out of ink or dried up.
One test that you could do to determine the difference between these (if everything else seems okay) would be to try and run the same plot with the pen-lift servo disconnected on the left side of the machine, so that the pen is down for the entire travel. If there’s a question as to whether the entire path was drawn (but the pen up/down wasn’t working), this could answer that question.
There isn’t a path maximum per se, but depending what you are doing and what is in your file, there are certain things that can go wrong.
What types of things can go wrong depends mostly on what it is that you are doing. There are different things that can go wrong if you are driving from a PC versus a raspberry pi, and there are different things that can go wrong if you are using the Inkscape plugin versus the CLI versus third party software.
If your file has extremely nested objects — like groups of groups more than 500 deep — you can run into certain types of recursion limits in the software, depending on which software you are using.
If you are working from a PC, check to make sure that it hasn’t gone to sleep.
In addition to not saying what type of computer or software you’re using, you haven’t said what happened when it quit. Do you mean that Inkscape quit, that something crashed, that you got an error message, or something else?
If you’re working from our Inkscape, python, or CLI based software, you might try running a plot preview. Doing so should reveal if any kind of memory limit or parsing error is encountered in the file.
You might also consider contacting tech support directly by email, so we can work on debugging with you. If it’s a particular file that’s causing an issue, we may be able to identify what the cause is.
It is the first *detected*, not the first that isn’t busy. The order that it uses is the order that the system lists the USB devices.