Well, here is the update.
I picked up some new stepper drivers from Pololu to experiment on. I also wanted to test out a .NETMF based one so I picked up the Fez Panda II.
Well, the Panda was a pretty nice board. Notice the "was"? Well, one of the joys of getting older is that my eyesight is not that great any more. While testing out a servo, I plugged into the wrong row on the breadboard and fried the poor little board. Ooops. Oh well.
My first impressions of the board were actually pretty positive. There are some things I prefer about the Ardiuno, and some about the Panda. The panda is faster and has more memory. It also has a built in SD card slot. The IDE has more features but I don't really put that much of a plus in its favor. C# isn't too bad and the ability to print debug statements is an advantage. If I were going to build a graphical interface for an LCD and stuff like that, it seems to be a pretty robust set of tools. That said, I wasn't impressed enough to wait and buy another one to work with. Maybe later for some other project.
I was doing some tests with the Pololu stepper drivers and so far I really like them better than EasyDriver boards I was using. The EasyDrivers were OK, but they began failing and I was down to one working board out of the 6 I had bought. At present, I don't have enough code to think about going with something besides grbl for a real machine. It is a lot more complete but I have been taking some of the code and converting to the Arduino IDE. The main reason I am going that way is to be able to switch boards more easily. The grbl code is pretty deeply tied to the 168/238 and I would like to move over to the Mega. I was testing out my ideas for writing directly to the ports to sequence the steps and that worked as planned. Actually, better than I had thought. I was having to increase the delays to allow the motors to keep up. In the 1/16 step mode, I was down to something like 90 microsecond wait for the motor to respond.
Now, I need to start doing some work on the communication. The plan I am working on is to lighten up grbl by using a pre-processor on the host computer side to be able to do things like units conversions and configuration storage on that end rather than keeping it on the arduino. I have been working with switching the stepping mode kind of like a transmission to switch between rapid motion and real cutting. I won't really be able to tell that much until I have some mechanical motion to see what it is really doing. Right now, I am just sending a fixed number of steps and directions. Some of the ideas I have for the motion control are not as sophisticated as grbl but I really don't think that some of the stuff that they do is totally necessary. At cutting speed, the motion will be slow enough that a simple acceleration scheme might be more economical. Of course I might be wrong, but I already have grbl installed on another board and I don't have to depend on my ideas.
The other thing that has been occupying me is I finally got my mini-mill from Harbor Freight. I had to reorganize my garage to be able to set it up and that was a lot of work. How this relates to this project is to be able to work out some of my ideas for linear motion. This week I will be able to get it all set up and actually see about cutting some metal. I will be tight on space for a few more weeks until I can get the boat out of the way in the garage.
Sunday, July 24, 2011
Wednesday, July 6, 2011
Background for software control of a CNC machine
Well, a few people have contacted me or commented so I guess I will go ahead and talk about the software control.
I am pretty opinionated so some might come off sounding a bit heavy handed but I'll put on my big boy pants and step up.
The normal operating systems we use for a general purpose computer are not real time operating systems. That means you can't guarantee when things will happen. You can't really do things that require millisecond precision in timing. That's fine. Most stuff with CNC doesn't require it. The only thing that is critical is the reading of a few sensors (limit switches and emergency stop buttons) and the stepping of the motors. Everything else can happen when it happens. Software like Mach3 and other stuff tries to come close to the millisecond timing by controlling the parallel port and does a pretty good job. If you don't have a lot of other programs running and can actually find a computer with a parallel port, you are set. Like it or not, parallel ports are going extinct. They are already somewhat unusable on some computers like laptops. Pretty soon, they will be an historical footnote like the IEEE488. (We all remember those, don't we?)
Another thing to consider is the communication rate. The first thing I keep hearing whenever someone says something about CNC control over USB is you can't communicate fast enough to control it properly. Somehow, the fact that we commonly have printers and plotters that have just as demanding positioning and control do just fine over a slow serial connection escapes them. Sitting on my desk next to me at work, I have an old Roland CAMM3 mill/engraving machine. It works with serial or parallel ports just fine. In fact, the only thing wrong with it is that it has a really small work envelope and it has a funky old control interpreter that isn't supported by more modern software.
With a little Arduino or the like, it doesn't run that fast compared to modern computers. My little Arduino runs at 16 MHz. For control of a few stepper motors, it is plenty fast though. The basic communication I intend to put together will do four main things:
Everything else can be done on the host system. Now, I am not claiming to be an expert on stepper control. I can send commands and make one move back and forth but the real intricacies are a bit tougher than that. The good thing is that Siemen Svale Skogsrud wrote grbl which has all that goodness already figured out. I have never communicated with him, I have only been reading his code. It is very pretty code. As with all open source software, he has written his code to scratch his own personal itch. It just doesn't do what I would like.
Well, that's enough for the background. More specific stuff later.
I am pretty opinionated so some might come off sounding a bit heavy handed but I'll put on my big boy pants and step up.
The normal operating systems we use for a general purpose computer are not real time operating systems. That means you can't guarantee when things will happen. You can't really do things that require millisecond precision in timing. That's fine. Most stuff with CNC doesn't require it. The only thing that is critical is the reading of a few sensors (limit switches and emergency stop buttons) and the stepping of the motors. Everything else can happen when it happens. Software like Mach3 and other stuff tries to come close to the millisecond timing by controlling the parallel port and does a pretty good job. If you don't have a lot of other programs running and can actually find a computer with a parallel port, you are set. Like it or not, parallel ports are going extinct. They are already somewhat unusable on some computers like laptops. Pretty soon, they will be an historical footnote like the IEEE488. (We all remember those, don't we?)
Another thing to consider is the communication rate. The first thing I keep hearing whenever someone says something about CNC control over USB is you can't communicate fast enough to control it properly. Somehow, the fact that we commonly have printers and plotters that have just as demanding positioning and control do just fine over a slow serial connection escapes them. Sitting on my desk next to me at work, I have an old Roland CAMM3 mill/engraving machine. It works with serial or parallel ports just fine. In fact, the only thing wrong with it is that it has a really small work envelope and it has a funky old control interpreter that isn't supported by more modern software.
With a little Arduino or the like, it doesn't run that fast compared to modern computers. My little Arduino runs at 16 MHz. For control of a few stepper motors, it is plenty fast though. The basic communication I intend to put together will do four main things:
- Control the stepper motors with an even smaller subset of commands resembling g-code
- Watch for fault conditions (Limit switches and emergency stop)
- Set control pins
- Report status.
Everything else can be done on the host system. Now, I am not claiming to be an expert on stepper control. I can send commands and make one move back and forth but the real intricacies are a bit tougher than that. The good thing is that Siemen Svale Skogsrud wrote grbl which has all that goodness already figured out. I have never communicated with him, I have only been reading his code. It is very pretty code. As with all open source software, he has written his code to scratch his own personal itch. It just doesn't do what I would like.
Well, that's enough for the background. More specific stuff later.
Monday, July 4, 2011
Still alive.
Well, there has not been much to talk about. The progress is pretty slow. Some has not been as quick to implement as I had hoped, some looks promising. I have also been spending a lot of time waiting for stuff to ship to me. I picked up a bulk package of bearings, some glue, a drill bit. That kind of stuff. I have also been waiting on my little milling machine that has been on backorder from Harbor Freight for a couple months.
I have been doing a bit of hardware stuff and a bit of software.
Hardware first.
I have been probably over thinking the linear bearings but there have been some things that bothered me. I prefer to make the rails out of aluminum but I don't like running hardened steel bearing races on aluminum. My current solution is to make some wheels for the bearings. I have a few small sheets of UHMW polyethelene and used that. I cut out a bunch of little squares of the UHMW and drilled out holes for the bearings with a 22mm Forstner bit. Then I took them to the lathe and cut them down to final diameter. It sounds a lot easier than it was. I had to figure out how to cut them out concentrically. The final solution was to make a plug mandrel that I could press fit the pieces on and then a small face plate on the lathe to press them against. I pinched them between the face plate and the mandrel with the tailstock and let them spin a bit on the live center while tightening. As they tightened, they centered themselves. I made enough for the entire router and a handful of extras. They are a snap fit on the bearings and seem to stay on well enough. I did get some 3M 90 adhesive that was supposed to stick to the polyethelene but it was pretty much a waste. It was messy and after a day of drying, it was still possible to pop off the wheels. It didn't stick to the steel well enough to bother with. I might as well just run a bead of epoxy, CA, or just paint on each side of the wheel to make a wall to keep the wheel from sliding off. If the UHMW wheel doesn't stay on the bearing, I can make some replacements with something else that glues better. The carriages will be much like the ones from cncrouterparts.com:
The difference will be that I am going to make mine in wood and in two parts. I have a set of theirs and they are really nice if you are going with steel rails. They would eat up an aluminum rail really quickly.
On the software side:
I already have the g-code interpreter on the Arduino and have had it running the motors for quite a while with the grblShield. I really like the board. The software, not so much. Actually, it is some of the most well written code I have ever seen. I just don't like how it is designed. Basically, you just dump g-code at it and it works.
Here are my main gripes about it:
I looked at the alternatives. The closest one was Firmata. It works similar to the MIDI protocol but when I started working with it, I found it really lacking. All the client libraries I found do not implement the protocol well enough to use it. Specifically, they are missing the sysex messages and the string passing. By the time I would implement that, it would be a lot more work than just creating my own protocol. It is just serial communication, it is not that hard.
All I need on the controller board is absolute positioning with a subset of g-code, reading and setting outputs on the other pins, and to be able to set an emergency state to stop the machine when things go really wrong. On the controlling computer, all the unit conversion, settings and calibrations, g-code interpretation, zeroing, spindle control, limit switches, jogging, and such can be handled. It also allows the possibility to switch either component. I could go with a faster controller with more memory like the Netduino. I could also write a more sophisticated host software to run everything.
Now, here is the question for readers here:
Do you want for me to get into the coding part as well here on this blog or do you want me to just focus on the hardware and machine design?
I have been doing a bit of hardware stuff and a bit of software.
Hardware first.
I have been probably over thinking the linear bearings but there have been some things that bothered me. I prefer to make the rails out of aluminum but I don't like running hardened steel bearing races on aluminum. My current solution is to make some wheels for the bearings. I have a few small sheets of UHMW polyethelene and used that. I cut out a bunch of little squares of the UHMW and drilled out holes for the bearings with a 22mm Forstner bit. Then I took them to the lathe and cut them down to final diameter. It sounds a lot easier than it was. I had to figure out how to cut them out concentrically. The final solution was to make a plug mandrel that I could press fit the pieces on and then a small face plate on the lathe to press them against. I pinched them between the face plate and the mandrel with the tailstock and let them spin a bit on the live center while tightening. As they tightened, they centered themselves. I made enough for the entire router and a handful of extras. They are a snap fit on the bearings and seem to stay on well enough. I did get some 3M 90 adhesive that was supposed to stick to the polyethelene but it was pretty much a waste. It was messy and after a day of drying, it was still possible to pop off the wheels. It didn't stick to the steel well enough to bother with. I might as well just run a bead of epoxy, CA, or just paint on each side of the wheel to make a wall to keep the wheel from sliding off. If the UHMW wheel doesn't stay on the bearing, I can make some replacements with something else that glues better. The carriages will be much like the ones from cncrouterparts.com:
 |
| Linear Bearing Carriages from cncrouterparts.com |
The difference will be that I am going to make mine in wood and in two parts. I have a set of theirs and they are really nice if you are going with steel rails. They would eat up an aluminum rail really quickly.
On the software side:
I already have the g-code interpreter on the Arduino and have had it running the motors for quite a while with the grblShield. I really like the board. The software, not so much. Actually, it is some of the most well written code I have ever seen. I just don't like how it is designed. Basically, you just dump g-code at it and it works.
Here are my main gripes about it:
- At present, it doesn't run on anything but a plain Arduino with a ATMega328 which doesn't leave a lot of room to do what I want. Little memory and few free pins. I would prefer to run it on an Arduino Mega with a lot more input and output capability and more memory.
- All the code resides on the Arduino. There is no reason to put all of that stuff there. It doesn't need to do all the settings. It doesn't need to do all the unit conversions. All I need to do on the Arduino is to run the steppers and set and retrieve info from the pins.
- There is no flow control to do things like zeroing, emergency stop, or spindle control. The have some preliminary stuff there to implement limit switches but that is about it.
- It implements a subset of g-code. No variables, subroutines and such.
- There is no flow control to handle things like bit changes, jogging, or pausing.
- It uses an older tool chain for development which I just don't like.
I looked at the alternatives. The closest one was Firmata. It works similar to the MIDI protocol but when I started working with it, I found it really lacking. All the client libraries I found do not implement the protocol well enough to use it. Specifically, they are missing the sysex messages and the string passing. By the time I would implement that, it would be a lot more work than just creating my own protocol. It is just serial communication, it is not that hard.
All I need on the controller board is absolute positioning with a subset of g-code, reading and setting outputs on the other pins, and to be able to set an emergency state to stop the machine when things go really wrong. On the controlling computer, all the unit conversion, settings and calibrations, g-code interpretation, zeroing, spindle control, limit switches, jogging, and such can be handled. It also allows the possibility to switch either component. I could go with a faster controller with more memory like the Netduino. I could also write a more sophisticated host software to run everything.
Now, here is the question for readers here:
Do you want for me to get into the coding part as well here on this blog or do you want me to just focus on the hardware and machine design?
Subscribe to:
Posts (Atom)