Forum Replies Created
-
Posts
-
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.
This isn’t something that we’ve heard of before. It could be an issue with the font, an issue with your file, or a bug in the software.
Without asking some much more detailed questions, it’s hard to know where to start. Can you contact tech support directly by email so that we can follow up privately?
I’m following up by email — this isn’t a great place for detailed technical questions.
Should I understand that you are trying to plot something _other_ than a diagonal line?
The red lights on the board indicate which direction the motors last turned. They do not indicate any sort of error.
There’s more information about them here:
https://shop.evilmadscientist.com/productsmenu/partsmenu/765-bulletpixYou can edit the machine size definition in the axidraw_conf.py configuration file.
If the carriages feel solid, that’s the important thing. Y axis movement when you move X isn’t necessarily indicative of any issue.
You might check that all four of the rubber feet are present. If the foot itself is bent, we can sell you a replacement at a discount.
People who have built integrations with the AxiDraw and automatic feeders tend to regard that solution as their trade secret.
I would recommend that you try contacting companies that supply equipment to print shops, rather than just searching online. You might be able to find used versions of paper feeders that normally go for $10k+ at a fraction of that price. Not to mention people that can help you navigate terminology.
In addition to the inkjet method, another solution that we hae seen a few times is to use a low-cost robot arm like the Dobot Magician ( https://www.robotshop.com/en/dobot-robotic-arm-magician-basic-plan.html ) with its suction cup accessory.
The short segments and the decimals are all driven by IC U3. If none of them are lighting, then either U3 is not running or it is not getting the signals.
Check that the chip is oriented properly and fully seated in its socket. In the schematic ( https://bcdn.evilmadscientist.com/source/alphafive/fiveletter_RevC.pdf ) note that U3 has power and ground connections at pins 1 and 16, and receives its serial data with pins 2, 3, and 4. So, check that the soldering is good at each of those pins. Next, check pin 22 of U2, where the serial data comes from.
