Gentle persons:
So I've been trying to practice due diligence. The sourceforge mail
archives have been really flaky for me today and the Gmane archives go
back only 2 years, so I started by searching my archive of
emc-users-digest messages that dates from when I subscribed to the
digest in
Kent
Kent A. Reed wrote:
Gentle persons:
So I've been trying to practice due diligence. The sourceforge mail
archives have been really flaky for me today and the Gmane archives go
back only 2 years, so I started by searching my archive of
emc-users-digest messages that dates from when I
Jon Elson wrote:
Kenneth Lerman wrote:
Jon,
Don't use rtnet. Just use ethernet point to point to replace a parallel
port. Then there is NO net stack. Just use raw ethernet packets.
Overhead is then a few dozen bytes.
OK, but is there an ethernet driver that is callable within the rt
Kenneth Lerman wrote:
Jon Elson wrote:
OK, but is there an ethernet driver that is callable within the rt
environment?
I may have missed such a thing, but I'm not aware of it.
I would think (always a dangerous activity), that if there is a rtnet
driver available within the rt
: [Emc-users] Ethernet, rtai, and rtnet
Jon Elson wrote:
Kenneth Lerman wrote:
Jon,
Don't use rtnet. Just use ethernet point to point to replace a parallel
port. Then there is NO net stack. Just use raw ethernet packets.
Overhead is then a few dozen bytes.
OK, but is there an ethernet
Remember that the issue on ethernet will not be throughput; it will be
latency. I'm sure Jon can give you a profile of what he is doing.
How many bytes in a send packet?
How many bytes is a receive packet?
Cycle time?
I assume it would be acceptable to do something like:
1 -- Receive M byte
Kenneth Lerman wrote:
Remember that the issue on ethernet will not be throughput; it will be
latency. I'm sure Jon can give you a profile of what he is doing.
How many bytes in a send packet?
How many bytes is a receive packet?
Cycle time?
OK, the current latency is VERY short per
Jon Elson wrote:
Kenneth Lerman wrote:
Remember that the issue on ethernet will not be throughput; it will be
latency. I'm sure Jon can give you a profile of what he is doing.
How many bytes in a send packet?
How many bytes is a receive packet?
Cycle time?
OK, the current latency
Stephen Wille Padnos wrote:
A standard ethernet frame has to be 512 bits (64 bytes) long. This
includes ethernet framing info, and I think the net payload is 46 bytes
for a minimum packet. This is aside from any UDP/IP or TCP/IP
addressing or protocol information. So you probably need at
Stephen Wille Padnos wrote:
I don't know the specifics of how to deal with the incoming packets on
the PC (or the specifics of how to send them, for that matter :) ), but
I'm pretty sure data throughput won't be an issue. Latency is unlikely
to be either, unless there's some very complex
Sebastian Kuzminsky wrote:
Stephen Wille Padnos wrote:
A standard ethernet frame has to be 512 bits (64 bytes) long. This
includes ethernet framing info, and I think the net payload is 46 bytes
for a minimum packet. This is aside from any UDP/IP or TCP/IP
addressing or protocol
Jon,
Don't use rtnet. Just use ethernet point to point to replace a parallel
port. Then there is NO net stack. Just use raw ethernet packets.
Overhead is then a few dozen bytes.
Ken
Jon Elson wrote:
Stephen Wille Padnos wrote:
I don't know the specifics of how to deal with the incoming
Sebastian Kuzminsky wrote:
Stephen Wille Padnos wrote:
A standard ethernet frame has to be 512 bits (64 bytes) long. This
includes ethernet framing info, and I think the net payload is 46 bytes
for a minimum packet. This is aside from any UDP/IP or TCP/IP
addressing or protocol
Jon Elson wrote:
Stephen Wille Padnos wrote:
I don't know the specifics of how to deal with the incoming packets on
the PC (or the specifics of how to send them, for that matter :) ), but
I'm pretty sure data throughput won't be an issue. Latency is unlikely
to be either, unless there's
Stephen Wille Padnos wrote:
[snip]
bound on data size, which gives an upper bound on transmit duration.
Uh, an upper bound on servo cycle rate. Geez.
- Steve
--
___
Kenneth Lerman wrote:
Jon,
Don't use rtnet. Just use ethernet point to point to replace a parallel
port. Then there is NO net stack. Just use raw ethernet packets.
Overhead is then a few dozen bytes.
OK, but is there an ethernet driver that is callable within the rt
environment?
I may
Stephen Wille Padnos wrote:
I agree with Ken - you don't need RTNet unless you want to have multiple
slave devices and all that stuff. It could still be useful since the
master defines the timebase (at least in one mode, AFAIK), so the master
could send one sync packet, then have all the
Gentle persons:
I'm sorry I wasn't able to put my oar in when this subject came up again
recently. I am interested in playing with rtnet in the Spring.
The trouble is, I'm certain enough of myself to believe I can
successfully lash up some computers running rtai/rtnet and exchanging
messages
Kent A. Reed wrote:
The trouble is, I'm certain enough of myself to believe I can
successfully lash up some computers running rtai/rtnet and exchanging
messages on a private ethernet segment (probably just round-tripping
packets in the first instance, so I could get a sense of the latency
There is no such thing as Linux driver. Call it GNU/Linux RT driver
for Ethernet interface or whatever. That too needs to be isolated from
the regular Ethernet driver as you would need to isolate SATA-CNC driver
from the default SATA driver.
Before making such statements, please read up on
Ray Henry wrote:
http://www.ce.utwente.nl/rtweb/publications/MSc2004/pdf-files/011CE2004_Buit.pdf
An interesting study of RTnet. In it they say;
RTnet communication times are mostly determined by the
hardware. Not only processor speed but also architecture and
Rafael Skodlar wrote:
If I were asked to select the most common port, bus, or interface in PC
for use in RT environment I would say either floppy or ATA bus. They are
present on most motherboards. However, they are now practically obsolete
and bad candidates for future EMC direction IMO.
In industry ethernet based realtime protocols are used more and more
with good success on pretty inexpensive and reliable hardware.
Especially I have SERCOS and EtherCAT in mind.
Both of these buses have fast cycles from 30us up, both have software
masters on a standard ethernet controller and
23 matches
Mail list logo
