PC CNC control

[David Kirtley]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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