Would you participate to an open-source CNC controller?

Hello
I have one idea: an open source CNC controller, with ethernet interface.
It will use cheap microcontroller and FPGA, and work with windows and linux. The biggest problem is to implement g-code compiler in FPGA.
Processing power is not a problem any more but I don't have time to fully understand and develop software for this, although I have previous experience with CNC, ethernet microcontrollers and FPGA design.

I could post schematic (but FPGA it's not fun to solder), and current development files.
How do I make sure that project remain open-source?

what FPGA chip you plan use?

Quote:

---

Originally Posted by beliefdrive

what FPGA chip you plan use?

---

XC3S250, package is TQFP144.
For now I have a Digilent "Basys" development board, with XC3S100 FPGA from Xilinx.
I know that ethernet can be implemented in FPGA too, but I didn't tested this yet.

i thinks we need begin with interpolation algorithms

If anyone can implement the necessary ETH module in FPGA, it will be perfect.
Here is a good start:
http://www.fpga4fun.com/10BASE-T0.html

The real advantage of FPGA is that modules are working separately, so if something is bug-free - will not be affected if oter module is modified.

Quote:

---

Originally Posted by beliefdrive

i thinks we need begin with interpolation algorithms

---

Yes. but I suspect this algorithms are already implemented somewhere, close to what we need.
1. My idea is that FPGA receive a g-code line, and interpret-it.
2. One advantage will be if the X/Y/Z/A/... coordinated are expressed in stepper's steps. It can be implemented right from the program that generates g-code.
3. A Java applet will take that file and send-it line by line to FPGA through ethernet. This way any operating system can be used.
4. Any new computer can be used, from anywhere in the local network with CNC controller (no need for parallel port, USB, or RS232)
5. There will be no need for optical isolation between computer and controller (ethernet is enough)
6. Java (although big and somehow slow) can do almost anything - from talking through ethernet to real-time animation of the CNC tool.

i found same article on fpagfun, it is usefull

http://www.fpga4fun.com/CNC.html

Have you looked at the mesanet.com 5I20 and similar FPGA PCI-cards.
They are currently being used with EMC2 and there is open-source VHDL for PWM-generation, encoder counting, step generation etc. There is also a "softdmc" motion-controller implemented for this FPGA.

On the EMC2 list there has been talk about a real-time (RTAI) port of Linux for the beagle board (http://beagleboard.org/). This could be another way of approaching embedded motion-control.

I would encourage you to seriously look what EMC2 already has and how you can extend that to what you want or how you could use parts of it.

Quote:

---

Originally Posted by andy55

Have you looked at the mesanet.com 5I20 and similar FPGA PCI-cards.
They are currently being used with EMC2 and there is open-source VHDL for PWM-generation, encoder counting, step generation etc. There is also a "softdmc" motion-controller implemented for this FPGA.

On the EMC2 list there has been talk about a real-time (RTAI) port of Linux for the beagle board (http://beagleboard.org/). This could be another way of approaching embedded motion-control.

I would encourage you to seriously look what EMC2 already has and how you can extend that to what you want or how you could use parts of it.

---

I want an embedded CNC controller, with ethernet interface and a small LCD, that can be used with any operating system.
I know about EMC, I don't want to design a new plugin for EMC or MACH or any other software. That are good solutions with their good and bad parts.

Why wouldn't the beagle-board, running real-time linux and EMC2 qualify ?

If you want to write your own real-time operating system, g-code interpreter, graphics drivers, PID-loops, etc. etc. etc. then please go ahead, but unless you are very talented and have lots of resources (time+money) it will be difficult.

To me it seems the real-time port for the beagle-board would be an excellent way to go.

Quote:

---

Originally Posted by andy55

Why wouldn't the beagle-board, running real-time linux and EMC2 qualify ?

If you want to write your own real-time operating system, g-code interpreter, graphics drivers, PID-loops, etc. etc. etc. then please go ahead, but unless you are very talented and have lots of resources (time+money) it will be difficult.

To me it seems the real-time port for the beagle-board would be an excellent way to go.

---

why do you want to make things heavier than it can be?
There is no reason to implement a real-time operating system.
Any problem from this idea can be solved at low-level.

if you want to receive G-code over ethernet, interpret it, show it on screen, and run a machine you need a lot of the software components that are already there in place with a linux+EMC2 solution.
IMO working on an fpga-based kick-ass I/O module for the beagle-board would be time more well spent.

Quote:

---

Originally Posted by andy55

if you want to receive G-code over ethernet, interpret it, show it on screen, and run a machine you need a lot of the software components that are already there in place with a linux+EMC2 solution.
IMO working on an fpga-based kick-ass I/O module for the beagle-board would be time more well spent.

---

sending G-code to a microcontroller over ethernet, displaying it on the LCD, and interpret-it (G00 and G01) in microcontroller is allready done.
I will use FPGA only to escape from microcontroller limitations.

Quote:

---

Originally Posted by andy55

if you want to receive G-code over ethernet, interpret it, show it on screen, and run a machine you need a lot of the software components that are already there in place with a linux+EMC2 solution.
IMO working on an fpga-based kick-ass I/O module for the beagle-board would be time more well spent.

---

if I've understand right, beagle-board is a small computer, based on CPU and memory. This architecture is not favorable to this embedded system.

There has been a need for this for awhile. Over the last 20 years, I have had alot of these pc based cnc controllers, on many different machines. The best ones to this date, I have had, were were centriod, linux based, and emc linux for sure.
Build a cnc controller the will cut parts, and do it well.
By far, the controller on HAAS mill is just down right awesome.
Some of the best applications I have ever ran, were open source, seems like the open source people really get programming.

Good luck with your venture

While I will wait for your opinion, please, comment about my idea:
- Software can be developed on a Digilent Basys/Basys2 boars (already have-it)
http://www.digilentinc.com/Products/...791&Prod=BASYS
Two days ago, it was 59$ for academic use. Now it's 89$!
- You must install ISE Webpack for FPGA any other idea is welcomed
*it's not that I really hate-it, but...
*you need to download 2G of software
*install-it as 5G in program files
*if you want to install the latest update, you need 10G more on program's partition.
*and you will use at most 1G of those files....)
-Project can be a mix of low-level/hierarchy schematics and vhdl/verliog language
-Programming FPGA - with USB cable from Digilent board
-Schematics of the board can be downloaded from Digilent site -some parts of the schematics can be reused in final design
-I will use small DRV8811 drivers, with small bipolar steppers - just for fun

I will start seriously the work, in january 2010. Until then - documentation stage

Get yourself a copy of altium to evaluate, its fpga dev tools are far more user friendly then the webpack by itself, and they give away a 30 day trial on their website. Also they support c-to-hardware compiling, that might get you round the limitations you are facing with using a micro for this job.

personally I would go for an fpga card with a PCI interface on it, as that way you could theoretically add support for EMC at a later date, whilst a USB solution would be problematic for that due to rt-linux support.

EDIT: personally this kind of approach doesn't appeal to me, as i am looking to move towards having drives and IO on a standard fieldbus like EtherCat, and a small embedded PC for machine control. The benefit of this is you don't have to bit bang steps out of the printer port, so your timing becomes less problematic, as you are commanding the drive setpoints directly over ethernet. I have heard of people getting 20khz position update rates over ethercat, which is more then enough for any cnc machine. You can get off the shelf interface ICs that speak ethercat, and the host software is free, with an open source implementation available.

Quote:

---

Originally Posted by daedalus

Get yourself a copy of Altium to evaluate, ...

---

I have tested once: like-it, but stability is a problem for Altium (at least in my case). And I can't be sure that its output code is optimal for used FPGA.

Quote:

---

Originally Posted by daedalus

personally I would go for an fpga card with a PCI interface on it, ... EMC ... USB ......

---

On the same idea you can use a high-end acquisition board, and Matlab, Labview, or any other software.
I don't want a CNC controller based on a PC! I don't care about Mach, EMC, RS232, or USB. All this require using a computer, with a software package installed; and in most of the situations, that software is licensed on that particularly hardware PC, so you are close-linked to that PC.
If my idea with CNC as eth. server will be implemented, all you will need to run the CNC will be a web browser with Java; nothing more.

From experience altium's output is exactly the same as using the vendor build tools, it actually runs them behind the scenes.

So you still need a dedicated pc for each machine tool, just one that now does nothing more then run a browser? And to get to this stage you need to rewrite the whole of mach's UI functionality yourself.

Good luck, i think you have a lot of work ahead of you.

Quote:

---

Originally Posted by daedalus

So you still need a dedicated pc for each machine tool, just one that now does nothing more then run a browser?

---

Nop, there will be no "dedicated PC" to run the tool. Any computer from local LAN can be used. This means anybody could use it's notebook to run the tool ;)
Beat that!

Cypress is bringing out a PSOC 5 chip next year with ARM cortex M3 & on board analog & digital peripherals.

As for FPGA - what MCU will you use ?

Are you coding verilog or VHDL ?

I nearly have my electronics degree now & have a diploma in control systems.

Why not just stick LINUX into your chip and run a LINUX g-code app ?

I have an altium development board.

To ensure it stays open source your best bet is to decide on a license. I would love to see it under LGPL (Lesser GPL) as it does allow some commercial use. Start a project under source-forge and then port here.

I have some FPGA experience, and lots of windows. I've actually been thinking of doing something like this. A good start would be a hardware solution and a plugin for Mach3 that didn't relay on 30 year old parallel ports. That way you could forgo the post-processing of g-code at least for the first little bit.

Quote:

---

Originally Posted by daedalus

Get yourself a copy of altium to evaluate, its fpga dev tools are far more user friendly then the webpack by itself, and they give away a 30 day trial on their website. Also they support c-to-hardware compiling, that might get you round the limitations you are facing with using a micro for this job.

personally I would go for an fpga card with a PCI interface on it, as that way you could theoretically add support for EMC at a later date, whilst a USB solution would be problematic for that due to rt-linux support.

EDIT: personally this kind of approach doesn't appeal to me, as i am looking to move towards having drives and IO on a standard fieldbus like EtherCat, and a small embedded PC for machine control. The benefit of this is you don't have to bit bang steps out of the printer port, so your timing becomes less problematic, as you are commanding the drive setpoints directly over ethernet. I have heard of people getting 20khz position update rates over ethercat, which is more then enough for any cnc machine. You can get off the shelf interface ICs that speak ethercat, and the host software is free, with an open source implementation available.

---

Not nessecarily. USB isn't real-time for certain, but there would be multiple reasons for the hardware to cache ahead to compute rates for turns and such. USB or Ethernet would be bulk transfers, and periodic responses back to the host machine if desired. I'm in the avionics development field. Most avionics displays only update at 30Hz, because pilots can't detect changes faster than that. Maintaining a 30hz feedback to the operator via USB or Ethernet is well within the performance of those interfaces on RT Linux, or windows for that matter.

I would dare-say that while no machinist could detect changes faster than a pilot, the feedback is needed in machining, on several orders of magnitude. With high-speed machining processes and S-curve acceleration being used (a welcome upgrade for the hobbyist/home shop user) it's far more important for the machine to be able to address any issues that might crop up...that is what is so great about CNC...the control SHOULD be doing all of the machining work, once a setup and program are optimized. In this case, it's all about putting the heavy lifting on the computer, not the operator.

Quote:

---

Originally Posted by keick

Not nessecarily. USB isn't real-time for certain, but there would be multiple reasons for the hardware to cache ahead to compute rates for turns and such. USB or Ethernet would be bulk transfers, and periodic responses back to the host machine if desired. I'm in the avionics development field. Most avionics displays only update at 30Hz, because pilots can't detect changes faster than that. Maintaining a 30hz feedback to the operator via USB or Ethernet is well within the performance of those interfaces on RT Linux, or windows for that matter.

---

Writing a G-code interpreter at the hardware level would offer no benefits whatsoever. It requires no speed-up that parallel execution in hardware could offer.

This is where a high level software package would be much more versatile, such as EMC2. As others have said, running the whole shebang on an embedded computer would be best. You could however, create an FPGA motion controller, thereby moving the real time motion aspects hardware which would give you very fast update rates, extremely low (and guaranteed) real time performance etc. Then use EMC2 as a G-code interpreter to fill the motion controllers command queue, run all the HMI etc. If you were really tricky, you could implement the processor that runs Linux/EMC2 inside of the FPGA using OpenRisc for instance. Another alternative is to use one of the MCU/FPGA products getting around such as Xilinx Virtex-4 FPGAs With PowerPC Processor Deliver Breakthrough 20x Performance Boost. Would be massive processing power there. You could probably encode HD video while you were machining :) In the scheme of things, machine control isn't going to require the processing resources that hobbyists can even get their hands on and work with.

What my friend and I have been toying with (idea-wise and researching), is an open source EtherCAT slave implementation for FPGA. Then we could create our own realtime distributed hardware for motion control, IO's etc, all driven from an EMC2 master. We would ideally like to create an open source embedded PC too, which would incorporate the features required for the HMI, front end processor etc. This would easily be accessible from a remote computer via ethernet/wireless for transfer of G-code programs etc.

shyfx: if you are planning on writing an open source ethercat slave implementation, that would be a very useful tool for a lot of projects out there.

So looking at my reply again now, I pretty much stand by it but could word it a lot better. In essence there are two routes which I personally believe are the way forward. The former is very reliable but inflexible (would have to be targeted at specific machine configurations, great for OEMs), the latter more modern and configurable, as we know, EMC2 can be applied to so many real time control problems.
My personal choice would be the latter although I do love FPGAs and processing in hardware, makes you feel like a real (nerdy) man.

As for the first solution...
Replicating EMC2's efforts would be a waste of time. You want to retain as much of it as possible. You do however, want to dispense with the real time aspects as much as possible to remove uncertainty in the performance of your controller. While EMC2 is pretty fantastic, there are always doubts over how the hardware will behave in scenarios it was never designed to be used in, i.e. hard real time.
Reusing EMC2 for non-real time stuff however means you have a pretty front end, that can process G-Code, present (non-real time) buttons to users, blah blah. You have all the configuration and connectivity of Linux at your disposal.
This front end would convert the G-Code into low level codes that a real-time machine controller can understand. You would essentially send the real-time controller a list of co-ordinates, speed and torque vectors to a FIFO queue which are to be processed at a fixed clock rate. With large amounts of RAM available these days you would easily buffer huge amounts of data to the controller in a non-real time fashion from the front end, which is then read and unloaded in a real-time fashion by the back end. Any front end lock ups however would stall the queue. As I said, with large amounts of RAM these days, you would be pretty confident that you have a sufficiently large queue for even large machine programs that the whole program could be buffered before starting.

A note on the above; the benefit is you don't even need to use double float data. You can speak to the controller purely in encoder counts. This gives you the control over unit conversion etc on the front end while the back end does what it does best, processing data in a real-time fashion making you pretty parts, or whatever your machine may do.

As for the second solution...
The inflexibility (compared to EMC2 anyway) of the former FPGA option would mean configuration would have to be done at too much a low level for most users. The most obvious option is to develop a purpose built hardware platform (embedded PC) for EMC2 to run in real-time mode. You can do away with Intel power management lock up issues, commercial graphics cards etc. This way you have a trusted solid, small and power efficient platform. This is essentially what Beckhoff and others do. I use Beckhoff PC based stuff at work and it works very well.
This method means you retain 99% of EMC2. You would need to port it to the hardware platform and ensure it works well but this is trivial compared to the aforementioned. Linux also supports a large hardware base already so you hit the ground running.

Networking
In regards to networking, or course Linux has many options here, so presenting a web interface that ANY computer could connect to would not be an issue, although I would sway toward just having it share a network path for dropping files in. You could in theory write connectors from your favourite CAM program to send it over a TCP connection. Possibilities are endless, blah blah, {insert propaganda speech}.

"I don't want to run my machine from a PC"
In reality, all solutions in the end are some form of computer processing. Just because it is actually running on a computer marketed as a personal computer does not mean it is any lesser. In fact some have probably found their PC with EMC2 or any other controller to be far more reliable than their commercial units.

Where can FPGAs fit into all of this?
Function specific, real-time modules. Servo drives, digital I/O, analogue I/O, encoder readers, serial ports, blah blah. Check out the Beckhoff catalogue for ideas.
Talk to these modules in real-time from a real-time master (EMC2). If we could develop an open source VHDL/Verilog EtherCAT slave module, that would open up worlds of possibilities for DIY CNCers.
Imagine you could buy a $100 brushless servo drive? Sure it doesn't have the option for positional control, some ad-hoc ladder logic implementation etc, but why would you want it anyway? Every time I use a drive for machine control I don't use any of that stuff. I put my servo drive in velocity or torque mode and put it in the PID loop of my CNC controller. Therefore I have all this functionality in my device sitting there dormant.
I would propose an open source EtherCAT torque-mode servo drive which has it's velocity and/or positional loop closed by EMC2.
Digital I/O, analog and all those other goodies can be implemented in much the same manner.
EMC2 just needs a good configurable EtherCAT master imlpementation and the community needs a good EtherCAT slave implement in VHDL/Verilog.

In closing
TGIF!

Quote:

---

Originally Posted by shyfx

Where can FPGAs fit into all of this?
Function specific, real-time modules. Servo drives, digital I/O, analogue I/O, encoder readers, serial ports, blah blah. Check out the Beckhoff catalogue for ideas.
Talk to these modules in real-time from a real-time master (EMC2). If we could develop an open source VHDL/Verilog EtherCAT slave module, that would open up worlds of possibilities for DIY CNCers.
Imagine you could buy a $100 brushless servo drive? Sure it doesn't have the option for positional control, some ad-hoc ladder logic implementation etc, but why would you want it anyway? Every time I use a drive for machine control I don't use any of that stuff. I put my servo drive in velocity or torque mode and put it in the PID loop of my CNC controller. Therefore I have all this functionality in my device sitting there dormant.
I would propose an open source EtherCAT torque-mode servo drive which has it's velocity and/or positional loop closed by EMC2.
Digital I/O, analog and all those other goodies can be implemented in much the same manner.
EMC2 just needs a good configurable EtherCAT master imlpementation and the community needs a good EtherCAT slave implement in VHDL/Verilog.
In closing
TGIF!

---

Modular is good. For an example of what can be done, see this project by two Hungarian students/researchers:
General Mechatronics - Industrial robot controller

Is the EtherCAT standard open? i.e. specs etc. are available for free?
The issue of real-time ethernet comes up on the EMC2/LinuxCNC mailing-list periodically. The problem seems to be that it needs special NIC-drivers, and the NIC-chips on motherboards and PCI/PCIe NICs keep changing at a fast pace.

AW

EtherCAT Specification
EtherCAT Technology Group | Downloads

Master implementation for Linux
http://soem.berlios.de/

As for the NIC issue, it further reinforces the need for a standard embedded platform which has known working hardware.
However, plopping in a PCI(e) network card from say, Intel or Realtek is no real drama either.
I am not confirming there is an issue when using ethernet NICs

Home :: OpenCores have an ethernet core written up, so you could use that if it works for real-time or build your base up from it. Either way it isn't a ground up development.

Another option for EtherCAT slaves is
Beckhoff EtherCAT ASICs ET1100, ET1200 | EtherCAT ASICs
Not sure of their unit cost however.

Other dribs and drabs
BECKHOFF New Automation Technology
Anybus-S - EtherCAT Interface
IXXAT [Industrial Ethernet Module for EtherCAT]

I will definitely have to fire up my LinuxCNC setup and have a tinker with EtherCAT and real-time.

Anyway, home time!!!

Hi! I wonder whether there is ready to develop on the basis of ideas EtherCat?
I did my slave controller implementation on FPGA Altera Cyclone IV. I can not get to run on the master driver in real time. Please help me in the wilds of Linux.

I can't take a part in this competition, but I can suggest someone from my friends to take part in this.

Actually now it has advocated open-source model with the development of society, which also will be popular in the cnc industry in the near future, I believe. So if I have the chance and with the software, I'll be participate to develop an open-source CNC controller.