>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.
Ken,
I needed to do something like this for a printer network interface a long
time ago.
By using UDP vs TCP/IP you remove all the overhead of the TCP/IP stack. At
the HAL parallel
port interface do a Network UDP send using a very small packet with the 8
bit parallel port output
data (or maybe several sets of port data). Always expect an immediate
response from the addressed device
with the port status. You can tag the UDP packet with a running count to
verify the response is from
the sent packet. It also lets you know when the network went south for
some reason. Now when HAL
reads the parallel port status, its just the last received data from the
network device.
The throughput is quite good on even a large network.
The remote device can be a simple Microcontroller with minimal code.
Use UDP broadcast (IP = 255.255.255.255.255) to "Find" a device on the
network for initial setup.
Their reply will have their IP address.
This works and works quite well (at least it did for the printer
interface). What we found was the network
latency was actually quite small and the response time was constant even
with other network protocols
running and even with high network usage.
Jim Combs
Lexmark
Kenneth Lerman
<[EMAIL PROTECTED]
e-ltd.com> To
"Enhanced Machine Controller
11/28/2008 01:17 \(EMC\)"
PM <[email protected]>
cc
Please respond to Subject
"Enhanced Machine Re: [Emc-users] general control
Controller thoughts
\(EMC\)"
<[EMAIL PROTECTED]
sourceforge.net>
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
> [email protected]
> 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
[email protected]
https://lists.sourceforge.net/lists/listinfo/emc-users
-------------------------------------------------------------------------
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
