I did quite a bit of research looking for a stepper driver board and motors suitable for my setup. I considered a TB6560 driver. There are a lot of them available on eBay. I was concerned about documentation, tech support and all. Not knowing a lot about the power requirements, and how to hook it all together, I decided on the Hobby CNC EZ Driver package that includes the driver board, stepper motors, and various other components for powering it. It did not come with a case or a transformer.
The entire package requires assembly. I don't have a lot of experience soldering PCBs. Most of my prior soldering is done with a small butane torch. Not exactly controlled heat. But with a little warm up practice I got the hang of things and I think I did a pretty good job. We'll see. I've put everything on the board except the driver chips. I have to test for 5V at a couple of key points. In order to do this I need to apply at least 12V DC to the board. I don't have a suitable power supply for this so I need to proceed with the rest of the assembly. Here's the almost-assembled driver board:
A friend of mine gave me a 24V 12A transformer. It's industrial strength. It's mounted in a NEMA 1 case, whatever that means. Anyway, it's big. It won't fit in the case the rest of the system was designed to go in, so I guess I'll have to mount it externally and make a power cord. Here's the transformer with 9V battery for scale (I didn't have a quarter on me). I was hoping to keep things as small as possible but I'd rather have such a robust power supply (that I got for free).
I managed to wire the transformer up and test it. 120V AC in and 23.7 V AC out, so that's good. I hooked it up to the bridge rectifier hoping to get something like 30+ V DC out of it. (I don't recall why it gives more than 24V. I'll look into that later.) Anyway, I got a beep from my multimeter but rather erratic numbers for voltage. I think that's to be expected since the AC signal sweeps back and forth and produces a pulsing DC signal. I've got a capacitor the size of a hamster that supposedly will smooth the signal out. This capacitor carries a "SEVERE SHOCK WARNING" in the instructions. Hopefully I won't kill myself.
I just got the case yesterday, so I'm ready to start the assembly of the major components. Here's the case. It's not bad looking at all. I'll be wasting a fair amount of space since there will be no transformer in it, but I will be putting the Arduino in it and down the road it will give me more flexibility. The front and rear cover are rectangular (no rounded edges or angles) so if I need to replace them as the configuration changes it should be easy enough.
Documenting the process of converting a Sherline 5000 mill to CNC control... and moving on to make cool stuff!
Sunday, December 26, 2010
Saturday, December 25, 2010
Tool Path Simulation
In my last post, I described generally what I want for the tool path software. It was important for me to find out how difficult this part was going to be since it was critical to the whole process. I work on a Mac and it's hard to find CAD/CAM/CNC software for it, particularly cheap or free software. If I couldn't put something together myself, I would not be able to achieve the main goals of the project. A few months ago I took the first stab at the host software for building tool paths. I gave an overview in my last post.
I write server-side Java for web applications by day, so naturally I want to write the host software in Java. Working with points and lines to describe the path seems easy enough, but I didn't want to get too bogged down in Pythagorean Theorem implementations and whatnot. Nor did I feel like learning how to do 2D and 3D graphics in Java. Fortunately there's a programming environment called Processing. (Notice I didn't call it a language, it's ultimately Java at the core.) This environment has a number of great libraries I was able to leverage to get 3D modeling code off the ground. The toxiclibs library in particular is really useful for working with 3D geometry. I can create a 3D line with the X/Y/Z coordinates and ask the line for the length, direction vector, etc.
I had a little bit of learning to do but the basic 3D path modeling and manipulation went together very quickly. It should be pretty easy to imagine how a 3D "turtle graphics" program would create lines in 3D space. Here's a basic rendering of a test path:
In my previous post I stated that the cone represents the spindle or cutting bit and is animated along the path. This required some real thinking that the path generation did not. I could have used some available linear interpolation code to move the cone, but decided to write the code myself using the same approach that the Arduino code would use to move the real spindle. Then my 3D preview would also serve as a simulation of the stepper driver sub system.
Ultimately the only thing the Arduino will do is send a signal to step one or more motors, wait a bit then do it again. If the cutter is moving along more than one axis, then the motors need to be stepped with a proper ratio. Step X three times, then step X and Y together, then X three times, etc. A graphical representation of such a move would look like this:
The starting position is at the left with XC, YC, and ZC holding 3, 5, and 7. XC holds the smallest non-zero value so we subtract 3 from all counters and we get the second frame. XC has reached zero so we step the XC axis. In the third frame we restore XC to its original value. Now YC holds the smallest value so we subtract 2 from all three. This leaves YC at zero so we step it and the process continues.
Pretty crafty solution, eh? I thought so. Well it turns out there's a name for it, the Bresenham line algorithm. Developed in 1962. Well if I came up with it on my own, I think it must be kinda obvious, no disrespect to Mr. Bresenham. I did study graphics programming in college, so maybe there was some lingering impression on my brain. Anyway, I got it to work, so I'm happy. Thomas has some interesting things to say about this approach. If I have any smoothness problems with this, perhaps I will have acquired enough experience working with Arduino timers to step each axis in independent time rather than one, two, or three at once "in time" with each other. Does that make any sense?
The above stepping algorithm will be repeated as many times as it takes to move the longest axis its full distance (the variable L above). The 3D line library I'm using makes it pretty easy to get the axis lengths from a line. One thing I've thought about but haven't tested yet is if I need to deal with remainders. If I get to the end of the line and XC, YC, and XC counters have 2, 1, and 3 in the counters, should I leave those values in and add the next set of values for the next move. I may lose accuracy if I don't do this, but it may take a rather long series of moves for that to translate into any distance I can measure with my tools.
I write server-side Java for web applications by day, so naturally I want to write the host software in Java. Working with points and lines to describe the path seems easy enough, but I didn't want to get too bogged down in Pythagorean Theorem implementations and whatnot. Nor did I feel like learning how to do 2D and 3D graphics in Java. Fortunately there's a programming environment called Processing. (Notice I didn't call it a language, it's ultimately Java at the core.) This environment has a number of great libraries I was able to leverage to get 3D modeling code off the ground. The toxiclibs library in particular is really useful for working with 3D geometry. I can create a 3D line with the X/Y/Z coordinates and ask the line for the length, direction vector, etc.
I had a little bit of learning to do but the basic 3D path modeling and manipulation went together very quickly. It should be pretty easy to imagine how a 3D "turtle graphics" program would create lines in 3D space. Here's a basic rendering of a test path:
In my previous post I stated that the cone represents the spindle or cutting bit and is animated along the path. This required some real thinking that the path generation did not. I could have used some available linear interpolation code to move the cone, but decided to write the code myself using the same approach that the Arduino code would use to move the real spindle. Then my 3D preview would also serve as a simulation of the stepper driver sub system.
Ultimately the only thing the Arduino will do is send a signal to step one or more motors, wait a bit then do it again. If the cutter is moving along more than one axis, then the motors need to be stepped with a proper ratio. Step X three times, then step X and Y together, then X three times, etc. A graphical representation of such a move would look like this:
Sometimes the line is not so smooth. We might step the axes in a ratio of 3:2 for example (I'm illustrating only 2 axes for simplicity, but we'd be dealing with 3). Because I want to minimize the workload on the Arduino, I'd like to have only integer math, adding and subtracting only. I define 3 variables to hold counters for each axis, XC, YC, and ZC. I also define a loop variable L. This defines the number of steps to take total (more details later). Suppose I move in a line defined by this ratio:
XC = 3
YC = 5
ZC = 7
If I subtract one from each, eventually one or more axes counters will reach zero and I then step it/them and reset the counter to the original value. I can speed things up a bit by subtracting the smallest non-zero value from all non-zero axes. Here's an illustration:
Pretty crafty solution, eh? I thought so. Well it turns out there's a name for it, the Bresenham line algorithm. Developed in 1962. Well if I came up with it on my own, I think it must be kinda obvious, no disrespect to Mr. Bresenham. I did study graphics programming in college, so maybe there was some lingering impression on my brain. Anyway, I got it to work, so I'm happy. Thomas has some interesting things to say about this approach. If I have any smoothness problems with this, perhaps I will have acquired enough experience working with Arduino timers to step each axis in independent time rather than one, two, or three at once "in time" with each other. Does that make any sense?
The above stepping algorithm will be repeated as many times as it takes to move the longest axis its full distance (the variable L above). The 3D line library I'm using makes it pretty easy to get the axis lengths from a line. One thing I've thought about but haven't tested yet is if I need to deal with remainders. If I get to the end of the line and XC, YC, and XC counters have 2, 1, and 3 in the counters, should I leave those values in and add the next set of values for the next move. I may lose accuracy if I don't do this, but it may take a rather long series of moves for that to translate into any distance I can measure with my tools.
Tool Path Software
In my current manual milling process I begin with 2D CAD design. The main purpose is to come up with accurate coordinates for moving the axes around. After completing the drawing of the part, I strategically place circles representing the cutting bit I will use around the drawing. I then add dimension lines referencing the cutter circles. All dimensions come from a 0, 0 "home" position. So each cutter circle essentially has X, Y coordinates. After squaring up my stock, I set the spindle to the "home" position and zero the DRO. Then it's just a matter of removing material until I reach the cutter positions on the drawing.
A way more sophisticated way of doing things is with advanced CAD/CAM software where you draw your part in 3D and then generate tools paths (G Code) that tell the mill how to remove the material. But this is not an "Easy Button". You don't just throw a piece of metal in the vice and press "go". Milling most anything is a series of discreet operations such as facing, pocketing, and drilling. Each operation may require remounting of the stock, changing tool bits, etc.
I'm not willing to invest in an advanced software stack that costs as much as the hardware. I think I can write a decent, flexible program for describing how to mill a particular piece (not simply "what it looks like"). While a fancy user interface would be nice, I'd like to have a "scripting language" that allows me to write "parameterized functions" representing the milling operations to be performed. The first step of making a part is usually squaring up rough stock. A "facing operation" might take parameters for the width and depth of the face, the size of the cutting bit, how much material to take off with each pass and how many passes to make. I would just take my cad drawing with dimensions on it and plug them into the facing operation.
A facing operation would be composed of many straight line movements to get the job done. This series of lines could be built up with a series of commands to move the spindle in 3D space. When I was a kid, personal computers had just come out. When the graphics got sophisticated enough, a program called "turtle graphics" came out. Basically you have a "turtle" with a "pen" it can draw with. You tell the turtle to move forward a certain distance, turn right a certain number of degrees, raise and lower the pen, etc. The core of my scripting language would essentially be "3D turtle graphics". Here's a code sample:
This describes a rather arbitrary path for testing purposes. (It's a bit hard to tell what the plunge command does. Here it says "descend 0.5 units while moving 5 units". So the circle becomes a helical path.) Here's a screen shot of the 3D preview / simulator:
A way more sophisticated way of doing things is with advanced CAD/CAM software where you draw your part in 3D and then generate tools paths (G Code) that tell the mill how to remove the material. But this is not an "Easy Button". You don't just throw a piece of metal in the vice and press "go". Milling most anything is a series of discreet operations such as facing, pocketing, and drilling. Each operation may require remounting of the stock, changing tool bits, etc.
I'm not willing to invest in an advanced software stack that costs as much as the hardware. I think I can write a decent, flexible program for describing how to mill a particular piece (not simply "what it looks like"). While a fancy user interface would be nice, I'd like to have a "scripting language" that allows me to write "parameterized functions" representing the milling operations to be performed. The first step of making a part is usually squaring up rough stock. A "facing operation" might take parameters for the width and depth of the face, the size of the cutting bit, how much material to take off with each pass and how many passes to make. I would just take my cad drawing with dimensions on it and plug them into the facing operation.
A facing operation would be composed of many straight line movements to get the job done. This series of lines could be built up with a series of commands to move the spindle in 3D space. When I was a kid, personal computers had just come out. When the graphics got sophisticated enough, a program called "turtle graphics" came out. Basically you have a "turtle" with a "pen" it can draw with. You tell the turtle to move forward a certain distance, turn right a certain number of degrees, raise and lower the pen, etc. The core of my scripting language would essentially be "3D turtle graphics". Here's a code sample:
m.down(0.75f); m.forward(0.25f); m.right(60.0f); m.forward(1.75f); m.down(1f); m.right(90); m.forward(2.5f); m.plunge(0.5f, 5f); float turn = (float) (360 / 16.0); for (int steps = 0; steps < 16; steps++) { m.right(turn); m.forward(0.5f); } m.up(0.25f); m.setHeading(30); m.forward(2.25f); m.right(45); m.forward(0.5f);
This describes a rather arbitrary path for testing purposes. (It's a bit hard to tell what the plunge command does. Here it says "descend 0.5 units while moving 5 units". So the circle becomes a helical path.) Here's a screen shot of the 3D preview / simulator:
The Cone in the upper right is a representation of the spindle or cutting bit. It is animated along the path and the path and the whole scene can be rotated and zoomed for examination. (The line colors and points are for analysis of the path generation algorithm.)
The tool path is fully modeled on the host computer and then sent to the Arduino (see "Major Components").
A G Code parser could pull in paths generated by other software components and mix the paths with other operations to create a complete job program that can even prompt the operator to change tool bits.
Friday, December 24, 2010
Major Components
I have a small workshop. I like it. It's comfortable though I wish the water heater wasn't in it. My Sherline 5000 mill is a bench-top mill. The footprint is about 15 x 10 inches, maybe 20 inches high. A 30 inch segment of my workbench is plenty of room to contain everything, tools, cutters, etc.
Many CNC systems are built around a common PC sending signals out the parallel port to a stepper motor driver that controls the motors. There is good, free software for controlling the part of the process that actually moves the machine. If I were to use a PC I'd be adding quite a bit of hardware to the system. The last thing I want to do is stuff a PC tower and a monitor in my workshop.
Then there is the matter of the design process. There is good, free software for basic CAD design available for the PC (Linux) so I could do everything on this PC. But I don't want to. My workshop is a bit cold and I don't want to sit still and plug away on a computer sitting on a bar stool or standing. (No room for a decent chair and computer workstation.)
What I want to do is design on my laptop anywhere in the house I want. I don't want to mess with networking my laptop to the PC I don't want in my workshop.
There are many stepper motor drivers that take "step and direction" signals to control the steppers. I've done some work with the Arduino microcontroller and I know it's capable of doing such a thing. There is a question of speed, of course. I've researched it quite a bit and I think it will do fine if I'm not trying to have it do too many complicated things.
The system will be composed of a laptop where design and tool path generation is done, the Arduino which receives motion commands from the laptop and the stepper driver. If this is the path I will take, it will fall on me to write the software to glue it all together. Fortunately I write software for a living so I'm pretty sure I can handle it.
Many CNC systems are built around a common PC sending signals out the parallel port to a stepper motor driver that controls the motors. There is good, free software for controlling the part of the process that actually moves the machine. If I were to use a PC I'd be adding quite a bit of hardware to the system. The last thing I want to do is stuff a PC tower and a monitor in my workshop.
Then there is the matter of the design process. There is good, free software for basic CAD design available for the PC (Linux) so I could do everything on this PC. But I don't want to. My workshop is a bit cold and I don't want to sit still and plug away on a computer sitting on a bar stool or standing. (No room for a decent chair and computer workstation.)
What I want to do is design on my laptop anywhere in the house I want. I don't want to mess with networking my laptop to the PC I don't want in my workshop.
There are many stepper motor drivers that take "step and direction" signals to control the steppers. I've done some work with the Arduino microcontroller and I know it's capable of doing such a thing. There is a question of speed, of course. I've researched it quite a bit and I think it will do fine if I'm not trying to have it do too many complicated things.
The system will be composed of a laptop where design and tool path generation is done, the Arduino which receives motion commands from the laptop and the stepper driver. If this is the path I will take, it will fall on me to write the software to glue it all together. Fortunately I write software for a living so I'm pretty sure I can handle it.
Introduction
Hello, this is my first post in my first blog. This blog will document the conversion of my Sherline 5000 vertical milling machine to CNC control. You might learn something cool or, more likely, find something wrong with what I'm doing. I'm open to feedback either way.
Several years ago I purchased the mill and have spent quite a bit of time learning how to machine. My ultimate goal is to build robots, though I may never get there. I find I like the process as much as the result. Recently I was inspired to take my machining capabilities to the next level by adding computer control to the system. Hopefully I won't spend a ton of time doing something about machining rather than doing machining.
Anyway, here we go...
Several years ago I purchased the mill and have spent quite a bit of time learning how to machine. My ultimate goal is to build robots, though I may never get there. I find I like the process as much as the result. Recently I was inspired to take my machining capabilities to the next level by adding computer control to the system. Hopefully I won't spend a ton of time doing something about machining rather than doing machining.
Anyway, here we go...
Subscribe to:
Posts (Atom)