I really think all of the thread raised issues have been addressed by Ethercat:
1. it uses Ethernet (100MBps max) raw packages 2. there is an opensource Ethercat "Master", which runs under linux/RTAI (http://www.etherlab.org/en/ethercat/index.php) 3. you could command motion and IO devices using one Ethercat network 4. "Data for and from 100 servo axis can be updated with up to 10 kHz." 5. "Process data exchange with 1000 distributed digital I/O takes about 30 µs." 6. The packages are really simple packages, each device looks inside if there's anything for itself, otherwise the package gets passed on. "Due to these features EtherCAT can support almost any topology such as line, tree or star. " 7. "Since 100BASE-TX Ethernet physical layer is used, the distance between any two nodes can be up to 100 m (300 ft). Up to 65535 devices can be connected per segment. If an EtherCAT network is wired in ring configuration (requires two ports on the master device), it can provide cable redundancy." 8. "For synchronization a distributed clock mechanism is applied, which leads to very low jitters of significantly less than 1 µs even if the communication cycle jitters. Therefore EtherCAT does not require a special hardware in the master device and can be implemented in software on any standard Ethernet MAC, even without dedicated communication coprocessor." 9. While the master can be implemented in software on the PC, "EtherCAT slave controllers are available as code for different FPGAs and are also available as ASIC implementation." 10. Using ethercat one could drive the motors from HAL, and read back encoder information (this would assume 1-2 ethercat logical devices / axis). I (personally) would implement a single axis controller (analog output or stepgen, and encoder input) which can be commanded by Ethercat. Then you could join 2-9 of these, depending how many joints the machine has. For I/O I would use existing products for starters (e.g. from Beckhof). Regards, Alex PS: most of the quotes are form http://en.wikipedia.org/wiki/EtherCAT ----- Original Message ----- From: "Jon Elson" <[EMAIL PROTECTED]> To: "Enhanced Machine Controller (EMC)" <emc-users@lists.sourceforge.net> Sent: Monday, October 29, 2007 7:44 PM Subject: Re: [Emc-users] Ethernet I/O > Erik Christiansen wrote: >> On Fri, Oct 26, 2007 at 08:37:47PM -0500, Javid Butler wrote: >> >>>The real problem is the endpoint device. There will have to be some way >>>to >>>decode the signals from the ethernet into the actual drives. It will >>>probably be a while before cost effective drives are available with >>>ethernet >>>inputs. Until then we will have to use decoders that provide translation >>>of >>>the ethernet commands to individual bits such as are on the parallel >>>port. >> >> >> Is it essential that it be ethernet? If Jon's custom host controller had >> one or more RS485 ports (preferably 4-wire full-duplex), then any fast >> microcontroller with one or more serial ports could potentially serve as >> the endpoint controller. >> > The idea is that 100 mbit/sec ethernet is fast. What other > RS485 device do you have that runs that fast? >> With on-board multiple-channel PWM generators (e.g. with 64 MHz clock) & >> counter/timers to offload the CPU, and interrupt service routines being >> the natural order, a reasonably fast uC can handle velocity feedback, >> and calculating PID without too much fuss. (But high speed machine >> control may be more demanding.) >> > The main idea of this discussion os to PRESERVE the mode of > EMC2, and get around the disappearance of the parallel port. > There is no doubt that the entire motion control task, in fact > all of EMC2 except the GUI, could be moved to one of these ARM > micros. > And, by spoon-feeding the G-code in large chunks, there's be no > need for a fast I/O channel. But, that is not waht I was trying > to do! > >> If ethernet is used, it'd surely be necessary to be able to DMA the data >> into the micro, or the benefit of 100 Mb/s would be lost. Now we'd need >> an ARM chip as axis controller? Incidentally, if linux is to run on the >> host, then ARM would be a better choice than the NXP beast? (Though >> eCos is well endowed in the ISR area, and more suited to real-time.) > This is all handled by these ARM7 micros, they are an entire PC > on one chip, except for video. The NXP LPC2300 IS an ARM7 CPU. > They also have ARM9 if you need even more. Their problem is > getting working silicon out of the lab. > > Jon > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > Emc-users mailing list > Emc-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-users > > > -- > No virus found in this incoming message. > Checked by AVG Free Edition. > Version: 7.5.503 / Virus Database: 269.15.12/1096 - Release Date: > 10/27/2007 11:02 AM > > ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
