Mac CNC

Folks,

I am fairly new to CNC but, I have a lifetime of professional experience in very high-tech computers and specialized embedded computing devices... The knowledge is applicable.

PC-based systems are "best-effort" computing platforms. There is little to no internal error checking or automated correction. Also, operating systems such as Windows, Linux/Unix, MacOS etc are toy-like entities when compared to a dedicated hard-real-time OS or better yet, a dedicated controller device with a burned-in control monitor. Even more dangerous than OS's like Windows, Linux, MacOS are the applications that run on them. -We all know what happens to our computers when some misbehaved javascript suddenly sucks the life out of your machine -often resulting in a crash. You don't want that happening when Mach III is turning your spindle at 3000 RPM and the head is traveling toward the table.

Mach 3 and (I assume) LinuxCNC do not use reliable, error correcting/detecting protocols. A reliable protocol is when the programs sends data to a controller motor and the controller motor acknowledges receipt of the data that was sent. Instead, Mach 3 sends data and goes on its merry way thinking the motors are doing what they're told. There are controllers made by many companies like Mitsubishi, Fanuc, Siemens, Toyota... many other places -that may have a user interface that's based on a commercial OS but, the G-Code gets loaded into ASIC, FPGA or DSP-like devices. Furthermore those devices have error-free, guaranteed delivery and communication with the motors. If the graphical interfaces crashes, so what, the controllers will do their job and they're probably programmed to "fail safe" in the worst of situations.

Honestly, Mach 3 makes me really nervous and if/when the time comes that my business needs higher end CNC machines, I'm not going to play games with it and all the related PCs. Don't get me wrong, it's OK and for $175 it does a lot and does it fairly well -but it doesn't play ball with the big league.

Right now, my machine controller PC is a pretty robust, dedicated device with all unnecessary services shut off and it's only used to run Mach 3. This gives the overall system the best chances for survival. One day, I was homing the system and the head was traveling upward. I pressed the "eject" button to remove a USB thumb drive and at that instant, the machine shut down.

Not one instinct in my body says it's a good idea to run multiple apps while running Mach 3... Since I'm in the business of selling these machines, this is a topic near and dear to me and I've followed-up with some of the top professional names in the business to get detailed info about this... The resounding reply on this topic: "Use a strong, dedicated, unburdened PC to run Mach 3".

Ray
 
Folks,

I am fairly new to CNC but, I have a lifetime of professional experience in very high-tech computers and specialized embedded computing devices... The knowledge is applicable.

PC-based systems are "best-effort" computing platforms. There is little to no internal error checking or automated correction. Also, operating systems such as Windows, Linux/Unix, MacOS etc are toy-like entities when compared to a dedicated hard-real-time OS or better yet, a dedicated controller device with a burned-in control monitor. Even more dangerous than OS's like Windows, Linux, MacOS are the applications that run on them. -We all know what happens to our computers when some misbehaved javascript suddenly sucks the life out of your machine -often resulting in a crash. You don't want that happening when Mach III is turning your spindle at 3000 RPM and the head is traveling toward the table.

Mach 3 and (I assume) LinuxCNC do not use reliable, error correcting/detecting protocols. A reliable protocol is when the programs sends data to a controller motor and the controller motor acknowledges receipt of the data that was sent. Instead, Mach 3 sends data and goes on its merry way thinking the motors are doing what they're told. There are controllers made by many companies like Mitsubishi, Fanuc, Siemens, Toyota... many other places -that may have a user interface that's based on a commercial OS but, the G-Code gets loaded into ASIC, FPGA or DSP-like devices. Furthermore those devices have error-free, guaranteed delivery and communication with the motors. If the graphical interfaces crashes, so what, the controllers will do their job and they're probably programmed to "fail safe" in the worst of situations.

Honestly, Mach 3 makes me really nervous and if/when the time comes that my business needs higher end CNC machines, I'm not going to play games with it and all the related PCs. Don't get me wrong, it's OK and for $175 it does a lot and does it fairly well -but it doesn't play ball with the big league.

Right now, my machine controller PC is a pretty robust, dedicated device with all unnecessary services shut off and it's only used to run Mach 3. This gives the overall system the best chances for survival. One day, I was homing the system and the head was traveling upward. I pressed the "eject" button to remove a USB thumb drive and at that instant, the machine shut down.

Not one instinct in my body says it's a good idea to run multiple apps while running Mach 3... Since I'm in the business of selling these machines, this is a topic near and dear to me and I've followed-up with some of the top professional names in the business to get detailed info about this... The resounding reply on this topic: "Use a strong, dedicated, unburdened PC to run Mach 3".

Ray

LinuxCNC uses a real-time kernel and supports closed-loop servos, if you can afford them. Real-time Linux is widely used in robotics.
 
I am running LinuxCNC, and am very happy with it. I have DC servos, and while they are technically "closed loop" reading the fine print, the loop is closed at the servo drivers. The result is the best you can hope for is to fault out if you get a following error (the servo equivalent of "missed steps"). There are systems that will close the loop at the controller.

As far as high end hardware, LinuxCNC plus dedicated controller hardware is pretty capable. I have a set of Mesa boards. The major drawback is that the setup can be somewhat involved.
 
I am running LinuxCNC, and am very happy with it. I have DC servos, and while they are technically "closed loop" reading the fine print, the loop is closed at the servo drivers. The result is the best you can hope for is to fault out if you get a following error (the servo equivalent of "missed steps").

IMHO that's the way you want it. The main controller shouldn't be running a PID process for each motor: let a dedicated processor do that and report errors to the main supervisory controller. It can then take measures to prevent a crash.
 
IMHO that's the way you want it. The main controller shouldn't be running a PID process for each motor: let a dedicated processor do that and report errors to the main supervisory controller. It can then take measures to prevent a crash.

If I set-out to design something like this, I would have transmitters that sent control signals to the motors and have sensors on the motors that sent back true RPM or positioning information -and let the "controller board" make adjustments to the control signals as necessary -basically, a PID (Process Integration/Derivative) algorithm with extremely tight settling parameters. The communication links would be timing synchronized, have handshake protocols and error detected/corrected data transfers. The idea is nothing new. Most all medical infusion pumps work this way.

I wish I new more about the really high-end equipment to see if this is what they do.

Ray
 
If I set-out to design something like this, I would have transmitters that sent control signals to the motors and have sensors on the motors that sent back true RPM or positioning information -and let the "controller board" make adjustments to the control signals as necessary -basically, a PID (Process Integration/Derivative) algorithm with extremely tight settling parameters. The communication links would be timing synchronized, have handshake protocols and error detected/corrected data transfers. The idea is nothing new. Most all medical infusion pumps work this way.

I wish I new more about the really high-end equipment to see if this is what they do.

Ray


The best way is to use a dedicated motion controller (available from many manufactures, who shall not be named here). That is pretty much what you described.

For instance: On my system, I fire off the desired tool path from the G-Code to the motion controller and it then takes over. This means that I am not dependent on the Windows OS for motion generation, I could surf the net while the machine is running with no ill effects, the worst case is that it could slow the machining time down a bit. Many times I work on a drawing or work in the CAM program while the machine is running a job.

When the controller is done with the particular motion profile is running, it fires an interrupt to the CNC control program that essentially says "I'm done, what do you want me to do next", and waits for the next profile. Normally this happens in about a mili-second.

All of the safety monitoring is done on the motion controller. The CNC control program is really just a translator and operator interface, unlike Mach3 or some of the other CNC control programs which are an active part of the motion generation.

All for the motor position feedback comes from the magnetic scales (in my case), or encoder on the lead screw, or some other feedback device directly to the motion controller. The motion controller PID takes care of figuring out what to do and sends a +/- 10V signal to the motor drives. The PID update rate is about 62uS.

My mill has a 4 axis controller, but could have up to 8 axis if I needed it. I am running a combination of a DC servo motors (X-Y) and step motor (Z). The step motor is configured to run with +/- analog input also, so to the controller it looks like a servo motor, and it is running at 20,000 steps / revolution. In an all stepper system it could also be configured for a step and direction input to the drives and run in open or closed loop.

The 4th axis is to run the spindle, but if I ever need a rotary axis, I can add a single axis card to the system to run the spindle, and connect the 4th axis to the rotary drive.

Having said that, the hardware cost may be out of the range of many hobby machinists, but there are some used motion controllers on Ebay that are not too costly.
 
LinuxCNC has realtime kernel extensions but it not really a fully realtime system. How much that matters when you are running a GHz class machine is debatable.

As far as the real motion controllers, they are pretty much unsupported for the hobbyist market if you can even acquire one. As a rule, the companies that make them are not interested in selling or supporting them directly. They prefer large annual support contracts.

There are several "budget" stepper based CNC controllers that would be compatible with a MAC but the downside is that they mostly run a subset of gcode. Many are a product of the 3D printing world with an Arduino/Arduino MEGA doing the heavy lifting. RAMPS, Sanguinololu, grblShield are most common. There are some a bit more robust like the PIC based USB based CNC controller from PlanetCNC and TinyG from Syntheos. For the most part, you just stream gcode over a serial connection (on USB) except for the one from PlanetCNC which uses Windows only software to communicate to it. Most are pretty limited as to the power that they can handle.
 
Back
Top