Kenneth Lerman wrote: > We've had previous discussions about using ethernet for real time control. > > In theory, this is NOT difficult stuff. I'll bet I could get something > going in a week or three. > > In practice, though, it is a PITA. That's because you would need a real > time driver for each of the zillion or so different ethernet boards, > chips, etc., that people want you to support. > > RTnet has already done much of this. I'm not sure of the details, but there really are only about 5 or so different ethernet chips that are built into PCs. > Then, of course, there is the question of what to put on the end of the > ethernet. Something like Jon Elson's boards would be nice. Something > that you could expand with lots of switch and relay interfaces would > make many people happy. > Yeah, I've been looking at this for some time. The problem is that the time-sliced ethernet protocol that Ulrich Marx came up with requires some serious changes to the protocol stacks on the target devices as WELL as on the host. rtnet takes care of the host end, but you are on your own to build a tiny real-time scheduler so the target device can place its transmissions in the correct time slot.
Really, rtnet is not needed for this purpose. Assuming a totally dedicated network card, and a request/response form of device control, none of this time slice allocation is actually needed. EMC sends a request to read encoder counts, computes new velocitioes and send them out. So, it sends a request packet, gets a response, sends a command packet and maybe gets a "done" response, or maybe we don't even bother with that response. I was thinking that the request packet would have a map that specifies what target device registers should be read. Something like : 0 12 -- read 12 consecutive registers starting at address 0 14 3 -- read 3 regs starting at addr 14 0 -- done And, you'd get back a response packet with 15 bytes of data. This could be fit into the framework already built for my boards that enumerates the boards, detects options and rev levels, etc. I don't know how simple it would be to "dumb down" rtnet to work with a standard target device with a standard protocol stack. Maybe rtnet wouldn't care if the target device answered out of order, as long as there are no collisions, which this scheme would not permit. I believe such a scheme would be a GREAT improvement for my boards, allowing us to get past many of the parallel port quirks as well as permitting a substantial speedup in the protocol. But, I don't really have the time to do all the research on my own. If somebody had a simple real-time driver for the ethernet chips that didn't require a lot of special changes to the target boards and protocol stacks, or if it could be determined that rtnet could be made to work without those changes, then I'd like to try experimenting with it. Making up a board with one of the ARM7 CPUs with ethernet and putting together a program to read/write to my existing boards would be a small project. Jon ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Emc-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-users
