[etherlab-dev] Support for multiple mailbox protocols

Knud Baastrup kba at deif.com
Tue Jun 24 15:13:09 CEST 2014


Hi !

I just discovered that the provided patch included a hardcoded mailbox size that I have now replaced with a dynamic allocated buffer. I have attached a new patch (ethercat_152_stable_mailbox_1.patch) that fully replaces the prior patch (ethercat_152_stable_mailbox.patch).

Thanks,

Knud Baastrup


From: etherlab-dev-bounces at etherlab.org [mailto:etherlab-dev-bounces at etherlab.org] On Behalf Of Knud Baastrup
Sent: 23. juni 2014 14:27
To: etherlab-dev at etherlab.org
Subject: [etherlab-dev] Support for multiple mailbox protocols

Hello Florian, Gavin, Frank (and others facing the lack of support for multiple mailbox protocols)


I have like Frank Heckenbach and Gavin also struggled with the lack of support for multiple mailbox protocols and came up with an alternative solution to the one provided by Frank in patch 9-10-11.

I have attached the patch that is based on the stable-1.5 branch. The patch should support all the mailbox protocols, but has only been tested with CoE, EoE and FoE.

I will in few lines try to summarize the patch:
In this patch I accept that a mailbox read request (e.g. FP-RD) for a given mailbox protocol can return data from any other mailbox protocol running at the same time. The data returned by a read datagram is therefore stored in a separate buffer for each mailbox protocol instead of the datagram data buffer. The mailbox state machines will check and fetch the data from their own buffer instead of the datagram buffer (that is no longer used for mailbox read data). A check_mbox flag is introduced to track when a given slave has an ongoing mailbox read request. In normal case the mailbox state machine will run as previously if no mailbox read request is ongoing, but if a mailbox read-request is ongoing (check_mbox flag is set) it will check its own mailbox buffer (as the ongoing mailbox read request might have returned its data) and otherwise wait until the read request is done and it gets the opportunity to reserve the mailbox for its own read request.


Venlig hilsen / Best regards,
Knud Baastrup
DEIF Wind Power Technology
SW Developer
Direct.: +45 9614 8458
E-mail: kba at deif.com<mailto:kba at deif.com>
---------------------------------------------------------------
[cid:image003.png at 01CF8FBE.261DF750]Retrofit your Vestas COTAS controller and optimize availability that will improve your annual energy generation, reduce service cost and extend the lifetime of your turbine.
V27 V39 V44 V47
Read more about DEIF's solutions to retrofit your turbines on our website<http://www.deifwindpower.com/retrofit.aspx?utm_source=Retrofit&utm_medium=email%20signatur&utm_term=Retrofit%2BVestas%2BCOTAS&utm_content=textlink&utm_campaign=Retrofit>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.etherlab.org/pipermail/etherlab-dev/attachments/20140624/fa15f8d4/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 3536 bytes
Desc: image001.png
URL: <http://lists.etherlab.org/pipermail/etherlab-dev/attachments/20140624/fa15f8d4/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.png
Type: image/png
Size: 2940 bytes
Desc: image003.png
URL: <http://lists.etherlab.org/pipermail/etherlab-dev/attachments/20140624/fa15f8d4/attachment-0003.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ethercat_152_stable_mailbox_1.patch
Type: application/octet-stream
Size: 90667 bytes
Desc: ethercat_152_stable_mailbox_1.patch
URL: <http://lists.etherlab.org/pipermail/etherlab-dev/attachments/20140624/fa15f8d4/attachment-0001.obj>


More information about the etherlab-dev mailing list