On Fri, 28 Nov 2008, Jon Elson wrote:
> Date: Fri, 28 Nov 2008 11:38:15 -0600
> From: Jon Elson <[EMAIL PROTECTED]>
> Reply-To: "Enhanced Machine Controller (EMC)"
> <[email protected]>
> To: "Enhanced Machine Controller (EMC)" <[email protected]>
> Subject: Re: [Emc-users] general control thoughts
>
> 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
I think the dedicated Ethernet port is a great idea, also if this is a plug-in
card, a single realtime Ethernet driver for a single chip type is all thats
required to cover a large number of systems.
We just ported the HostMot2 firmware to USB 7I43s using our simple LBP
protocol (sort of like what you were describing above) Of course this is no
good for real time, but an Ethernet version doing the same thing would be a
good way to avoid all the Parallel port troubles, as long as a single
point-point link is all thats needed. I was thinking of just raw packets with
a very simple protocol like LBP to speed up parsing at the (possibly slow)
external device. The motherboard (TCPIP) link could be used for normal
internet and non-realtime I/O (Modbus over TCPIP etc)
Peter Wallace
Mesa Electronics
(\__/)
(='.'=) This is Bunny. Copy and paste bunny into your
(")_(") signature to help him gain world domination.
-------------------------------------------------------------------------
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
