On 2/6/2011 1:47 AM, Kim Kirwan wrote: <snippage> > > But look at the (current) EtherCAT hardware page > (there in the green block at the top): > http://www.etherlab.org/en/ethercat/hardware.php > > It seems to say they have a universal driver that supports all network > cards that are currently supported in linux, but that you can't use it > with RTAI. So although yes, the universal driver can run the network in > real-time, it's not able to run in real-time under a real-time OS.
For some reason, I'm not quite getting the distinction. What's the point of a RT network if it's not going to run under a RTOS? > > (This reminds me of Bob Newhart's classic turn as Major Major in > "Catch-22" who would agree to see people in his office, but only when > he wasn't there:) > http://www.youtube.com/watch?v=gwT-_uCEMiA > > So maybe rtnet.org is not re-inventing the wheel after all? > > Additionally, RTnet.org mentions an RT-Firewire, so maybe those who > have been wanting EMC2 to run over USB would accept Firewire? Eh, Firewire usage is fading faster than parallel port. My latest laptop and desktop systems don't have any Firewire ports on them > > Or, back to Ethernet, RTnet.org lists 12 supported NICs: > http://www.rtnet.org/doc.html > > I wonder if EtherCAT is trademarked? And we (and slave card makers?) > might have to pull out all the "EtherCAT"s the way that CentOS has > to pull out all of the "Red Hat"s out of otherwise GPL'd software? > And only mention "the upstream source provider"? > > Also, EtherCAT lists only four NIC cards as specifically supported. > (I'm guessing this means running *with* a real-time OS? Not sure.) Could be our biggest problem is going to be the slave port. Now, we're using a relatively simple and cheap parallel port breakout board to the drivers. How do we inexpensively make a slave card work RT at the driver end of the link? It needs to be able to accept the signals from the master, then convert those signals to step/dir, or servo loops, and in the case of servo loops, be able to communicate the loop back to the controller. > > I consider a large number of supported NICs to be a feature, not a > drawback. And I think manufacturers would agree, if we can get to > the point where the NICs are supported generically(?) in some way > so that it's not much extra work for the slave manufacturers. Or, > if not, then pick a couple of popular ones and support those. > > And just to clarify a point, it wouldn't bother me at all if the > EMC2 master PC had to have at least one real-time-only network > interface in this proposed scheme. I don't see why we want to make > Samba and BitTorrent available over the same network as the CNC RT > control signals. Even if they can be tunneled or whatever. The RT > network should IMHO connect only EMC2 and the CNC machine slaves, > nothing else. NIC cards for PC's are cheap, and the more that support RT ethernet the better. The big issued is going to be what do we do on the other end. > > So the way I see it we have to first plan a way to get simple, fast, > RT I/O working from a NIC in EMC2 with an eye toward how to build > the remotes, and if they can be EtherCAT or RTnet.org (or anything > else) compatible, great! If they have to be something non-standard, > but it's fast, simple, cheap, and reliable, it might be a reverse > case of "If you come, they will build it." > > This is a great discussion and I think it will eventually prove > valuable, please continue, everyone, with your great contributions. > > Thanks, > > Kim Cheers, Mark ------------------------------------------------------------------------------ The modern datacenter depends on network connectivity to access resources and provide services. The best practices for maximizing a physical server's connectivity to a physical network are well understood - see how these rules translate into the virtual world? http://p.sf.net/sfu/oracle-sfdevnlfb _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
