[etherlab-dev] Multiple mailbox protocols and other issues

[Knud Baastrup]

Hello Florian, Gavin, Frank and others

I have attached the complete list of patches that we use for our IgH EtherCAT master:

Patch 1 (ethercat_152_patch_1_eoe.patch):
Ensures that we use the call back functions (with io lock support) when using the IOCTL interface.

Patch 2 (ethercat_152_patch_2_foe.patch):
Wrong datagram used for timeout calculation.

Patch 3 (ethercat_152_patch_3_lrw_datagram.patch):
Input/Output counter were not incremented if new datagram were allocated.
Patch 4 (ethercat_152_patch_4_eoe_mac.patch)
Change the MAC address for eoe0sY devices to real local administrated MAC addresses based on the NIC part of eth0 and the EoE slaves ring position.

Patch 5 (ethercat_152_patch_5_priority_inheritance.patch)
Replaced semaphores with mutexes to utilize priority inheritance and limit impact from lower priority tasks (EtherCAT-EOE) running as sched_other task.

Patch 6 (ethercat_152_patch_6_mailbox.patch)
Alternative solution to Patch 9-10-11 provided by Frank Heckenbach for 1.5.0 (that I did not succeed to get up running on 1.5.2). In this solution 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.

Patch 7 (ethercat_152_patch_7_sdoinfo.patch)
Alternative solution to Patch 28 provided by Frank Heckenback for 1.5.0. More simple but without the same user feed-back.

Patch 8 (ethercat_152_patch_8_ext_queue_protect.patch)
It is due to the usage of the call back function added in Patch 1 also very important to secure protection of the external datagram queue. Also discovered by Frank Heckenback in Patch 23.

Patch 9 (ethercat_152_patch_9_clear_mailbox.patch)
A slightly modified version of Patch 26 provided by Frank Heckenback. The required modification were needed due to the alternative multiple mailbox protocol solution provided in Patch 6.

Patch 10 (ethercat_152_patch_10_scan_skip_stats.patch)
No reason to write output statistics in syslog when issuing a slave scanning where UNMATCHED datagrams are expected behavior.


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:image002.png at 01CF9C58.9B9CBFB0]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/20140710/b3e9958c/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/20140710/b3e9958c/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 2940 bytes
Desc: image002.png
URL: <http://lists.etherlab.org/pipermail/etherlab-dev/attachments/20140710/b3e9958c/attachment-0003.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ethercat_152_patches.tar.gz
Type: application/x-gzip
Size: 26942 bytes
Desc: ethercat_152_patches.tar.gz
URL: <http://lists.etherlab.org/pipermail/etherlab-dev/attachments/20140710/b3e9958c/attachment-0001.bin>