Many a forum post has carried the derisive view that Mach3 can’t be an industrial grade control because you can’t build “industrial grade” on top of Microsoft Windows. The logic goes on to say that because Windows is not a real time operating system, it’ll never be able to do industrial grade work. There are various other arguments against Mach3, such as the idea that the servo closed loop isn’t accessible to Mach3, but the big issue is the real time operating system issue. How severe is this criticism of Mach3 and Windows?
It turns out the idea that an industrial grade CNC controller can’t be built on top of Windows is false. We know that because there are many successful industrial CNC controls that are built on Windows. Okuma’s THINC®-OSP control is Windows-based, for example. They tout their resulting open architecture as a big advantage, and THINC-OSP even lets you install apps as a result of its Windows underpinnings.
Okuma’s THINC®-OSP control is Windows-based…
Lest we think this is because machines are only recently powerful enough to allow Windows to work for CNC, let’s understand that building controllers on Windows is not even all that new an idea. Consider the Siemens A2100 control, used on machines like the Cincinnati Arrow. Some say it was one of the best CNC controllers ever made, but whether you agree with that assessment or not, it was clearly an industrial grade controller, and it was based on Windows NT.
How did these CNC Controls manage to get great results despite Windows and what’s the deal with Mach3?
The key answer to getting industrial-grade CNC Control performance is that controls must separate the functions of low level motion control from the user interface and g-code interpreter. Look at a CNC controller as consisting of 3 layers:
3 layers of function separation for CNC Controllers…
At the top level is the human interface, the part that talks to the operator through the control panel. The middle level is the g-code interpreter. Give it a block of g-code (uploaded by the User Interface through a USB key, serial feed, FTP, or other means), and it knows how to convert that g-code into simple motions.
Those simple motions go to the motion control portion of the program which is responsible for converting the simple motions into driver control signals. For example, if you want the machine to move to X0Y0Z0 and the machine is at X1Y0Z0, the X-axis has to move -1 to get to 0. Let’s say your machine moves in 0.0005″ steps. It then has to move 1 / 0.0005 = 2000 steps in the correct direction.
To accomplish that, the Motion Control portion of the Controller sends 2000 steps to the hardware driver for the servo or stepper motor on the X-axis. At the same time, it must also control the direction line so the motor spins either clockwise or counterclockwise, as desired:
Motion Control must generate step and direction pulses to send to the controller…
An additional wrinkle is that the faster we want the axis to move, the faster the 2000 pulses have to be sent to the step pin of the stepper or servo driver. If we run Mach3 through a parallel port, it’s cheap and cheerful, but the faster the axis needs to move, the more we are expecting from the software.
Let’s look at how this works with vanilla Mach3, running with a parallel port. What that means is the Mach3 software must generate a smooth series of 2000 pulses on a parallel port pin to accomplish that motion. If we want to move at 100 IPM, which is not very fast by industrial standards, we have to produce those 2000 pulses in 0.6 seconds. For each pulse, we only have 0.0003 seconds to get the job done. Put another way, we need to move at 3,333 pulses per second. It turns out Mach3 can pulse up to 6 axes at whatever the kernel speed allows, but Mach has to do more than a few unnatural acts to pull that off.
Any minor interruption or distraction for the computer, may result in a brief pause between sets of the pulses. It turns out that Mach processes groups of buffered pulse requests. For example, it may have 5 requests that each ask for 0 to 5 pulses, depending on whether the axis is maintaining speed, slowing down, or accelerating. Lets say we have perhaps 25 pulses from 5 requests of 5 each. If, instead of getting a following on request for 25 pulses, that follow on is lost, it may take a whole new kernel timer cycle before the pulses are delivered.
In the meanwhile, it’s as though the lost cycle had instead been heard but requested the axis to slam on the breaks to 0 speed. On average, we got 25 pulses instead of 50, so we ran a lot slower, but the acceleration/deceleration makes it that much worse. Imagine trying to cut smoothly and with good surface finish if you command your cutter to move 1″ at 100 IPM, but at 2 points during the move it actually slows down to 33 IPM. Things are not quite that bad because we have inertia to smooth it out and the axis doesn’t start and stop instantaneously, but you can start to understand the problem here.
What causes such interruptions?
There are a myriad of things that can result in an interruption of the basic cycle. Remember, we run Mach3 runs on a general purpose Windows PC. The owner may have installed all sorts of other software on the machine. They might be running the MP3 player so they have music while they’re machining.
Installing and running the wrong software on your Windows CNC machine can cause problems if the software interrupts the motion control functions of the CNC Controller software…
There are a number of factors that can cause one of these timer ticks to be disturbed including:
– Multimedia Software. I’m told Quicktime is a known offender.
– DMA. If your machine accesses disk too much, it interferes as the disk takes control of data transfer through a process called “Direct Memory Access”.
– Normal OS operations can also disable the interrupts involved from time to time.
– Lots of other kinds of software.
A so-called “real-time” operating system, which Windows is not, has the capacity to put out a “do not disturb” sign during critical operations. If it was making that 1″ move, it might very well want to be left alone to finish that task in perfect timing and at exactly the right speed. Linux is sometimes touted as real-time, and therefore a better alternative. It’s actually not a real-time OS either, it’s just closer to the ideal than Windows, and since so much less software will run on Linux, we’re much less tempted to put software that can interfere onto the machine.
For this reason, you frequently see recommendations not to connect a Mach3 PC to the Internet, not to allow any extraneous software onto the controller machine, and so on. This is a pity, because it is almost entirely due to the parallel port’s limitations and we can work around those as we shall see in a moment. Personally, I hate the idea of being cut off from the Internet in my shop. There’s just too much useful information to be had there that I can use in my work.
How do the Industrial Grade Controllers get around this problem?
The answer is pretty simple. They move those parts of the software that are sensitive to these timing issues to another piece of hardware. Imagine a configuration like this:
Now we have a separation of tasks that forms an assembly line. As the Windows PC finishes converting each g-code line to some sort of motion commands, it hands them off to the Motion Control Board and goes on to the next line. The Motion Control board is a piece of dedicated hardware whose sole purpose is converting motions to driver control signals. It can’t really be interrupted because it doesn’t do anything else, which is great in terms of providing smoother and higher speed motion.
The G-Code Interpreter is happier too. It takes a fair amount of machine cycles to produce all those motion control pulses smoothly. By handing that task off to another piece of hardware, the G-Code Interpreter finds more time to do a better job itself. Whether that’s simply processing g-codes faster, or using the time for more sophisticated “look-ahead” and trajectory planning is a function of the controller, but the important thing is that more time is available.
Having this 2-part architecture is the secret sauce in creating an industrial grade CNC control from Microsoft Windows. It isn’t the only secret sauce, but it is an extremely important starting point.
Is it hard to use a Motion Control Board with Mach3 instead of the Parallel Port? Is it worth it?
It turns out to be pretty easy to use a Motion Control Board with Mach3, and it is well worth the effort. In Part 2 of this series, we’ll take a look at some of the Motion Control Boards that are available and we’ll also talk about the results.
Note: I originally published this two-part series some time ago, and it has been hugely popular ever since. I recently went through it and added a lot of new information and updates. I am republishing so new folks will get a chance to see it and so folks that have already seen it can take advantage of all the new information.
Like what you read on CNCCookbook?
Join 100,000+ CNC'ers! Get our latest blog posts delivered straight to your email inbox once a week for free. Plus, we’ll give you access to some great CNC reference materials including:
- Our Big List of over 200 CNC Tips and Techniques
- Our Free GCode Programming Basics Course
- And more!
Just enter your name and email address below:
100% Privacy: We will never Spam you!
Bob is responsible for the development and implementation of the popular G-Wizard CNC Software. Bob is also the founder of CNCCookbook, the largest CNC-related blog on the Internet.