<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Word 14 (filtered medium)">
<!--[if !mso]><style>v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style><![endif]--><style><!--
/* Font Definitions */
@font-face
        {font-family:Wingdings;
        panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
        {font-family:Wingdings;
        panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
        {font-family:Tahoma;
        panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0cm;
        margin-bottom:.0001pt;
        font-size:11.0pt;
        font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:blue;
        text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
        {mso-style-priority:99;
        color:purple;
        text-decoration:underline;}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
        {mso-style-priority:99;
        mso-style-link:"Balloon Text Char";
        margin:0cm;
        margin-bottom:.0001pt;
        font-size:8.0pt;
        font-family:"Tahoma","sans-serif";}
span.BalloonTextChar
        {mso-style-name:"Balloon Text Char";
        mso-style-priority:99;
        mso-style-link:"Balloon Text";
        font-family:"Tahoma","sans-serif";}
span.EmailStyle19
        {mso-style-type:personal;
        font-family:"Calibri","sans-serif";
        color:windowtext;}
span.EmailStyle20
        {mso-style-type:personal;
        font-family:"Calibri","sans-serif";
        color:#1F497D;}
span.EmailStyle21
        {mso-style-type:personal;
        font-family:"Calibri","sans-serif";
        color:#1F497D;}
span.EmailStyle22
        {mso-style-type:personal-reply;
        font-family:"Calibri","sans-serif";
        color:#1F497D;}
.MsoChpDefault
        {mso-style-type:export-only;
        font-size:10.0pt;}
@page WordSection1
        {size:612.0pt 792.0pt;
        margin:3.0cm 2.0cm 3.0cm 2.0cm;}
div.WordSection1
        {page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1027" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="color:#1F497D">Hi Gavin,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">Thanks for the feed-back, I have in-lined some comments below.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">Mvh. Knud<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> Gavin Lambert [mailto:gavinl@compacsort.com]
<br>
<b>Sent:</b> 25. juni 2014 02:02<br>
<b>To:</b> Knud Baastrup<br>
<b>Cc:</b> etherlab-dev@etherlab.org<br>
<b>Subject:</b> RE: [etherlab-dev] Support for multiple mailbox protocols<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span lang="EN-NZ" style="color:#1F497D">Hi Knud,<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-NZ" style="color:#1F497D">I haven’t reviewed or tested the whole patch yet, but I like the idea in concept.  One thing that made me pause though is the way that the check_mbox flag is handled.  You have it protected by a
 semaphore (implying you’re expecting it to get used concurrently), but you have non-atomic test-and-then-set actions which will mean that if concurrent access is attempted multiple users might call prepare_check and check_mbox_set (causing some of them to
 be “lost”, which may or may not be a problem), and then on failure one might call check_mbox_clear while another is still waiting for a check to occur (which seems like it would be a problem).<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-NZ" style="color:#1F497D">[Knud] We have concurrent mailbox access due to the EoE Handlers running in a separate thread. I fully agree that it is a mistake that I have not used a test-and-set operation for the check_mbox
 flag and I will correct this in an updated patch.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-NZ" style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-NZ" style="color:#1F497D">Again, I haven’t followed the logic all the way through yet so possibly this isn’t a real problem, but it bothers me.
</span><span lang="EN-NZ" style="font-family:Wingdings;color:#1F497D">J</span><span lang="EN-NZ" style="color:#1F497D"><o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-NZ" style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-NZ" style="color:#1F497D">If the intent is to have only one concurrent state machine trigger a check datagram at a time (which it seems like it is), then you should probably be using an atomic test-and-set operation instead.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-NZ" style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-NZ" style="color:#1F497D">Additionally it doesn’t look like you have any protection against concurrent CoE access (which TBH I’m not entirely sure whether this occurs, but Frank’s patch 27 suggests it does), and I’m definitely
 not a fan of allocating/deallocating memory on each mailbox transfer, which is what it looks like you’re doing.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-NZ" style="color:#1F497D">[Knud] I believe that the check_mbox flag should work ok for concurrent CoE access as well (however, I can as well not see how this can happen?) as the check_mbox flag will ensure only one ongoing
 read request per slave no matter which mailbox protocol.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-NZ" style="color:#1F497D">[Knud] Each fetch data datagram is already allocating memory corresponding to the mailbox size so allocation memory is already heavily used. In my case, I know the payload size of the returned data,
 which in most cases is significantly smaller than the configured mailbox size and that is why I choose to allocate. In my test setup I have slaves with both 192 bytes and 1024 bytes mailboxes and yes I could as an alternative do a one-time allocation once
 the configured mailbox size is known (i.e. when slave configuration/scanning has finalized).<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-NZ" style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-NZ" style="color:#1F497D">Regards,<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-NZ" style="color:#1F497D">Gavin Lambert<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-NZ" style="color:#1F497D"><o:p> </o:p></span></p>
<div style="border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm 4.0pt">
<div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">
<a href="mailto:etherlab-dev-bounces@etherlab.org">etherlab-dev-bounces@etherlab.org</a> [<a href="mailto:etherlab-dev-bounces@etherlab.org">mailto:etherlab-dev-bounces@etherlab.org</a>]
<b>On Behalf Of </b>Knud Baastrup<br>
<b>Sent:</b> Wednesday, 25 June 2014 01:13<br>
<b>To:</b> <a href="mailto:etherlab-dev@etherlab.org">etherlab-dev@etherlab.org</a><br>
<b>Subject:</b> Re: [etherlab-dev] Support for multiple mailbox protocols<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><span lang="EN-NZ"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">Hi !<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">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).<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">Thanks,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">Knud Baastrup<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">
<a href="mailto:etherlab-dev-bounces@etherlab.org">etherlab-dev-bounces@etherlab.org</a> [<a href="mailto:etherlab-dev-bounces@etherlab.org">mailto:etherlab-dev-bounces@etherlab.org</a>]
<b>On Behalf Of </b>Knud Baastrup<br>
<b>Sent:</b> 23. juni 2014 14:27<br>
<b>To:</b> <a href="mailto:etherlab-dev@etherlab.org">etherlab-dev@etherlab.org</a><br>
<b>Subject:</b> [etherlab-dev] Support for multiple mailbox protocols<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Hello Florian, Gavin, Frank (and others facing the lack of support for multiple mailbox protocols)<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">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.
<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">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.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">I will in few lines try to summarize the patch:<o:p></o:p></p>
<p class="MsoNormal">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.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:6.0pt;font-family:"Arial","sans-serif";color:black"><br>
</span><span style="font-size:10.0pt;font-family:"Arial","sans-serif"">Venlig hilsen / Best regards,
<o:p></o:p></span></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><b><span style="font-size:10.0pt;font-family:"Arial","sans-serif";color:black">Knud Baastrup
<br>
</span></b><i><span style="font-size:10.0pt;font-family:"Arial","sans-serif";color:black">DEIF Wind Power Technology</span></i><span style="font-size:10.0pt;font-family:"Arial","sans-serif""><br>
<i><span style="color:black">SW Developer<o:p></o:p></span></i></span></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:7.5pt;font-family:"Arial","sans-serif";color:#4A575E">Direct.: +45 9614 8458</span><span style="font-size:7.5pt;font-family:"Arial","sans-serif";color:navy"><br>
</span><span style="font-size:7.5pt;font-family:"Arial","sans-serif";color:#4A575E">E-mail:
</span><span style="font-size:7.5pt;font-family:"Arial","sans-serif""><a href="mailto:kba@deif.com"><span style="color:#0563C1">kba@deif.com</span></a><span style="color:#4A575E"><br>
---------------------------------------------------------------</span></span><span style="font-size:10.0pt;font-family:"Arial","sans-serif";color:#1F497D"><o:p></o:p></span></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><!--[if gte vml 1]><v:shapetype id="_x0000_t75" coordsize="21600,21600" o:spt="75" o:preferrelative="t" path="m@4@5l@4@11@9@11@9@5xe" filled="f" stroked="f">
<v:stroke joinstyle="miter" />
<v:formulas>
<v:f eqn="if lineDrawn pixelLineWidth 0" />
<v:f eqn="sum @0 1 0" />
<v:f eqn="sum 0 0 @1" />
<v:f eqn="prod @2 1 2" />
<v:f eqn="prod @3 21600 pixelWidth" />
<v:f eqn="prod @3 21600 pixelHeight" />
<v:f eqn="sum @0 0 1" />
<v:f eqn="prod @6 1 2" />
<v:f eqn="prod @7 21600 pixelWidth" />
<v:f eqn="sum @8 21600 0" />
<v:f eqn="prod @7 21600 pixelHeight" />
<v:f eqn="sum @10 21600 0" />
</v:formulas>
<v:path o:extrusionok="f" gradientshapeok="t" o:connecttype="rect" />
<o:lock v:ext="edit" aspectratio="t" />
</v:shapetype><v:shape id="Picture_x0020_1" o:spid="_x0000_s1026" type="#_x0000_t75" style='position:absolute;margin-left:0;margin-top:0;width:31.6pt;height:68.25pt;z-index:251659264;visibility:visible;mso-wrap-style:square;mso-width-percent:0;mso-height-percent:0;mso-wrap-distance-left:9pt;mso-wrap-distance-top:0;mso-wrap-distance-right:9pt;mso-wrap-distance-bottom:0;mso-position-horizontal:left;mso-position-horizontal-relative:text;mso-position-vertical:absolute;mso-position-vertical-relative:text;mso-width-percent:0;mso-height-percent:0;mso-width-relative:page;mso-height-relative:page'>
<v:imagedata src="cid:image001.png@01CF904C.2BF0A860" o:title="" />
<w:wrap type="square"/>
</v:shape><![endif]--><![if !vml]><img width="42" height="91" src="cid:image002.png@01CF908E.454D66D0" align="left" hspace="12" v:shapes="Picture_x0020_1"><![endif]><span style="font-size:10.0pt;font-family:"Arial","sans-serif";color:#1F497D">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.<br>
V27 V39 V44 V47<o:p></o:p></span></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><u><span style="font-size:10.0pt;font-family:"Arial","sans-serif";color:blue"><a href="http://www.deifwindpower.com/retrofit.aspx?utm_source=Retrofit&utm_medium=email%20signatur&utm_term=Retrofit%2BVestas%2BCOTAS&utm_content=textlink&utm_campaign=Retrofit"><span style="color:#0563C1">Read
 more about DEIF’s solutions to retrofit your turbines on our website</span></a></span></u><span style="font-size:10.0pt;font-family:"Arial","sans-serif";color:#1F497D"><o:p></o:p></span></p>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
</body>
</html>