Forum Replies Created
-
Posts
-
Native parsing is done from the SVG file format, and people often start with files in one of those three formats. However, the answer in general is “It depends on what’s in the file.”
The AxiDraw is a pen plotter. Its sole function is to _plot vector graphics_, tracing the paths in the files that you provide to it. EPS, PS, and PDF files that contain vector artwork can be imported by Inkscape and plotted. This is often as simple as using File > Import. (Various other tools, besides Inkscape, can be used if you prefer.)
However, just because you have an EPS, PS, or PDF file does not mean that you have a vector artwork file. EPS, PS, and PDF files may contain vectors, bitmaps, or both. I can take a photograph, and save it as a .png file, but I could also save it as EPS, PS, or PDF — but doing so still leaves it as a bitmap, not a vector graphic.
I don’t know enough about the environment that you’re working with here to make any informed guesses as to what the issue is. However, my instinct would be that a function named something like “writeLine” (as opposed to “write”) would have a built-in linefeed of some sort, which may not work well with all of the explicitly written line terminators that you have added.
There is not separate timing used for the QB command– if timing is working correctly for other commands, it should work there. You might try checking the EBB Command Set Documentation as your reference on what exact characters it should send back.
The svg file is directly “handed” to the python script. It is not modified, so far as I know.
If the QB command works differently than on our hardware, there must be some difference in how it’s implemented. If it was genuinely identical, it would work identically.
Can you please point out the actual location this copy of inkex.py is located on github? I didn’t see it in a first pass.
I don’t have experience with this chip, but if it’s giving an output, then you may have a different peripheral having control of that pin.
You’ll also need to make sure that your MUX settings selects AIN0.0 to be active (rather tan AIN0.1), and that the correct Analog Input Enable Bit is set for that pin.
No, that’s not normal at all. If it’s been doing this since your first plot, it sounds like your machine may have had some damage in shipping, or perhaps there is a problem with the power supply. Please contact customer support directly so that we can follow up personally, ask some follow-up questions, and determine the best way to get you back up and running.
Your grinding sound is when the motor “cogs” to the wrong position — that’s “loss of position control” as described in section 11.4 of the user guide. If you were running near the upper end of the speed range, I might advise that you turn down the cornering speed factor, but my suspicion is that something is _very_ wrong if you’re seeing this at speeds like these. If you’d like to send us a zipped SVG file for a sanity check, we’d be happy to look at it as well.
If you want to vary the speed within a stroke, then yes, you’ll need to use a low-level interface of one type or another. You can either use the direct serial interface (EBB commands), the [robopaint API](https://github.com/evil-mad/robopaint-mode-remote/blob/master/API.md “robopaint API”), or other means to do so. If you can say what tools or environment you are using to generate your vectors, I might be more able to point you in the right directions.
There is not natively support for per-object drawing speed variations, but you can probably work around that by using the layer-based controls. You can find documentation for them here: http://wiki.evilmadscientist.com/AxiDraw_Layer_Control
To use this method, select all of the objects that you would like to plot at the same speed, and move them to a layer that is set to print at a given speed.
Alternately, if you’re coding this, feel free to give each and every line segment its own layer. However, be aware that there will always be a pen-lift operation when switching between layers.
If consistently controlled line width is your goal with different speeds, you’ll likely also want to use the constant-speed method, as otherwise there will be acceleration on pen-down strokes.
Nothing in your description would suggest to me that there is any kind of “shorting” or overcurrent event going on. If there were, I’d expect it happen on either computer, and I would not expect resetting to make a difference.
Unplugging the power supply is probably unnecessary in resetting; you can probably press the RST button to reset it just as effectively.
If you can, I would suggest that you try running the two motors simultaneously from within Inkscape. If you can do that, it should rule out the possibility (which you seem to be suggesting) that the issue is that running both motors at once is causing the issue, as well as ruling out the possibility that the new computer itself is the issue.
(If you were to find that running both motors at once causes a failure, then it may be an issue of voltage droop due to pulling too much power from the power supply, which would suggest that a higher-capacity power supply is needed. This seems very unlikely as a root cause since it was working on the other computer)
What this sounds like is as though you have some kind of USB communications issue in LabView, one which is causing something to get mucked up. Amongst other possible causes, this could easily be due to the change in the LabView version. (I have encountered changes in device communication methods in other situations when changing versions of LabView.) It could also be the case that the new computer is simply _faster_, and that this is the issue. The EBB has a very limited queue for input commands and it may be necessary to add intentional delays between subsequent commands to ensure reliable communication. This, of course, depends a lot on the types of commands that you are using, and how you are using them.
Unfortunately, not enough for us to recommend it yet.
They did put out a quick bug fix release (0.92.1) in February release to correct a couple of major issues. However, they are still recommending that Mac users stay on 0.91 for the time being. Between that and the physical-DPI change between versions (ugh), we have decided to continue to recommend 0.91 for all platforms for the time being.
If you have a use case where it’s important to get the AxiDraw up and running under 0.92, please let me know what that case is and which platform you are on, and I’ll see what I can do.
Yes, that is all correct, with the note that the firmware does not have a mode that directly supports a clock spanning two units; you will need to play with the firmware to get it to do this function. We would recommend that you leave the Chronodot on one, and designate that as the controller, and have it send serial display commands to the second unit.
Yes, you can potentially run from a power supply and switch. The red Alpha Clock runs at 5 V, and the blue/white version runs at 9 V.The displays are socketed, and can be removed with some careful wiggling. Our store does also sell the displays separately, so there’s no issue there.
The displays are a bit challenging to drive, since the different segments take different voltages and currents, and the Alpha Clock Five multiplexes the displays to spread the cost of the drivers amongst five displays. You could in principle extend the multiplexing to three additional units, at the cost of some challenging wiring and a ~40% hit in brightness.You are of course welcome to use the design of the Alpha Clock Five as a starting point (it’s a fully open source project– the schematics, circuit board designs, and part lists are all available for you to play with), and design a fully independent project. Another approach that you might consider would be to get two Alpha Clock Five (basic edition) kits, and connect them with a ribbon cable. The default firmware supports daisy chained display, and you could play with the firmware to make a stand-alone version that forms a single 8-digit clock. (The circuit boards can be tiled side to side seamlessly.)If you contact customer service, we can also pack a custom kit for you that includes just the number of displays that you want to purchase, and we do sell the individual components as well.Did you follow the directions from the AYAB web site, or from our web site? For use on Mac, I would _highly_ recommend following (to the letter) the directions on our wiki: http://wiki.evilmadscientist.com/AYAB_Mac_Installation
AxiDraw is only an option for newer beta versions of RoboPaint; we are expecting a new beta release (after a long delay) towards the end of this month.
It sounds like you’re not having the same issue with RoboPaint– the issue that you’re having is that some modes (?) aren’t working for you? (It must be working somewhat, if you can get to the settings and see that there’s an AxiDraw option.) We are currently using RoboPaint 2.0.0 beta 3, and we would very strongly _not_ recommend using an older version of RoboPaint with it– Not only does it print at the wrong angle, but it doesn’t know how big the machine is, and can run into the walls, which can cause gradual physical damage to the machine.From what I understand of this issue, the root cause is that AutoCAD produces actual dots at those locations– is that correct? If so, it’s not really an issue with Inkscape or what it’s doing, but with how AutoCAD creates the files. Does AutoCAD have export options that control these types of things?
In any case, you might be able to open up the SVG document in a text editor and see if there is any kind of characteristic that these dots have in their code– perhaps there is a way to identify the offending nodes and remove them programatically. I haven’t seen a file like this, so I don’t know what I’d be looking for.
