[JasonCampbell]

Hi,

I pursue robotics as hobby and these days there are 32-bit motor controllers that operate in 10+ MHz refresh rate that can perform amazing number of PID calculations per sec and this type of controllers can drive DC motor at very high rpm while maintaining tight speed regulation.

Back to CNC, the cnc servo drive and controller combo I know is gecko g320/g340(drive) and Mach(controller) and no more (sorry I'm new to cnc)
Anyways because Mach is limited to 48000 pulse/sec due to computer's motherboard clockspeed, high speed operation is difficult even with drive-side pulse multiplier (and pulse multiplier is not a good thing since it will multiply PID error too)

So why not a cnc software that output ASCII commands? You know, software just sends out ASCII commands to make blabla number of steps in blabla pulse rate, then the drive's microcontroller performs the move accordingly. In other words, forget sending pulse at all because the controller sending out pulse is simply "a way" to give out message of step direction and rate, so replace it "ASCII way".
In this way, 48000 pulse/sec limitation is easily overcome and higher rpm will be possible.
Any drive equiped with 10 MHz 32 bit microcontroller will be capable of producing much higher PID refrash rate than needed for 48000 pulse/sec hence will be able to control the motor at much higher rate, which will result in not only an operability at higher rpm but also smoother rotation of motor(fully utilze high resolution of the encoder).


...
Anyone aware of such cnc software or standalone controller that put out ASCII(or binary) command?
Anyone aware of inexpensive servo drive that will accept such ASCII commands?
I guess it has to be a controller+drive combo.

Again my knowledge is limited to gecko and Mach, sorry.
Thanks for your time.

[Xerxes]

You're right that step/dir can be quite limiting with PC printer port.

There are number of different control buses for servo drives but not many of them are supported in low cost control software. However, several software tools have support for hardware pulse generators which can be used to solve the limited pulse frequency.

[NC Cams]

I'd surmise that a lot of the control logic is based on tradition as much as technology.

Keep in mind that, at one time, the ONLY external means of communication from a computer was thru the printer port. This came about simply because the original developers only had teletype machines to communicate to and with the computer with.

I'd propose that some MS/MD (monkey see, monkey do) took place and parallel path development of communications took off. Since you only had the LPT port, that's the mind speak that development nested about/around. It is no wonder that so many folks used step/direction systems that were LPT based - they were documented and DIY'able so that's were the focus took place.

Fast forward 20-30 years. We have many new ways to communicate with the hardware bus (parallel, serial, USB, whatever). However, once you have a developed and mature product base that is LPT port focused, it is going to be pretty hard to develop and all new "whatever" based communication/machine control scheme. We may be in the twilight days of LPT use, simply because the computer industry has found alternate ways to communicate with the outside world as opposed to the LPT port. Perhaps ASCII/binary communications of some other form may become the new defacto standard - time will tell.

This is why dedicated machines used dedicated processors. They are NOT locked into an industry standard buss of some sort that has the benefits (low cost, wide spread availability) but limitations (speed, thru put) that the legacy communication ports have. When you do that, you can bypass the bottlenecks and do faster or more elegant machine control - especially when the M/B isn't doing e-mail, web browsing, playing games and/or typing a resume while you're CNC milling some material.

Most certainly, a clean sheet of paper, new technology communication/control scheme could be taken advantage of today. The question is, "who wants to be the first to spend the time and $$$'s to develop it and try to create/carve out an all new market???". The devil you know is easier to deal with than the devil you don't.

[turmite]

Well I am surprised Ger hasn't already addressed this post , but since he hasn't I will. Mach is no longer limited to 48000. Art bumped the top speed to 100,000 about two months ago. Another thing to remember......at 25000 I can drive my big gantry machine as fast as I can current cut with the spindle I have. There are many other factors associated with "speed" cutting than just the controller. Rigidity of the machine being one. It doesn't matter if you can cut at 10,000 ipm as long as the finish of the cut is bad it does you no good!

Mike

[NC Cams]

Ah yes, cutter speed versus "digital processing speed".

No matter what computer you use, the speed you can run electrons at thru wires will ALWAYS outrun that which you can run mechanical devices.

Not only is finish an issue/problem but finding a cutter that will burn thru materials at 10,000 ipm is a real challenge - not even lasers can do that AFAIK.

[JasonCampbell]

Thanks for your thoughts.

I found Rutex does this. Their newer Rutex R2000 series use SPI communication: Basically a serial communication through parallel port. 32-bit too! This means this drive can update PID in fraction of a millisecond (over 10,000 PID calculation a second is possible). Nice.

Didn't realise Gecko is spurring similiar path by their new add-on borads (G-Rex G100/G101). However charging $150+ for this add-on is a near rip-off since this add-on board is mere 8-bit though understandable the "mother" boards these add-ons get plugged in are 8-bit. These add-ons communicate via USB and ethernet but ethernet may not be a very good idea since ethernet is packet delivery based (not a continous stream). Packet delivery means delay in fraction of a second and tx side delay + rx side delay can accumulate into a latency longer than a second (This is why Robotics community stay clear from ethernet). However in cnc, absolute timing is of less importance than relative timing - meaning that it is sufficient that all axis keep relative timing to each other but finishing the job on exact time mark is not so important, though in Robotics, absolute timing is also very important - packet scheme may work fine in cnc (Though I need to mention Mach does support absolute time control. Mach calls it "inverse time control". I tried this feature but is not very tightly implemented. Or should I say it is impossible to implement this with 48000/sec pulse train)

As to Mach doing 100,000 pulse a sec, I wasn't aware I'll look into it, though I do not see how they do this since pulse train cannot be "compressed" unlike ASCII/binary data. Just off my head, this may either mean that Mach is capable of 100,000 but actual pulse train throughput will still be bottlenecked to 48000 or Mach is using some type of "packet scheme" or Mach is using non-parallel port. And after all, to take full advantage of 10000+ PID calculation a sec capability, probably minimum of 300,000 positional command a sec update rate is necessary (10 MHz chip can update 10,000,000 positions a sec: and ASCII/binary can easily command the chip to do this many updates a sec)

As to IPM, sure 48000 maybe sufficient for current IPM usage but one might ask why soundcard go upto 192KHz while human hearing is limited to 20KHz (192KHz sampled music certainly sounds better) IPM is not the only factor that higher refresh rate affects - e.g. higher refresh rate means less fluctuation of velocity and less oscillation at tight turns/stops/reverse which translates into better smoothness and accuracy (imagine gradual transition possible with 10000+ PID calculations a sec!)

Pulse control is ineffient and inefficiency means higher price (high tech is cheaper). 10 MHz 32-bit motor controller with sophisticated PIDD (yes, one more finer derivative added to regular PID) for Robotics is not expensive at all these days. Amazing steep downhill rate those marvelous microchip prices go! Need for absolute as well as relative velocity control of Robotics community necessitates much more rigorous velocity regulation and this is achieved through finer PID(PIDD) and higher bit/higher MHz and some of these boards are priced below $100. And these borads with good power have fancy functions that cnc drive doesn't need. Someone in this forum might as well want to modify/strip down these Robot boards and sell to cnc community for ..say $60 (Uli?)

:idea:
Well enough babbling, sorry, the reason I started this thread is to find out cnc drive board that accepts ASCII or binary or whatever way that is not pulse train while priced below ..$200
Please let me know more of these types. Thank you!

[turmite]

[QUOTE=JasonCampbell :idea:
Well enough babbling, sorry, the reason I started this thread is to find out cnc drive board that accepts ASCII or binary or whatever way that is not pulse train while priced below ..$200
Please let me know more of these types. Thank you! [/QUOTE]

Wullll...why didn't ye just ask?

http://www.jrkerr.com/boards.html

Though, I don't really understand the need, when machine limitations are still going to be a factor both in smoothness and speed. BTW Mach also has Quantum coming out that has s curve smoothing, though I don't know if it will function at the 100k level. HTH

Mike

[bsharp]

All big expensive industrial machines have proprietary motion control boards and software. Parker makes a card that I know of that plugs into a pc slot “Acroloop”. The speed you can obtain from motion control boards is incredible. You can take an old Pentium4 pc and drive round servos at there absolute max. With linear drives the acceleration and max speed is to put it lightly “awesome”. The fist time I seen a linear drive CO2 laser rapid at 4700 IPM at 3G acceleration made my jaw drop. And it had a table resolution of 0.0005. In the big industrial world the speed limit is the size of your pocket book.
But I think for DIY cnc the simple Mach2 "or any of the many", PC"anything from a 486", Driver "Gecko, Larken, Rutex and more" combo is pretty darn good. You have no proprietary components or software to be forced into paying an arm and a leg for.

[bbj]

Making an interface that runs SPI or serial or any other protocol for that matter is reasonably simple. Most microprocessors have hardware support for it. The issue comes in with your current software. It cant "talk" SPI. You will need to write your own control software / modify an existing program.