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.
This sounds like an interesting approach. I'm just getting together a demo cnc (ie total newb) and found this while researching grbl, which is a lot closer to the mark for me than EMC2. How many primative commands do you imagine will be needed?
ReplyDeleteCheers for the structural comments!
Hi Clark,
ReplyDeleteAt the simplest, you are looking at only straight lines with the curves being approximated by segments. The more you put in, the more the load goes to the controller. Of course you also end up increasing the communication load sending all those segments. You pay either way.
David,
ReplyDeleteI realize that this is an old post and you may realize some of these things already but I thought I'd comment just in case on some points you make in this post.
Let's say you need to turn a stepper motor at 1000 rpm with a 10x micro stepping drive. Do do so, you must provide a pulse train at a frequency of 1000 x 200 steps/rev x 10 (micro step) / 60 seconds = 33.3kHz or a period of 30uS - not milliseconds but microseconds.
USB is certainly fast enough to get data to a real time controller (check out the smooth stepper) and actually, what's happening is that you're misinterpreting what people are saying. What they are actually saying is that you can't use a USB to Parallel converter to use Mach 3 to control something like a G540 using a computer without a parallel port.
Comparing this to a printer communicating over usb is illustrating your lack of understanding of the concept here. When you send data to a printer, you basically send a message asking it to e.g. print the letter "A" - all of the real time control of the print head is accomplished in the printer itself.
This is the equivalent to how something like a smooth stepper works. The Mach 3 plug in sends it a request over USB to generate a pulse train with certain parameters and then the real time control is generated in the smooth stepper.
3/4 of the battle is understanding the question.
Hi Andy,
ReplyDeleteThis is actually an argument that goes back quite a while. You have to decide where the processing should place. Look at the old Commodore computers. They had another 6502 (or similar) on each of the components. Printer, hard drive, etc. When you use Mach 3 or EMC2 or whatever, you are dealing with an OS that does not have the real time capabilities and trying to perform functions that are real time in nature. The current philosophy is to combat that with higher and higher speed CPUs.
A more reasonable solution is to work in a two tier system which is exactly what printers use. They have an interpreter to handle the real time requirements and the communication to the host computer is done through something like Postscript, HPGL, PCL, or the like. If you have a small subset of time critical operations on an embedded controller, then you can work at a high level with an interface such as the current CAM programs and have it parse into simple instructions to send to the embedded controller.
As I am typing this, I have a Makerbot printing out a part next to me on the table connected through USB. It has a similar set-up and works just fine.
I realize that programs Mach3 aren't set up with this type of philosophy but there is no technological reason for them to work that way. It was just a design choice by the program's authors.
I had never seen a bandura before, those are very nice. Are the base strings played free or is there a fingering against the board?
In the old days, the bass strings were stopped to get certain notes but now a days it's only the recreationists that play in that fashion.
ReplyDeleteThe decision to leave the real time component in the PC for EMC and Mach 3 was made for reasons of economics - when they came out, it was rather expensive to make an off board device to do what needed to be done and even USB was pretty new. The whole purpose in life for EMC was to make something that could control a PC without off board hardware.
EMC is free and Mach 3 is only $150.
The "Current Philosophy" as you describe it only relates to low end controllers like Mach and EMC and that's only due to cost. Since the beginning of CNC, "real" controllers have had dedicated hardware to create the pulse stream.
For several years now, there are several options for at least Mach 3 to offload the real time component:
http://www.warp9td.com/ (which has been out since 2008)
http://dynomotion.com/KFLOP.html
http://www.aliexpress.com/product-fm/492988304-USB-Breakout-Board-4-Axis-Mach3-Interface-Adapter-Free-Shipping-By-CNC-Modulkit-wholesalers.html
Without a doubt, Mach 3 will have to move away from Parallel Port - on board timing etc. if they want to remain viable in the future. There are already several USB devices out there with Mach 3 support and there will almost certainly be more in the future and the costs will come down, performance will go up.
So just to wrap things up - I doubt anyone would argue or has ever argued that USB is too slow for use in a CNC system - it's been done for years. What's been argued is that USB is not a real time protocol and that for accurate machine control, there must be a device on the other end to provide the real time pulse control.