My ACRO 1010 pen plotter is still a work in progress. Started running initial tests with a pen holder I designed and 3D printed. Created a simple svg image in Inkscape to start with, with 3 simple objects - Square, oval, and polygon - which I converted to gcode in CAM, then plotted with BB Control software. Noticed oval does not close its path exactly where it started. It is offset. Ran this test 3 times and got the exact same result. Then plotted "hello world" svg created and plotted the same way. Multiple places where some of the "Os" as well as most of the straight line paths do not terminate exactly where they start. Separate issue (I think) notice the pen paths have a certain amount of line "wiggle". Perhaps this is due to my pen holder design not being solid enough to withstand the drag on it. Not sure about that yet. It feels very solid, but going back to take a closer look at my design. The pen pressure is not spring loaded. It relies on the weight of the moving part of the holder to meet the drawing surface. But either way, it would not explain why the pen paths don't come back to their starting coordinates so consistently. Is there a calibration procedure to perform that will solve this problem?
If it's not the frame that has some play (belt tension, wheels tight, etc) also check the paper, under the pen you may find a "wave front" of paper slightly lifting ahead of the pen. It's usually enough to cause what we see here. Stiffer card stock helps test that.
I’m not plotting on paper. The surface is a stiff flat 3mm sign board used by sign makers. As for a mechanical issue - maybe - I’ll try tightening things up but if so that would not explain why the error is so consistent. It does the exact same thing on every plot. That said, could the problem be caused by Y and Y2 not being dead nuts parallel say by 1 or 2mm?
Ahh OK, was just mentioning that as it caught me a couple times. Good then that it is a stiff surface Yes, its "as good as you built it" So put a square against the Y rail and make sure the X gantry is square to it too. Any source of inaccuracy makes its way down to the tool after all
Looks like some significant wiggle in the y-axis and either backlash in the x or flexibility in the pen holder/z-axis/carriage assembly, if I'm looking at it the right way around. Pen pressure plays a very significant role too. Backlash frequently results in very consistent errors under load. It's electrical problems that are weird.
What is "blacklash"? Here's how my pen holder works as isolated test. I optimized the servo throw using BB's wizard tool once installed.
Solved the closed path problem - in part. Forgot to convert the ellipse in Inkscape from "object" to a "path". CAM accepted and converted the ellipse object to gcode, but in the process it makes a fractional calculation difference between the start and ending gcode coordinates. That explains why I see the exact same plot error on every try. However, that does not explain why the outer "O" paths in the "Hello World" plot test do not close perfectly since the letters were converted to a path prior to opening in CAM. As for the "wiggle" in the plot, it's looking more and more like the fault is with my pen holder which has a tiny amount of give in the moving part. The question is how to solve that. By the nature of the design, the pen has to ride up and down via some kind of mechanism. In my case I'm using two 5mm shafts and 5mm linear bearings to guide the moving part. The servo arm drops out of the way when engaged leaving the pen to drop down on to the plot surface via gravity. Not sure if I were to spring load it if that would help or hurt. More likely I think it will require the pen to be held in place by 2 secure points vs one, but still there's likely to be some kind of give, however small, in the moveable floating part.
I concur. Having just looked at your pen bracket, I don't think it is backlash any more. When I made a pen holder to test my laser mechanicals, I made a welded aluminum bracket that held a solid aluminum pen tube with a very narrow hole in the tip to hold the ballpoint quite snugly in X-Y, which held a spring-loaded refill tube (G2 maybe?): Rob Taylor-Case on Instagram: “Sometimes a one-day build is actually a one-day build! That build is supposed to be a 5-hour build, of course, but who’s counting? Since…” The spring was at the top of the bracket, under the socket head cap screw lid, rather than its normal position at the base of the cartridge. Overkill? Sure, but zero issues. You don't want it moving in X-Y at all, and you want consistent pressure in Z. Very good results under high speed, too: Rob Taylor-Case on Instagram: “I tuned the acceleration and feed rates and got the (grbl default rates) 2hr25 cycle time down to 13min with rapids of up to 20,000mm/min @…” With your type of pen you don't have to worry about the nib floating around within the main tube, but you do need to keep it very secure along the barrel. Two or three printed brackets- or one long bracket with maybe three screw points on each side- would probably do the trick. I don't think it actually needs to be metal!
That looks like a killer mechanical design however, difficult to translate in to something controlled by a servo that would fit on the acro. Besides, I've got more issues to face than just one pen. My ultimate goal is a pen holder that will accept different diameter pen shapes and sizes. I want to be able to use Copic markers of varying sizes. I limited my first 3D design to a liner type pen in order to have something to work with, but I was concerned about the potential for it to wiggle. I may try adding 2 more 5mm linear bearings (total of 4) in an attempt to give the moving part more rigidity before attempting to add another secure point to the pen itself. The base of the moving part is only 3mm thick. Could be the drag load on the pen is overcoming the rigidity of the moving part held in place by only two 5mm bearings 10mm long.
Forgot to ask. What vector software was used to create the tree illustration, and what software was used to generate the gcode? Thx
If you use a pushrod on the servo instead of the gravity catch, it should be pretty straightforward to get a similar effect on the ACRO with linear shafts. You could even spring-load the pushrod itself, so that mechanism is completely independent of what pen is attached but you get all the reliability advantages of a direct-connection mechanism. My laser actually has a similar mechanical setup to an ACRO 55 (though it existed before the ACRO, I believe), it can take a surprisingly heavy X carriage under those accelerations: Portable Diode Laser Cutter To take any size pen, the obvious simple option is to print a V-block style holder, with pressure applied by screw-down strapping. Downside of that, of course, is the nib tip moves depending on the pen barrel diameter. Other option is to make the head modular, where every pen gets its own holder that attaches, and you use spacers (or spacing built into the holder) to maintain X-Y position of the pen tip between changes. That only matters if you foresee using multiple pens on the same job, but it looks similar to what you already have going on here. Two points of contact on the pen (and the z-axis carriage) is probably a pretty big deal in terms of rigidity though, but that may not be borne out by testing, who knows. Vector software was Adobe Illustrator with direct input from my Wacom. Affinity Designer has the same brush tool if you don't have/want to subscribe to AI though. G-code generation was, I think, Inkscape's Gcodetools extension, though it's possible I just imported the SVG into Fusion 360 and did it from there. Likely the easier option nowadays.
I don't foresee needing to change to different pen sizes per plot and if I did, registration would not be a problem for me in my app. Yes, a v-slot of some kind is an obvious choice as a pen holder design, and I had that in mind when I switched my design from 8mm shafts and bearings to 5mm to give me more room to work with in the center of the moving part. I may ultimately go that route, but before then I plan to explore an idea where I use a very strong neo magnet to secure a snap-in removable/swappable pen holder part. Waiting for the parts to arrive to print and test that idea. I had been an Inkscape user for years, but forced to switch to Adobe Illustrator (hate their pricing model) because of a special plug-in in it that I cannot get around. Affinity would also be a good alternative (I have the ipad version) if it were not for this issue. However, I'm finding generating gcode to be a major issue. The gcode extension in Inkscape is no longer an option . It's a basket case especially with Mac OS 10.14 or above. I've been in touch with the inkscape developers on this issue and they have advised me that the author of that extension has abandon it and no one is there to pick up the ball to fix the problems let alone fix the extremely poor interface. In fact they asked me if I was interested in sponsoring the development of a replacement - which I'm not. My application calls for plotting hundreds, if not a thousand or more of open ended (that's key) illustrative vectors via the 1010, on to base artwork created via a different media. Finding a gcode generator for that has been a challenge so far. My latest attempt is to try to use Lightburn laser software as a svg to gcode generator, but I'm off to a bumpy start so far down that path. You mentioned Fusion 360 (that's what I used to design the pen holder) as possible contender. I know there is a use case for Fusion, gcode, and 3D printing, but I can't image how it would function as a tool to import an illustrative svg file, treat it properly as artwork in its workspace, and then generate gcode for BlackBox - but I could be wrong.
Magnetic is a good idea. It may even be sufficient to provide the spring-loading you need to protect the pen tip/paper surface and avoid pen-wiggle. Magnets do slide together pretty well, I've used them for removable prop parts like magazines. Downside is, sometimes the friction can be too high for them to reliably self-center, which would cause you issues with z-height repeatability. It might not be a huge deal though. That's pretty unfortunate, shame about Inkscape too. I know Affinity Photo can use Photoshop plugins, I have Nik Efex Pro installed in it right now. Maybe Designer can take AI plugins, I dunno. Fusion 360 will generate g-code from simple svg drawings quite well, I'd try it. Fusion's CAM is great, and pretty flexible. There are grbl post-processors for it, and I also sometimes use Notepad++ to manually do some mass adjustments because it's really good at picking out specifics with search expressions. Open-ended is no problem, as you saw. By the looks of the folder it's in, I did in fact use Fusion 360 to do the g-code generation for the file. It's just over 20,000 lines of... This: That's jiggling around in X-Y, jump up to z0.3mm (very short z-retracts are the key to high-speed drawing, I found!), move over a bit, bounce back down to z-1mm, draw one line, back up, over, back down, more jiggling around. Simple! Feed rate is only 2000mm/min because otherwise the jiggly bits got too violent and the whole machine and table it was bar-clamped to would resonate. The NEMA 17s are more than capable of throwing that motor and solid blocks of aluminum around at those speeds though, they're pretty underrated. In the CAM module I'm pretty sure there's a "line trace" option under 2D and you can just select all the lines in your imported drawing. Super easy.
I'll look in to it - thx. Everything I've seen related to Fusion CAM thus far has been in the context of a 3D model and CNC routing so interesting to see how to adapt it to flat art. The ideal workflow would be to import an svg file from Illustrator and go directly to a gcode conversion. A well done vector file uses the least amount of nodes as possible. Tracing functions tend to ramp up the node count and/or mess up bezier curves, so best to avoid that extra step whenever possible.
Fusion's CAM is world class- from our little toys to million-dollar Swiss five-axis units, it's running them all. In theory there are simple spline and NURB commands actually in the g-code spec, I don't know how many CAM packages actually use them though. They're useful for high-speed work, could be worth playing with. The line trace is in the CAM package, not the CAD package, it's one of the possible operations. I.E. "trace these lines with this tool", not the bloated image-trace type stuff you're more familiar with from Illustrator.
