And the great thing is, by changing the multiplier (at the minute we're using 25.4/90 to convert an image at 90dpi into millimetres) we can output our g-code in any units that the cnc machine requires.
One thing we have noticed, however, is that there's no real control over the order of the dots - the svg file appears to write them in the order they were drawn on the screen. That's fine for a simple example like this, but could be a bit of a nightmare when importing files from other applications.
The generated g-code (obviously) follows the drawing order of the svg file, which may not necessarily by the most efficient path between points.
By following the points in our svg file exactly, we would end up with a drilling pattern something like this:
So the last little bit of our project to do now, is to add in some path optimisations. We've already done something similar in the past, with our miniature CNC drill, so it shouldn't be a major problem.
Because our CNC is pretty accurate this time (the miniature one had loads of backlash because of the super-cheap stepper motors) we should be able to implement a "move to nearest point" routine to reduce the amount of time the drill head spends travelling from one point to the next (and hopefully reduce the overall drilling time for each entire board).
I've heard of bad motor driver electronics, lead screws, linear motion systems, etc, contributing to an inaccurate CNC machine, but the stepper motors? That is a new one on me.
ReplyDelete