# PC CNC control



## bsharp (Dec 9, 2014)

I have been beating around the idea of writing a windows based CNC control for a while. I currently have Mach 3 and it has worked well over the years but it does have its flaws, limits and quirks that will never be fixed.
I would like to write a Windows based controller that would have more ability's and be more refined for normal shop CNC machines.
At this point I don't think it would be of use to mess around with writing a parallel port driver as they are limited and will soon be extinct anyway. The controller would interface with USB or network controller cards and IO boards. 

1: The software would be specifically written for a 2 to 3 axis lathe or a 3 to 4 axis mill
2: More robust and useful built in conversational ability's
3: Ability to support more I/O for tool changers and ability to support a proper machine error reporting system

I guess my question would be from a home shop perspective what are some things that you would like to see or not see in a cnc controller software?
Like I said this is just an idea that has been rattling around my brain for the last few years and figured I would try and get a little input from others.


----------



## MarkStephen (Dec 9, 2014)

Nice idea, and sense you asked. The #1 feature I would like to see is a program that is cross platform. :soapbox: ->About 25% of the world does NOT use window$ and that number is growing. Way too much windows only crap out there as it is. Don't really think the world needs any more.<- :soapbox:


That being said, as I'm sure your aware, using usb can not be relied upon to be real time. That means that your going to need to offload the machine commands to an external buffer. Regardless if your going proprietary or open source, make sure your com protocols are well documented and open so hardware can be adapted. The program should be able to talk to a $10 Arduino as easily as it can a$10,000 state of the art control box. 

Touch screen friendly interface. Keyboard and mice don't always play well in the shop, but a sealed up touch screen can last years. 

On the fly adjustable jogging speed. 

Ability to accept user scripting with a straight froward and easy to understand interface.

I'm sure there's more, but that's just off the top of my head at the moment 

Mark


----------



## Transformer (Dec 9, 2014)

Well I am very new to all of this, in way over my head but plodding along, so I cannot even say what I would like to see, except .......... better, more understandable, clearer documentation and manuals.  Mach3 is on its way out but the documentation has never been brought up to snuff.  I was reading one of the manuals recently and it said see further information on page ?????.  For me a less than perfect program with good documentation would be better than a great program with poor documentation.  I know writing documentation is not fun or sexy but you can see why some programs are expensive, because they have invested in what is needed to make the program useful.


----------



## John Hasler (Dec 9, 2014)

MarkStephen said:


> Nice idea, and sense you asked. The #1 feature I would like to see is a program that is cross platform. :soapbox: ->About 25% of the world does NOT use window$ and that number is growing. Way too much windows only crap out there as it is. Don't really think the world needs any more.<- :soapbox:
> 
> Mark



I'll second that, as long a "cross-platform" includes more than just Microsoft and Apple.


----------



## JimDawson (Dec 9, 2014)

The Windows program should only be a translator and communication conduit.  Drip the motion commands to the controller buffer.  Offload all of the motion control duties to the controller.  That is one of the problems with Mach3, if Windows decides to go do something else for a bit, Mach 3 gets confused.  I can surf the net, work on a drawing, or work on the CAM file for the next part while my machine is running.

Put in a teach function, on-the-fly speed changes, make the goto, and manual position entry simple to use, a 0.100 step over for easy edge zeroing, go to 0 buttons for each axis, variable park position (single button set).  Keep most functions on the main screen.

I may think of more later.

I'm looking forward to seeing your work.


----------



## MarkStephen (Dec 9, 2014)

John Hasler said:


> I'll second that, as long a "cross-platform" includes more than just Microsoft and Apple.



Yes, I should of said that. Cross platform means all 3 major OS's, Linux Mac and that other one.


----------



## dave2176 (Dec 9, 2014)

If folks don't like Windows why not just use LinuxCNC?

My first requirement for a Windows program would be for it to be written in a language that is native to Windows like C#. The same would be true if I was writing for a flavor of Unix including Apple OSX although Java would have no place in my program. If I had to have cross platform it would need to be written in C/C++ since other up and coming languages like JavaScript don't seem fast enough to handle a fast performing lathe or mill.

Error and memory handling would be front and center. Create a variable or object, add the appropriate destroy code before continuing on. I see to many people say "I'll clean it up later" and you have a junk program bleeding memory all over the place.

The config file would have a debug switch to turn on additional in depth error handling.

Wizards would be a big part. For instance thread milling would be built in. Geometric shapes that are easily defined. Rectangle, square, circle, oval, rhombus, etc. Specify the dimensions, cutter diameter, depth and sit back. Combine the output from multiple wizards to work faster.

Oh yeah and it would have to use scales to ensure that steppers have feed back to overcome missteps.

Dave


----------



## David Kirtley (Dec 10, 2014)

Getting away from Windows is not really a slam against Windows as an Operating System. It is not designed for that type of control.  To be fair, Mac OSX and Linux are not either. The realtime linux kernel extensions help a bit but there is still a lot going on that is not part of controlling the machine.

What you would be best off doing is a two layer type program. An embedded controller to actually control the machine with a simplified g-code  and a higher level program to feed that code and doing tasks that are not timing critical. There are many that are going that way. Off the top of my head: TinyG, Grbl, Planet-CNC's USB controller, Reprap software such as Marlin and the like and to a lesser extent, the Mesa cards and such. It doesn't take that much computer to handle the hardware. Little Arduinos and PIC based systems like PlanetCNC's work just fine. More elaborate controllers could run on things like a Raspberry Pi (although it's IO capabilities are pretty much crap in comparison to an Arduino Mega). Beaglebone is another option. The newer Arduinos with a system on a chip are looking pretty good.  G-code is can be streamed to a controller well with the capacity of USB or Ethernet. It has been that way for years with printers. Most better ones use a page description language that is kinda comparable to g-code - postscript and HP's PCL.

There is a lot of room for improvement for the user interfaces of the programs. Putting it bluntly, Mach3 and LinuxCNC interfaces suck. They put so much on the screen at once, it is just sensory overload. You don't need to see the g-code stream past  while the machine is running. It goes by to fast to be useful. You don't need to see the graphic path stuff all the time. The coordinate readouts are too small and hard to see unless you are right up on the screen. The HAL stuff in LinuxCNC is pretty nasty. I don't know anything about the MACH3 hardware stuff to have an opinion.

As far as the development tools, I am biased towards platform independance. Java and C++ with a good multi-platform library like QT would be first on my personal list for the main GUI and program logic and maybe something like a Python scripting interface. To be fair, you could do some pretty sweet stuff with C# and the .NET controllers like the Netduino family of boards.

In all, it is something that people have done. so no reason why you couldn't. The program that works with Planet-CNC's controller seems really capable of someone doing it themselves. The 3D printers do it just fine. There is a lot of room for a better product.


----------



## dracozny (Dec 10, 2014)

Linux can be stripped down to the bare necessity. The real problem is choosing a Motherboard that is not inundated with unnecessary hardware killing CPU cycles. A basic Atom based mini itx or smaller board will give you the best latency. 
You can also build a custom GUI for Linuxcnc to suit your tastes which several people have done.


----------



## Karl_T (Dec 10, 2014)

JimDawson said:


> The Windows program should only be a translator and communication conduit.  Drip the motion commands to the controller buffer.  Offload all of the motion control duties to the controller...  .



I want to strongly 2nd this point. This is THE PROBLEM with other windows based controls.

The very few controls that handle this issue correctly are so expensive almost no hobbyists use them.

Karl


----------



## John Hasler (Dec 10, 2014)

dracozny said:


> Linux can be stripped down to the bare necessity. The real problem is choosing a Motherboard that is not inundated with unnecessary hardware killing CPU cycles.



Hardware for which no driver is loaded uses no cpu cycles.



> A basic Atom based mini itx or smaller board will give you the best latency.
> You can also build a custom GUI for Linuxcnc to suit your tastes which several people have done.



Better to devote a mini itx or somesuch to LinuxCNC (or to your homegrown software) and use a different one for the GUI.


----------



## John Hasler (Dec 10, 2014)

David Kirtley said:


> Getting away from Windows is not really a slam against Windows as an Operating System. It is not designed for that type of control.  To be fair, Mac OSX and Linux are not either. The realtime linux kernel extensions help a bit but there is still a lot going on that is not part of controlling the machine.



Linux even with realtime extensions may not be true hard realtime but I think that with modern hardware it should be fast enough for machine control.  You can easily strip out all unnecessary processes and you have control over the type of scheduler and the process priorities and can lock processes into RAM.  There is, of course, no reason that the cpu controlling the machine should have a GUI.  That belongs on a seperate laptop or somesuch.


----------



## MarkStephen (Dec 10, 2014)

If bsharp isn't looking to produce a closed, for profit control package, and their is nothing wrong with that, but just wants to produce something that works with simplicity and ease of use, maybe contributing to already existing software or forking existing software might be an option. There is GRBL Controller that is looking real promising. Just lacking a few features, like auto probing, (3 axis edge and center), scripting, and maybe offsets. It's cross platform, runs really well on anything from desktop to tablets to Raspberry Pi/BeagleBone. interfacing hardware is very inexpensive, (dirt cheap) and lets one use about any stepper/servo driver one would want, from little postage stamp size on up. Something to think about anyway. 

Mark


----------



## bsharp (Dec 10, 2014)

Transformer said:


> Well I am very new to all of this, in way over my head but plodding along, so I cannot even say what I would like to see, except .......... better, more understandable, clearer documentation and manuals.  Mach3 is on its way out but the documentation has never been brought up to snuff.  I was reading one of the manuals recently and it said see further information on page ?????.  For me a less than perfect program with good documentation would be better than a great program with poor documentation.  I know writing documentation is not fun or sexy but you can see why some programs are expensive, because they have invested in what is needed to make the program useful.



When I started out I was the same way and figured I was in way over my head and at the time I was!
Looking back on it all now is one reason why I had the idea. It would have been a lot less frustrating if things were a little more refined and strait forward.
I actually like writing documentation and procedures. I did a lot of that when I worked as an engineering specialist, machine programmer and also product designer.


----------



## JimDawson (Dec 10, 2014)

The problem with Windows and most other OS, it that they are not a real time operating system and are not capable of being locked into a program thread as a priority.  The exception to this is Windows CE, at least the older versions, I haven't worked with the newer versions.  You could set up deterministic control and write the program just like a PLC would scan the program.  Then you would put a break in the program scan and allow a milli-second or so for the OS to take care of it's housekeeping.  That way it keeps it's mind on what you want it to do, and takes care of the other stuff when you allow it.


----------



## John Hasler (Dec 10, 2014)

JimDawson said:


> The problem with Windows and most other OS, it that they are not a real time operating system and are not capable of being locked into a program thread as a priority.  The exception to this is Windows CE, at least the older versions, I haven't worked with the newer versions.  You could set up deterministic control and write the program just like a PLC would scan the program.  Then you would put a break in the program scan and allow a milli-second or so for the OS to take care of it's housekeeping.  That way it keeps it's mind on what you want it to do, and takes care of the other stuff when you allow it.



There doesn't have to be any housekeeping with Linux.  Even if there is you can choose a scheduler and priority that assure that it will run on time and not be interrupted.  There are billions of embedded systems out there running Linux.  A typical embedded system has the kernel, uClibc (small version of the C library), busybox, and the application on it.

BTW I'm sure Jim knows this but Windows CE is not a version of the Windows you use on your desktop.  It is a totally different OS designed for embedded systems.


----------



## bsharp (Dec 10, 2014)

Wow thanks for all of your great replies on this!
I guess I should have clarified "using USB or Ethernet" a bit further.  The program itself would just be a translator and GUI. It would set up  and do all the motion setup like work offset's, tool compensation and  ect. The software would then download the instructions to the motion  controller connected to the USB or Ethernet. At this point I am really  undecided on what motion board to start out with but it needs to be  inexpensive and simple to hook up and use "virtually plug and play".  
A industrial standard Ethernet bus interface that could be easily  connected to a cheap $50 - $100 dollar PLC would work great as simple  and robust IO capability.

I will be initially writing the software in C++ on windows. The reason is that it  is simple to use easy to support and familiar to lots of people. Lets  face it not that many people know what a bash prompt is or how to edit  text in Vi. Although there is nothing saying that it could not be ported  to something else later on. What I think would be nice down the road is to have an imbedded version on a usb stick. Sort of like a Roku for CNC!

Most of the pc controller software core logic like mach that are out  there were written on nix and ported to windows. If you have ever looked  at the source for EMC I think you would agree that it is a complete  mess. The original core logic was created by NIST to support as many  different configurations as possible including scara robots and  hexapods! This is all just unnecessary for what the majority of home  shops that just want to retro fit a 2 axis lathe or a 3 axis mill would use it for. I  think a clean slate needs to be made. A clean program designed  specifically for the type of machine it will be used on and for the guy  in his garage more interested in machining out his latest idea and not  so much learning the inner workings of coordinated motion control. I know there are lots of these guys because I was one of them.

The first thing that I need to work on is creating the core logic from  scratch. This will include all the algorithms that modify the trajectory  code like tool and work offsets and cutter comp. This will be the  toughest for me as I will need to dust off the rusty calculus gears that  haven't been used in a long time.   After the core is finished then we can do the fun stuff like create the  GUI and conversational generators like threading, facing, pocketing,  ect.

I really appreciate all of your input and please keep it coming.


----------



## JimDawson (Dec 10, 2014)

You might find these books helpful.

"Step by Step Design of Motion Control Systems"


"Motion Control Applications"


"Motion Control by Microprocessors"


All of the above by Dr. Jacob Tal


----------



## bsharp (Dec 10, 2014)

JimDawson said:


> The problem with Windows and most other OS, it that they are not a real time operating system and are not capable of being locked into a program thread as a priority.  The exception to this is Windows CE, at least the older versions, I haven't worked with the newer versions.  You could set up deterministic control and write the program just like a PLC would scan the program.  Then you would put a break in the program scan and allow a milli-second or so for the OS to take care of it's housekeeping.  That way it keeps it's mind on what you want it to do, and takes care of the other stuff when you allow it.



I worked with a small touch screen plc at a previous employer that ran windows CE and it was really nice. They used it to test the response time of proportional and conventional pneumatic valves. It was nice as it booted up almost instantly and was easy to train an assembler to use. Programming it was really easy using basic. Although I think it was a bit expensive if I am not mistaken.


----------



## MarkStephen (Dec 10, 2014)

> At this point I am really undecided on what motion board to start out with but it needs to be inexpensive and simple to hook up and use "virtually plug and play".
> A industrial standard Ethernet bus interface that could be easily connected to a cheap $50 - $100 dollar PLC would work great as simple and robust IO capability.



I would think that the Arduino family hit's the mark rather well here. Already working with great success, very very inexpensive, and they are usb out of the box. Add an ethernet shield, (or BlueTooth/WiFi), also dirt cheap, and your good to go. The platform has a lot going for it. Available the world over, huge user community, tons of peripherals, easy to use and hook up. 

Not to say you could not use other PIC's / PLC's, but targeting the Arduino platform up front is a good hedge towards wide spread adoption. Their already being used in countless 3D printers. (that's 4 and 5 axis control), and seeing more and more use with 4 axis hotwire foam cutters, laser engravers, as well as lathe and mill operations. This translates to - hardware is already in place, waiting for a good controller program to come talk to it. 

Mark


----------



## David Kirtley (Dec 10, 2014)

While I was waiting on some stuff, I went ahead and loaded Grbl on an arduino and hooked it up to a cheap chinese parallel port CNC controller. All it took was a parallel port breakout board. They already have a pretty good interpreter on it and the gcode streaming program universal-g-code-sender was pretty nice. Since the basic g-code is already in place, you can do all the more advanced gcode stuff on the controlling computer (drilling cycles, tapping, whatever.)

By the dials on the lathe, it was positioning properly and doing what it was supposed to do.


----------



## CNC Dude (Dec 10, 2014)

I also think putting the G Code interpreter on a microcontroller board is the way to go. GRBL for Arduino is a good starting point, but I think it is already taxed. I think a fast ARM microcontroller with something like an M3 or M4 core would work way better. You should be able to easily step at very fast speeds and with as much as 5 axis quite easily! I am under the impression this is what the TinyG guys are using.

BTW, coding the G Code interpreter does not need to be a from scratch endeavor. You could easily look at the Open Source stuff out there and enhance it, if need be. I think that the freebie G Code interpreters out there are already pretty good at what they do, but are lacking a few commands. After all, these G Code interpreters were designed mostly for 3D printers and CNC routers, so there is plenty of G Codes which were not required for any of these applications.


----------



## David Kirtley (Dec 10, 2014)

CNC Dude said:


> I also think putting the G Code interpreter on a microcontroller board is the way to go. GRBL for Arduino is a good starting point, but I think it is already taxed. I think a fast ARM microcontroller with something like an M3 or M4 core would work way better. You should be able to easily step at very fast speeds and with as much as 5 axis quite easily! I am under the impression this is what the TinyG guys are using.



Just step and direction movement, the arduino can pump out pulses faster than most steppers can make them -- especially at real cutting speeds and not just drag racing rapids for bragging rights. Where it really falls flat would be if you are running encoders. While some load can be pushed off elsewhere, it is still a huge amount of bits if you are doing fine increments.


----------



## John Hasler (Dec 10, 2014)

David Kirtley said:


> Just step and direction movement, the arduino can pump out pulses faster than most steppers can make them -- especially at real cutting speeds and not just drag racing rapids for bragging rights. Where it really falls flat would be if you are running encoders. While some load can be pushed off elsewhere, it is still a huge amount of bits if you are doing fine increments.



With encoders you probably want one Arduino per axis.


----------



## MarkStephen (Dec 10, 2014)

The one big hold back with the main branch of GRBL is they are still trying to stick to the uno platform and fit everything into the 4kb of memory. Just move to the Mega 2560 and that problem is solved with 32Kb. There are plenty of processor cycles there to run Gcode, handle Spindle speed control, work pneumatic valves, turn pumps on and off, etc.. That and the fact they play well with most any higher level device that has a usb port, I think it's hard to beat. It's just the memory of the Uno that has reached it's limit, nothing else. Or am I missing something?

Mark


----------



## David Kirtley (Dec 11, 2014)

MarkStephen said:


> The one big hold back with the main branch of GRBL is they are still trying to stick to the uno platform and fit everything into the 4kb of memory. Just move to the Mega 2560 and that problem is solved with 32Kb. There are plenty of processor cycles there to run Gcode, handle Spindle speed control, work pneumatic valves, turn pumps on and off, etc.. That and the fact they play well with most any higher level device that has a usb port, I think it's hard to beat. It's just the memory of the Uno that has reached it's limit, nothing else. Or am I missing something?
> 
> Mark



Yes. You are missing Marlin and other firmware that are already on that platform. Thats what they are running the 3D printers on.


----------



## compsurge (Dec 11, 2014)

The Mega 2560 is used a lot currently in 3D printers running Marlin. If you spend a few more dollars, you can upgrade to the Due board with the ARM - the xyzprinting Davinci uses this microcontroller. Also, the Spark Proton SoC (ARM M4 + WiFi) might be interesting to play with. 

I definitely think using a standalone board with direct connection to motors (with the option for modular motor drivers or daughterboards) would be a great path forward. Ethernet, WiFi, USB, or SD for uploading G-code and a simple user interface via touchscreen monitor and pendant / custom control panel would be great!


----------



## David Kirtley (Dec 11, 2014)

compsurge said:


> The Mega 2560 is used a lot currently in 3D printers running Marlin. If you spend a few more dollars, you can upgrade to the Due board with the ARM - the xyzprinting Davinci uses this microcontroller. Also, the Spark Proton SoC (ARM M4 + WiFi) might be interesting to play with.
> 
> I definitely think using a standalone board with direct connection to motors (with the option for modular motor drivers or daughterboards) would be a great path forward. Ethernet, WiFi, USB, or SD for uploading G-code and a simple user interface via touchscreen monitor and pendant / custom control panel would be great!



But here is the problem. By the time you upgrade to those boards, you are back to the price (or above) of a mini-ITX that has a lot more resources and capabilities. You add touch screen, WiFi, Ethernet, removable storage and such, you are back to the drivers and resources that take away all the clock cycles that mess up the timing (on a slower platform so it makes the problem worse).  The mini-ITX also shines as having ready to use power supplies, cases, and such. You also are on an isolated platform that doesn't have the active user base to contribute (not a problem for a company with a product development team but pretty major problem for a single user)


----------



## bladehunter (Dec 11, 2014)

Interesting topic, I hope I'm not too off topic by mentioning this, Linux CNC can be run on the Beagle Bone Black, from what I've read it is able to produce Step\Direction signal via a hardware module.

From what I've gathered the BBB runs headless (no keyboard\mouse\monitor) and GUI is via a remote X console (remote desktop).

There is a cape (add on boards) that bring a slection of signals out via a Db25 connector that are compatiable with BOB that use a Parallel port.

The project goes by the name of Machinekit more info here:
http://blog.machinekit.io/

I've just finished my CNC conversion and getting my head around Mach3 and general concepts, once I feel a bit more comfortable I'll give Linux CNC a shot then have a go at the BBB\Linux CNC setup.


There's also the TinyG Project
https://github.com/synthetos/TinyG/wiki


----------



## bsharp (Dec 17, 2014)

Again thanks for all the great feed back!  
I am getting excited about starting on this project. 

1:
I have some free time coming up and plan on getting some of the Core frame work setup and building a simple GUI and 3D path viewer. 

2:
I will need to build a small test machine as testing it on my production machine is way to risky. I have a few stepper motors and drivers I could use to build a simple three axis gantry for testing. This way I can set the thing up dead bug in the office and be able to test / debug issues on the fly. 

3:
With the test system in place it will be time to get started on building the hardware plugins. For starters I will work on creating a hardware plugin for an inexpensive GRBL Arduino type controller as mentioned in the thread. It seems like there is plenty of info on those types of controllers to get one integrated for simple open loop control. I think this would be a handy tool for many hobbyists.

4:
I also plan on building a plugin for a controller that people can use to retro fit or scratch build a precision closed loop servo system.

5:
Start adding all the fun conversational programming stuff and things that people could actually use making parts in the shop.

So that is the game plan for now as it may change as things go along


----------



## compsurge (Dec 20, 2014)

Just saw this... Might be interesting.

http://3dprint.com/30793/marvell-3d-printing-socs/


----------



## Cadillac STS (Dec 20, 2014)

Just to throw this in the conversation:  I know the OP said he has Mach 3 and knows it through and through including the problems and limitations.  Mach 4 is out.  It would be a good idea to check out Mach 4 if only to see if they solved the concerns of Mach 3 and how they did it to be able to use the workarounds in a new product.  And possibly just move to Mach 4 if it makes sense and move on to other things with the control out of the way.


----------



## scalci (Dec 21, 2014)

My input will be to keep compatibility with legacy boards and interfaces lr as an addon that can be disabled once someone move to a later technology interface.


----------



## rcaffin (Dec 21, 2014)

Karl_T said:


> I want to strongly 2nd this point. This is THE PROBLEM with other windows based controls.
> The very few controls that handle this issue correctly are so expensive almost no hobbyists use them.



Ah ... 'almost no' is probably thousands and thousands. They just don't use this web site. Try the Artsoft web site or CNCZone or various Yahoo groups. Mach3 by itself is tens of thousands.

Fwiiw, I do NOT agree that they are expensive.

Cheers


----------



## rcaffin (Dec 21, 2014)

Cadillac STS said:


> Mach 4 is out.  It would be a good idea to check out Mach 4 if only to see if they solved the concerns of Mach 3


Early days, but it is likely.
How?
By doing a total rewrite, using professional programmers and structured design, in a portable language so it can run on most any machine - PC, Mac, etc, as long as you can find a compiler. It is designed to use an external hardware engine like the ESS, although I think someone has managd to write an LPT handler for it to run under W7. (Which was not easy.)

Yes, Mach3 had internal structural and desgn flaws which were NOT repairable. It had grown a bit too far. But it started as a hobby hack.

Quite a few commercial sites have been using Mach3 for years. I rather suspect they will all be moving to Mach4 over the next year or so, as the bugs get ironed out.

Cheers


----------



## rcaffin (Dec 21, 2014)

Hi bsharp

Look, go for it. Just be aware that:

The idea is NOT new by a decade or two.

There are several fairly well-developed and affordable software systems out there right now doing exactly this - with huge numbers of both hobby and commercial users. 

There are many inexpensive hardware engines out there already, with huge sales to both hobby and commercial users.

There is a quite large infrastructure selling all the servo drivers, BoBs etc by the thousands or more, at reasonable prices.

One could describe it as a well-developed and almost mature market.

Cheers


----------



## JimDawson (Dec 21, 2014)

JimDawson said:


> The Windows program should only be a translator and communication conduit. Drip the motion commands to the controller buffer.* Offload all of the motion control duties to the controller.* That is one of the problems with Mach3, if Windows decides to go do something else for a bit, Mach 3 gets confused.






Karl_T said:


> I want to strongly 2nd this point. This is THE PROBLEM with other windows based controls.
> 
> 
> *The very few controls that handle this issue correctly are so expensive almost no hobbyists use them.*
> ...





rcaffin said:


> Ah ... 'almost no' is probably thousands and thousands. They just don't use this web site. Try the Artsoft web site or CNCZone or various Yahoo groups. Mach3 by itself is tens of thousands.
> 
> Fwiiw, I do NOT agree that they are expensive.
> 
> Cheers



The original question of this thread was what features might  be wanted in a new, Windows based CNC controller program.  So my response was related to that.

Karl was responding to my post.  What he says is correct, very few hobbyists will pay about $2500 for a 4-axis motion controller. And that price does not include any other hardware to complete the system.  Total system cost for a 3-axis + spindle control would run in the $4500+ range, using stepper motors on the axis.

Mach3 is used by thousands of happy users, and there are a number of options that don't use the parallel port.  My experience with Mach3 is that in high speed applications it comes up a bit short.  It is not a commercial quality product, but works fine in hobby or low speed applications.

I am using Mach3 on a 4-axis machine that is being shipped to a customer, so that means I have confidence in it to do the job for that application.  I am using it with 32 bit, Win7 using the parallel port and it seems to be working OK.   I have another 3-axis machine in process that is using the high end controller because I know Mach3 won't work for that one.  I'll be looking at Mach4 for future projects when the dust settles a bit, and some of the kinks are worked out.


----------

