[Xenomai-help] XUM 2009 follow-up : Powerlink, CANopen and sockets.

[Xenomai-help] XUM 2009 follow-up : Powerlink, CANopen and sockets.

[Edouard TISSERANT]

Dear hackers,

I've been passing last month seeking for the best way to implement
Powerlink with Xenomai. I still didn't find the absolute truth, and
would like to confront my point of view.

In short, Powerlink is a kind of CANopen over polled ethernet.
Powerlink re-use a subset of CANopen concepts for high level
communications, whereas on the low level, a single master cyclically
poll each node for data. As you can imagine, communication cycle is
seriously influenced by each controlled node latency answering poll
requests from master.

My intention is to write an efficient Powerlink implementation for
Xenomai, but suitable for later reuse in future Real Time Linux
implementation such as RT-PREEMPT. Discussing with RT-PREEMT gurus, I
understood that re-using native Linux queues could never be a
solution, as those queues induce way too long and unpredictable
latencies for such real-time ethernet (those latencies also apply for
SocketCan). Some software hook at ethernet driver level will be
necessary to reroute RT-related packets directly to the concerned RT
stack. With this approach, the whole stack would have to stay kernel
side to reduce latency in answering poll requests. Implementing the
whole CANopen stack kernel side is generally a bad idea, as it
complicate access to object dictionary from application, usually in
user space.

RTnet proves that Real-Time ethernet can be implemented through the
socket paradigm. I believe that Time Division Medium Access (TDMA) of
RTnet could be interchanged with polled ethernet medium access
discipline from Powerlink. Thus, CANopen implementation part could
stay user side, and could pre-fill answers to poll requests, avoiding
long latencies. But what is the future of RTnet ? Will it be ported to
RT-PREEMPT or will it enter official Xenomai tree ? Will available
RTnet's drivers set continue to grow ? Would it be theoretically
possible for RTnet to support Linux ethernet drivers through a hook
mechanism as mentioned in previous paragraph ?

My feeling is that, yes, we should try to fit implementation of
Powerlink data link layer inside RTnet as another MAC discipline, and
use a modified version of CanFestival for CANopen aspects, keeping it
a user space library. Please comment.

Best regards,

Edouard

-- 
LOLITech
24, rue Pierre Evrat
88100 Saint-Dié des Vosges
tel: +33 3 29 57 60 42
mob: +33 6 10 49 76 41
edouard.tisserant@domain.hid
http://www.lolitech.fr

Re: [Xenomai-help] XUM 2009 follow-up : Powerlink, CANopen and sockets.

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 3705 bytes --]

Hi Edouard,

Edouard TISSERANT wrote:
> Dear hackers,
> 
> I've been passing last month seeking for the best way to implement
> Powerlink with Xenomai. I still didn't find the absolute truth, and
> would like to confront my point of view.
> 
> In short, Powerlink is a kind of CANopen over polled ethernet.
> Powerlink re-use a subset of CANopen concepts for high level
> communications, whereas on the low level, a single master cyclically
> poll each node for data. As you can imagine, communication cycle is
> seriously influenced by each controlled node latency answering poll
> requests from master.
> 
> My intention is to write an efficient Powerlink implementation for
> Xenomai, but suitable for later reuse in future Real Time Linux
> implementation such as RT-PREEMPT. Discussing with RT-PREEMT gurus, I
> understood that re-using native Linux queues could never be a
> solution, as those queues induce way too long and unpredictable
> latencies for such real-time ethernet (those latencies also apply for
> SocketCan). Some software hook at ethernet driver level will be
> necessary to reroute RT-related packets directly to the concerned RT
> stack. With this approach, the whole stack would have to stay kernel
> side to reduce latency in answering poll requests. Implementing the
> whole CANopen stack kernel side is generally a bad idea, as it
> complicate access to object dictionary from application, usually in
> user space.
> 
> RTnet proves that Real-Time ethernet can be implemented through the
> socket paradigm. I believe that Time Division Medium Access (TDMA) of
> RTnet could be interchanged with polled ethernet medium access
> discipline from Powerlink. Thus, CANopen implementation part could
> stay user side, and could pre-fill answers to poll requests, avoiding
> long latencies. But what is the future of RTnet ? Will it be ported to
> RT-PREEMPT or will it enter official Xenomai tree ?

RTnet is expected to gain PREEMPT-RT support via Xenomai 3 (porting it
to "native" PREEMPT-RT, thus creating a branch from its current
RTDM-based version would let the maintenance effort explode). And I hope
we will find the required resources/contributor to welcome a cleaned up
RTnet stack inside the Xenomai 3 source tree one day.

> Will available
> RTnet's drivers set continue to grow ?

Yes, as users keep contributing. It makes no sense to port blindly, we
always have to focus on chips that are in use, provide test
environments, simply have a non-zero user base.

> Would it be theoretically
> possible for RTnet to support Linux ethernet drivers through a hook
> mechanism as mentioned in previous paragraph ?

Everything is possible :), but it's hard to assess the feasibility based
on this vague description. Just note that RTnet drivers also require
some "hook" for deterministic buffer management, ie. they must not
blindly allocate buffers for incoming frames from shared Linux pools.

> 
> My feeling is that, yes, we should try to fit implementation of
> Powerlink data link layer inside RTnet as another MAC discipline, and
> use a modified version of CanFestival for CANopen aspects, keeping it
> a user space library. Please comment.

It would be great to start this endeavor with implementing the Powerlink
MAC protocol inside RTnet. Just one question arises to me: How would the
programming model look like? PF_PACKET via sockets? Or some special
protocol, PF_POWERLINK?

When thinking further: If you move the node's object dictionary into
user space, you will also have to design a local interprocess
communication interface so that multiple processes can access it, right?

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 257 bytes --]

Re: [Xenomai-core] XUM 2009 follow-up : Powerlink, CANopen and sockets.

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 4855 bytes --]

[restoring CC]

Edouard TISSERANT wrote:
>> [...] And I hope
>> we will find the required resources/contributor to welcome a cleaned up
>> RTnet stack inside the Xenomai 3 source tree one day.
> 
> Could you detail that point ?  What is to be changed in RTnet to fit
> with Xenomai 3 ?

No ground shaking changes. I would just like to take the chance and drop
legacy kernel 2.4 support and set a sufficiently high baseline in 2.6
(just like Xenomai 3 will do), clean up the code from some dead
fragments, lindent everything properly, switch to a config interface
that uses socket ioctls instead of /dev/rtnet and go through the locking
once again, specifically checking if it might be done simpler or more
efficiently in some cases. Also drivers should undergo this process (and
not all need to be ported over).

> 
>>> Would it be theoretically
>>> possible for RTnet to support Linux ethernet drivers through a hook
>>> mechanism as mentioned in previous paragraph ?
>> Everything is possible :), but it's hard to assess the feasibility based
>> on this vague description. Just note that RTnet drivers also require
>> some "hook" for deterministic buffer management, ie. they must not
>> blindly allocate buffers for incoming frames from shared Linux pools.
> 
> Of course there is no magic bullet to change an ethernet driver into a
> real-time one, a porting effort will always be required. Nevertheless,
> you could reduce this effort considerably and let most maintenance
> effort to linux' maintainer of each driver. Let me explain...
> While porting CAN driver to Xenomai I asked myself why there was no
> "linux skin". Don't laugh. That skin would have been similar to RTDM
> in purpose and would be have implemented a subset of linux interface
> for fops, tasks, queues,locks, etc. That skin would require some
> compiler, linker or loader magic to replace calls or re-bind symbols
> initially used by module to some RT replacement. A fine grained
> per-driver or per-subsystem symbol overloading approach could be also
> envisioned.
> Applying this to Ethernet drivers so that they become RTnet driver
> looks like possible, but bringing up such a pipe dream may require
> more effort that porting each driver individually. Your opinion ?

What makes things complicated are the unavoidable semantical differences
in the _use_ of whatever API. Specifically as long as there is no
PREEMPT-RT or, even better, mainline user with such requirements, it
will remain hard to maintain the required diffs.

>> It would be great to start this endeavor with implementing the Powerlink
>> MAC protocol inside RTnet. Just one question arises to me: How would the
>> programming model look like? PF_PACKET via sockets? Or some special
>> protocol, PF_POWERLINK?
> 
> If we keep CANopen as a userspace library, PF_PACKET should be enough.
> Application may have to open multiple sockets in order to distinguish
> packets sent in Isochronous phase (poll requests and responses) and
> those sent in Asynchronous phase. MAC discipline would guess what to

"guess" - that sounds scary in the context of RT... :)

> do with packets according to specified MAC addresses. In my sense a
> packet interface is what best fit as a CANopen library back-end.

So Powerlink simply uses a few Ethernet frame types, and we would simply
pass them to/from user space via PF_SOCKET? If that fits, it would be nice.

> 
>> When thinking further: If you move the node's object dictionary into
>> user space, you will also have to design a local interprocess
>> communication interface so that multiple processes can access it, right?
> This is perfectly true, and the only workaround is to have a special
> PF_POWERLINK or protocol, or even better,  PF_CANOPEN (for re-use in
> SocketCan). Problem is that I still don't see clearly how to implement
> CANopen through socket paradigm in a simple and efficient way.
> If the whole CANopen stack with object dictionary reside in kernel
> space it is not conceivable anymore to have a static dictionary
> implemented through generated C code. Would process(es) have to
> declare their own CANopen nodes and OD entries through socket API
> (with bind() and listen() ?). Or maybe could nodes and dictionary be
> constructed with network interfaces administration tools ?
> In the end I'm not sure at all that socket would be the right
> interface for object dictionary entries.... A virtual file system with
> mmap() and select() would certainly fit better.

Well, let's start small, maybe even only with single-process support
(ie. stuffing all the CANopen and high-level Powerlink stack into some
library). We can still evolve the approach once more demanding use cases
pop up, specifically as long as no special ABIs are set in stone.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 257 bytes --]

Re: [Xenomai-help] XUM 2009 follow-up : Powerlink, CANopen and sockets.

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 4981 bytes --]

[restoring CC]

...but accidentally to the core list - probably because I thought it is
a core topic, but let's keep it where it started.

Edouard TISSERANT wrote:
>> [...] And I hope
>> we will find the required resources/contributor to welcome a cleaned up
>> RTnet stack inside the Xenomai 3 source tree one day.
> 
> Could you detail that point ?  What is to be changed in RTnet to fit
> with Xenomai 3 ?

No ground shaking changes. I would just like to take the chance and drop
legacy kernel 2.4 support and set a sufficiently high baseline in 2.6
(just like Xenomai 3 will do), clean up the code from some dead
fragments, lindent everything properly, switch to a config interface
that uses socket ioctls instead of /dev/rtnet and go through the locking
once again, specifically checking if it might be done simpler or more
efficiently in some cases. Also drivers should undergo this process (and
not all need to be ported over).

> 
>>> Would it be theoretically
>>> possible for RTnet to support Linux ethernet drivers through a hook
>>> mechanism as mentioned in previous paragraph ?
>> Everything is possible :), but it's hard to assess the feasibility based
>> on this vague description. Just note that RTnet drivers also require
>> some "hook" for deterministic buffer management, ie. they must not
>> blindly allocate buffers for incoming frames from shared Linux pools.
> 
> Of course there is no magic bullet to change an ethernet driver into a
> real-time one, a porting effort will always be required. Nevertheless,
> you could reduce this effort considerably and let most maintenance
> effort to linux' maintainer of each driver. Let me explain...
> While porting CAN driver to Xenomai I asked myself why there was no
> "linux skin". Don't laugh. That skin would have been similar to RTDM
> in purpose and would be have implemented a subset of linux interface
> for fops, tasks, queues,locks, etc. That skin would require some
> compiler, linker or loader magic to replace calls or re-bind symbols
> initially used by module to some RT replacement. A fine grained
> per-driver or per-subsystem symbol overloading approach could be also
> envisioned.
> Applying this to Ethernet drivers so that they become RTnet driver
> looks like possible, but bringing up such a pipe dream may require
> more effort that porting each driver individually. Your opinion ?

What makes things complicated are the unavoidable semantical differences
in the _use_ of whatever API. Specifically as long as there is no
PREEMPT-RT or, even better, mainline user with such requirements, it
will remain hard to maintain the required diffs.

>> It would be great to start this endeavor with implementing the Powerlink
>> MAC protocol inside RTnet. Just one question arises to me: How would the
>> programming model look like? PF_PACKET via sockets? Or some special
>> protocol, PF_POWERLINK?
> 
> If we keep CANopen as a userspace library, PF_PACKET should be enough.
> Application may have to open multiple sockets in order to distinguish
> packets sent in Isochronous phase (poll requests and responses) and
> those sent in Asynchronous phase. MAC discipline would guess what to

"guess" - that sounds scary in the context of RT... :)

> do with packets according to specified MAC addresses. In my sense a
> packet interface is what best fit as a CANopen library back-end.

So Powerlink simply uses a few Ethernet frame types, and we would simply
pass them to/from user space via PF_SOCKET? If that fits, it would be nice.

> 
>> When thinking further: If you move the node's object dictionary into
>> user space, you will also have to design a local interprocess
>> communication interface so that multiple processes can access it, right?
> This is perfectly true, and the only workaround is to have a special
> PF_POWERLINK or protocol, or even better,  PF_CANOPEN (for re-use in
> SocketCan). Problem is that I still don't see clearly how to implement
> CANopen through socket paradigm in a simple and efficient way.
> If the whole CANopen stack with object dictionary reside in kernel
> space it is not conceivable anymore to have a static dictionary
> implemented through generated C code. Would process(es) have to
> declare their own CANopen nodes and OD entries through socket API
> (with bind() and listen() ?). Or maybe could nodes and dictionary be
> constructed with network interfaces administration tools ?
> In the end I'm not sure at all that socket would be the right
> interface for object dictionary entries.... A virtual file system with
> mmap() and select() would certainly fit better.

Well, let's start small, maybe even only with single-process support
(ie. stuffing all the CANopen and high-level Powerlink stack into some
library). We can still evolve the approach once more demanding use cases
pop up, specifically as long as no special ABIs are set in stone.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 257 bytes --]

Re: [Xenomai-help] XUM 2009 follow-up : Powerlink, CANopen and sockets.

[Peter Puchwein]

Edouard TISSERANT wrote:
> Dear hackers,
> 
> I've been passing last month seeking for the best way to implement
> Powerlink with Xenomai. I still didn't find the absolute truth, and
> would like to confront my point of view.
> 
> In short, Powerlink is a kind of CANopen over polled ethernet.
> Powerlink re-use a subset of CANopen concepts for high level
> communications, whereas on the low level, a single master cyclically
> poll each node for data. As you can imagine, communication cycle is
> seriously influenced by each controlled node latency answering poll
> requests from master.
> 
> My intention is to write an efficient Powerlink implementation for
> Xenomai, but suitable for later reuse in future Real Time Linux
> implementation such as RT-PREEMPT. Discussing with RT-PREEMT gurus, I
> understood that re-using native Linux queues could never be a
> solution, as those queues induce way too long and unpredictable
> latencies for such real-time ethernet (those latencies also apply for
> SocketCan). Some software hook at ethernet driver level will be
> necessary to reroute RT-related packets directly to the concerned RT
> stack. With this approach, the whole stack would have to stay kernel
> side to reduce latency in answering poll requests. Implementing the
> whole CANopen stack kernel side is generally a bad idea, as it
> complicate access to object dictionary from application, usually in
> user space.
> 
> RTnet proves that Real-Time ethernet can be implemented through the
> socket paradigm. I believe that Time Division Medium Access (TDMA) of
> RTnet could be interchanged with polled ethernet medium access
> discipline from Powerlink. Thus, CANopen implementation part could
> stay user side, and could pre-fill answers to poll requests, avoiding
> long latencies. But what is the future of RTnet ? Will it be ported to
> RT-PREEMPT or will it enter official Xenomai tree ? Will available
> RTnet's drivers set continue to grow ? Would it be theoretically
> possible for RTnet to support Linux ethernet drivers through a hook
> mechanism as mentioned in previous paragraph ?
> 
> My feeling is that, yes, we should try to fit implementation of
> Powerlink data link layer inside RTnet as another MAC discipline, and
> use a modified version of CanFestival for CANopen aspects, keeping it
> a user space library. Please comment.
> 
> Best regards,
> 
> Edouard
> 


Hi Edouard,

we are successfully using the EtherCAT-Master (www.etherlab.org) with 
xenomai. We've choosen EtherCAT because of the high availability of 
components.
With the features CoE (Can over Ethercat) and EoE (Ethernet over 
Ethercat) you have a lot of possibilities.
Most common network drivers are already implemented for use with 
realtime implementations like Xenomai.

Peter

Re: [Xenomai-help] XUM 2009 follow-up : Powerlink, CANopen and sockets.

[Anders Blomdell]

Peter Puchwein wrote:
> Edouard TISSERANT wrote:
>> Dear hackers,
>>
>> I've been passing last month seeking for the best way to implement
>> Powerlink with Xenomai. I still didn't find the absolute truth, and
>> would like to confront my point of view.
>>
>> In short, Powerlink is a kind of CANopen over polled ethernet.
>> Powerlink re-use a subset of CANopen concepts for high level
>> communications, whereas on the low level, a single master cyclically
>> poll each node for data. As you can imagine, communication cycle is
>> seriously influenced by each controlled node latency answering poll
>> requests from master.
>>
>> My intention is to write an efficient Powerlink implementation for
>> Xenomai, but suitable for later reuse in future Real Time Linux
>> implementation such as RT-PREEMPT. Discussing with RT-PREEMT gurus, I
>> understood that re-using native Linux queues could never be a
>> solution, as those queues induce way too long and unpredictable
>> latencies for such real-time ethernet (those latencies also apply for
>> SocketCan). Some software hook at ethernet driver level will be
>> necessary to reroute RT-related packets directly to the concerned RT
>> stack. With this approach, the whole stack would have to stay kernel
>> side to reduce latency in answering poll requests. Implementing the
>> whole CANopen stack kernel side is generally a bad idea, as it
>> complicate access to object dictionary from application, usually in
>> user space.
>>
>> RTnet proves that Real-Time ethernet can be implemented through the
>> socket paradigm. I believe that Time Division Medium Access (TDMA) of
>> RTnet could be interchanged with polled ethernet medium access
>> discipline from Powerlink. Thus, CANopen implementation part could
>> stay user side, and could pre-fill answers to poll requests, avoiding
>> long latencies. But what is the future of RTnet ? Will it be ported to
>> RT-PREEMPT or will it enter official Xenomai tree ? Will available
>> RTnet's drivers set continue to grow ? Would it be theoretically
>> possible for RTnet to support Linux ethernet drivers through a hook
>> mechanism as mentioned in previous paragraph ?
>>
>> My feeling is that, yes, we should try to fit implementation of
>> Powerlink data link layer inside RTnet as another MAC discipline, and
>> use a modified version of CanFestival for CANopen aspects, keeping it
>> a user space library. Please comment.
>>
>> Best regards,
>>
>> Edouard
>>
> 
> 
> Hi Edouard,
> 
> we are successfully using the EtherCAT-Master (www.etherlab.org) with 
> xenomai. We've choosen EtherCAT because of the high availability of 
> components.
> With the features CoE (Can over Ethercat) and EoE (Ethernet over 
> Ethercat) you have a lot of possibilities.
> Most common network drivers are already implemented for use with 
> realtime implementations like Xenomai.
Beware that Beckhoff does not allow open-source implementations of the EtherCAT
stack, they require you to sign a "shared source license" that prohibits anybody
to use the code for any other purpose than a "standard compliant EtherCAT
master". We scrapped all our EtherCAT development (which was demonstrated at
JavaOne 2007) because of that very prohibitive license.

/Anders

-- 
Anders Blomdell                  Email: anders.blomdell@domain.hid
Department of Automatic Control
Lund University                  Phone:    +46 46 222 4625
P.O. Box 118                     Fax:      +46 46 138118
SE-221 00 Lund, Sweden

Re: [Xenomai-help] XUM 2009 follow-up : Powerlink, CANopen and sockets.

[Edouard TISSERANT]

Hello.

I agree, it is a shame for those patent holder to behave that way.
Sure they don't even understand the way they are killing their own
future business. Even more incredible is the weakness of the invention
claimed by those patents.

I also admit that Powerlink is far from being the smartest and more
efficient real time Ethernet implementation, but it have the advantage
to only require standard Ethernet controllers for both Masters and
Slaves.

Please, now, let's keep those problems out of that discussion, and
focus on the only Ethernet based fieldbus we can implement freely
without taking risk to be censored.

Edouard


2009/10/8 Anders Blomdell <anders.blomdell@domain.hid>:
> Peter Puchwein wrote:
>> Edouard TISSERANT wrote:
>>> Dear hackers,
>>>
>>> I've been passing last month seeking for the best way to implement
>>> Powerlink with Xenomai. I still didn't find the absolute truth, and
>>> would like to confront my point of view.
>>>
>>> In short, Powerlink is a kind of CANopen over polled ethernet.
>>> Powerlink re-use a subset of CANopen concepts for high level
>>> communications, whereas on the low level, a single master cyclically
>>> poll each node for data. As you can imagine, communication cycle is
>>> seriously influenced by each controlled node latency answering poll
>>> requests from master.
>>>
>>> My intention is to write an efficient Powerlink implementation for
>>> Xenomai, but suitable for later reuse in future Real Time Linux
>>> implementation such as RT-PREEMPT. Discussing with RT-PREEMT gurus, I
>>> understood that re-using native Linux queues could never be a
>>> solution, as those queues induce way too long and unpredictable
>>> latencies for such real-time ethernet (those latencies also apply for
>>> SocketCan). Some software hook at ethernet driver level will be
>>> necessary to reroute RT-related packets directly to the concerned RT
>>> stack. With this approach, the whole stack would have to stay kernel
>>> side to reduce latency in answering poll requests. Implementing the
>>> whole CANopen stack kernel side is generally a bad idea, as it
>>> complicate access to object dictionary from application, usually in
>>> user space.
>>>
>>> RTnet proves that Real-Time ethernet can be implemented through the
>>> socket paradigm. I believe that Time Division Medium Access (TDMA) of
>>> RTnet could be interchanged with polled ethernet medium access
>>> discipline from Powerlink. Thus, CANopen implementation part could
>>> stay user side, and could pre-fill answers to poll requests, avoiding
>>> long latencies. But what is the future of RTnet ? Will it be ported to
>>> RT-PREEMPT or will it enter official Xenomai tree ? Will available
>>> RTnet's drivers set continue to grow ? Would it be theoretically
>>> possible for RTnet to support Linux ethernet drivers through a hook
>>> mechanism as mentioned in previous paragraph ?
>>>
>>> My feeling is that, yes, we should try to fit implementation of
>>> Powerlink data link layer inside RTnet as another MAC discipline, and
>>> use a modified version of CanFestival for CANopen aspects, keeping it
>>> a user space library. Please comment.
>>>
>>> Best regards,
>>>
>>> Edouard
>>>
>>
>>
>> Hi Edouard,
>>
>> we are successfully using the EtherCAT-Master (www.etherlab.org) with
>> xenomai. We've choosen EtherCAT because of the high availability of
>> components.
>> With the features CoE (Can over Ethercat) and EoE (Ethernet over
>> Ethercat) you have a lot of possibilities.
>> Most common network drivers are already implemented for use with
>> realtime implementations like Xenomai.
> Beware that Beckhoff does not allow open-source implementations of the EtherCAT
> stack, they require you to sign a "shared source license" that prohibits anybody
> to use the code for any other purpose than a "standard compliant EtherCAT
> master". We scrapped all our EtherCAT development (which was demonstrated at
> JavaOne 2007) because of that very prohibitive license.
>
> /Anders
>
> --
> Anders Blomdell                  Email: anders.blomdell@control.lth.se
> Department of Automatic Control
> Lund University                  Phone:    +46 46 222 4625
> P.O. Box 118                     Fax:      +46 46 138118
> SE-221 00 Lund, Sweden
>



-- 
LOLITech
24, rue Pierre Evrat
88100 Saint-Dié des Vosges
tel: +33 3 29 57 60 42
mob: +33 6 10 49 76 41
edouard.tisserant@domain.hid
http://www.lolitech.fr

Re: [Xenomai-help] XUM 2009 follow-up : Powerlink, CANopen and sockets.

[Peter Puchwein]

Edouard TISSERANT wrote:
> Hello.
> 
> I agree, it is a shame for those patent holder to behave that way.
> Sure they don't even understand the way they are killing their own
> future business. Even more incredible is the weakness of the invention
> claimed by those patents.
> 
> I also admit that Powerlink is far from being the smartest and more
> efficient real time Ethernet implementation, but it have the advantage
> to only require standard Ethernet controllers for both Masters and
> Slaves.
> 
> Please, now, let's keep those problems out of that discussion, and
> focus on the only Ethernet based fieldbus we can implement freely
> without taking risk to be censored.
> 


I've talked with Beckhoff about these issues.

I think the problem is, to have a fieldbus-technology, that always stays 
compatible. If you don't have this instance we could get a technology 
with maybe non compatible components.
So it's very hard to get the right way here.
So the usage of the linux-based Ethercat implementations is completely 
free but Beckhoff want's to take care that EtherCAT products stay 
compatible so they have their own license you sign if you use the 
technology.
With this type of license the Opensource-Community is not happy I think, 
maybe of conflicts with the GPL.

So maybe they find a solution for this situation in the future.

Peter

Re: [Xenomai-help] XUM 2009 follow-up : Powerlink, CANopen and sockets.

[Wolfgang Denk]

Dear Peter Puchwein,

In message <4ACDA16B.70607@domain.hid> you wrote:
> 
> So the usage of the linux-based Ethercat implementations is completely 
> free but Beckhoff want's to take care that EtherCAT products stay 

This is not correct.

OSADL had long discussions with Beckhoff about that before OSADL
buried their ready to be released EtherCAT master stack.

> compatible so they have their own license you sign if you use the 
> technology.

Right, and this additional license requirements imposed by Beckhoff
prevents the use of EtherCAT in a GPL based contaxt (like the Linux
kernel).

> With this type of license the Opensource-Community is not happy I think, 
> maybe of conflicts with the GPL.

Indeed it it is a conflict with GPL.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@domain.hid
Single tasking: Just Say No.

Re: [Xenomai-help] XUM 2009 follow-up : Powerlink, CANopen and sockets.

[Anders Blomdell]

Edouard TISSERANT wrote:
> Hello.
> 
> I agree, it is a shame for those patent holder to behave that way.
> Sure they don't even understand the way they are killing their own
> future business. Even more incredible is the weakness of the invention
> claimed by those patents.
I was not even able to find anything in the patents that related to the master
side, but in this case better safe than sorry.

> I also admit that Powerlink is far from being the smartest and more
> efficient real time Ethernet implementation, but it have the advantage
> to only require standard Ethernet controllers for both Masters and
> Slaves.
I totally agree (thats probaly why there is a X20 system on my desk right now).

> Please, now, let's keep those problems out of that discussion, and
> focus on the only Ethernet based fieldbus we can implement freely
> without taking risk to be censored.
Will do, I just had to speak up so no-one else started putting code into a
project that couldn't legally be used anywhere. Looking forward on testing your
stuff.

/Anders

> 
> Edouard
> 
> 
> 2009/10/8 Anders Blomdell <anders.blomdell@domain.hid>:
>> Peter Puchwein wrote:
>>> Edouard TISSERANT wrote:
>>>> Dear hackers,
>>>>
>>>> I've been passing last month seeking for the best way to implement
>>>> Powerlink with Xenomai. I still didn't find the absolute truth, and
>>>> would like to confront my point of view.
>>>>
>>>> In short, Powerlink is a kind of CANopen over polled ethernet.
>>>> Powerlink re-use a subset of CANopen concepts for high level
>>>> communications, whereas on the low level, a single master cyclically
>>>> poll each node for data. As you can imagine, communication cycle is
>>>> seriously influenced by each controlled node latency answering poll
>>>> requests from master.
>>>>
>>>> My intention is to write an efficient Powerlink implementation for
>>>> Xenomai, but suitable for later reuse in future Real Time Linux
>>>> implementation such as RT-PREEMPT. Discussing with RT-PREEMT gurus, I
>>>> understood that re-using native Linux queues could never be a
>>>> solution, as those queues induce way too long and unpredictable
>>>> latencies for such real-time ethernet (those latencies also apply for
>>>> SocketCan). Some software hook at ethernet driver level will be
>>>> necessary to reroute RT-related packets directly to the concerned RT
>>>> stack. With this approach, the whole stack would have to stay kernel
>>>> side to reduce latency in answering poll requests. Implementing the
>>>> whole CANopen stack kernel side is generally a bad idea, as it
>>>> complicate access to object dictionary from application, usually in
>>>> user space.
>>>>
>>>> RTnet proves that Real-Time ethernet can be implemented through the
>>>> socket paradigm. I believe that Time Division Medium Access (TDMA) of
>>>> RTnet could be interchanged with polled ethernet medium access
>>>> discipline from Powerlink. Thus, CANopen implementation part could
>>>> stay user side, and could pre-fill answers to poll requests, avoiding
>>>> long latencies. But what is the future of RTnet ? Will it be ported to
>>>> RT-PREEMPT or will it enter official Xenomai tree ? Will available
>>>> RTnet's drivers set continue to grow ? Would it be theoretically
>>>> possible for RTnet to support Linux ethernet drivers through a hook
>>>> mechanism as mentioned in previous paragraph ?
>>>>
>>>> My feeling is that, yes, we should try to fit implementation of
>>>> Powerlink data link layer inside RTnet as another MAC discipline, and
>>>> use a modified version of CanFestival for CANopen aspects, keeping it
>>>> a user space library. Please comment.
>>>>
>>>> Best regards,
>>>>
>>>> Edouard
>>>>
>>>
>>> Hi Edouard,
>>>
>>> we are successfully using the EtherCAT-Master (www.etherlab.org) with
>>> xenomai. We've choosen EtherCAT because of the high availability of
>>> components.
>>> With the features CoE (Can over Ethercat) and EoE (Ethernet over
>>> Ethercat) you have a lot of possibilities.
>>> Most common network drivers are already implemented for use with
>>> realtime implementations like Xenomai.
>> Beware that Beckhoff does not allow open-source implementations of the EtherCAT
>> stack, they require you to sign a "shared source license" that prohibits anybody
>> to use the code for any other purpose than a "standard compliant EtherCAT
>> master". We scrapped all our EtherCAT development (which was demonstrated at
>> JavaOne 2007) because of that very prohibitive license.
>>
>> /Anders
>>
>> --
>> Anders Blomdell                  Email: anders.blomdell@domain.hid
>> Department of Automatic Control
>> Lund University                  Phone:    +46 46 222 4625
>> P.O. Box 118                     Fax:      +46 46 138118
>> SE-221 00 Lund, Sweden
>>
> 
> 
> 


-- 
Anders Blomdell                  Email: anders.blomdell@domain.hid
Department of Automatic Control
Lund University                  Phone:    +46 46 222 4625
P.O. Box 118                     Fax:      +46 46 138118
SE-221 00 Lund, Sweden