I think the easiest way to do this is for a point to point network or even a network with a hub is to use raw ethernet packets. An ethernet packet has a payload of up to 1500 bytes. That should be large enough for most things we would want.
On top of the payload we have around 20 bytes of overhead, including a CRC. I think we could come up with a simple polling protocol. The EMC machine would be the master. To me, the thing that needs the most thought is how to build a generic HAL component to handle this. It is the same problem that SWP and I discussed at Fest regarding Modbus. Ideally, you could have a configuration file for the driver that specified the devices (in the case of ethernet if would be by MAC address) and how to map HAL pins to channels on the device. We would need to have a comprehensive set of signal types. There is a decent amount of work involved in spec'ing this out. Offhand, for inputs, I see things line single bit, multi-bit word input, signed word input, counter input, counter that resets on read input. I would make words all the same length; at least thirty-two bits, but possibly sixty four bits. The fact that the transmission time is very small makes that reasonable. Enough, for now. I don't think I have the time to really work on this now. Ken Jon Elson wrote: ... > 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 > Emc-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-users -- Kenneth Lerman Mark Kenny Products Company, LLC 55 Main Street Newtown, CT 06470 888-ISO-SEVO 203-426-7166 ------------------------------------------------------------------------- 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 Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
