[Detailed post] Need input and advice for my next CNC machine.

Hi! I'm rebuilding my CNC machine again and I want to use arduino this round. It has been several years since I’ve dabbled in arduino and the whole landscape has changed, so I'd like some advice!


My machines:

My first generation I built several years ago using an arduino with some software I forgot the name of, but the machine had a variety of problems (mostly that the driver chips I was using kept burning out because they couldn't handle the amperage I needed to power the steppers).

When I built my second generation machine, I switched to a professional driver using a pirated copy of Mach3 as a gcode interpreter to send step pulses to the stepper driver. This has several problems: one, it isn't a legal copy (at the time I wasn't willing to spend several hundred dollars on old software that requires an ancient OS and a parallel port). Two, Mach3 only runs on Windows XP; I had to actually buy a junk PC off of craigslist that was old enough to run it. Finally, I am completely limited to what Mach3 can and can't do and do not have the ability to hack it to my preference. Even doing a zero plate calibration requires macros in an confusing and virtually undocumented macro language.

So, now we're on to my third machine, which is currently in design phase. I have most of the specialty hardware ordered or arrived and I am getting ready to drive down and buy the steel framing I’m going to weld together. However, it is quickly becoming clear to me that in order to complete the design, I need to begin stress testing the load and speed capabilities of the stepper motors on test jigs with the driver I want to use, just to make sure my drive system can handle the weight of the steel framing and heavy spindle.

So...I need an arduino up and running as quickly as possible with my target software so my stress tests will use the software package that my production environment will use.


My background and proficiencies:

I am conversive enough in C and arduino to use existing code and compile to an arduino, and to make small changes as needed on a trial and error basis. I am not proficient enough to generate a ton of hardware-level unique code, but I am pretty good at adapting existing solutions and figuring out how to make things work together with research and trial and error.

I am at most a hobbyist in software development; scripts and little else. I am most proficient in scripting with Ruby, and in fact wrote a plugin to interpret Sketchup geometry into gcode paths. I use this mostly to build telescopes.


Goals: (aka the "ideal" machine capabilities)

I want to use an arduino to interpret gcode, drive stepper motors, and run a variety of sensors for calibration, sanity checks, and limit switches.

  • Interface: I need to be able to interact with the arduino through a network. Either wifi or LAN is fine. I want to stream gcode directly from my laptop or home PC. (My home PC is a short drive away from my workshop, but accessible via long-range directional cantenna. I want to be able to load gcode into, and activate, the machine from my home computer.)

  • Steppers: I’ll need to drive 4 axes (8 pins total). The new machine will have two Z-axis spindles, which I’ll handle the gcode for on my end. The power will be delivered by drivers that come bundled with the steppers, all I need is to send direction and pulse for each stepper.

  • Spindles and vacuum: Several pins will need to be allocated to turning the spindles on and off, activating cooling, and activating vacuum. Probably no more than 4 or 5.

  • Limit switches: I will need 6 limit switch pins. Technically I should only need 4, but I’m going to overkill with one limit switch on each end.

  • Z plate: I’ll need a pin open for a z-plate at some later date. Basically just a switch.

  • Manual controls: I would like to be able to directly hardware control the machine, although this isn’t critical. It would involve two pins per axis, for a total of 8. All of the above can probably be handled by any off-the-shelf arduino software that is designed for CNC or 3D printing. However, I want to add some MORE stuff to mine to correct for some problems I keep encountering with my old machines. Specifically, I have ruined a lot of wood and wasted a lot of time because my motors seized up and then broke a bit, or offset the entire run by an inch and ruined a dozen pieces, so I want two redundant layers of feedback that I can use to correct for errant motor behavior.

  • Range finders: I want to get an approximate non-relative position in the Z1, Z2, X, and Y axes. This means a total of 4 range finders. These will be used to guess initial conditions after a fresh startup and pre-calibration, and to slow down the machine before it hits the limit switches during fine calibration. I have no idea how many pins this will require. (Ultrasonic should work fine, although I’d prefer laser.)

  • Rotary encoders: I want a rotary encoder on each axis to very accurately measure relative position changes. I will be using this to instantly hard stop the machine if a motor seizes and set the machine to re-calibrate the axis before continuing. No more destroyed wood stock! I am only concerned with the X and Y axes; the Z1/Z2 axes are a bonus but not critical, because a laser rangefinder would be accurate enough.

The thing is, I actually know very little about rotary encoders. Given a starting point I can work it out, there’s plenty of material available, but I think they need 5 pins each. So...minimum 10, possibly 20 if I include the Z axes.

  • Power/activation: I want to be able to remotely fire up the power supplies at the outlet level. As in, actual physical power switches. The idea is that, from home, I can fire up the machine from a near-zero-power state to fully functional. NO IDEA how to do this. Suggestions? So...adding up everything, that means I need an arduino that has a minimum of 34 pins, but 50+ would be better, and has LAN or wifi access.

Questions:

  • Given my requirements (34+ pins, lan/wifi, the ability to run existing CNC software that someone has written for arduino), what arduino should I pick that has the capabilities I need?

  • Any suggestions on CNC software (gcode -> stepper pulses) that would work on said arduino, that I could modify to add in all that extra stuff I want to do?

  • Any unforeseen hurdles or suggestions from people who have done this before?

  • How would I go about letting this little arduino power up all the machine power supplies at the outlet switch level?

  • Any rangefinder suggestions? (Ultrasonic/laser?)

Thanks in advance for any feedback!

Unless you can reduce your questions to something very specific - such as "is this the right way to read this particular encoder" I think it will be difficult to help.

My first question would be why interpret the GCode on the Arduino when it would be so much easier to do so on the PC and would have the added value of reducing the load on the Arduino so it could attend to the other tasks you have in mind. I have never understood the enthusiasm for getting the Arduino to interpret GCode and on my little lathe it is done on my PC - but my system is probably very trivial compared with yours.

My next comment would be that it seems that the business of reading encoders uses a lot CPU cycles - but I don't have any personal experience. This may mean that they limit the speed you can get from your entire system. There is also the complexity of matching the encoder pulses step by step with the motor pulses so you can quickly determine that there is a problem. It might actually be easier to write the software so that the encoder is "in charge" and the motor is its slave - but none of this would simple.

Taking these comments together, I have the impression that you are planning to use off-the-shelf software for GCode interpretation which would make my first comment redundant and make the coordination with encoders even more complex.

If you were writing all the code yourself and if the "load" imposed by the encoders is not too great I would expect a Mega to be well able to manage the job. Off-the-shelf code may limit your choice of hardware.

I guess one way to deal with the encoders would be to use a second Arduino for them - but that adds a whole other bunch of complexities.

Rather than range finders, could you use Digital Readout devices (like digital calipers) that are widely used on metal working lathes.

I am tempted to wonder if the motors seizing is due to undersized motors - if so spending more on the motors might be a simple solution.

As an overall comment, I think you need to make some decisions before you can begin to consider others in order to limit the number of permutations that have to be juggled.

...R

Thanks for the feedback!

As to why I was wanting to do gcode interpretation on the arduino side, my main motivation is that a native hardware-side implementation resolves timing issues and transmission issues that plagued my Mach3 setup. Much of the difficulty came from the fact that Mach3 is more than a decade old with virtually no documentation, and the only other reasonably accessible alternative controller is LinuxCNC, which I don't have the setup for and I don't know the first thing about Linux. :\

Another consideration I made is that the developers of software packages like GRBL, TinyG and Smoothieboard are coming from a hobby development perspective for people that make their own 3D printers (since that's insanely popular right now). These software packages will be light years ahead of Mach3, run smoother, faster, and better...if I can only get them to work! And since they compile from source, I can (in theory) insert my own homing routines and sensor processing.

As for the encoders...hmm. I hadn't considered the processing power required to read the encoders. That's a good point. I wouldn't mind at all running two arduinos...one driving the steppers, one running all the sensors, if I can get the sensor arduino to spit out the state of all sensors in serial, then read what I need to on the other. I have no idea how I'd do that, but that's the interesting part. :\ Still, that makes me think that I should bite the bullet and give LinuxCNC a try.

As far as motors seizing, size may have been a partial factor, but I run two pretty beefy NEMA 23 36v motors, and they were driving a fairly lightweight MDF assembly, so weight was almost certainly not an issue. I mostly get seizing when the gantry is slightly out of alignment and one of the two locks up, causing the other to go severely out of alignment. It's a progressively worsening problem as the two motors are becoming increasingly unstable and the MDF construction is starting to give up the ghost, so I'm pushing forward with the steel-frame CNC rebuild I've been mulling for the past year.

To sum everything up...I'm really trying to find the most reliable controller I can, to run steppers with independent power drivers. Working with Mach3 is painful, LinuxCNC is mostly inaccessible to me, and those are the only robust computer-side controllers available. The alternative is arduino. I've used it before, and I'm posting to explain my situation and get feedback. I appreciate your response!

@Grumpy_Mike's Miller... http://www.thebox.myzen.co.uk/Hardware/CNC_Conversion.html

I suspect you can find one or two useful things from his write-up.

I suppose you had a look at grbl athough you did not mention it. As for the hardware a mega and a ethernet board should do it but i aggree with robin cpu cycles could get sparse.

grays42: These software packages will be light years ahead of Mach3, run smoother, faster, and better...if I can only get them to work! And since they compile from source, I can (in theory) insert my own homing routines and sensor processing.

I suggest you download the source code and the documentation (if it exists)and study it before jumping to conclusions about your ability to modify or extend it. It would probably take a lot less time to learn Linux and maybe use LinixCNC.

if I can get the sensor arduino to spit out the state of all sensors in serial, then read what I need to on the other.

This will also depend on interacting with the motor control software and on top of that there will almost certainly be latency issues.

that a native hardware-side implementation resolves timing issues and transmission issues that plagued my Mach3 setup

You can have the timing issues managed by the Arduino even though the GCode is interpreted on the PC.

I mostly get seizing when the gantry is slightly out of alignment

I think you need to eliminate this sort of problem at source before you can figure out whether (and what) changes to the software are required.

...R

I assume that the reason to interpret G-code on the arduino is that there's no issue with multi-tasking causing timing issues.

A friend in the auto industry tells a story about a perplexing issue he encountered with a PC controlled hydraulic press running well in initial tests, but damaging itself after thirty minutes of stamping out parts perfectly. It turns out that the screen saver kicking in caused enough delay to cause the rams to overshoot.

That was a long time ago and modern PC hardware is much faster, but the issue remains that it's hard to defend against some other O/S process kicking in and stealing CPU cycles at an important moment. Hard to debug too.

A Mega seems to be the system of choice for 3D printers - RAMPS and the current firmware options fit easily and it's fairly simple to add additional M or G codes for your custom purposes such as vacuum. If you need more power, perhaps a Due is worth looking at, although you'll have to deal with it being 3.3V. The Mega certainly seems like a good place to start though.

wildbill:
I assume that the reason to interpret G-code on the arduino is that there’s no issue with multi-tasking causing timing issues.

It is not necessary to interpret the GCode on the Arduino to avoid that problem. If the GCode is interpreted on the PC the timing can be fully managed on the Arduino. The PC can send data for a move to the Arduino in a simpler format (simpler for the Arduino) so it has even more CPU cycles available to keep track of timing.

…R

Thank you for the replies!

It would probably take a lot less time to learn Linux and maybe use LinixCNC.

Discussing this here and on reddit, and doing more research, I'm getting that feeling. I'm leaning toward LinuxCNC as the solution that will eventually do what I need to.

Robin2: I think you need to eliminate this sort of problem at source before you can figure out whether (and what) changes to the software are required.

I'm rebuilding the machine. ;) But that aside, I am tired of Mach3, for a variety of reasons. So, I'm addressing both the build and the software at the same time.

RAMPS and the current firmware options fit easily

I hadn't seen RAMPS. Taking a look. Thanks!

The PC can send data for a move to the Arduino in a simpler format (simpler for the Arduino) so it has even more CPU cycles available to keep track of timing.

What kind of data would that be, though? The controller, whatever it would be, takes gcode instructions and spits out direction and pulse directly to the drivers. If the controller is software-side through LinuxCNC (as you suggested), then I'd be sending the data directly to the stepper drivers, bypassing the need for an arduino altogether.

No matter, what, under no circumstances am I going to power the steppers on the same board that I am doing logic and processing on. I have burned out too many CNC drivers during my first build, learning what I was doing. All pulses will be sent to standalone, replaceable drivers one hardware step removed from the logic, like these.

grays42: What kind of data would that be, though?

My PC sends to the Uno a small package which is the total microseconds for a move and the number of microseconds between steps for each stepper motor during that period. A crude example 50000 1000 0 2000 would represent a move requiring a total time of 50,000 usecs and 50 steps for the first motor, none for the second and 25 steps for the third.

...R

Mach3 does one thing you have not addressed. That is it has read several steps of code ahead of the line being processed so it is able to detect errors and unsafe conditions before it actually has to execute them.

Paul

as you use encoders better to use dc motors like servo. they are faster and as the resolution of the encoders is higher.

shooter: as you use encoders better to use dc motors like servo. they are faster and as the resolution of the encoders is higher.

Perhaps just a tad more complex ?

...R

My PC sends to the Uno a small package which is the total microseconds for a move and the number of microseconds between steps for each stepper motor during that period. A crude example 50000 1000 0 2000 would represent a move requiring a total time of 50,000 usecs and 50 steps for the first motor, none for the second and 25 steps for the third.

Ah, I see. That makes sense. Let the PC handle gcode processing and let the arduino drive the steppers. Since I am leaning toward LinuxCNC, would this be advisable if I use that? Or just let LinuxCNC deliver dir and step directly using a DB25 breakout?

Mach3 does one thing you have not addressed. That is it has read several steps of code ahead of the line being processed so it is able to detect errors and unsafe conditions before it actually has to execute them.

I'm not worried about limit conditions and errors--I do error checking in my Ruby script that I generate gcode with, and I visually verify the integrity of the paths using a separate ruby script that parses the gcode files and draws them over the original geometry so I can do a quick sanity check to make sure the paths look okay. Here is an (old) example. For this reason, I don't enable the soft limit feature of Mach3.

as you use encoders better to use dc motors like servo. they are faster and as the resolution of the encoders is higher.

I suppose that's an option, but I'd want a software package to drive them, as I don't trust hardware-level code I'd write myself. I'm pretty good at scripting at the software level (as I wrote the gcode generation routines I use to export gcode from Sketchup geometry), but the extent of my experience at the kind of code that directly drives an arduino would be to adapt existing solutions or making small changes. I'm frankly a lot more comfortable dealing with steppers; the reason I wanted encoders is because I need to correct for motor failures. I do not want to trust my motors to never fail; I need a safety check in place for when they DO fail.

grays42: Ah, I see. That makes sense. Let the PC handle gcode processing and let the arduino drive the steppers. Since I am leaning toward LinuxCNC, would this be advisable if I use that? Or just let LinuxCNC deliver dir and step directly using a DB25 breakout?

If you use LinuxCNC just use it - don't tamper with it. What I'm suggesting is a DIY alternative.

...R

Sounds good. Thank you again for all the advice. I've got some hardware recommended on the LinuxCNC forums on the way, I'll put together a Linux box this week and do some testing.

grays42:
I’ll put together a Linux box this week and do some testing.

I’m a recent convert to Puppy Linux (from Xubuntu)

Very easy to install

…R