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. 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.) Something like the AT90PWM3B, while only clocking 16 MIPS, needs only H-bridges and drivers added, to control a BLDC from its on-chip synchronised power stage controllers (specialised PWM). I haven't tried the ready made card at http://www.atmel.com/dyn/products/tools_card.asp?family_id=607&family_name=AVR+8%2DBit+RISC+&tool_id=3764 Estop can be fed directly into the output power stage controllers, if desired. The 100 MHz 8051 core also sounds interesting (as an axis controller) from a hardware point of view, but it's famously mismatched for 'C' coding, due to its stack limitations, and accumulator-centric architecture. The (possibly consequential) lack of gcc support, is probably the biggest hindrance to my eye, followed by the greater wealth of on-board peripherals on competing products. (Having used it professionally for nearly 2 decades, I have a soft spot for it, though.) A distributed architecture appeals because it is easier to upgrade/rebuild if the host controller only reads gcode and says "go to x, at speed s". There are no precison dc control voltages dodging EMI from power electrics either. Incidentally, with eeprom as well as flash in these microcontrollers, PID and other parameters can be stored in the drive, and updated via the host. (No panicked search for old data files when bringing a mothballed drive back into service.) Trying to make the serial communications super-hard real-time could be the hard way to do things. Where several axes need to be synchronised, one axis controller can put its encoder pulsetrain directly onto an RS485 synchronisation bus, and slaved axes feed that into on-chip hardware counters, either interrupting when the count is big enough to act on, or being read at the sample interval to check if the axis feed ratio is being maintained. Especially at high speeds, with high encoder line counts, a micro will still have to sample. (1 mS & 16 MIPS = 16,000 instructions per interval) The synchronising source can be chosen by selecting which axis controllers send, and which receive on a bus. The synchronisation busses would necessitate running a second cable between controllers, I figure. (I have some cat5 cable and some oil-resistant metallic flexible conduit, which I figured might do.) Would a 64 byte packet be required to issue a motion command to an axis controller, addressing included? (Since commands and status reports need not be nanosecond realtime, now that sync is on separate busses, does it hurt that an AT90PWM3B's 2Mb/s maximum baudrate extends transfer time to 320 uS for 64 bytes?) Let's send 32 bytes. ;-) Like the 8051, the AVRs have hardware address frame recognition, but must compare addresses in software, so an RS422-style point-point connection would be kinder. 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.) Erik ------------------------------------------------------------------------- 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
