[gareth]

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.

[keick]

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.

[keick]

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.

[307startup]

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.

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.

[shyfx]

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.

[daedalus]

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.

[shyfx]

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!

[andy55]

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

[shyfx]

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!!!

[impartial]

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.

[navins]

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

[sunny_daise]

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.