<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 15 (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:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;
mso-fareast-language:EN-US;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:#0563C1;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:#954F72;
text-decoration:underline;}
p.msonormal0, li.msonormal0, div.msonormal0
{mso-style-name:msonormal;
mso-margin-top-alt:auto;
margin-right:0cm;
mso-margin-bottom-alt:auto;
margin-left:0cm;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
span.EmailStyle18
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EmailStyle19
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EmailStyle23
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</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-NZ" link="#0563C1" vlink="#954F72">
<div class="WordSection1">
<p class="MsoNormal">Hi,<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">In general, and in my case, the whole point of using RTDM is so that you don't need or want to have any kernel level stubs / apps. Also kernel level locking isn't transferable up to user space (without a lot of headaches).<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">So the idea is that if you are using RTDM, you basically can't have callback locking.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Also, patch "base/0018-Use-call-back-function.patch" subverted the use of the callback functions in ec_ioctl_send() and ec_ioctl_receive() away from what the vanilla EtherLab master intended (in my opinion, there's a bunch of dev forum
emails about it). This sort of suits non-RTDM installations (i.e. RT-PREEMPT). There are various people now using this (in non-RTDM instances) hence the defines.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">By default the master sets master->send_cb = ec_master_internal_send_cb<o:p></o:p></p>
<p class="MsoNormal">ec_master_internal_send_cb calls ecrt_master_send_ext()<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">From RTDM you want to call the real ecrt_master_send(), not ecrt_master_send_ext(). And you especially want to avoid calling any locking on the master semiphores.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Apart from that there's also a comment in my patch header:<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:36.0pt"><span style="mso-fareast-language:EN-NZ">Have also removed some send_cb and receive_cb calls as they look like they are creating a loop<o:p></o:p></span></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">But I don't remember what that was all about.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Regards,<o:p></o:p></p>
<p class="MsoNormal">Graeme.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span lang="EN-US" style="mso-fareast-language:EN-NZ">From:</span></b><span lang="EN-US" style="mso-fareast-language:EN-NZ"> Gavin Lambert <gavin.lambert@tomra.com>
<br>
<b>Sent:</b> Friday, 12 July 2019 1:08 PM<br>
<b>To:</b> Graeme Foot <Graeme.Foot@touchcut.com>; etherlab-dev@etherlab.org<br>
<b>Subject:</b> RE: EoE IP command patch<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Regarding patch 0002, I’m curious why the callbacks are being disabled for the RTDM case. (master/ioctl.c) (And note that EC_EOE is enabled by default, so this will affect most RTDM users.)<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">As I understand it (although I might be wrong), the callbacks are expressly intended for use with RTAI/Xenomai apps, so that you can make it use an RTAI/Xenomai lock instead of a Linux lock (or defer sending/receiving entirely to another
cycle, if you’re busy and don’t want to lock). It does require either a kernel-space app or at least a stub that implements a suitable locking model -- user-space applications will always have NULL callbacks and would thus behave the same as if this part
of your patch had never been applied.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Since the ec_ioctl_* locks are automatically disabled for RTDM, the change you’re suggesting in this patch completely disables any possibility of locking/deferral at all for RTDM apps, which seems a bit odd, since AFAIK that’s the only
reason that the callbacks exist in the first place.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p><strong><span style="font-family:"Calibri",sans-serif;color:#595959">Gavin Lambert</span></strong><b><span style="color:#595959"><br>
</span></b><span style="color:#595959">Senior Software Developer<o:p></o:p></span></p>
<table class="MsoNormalTable" border="0" cellpadding="0">
<tbody>
<tr>
<td style="padding:.75pt .75pt .75pt .75pt"></td>
</tr>
</tbody>
</table>
<p><span style="font-size:10.0pt;font-family:"Arial",sans-serif"><img width="360" height="102" style="width:3.75in;height:1.0625in" id="_x0000_i1025" src="cid:image001.png@01D538B5.07AD1F80"><br>
<a href="http://www.compacsort.com"><span style="text-decoration:none"><img border="0" width="33" height="37" style="width:.3437in;height:.3854in" id="_x0000_i1026" src="cid:image002.png@01D538B5.07AD1F80" alt="TOMRA"></span></a><a href="https://www.facebook.com/Compacsort"><span style="text-decoration:none"><img border="0" width="35" height="37" style="width:.3645in;height:.3854in" id="_x0000_i1027" src="cid:image003.png@01D538B5.07AD1F80" alt="Facebook"></span></a><a href="https://www.linkedin.com/company/compac-sorting-equipment/"><span style="text-decoration:none"><img border="0" width="35" height="37" style="width:.3645in;height:.3854in" id="_x0000_i1028" src="cid:image004.png@01D538B5.07AD1F80" alt="Linkedin"></span></a><a href="https://vimeo.com/compacsort"><span style="text-decoration:none"><img border="0" width="37" height="37" style="width:.3854in;height:.3854in" id="_x0000_i1029" src="cid:image005.png@01D538B5.07AD1F80" alt="Youtube"></span></a><a href="https://twitter.com/compacsort"><span style="text-decoration:none"><img border="0" width="33" height="37" style="width:.3437in;height:.3854in" id="_x0000_i1030" src="cid:image006.png@01D538B5.07AD1F80" alt="twitter"></span></a><o:p></o:p></span></p>
<p><b><span style="font-size:8.5pt;color:#595959">COMPAC SORTING EQUIPMENT LTD</span></b><span style="font-size:8.5pt;color:#595959"> | 4 Henderson Pl | Onehunga | Auckland 1061 | New Zealand<br>
Switchboard: +64 96 34 00 88 | <a href="http://www.tomra.com">tomra.com</a> <o:p>
</o:p></span></p>
<table class="MsoNormalTable" border="0" cellspacing="0" cellpadding="0" style="border-collapse:collapse">
<tbody>
<tr>
<td valign="top" style="border-top:solid #595959 1.0pt;border-left:none;border-bottom:solid #595959 1.0pt;border-right:none;padding:0cm 0cm 0cm 0cm">
<p><span style="font-size:8.5pt;color:#595959">The information contained in this communication and any attachment is confidential and may be legally privileged. It should only be read by the person(s) to whom it is addressed. If you have received this communication
in error, please notify the sender and delete the communication. <o:p></o:p></span></p>
</td>
</tr>
</tbody>
</table>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span lang="EN-US" style="mso-fareast-language:EN-NZ">From:</span></b><span lang="EN-US" style="mso-fareast-language:EN-NZ"> Graeme Foot<br>
<b>Sent:</b> Thursday, 7 February 2019 10:35<br>
<b>To:</b> <a href="mailto:etherlab-dev@etherlab.org">etherlab-dev@etherlab.org</a><br>
<b>Subject:</b> [etherlab-dev] EoE IP command patch<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Hi,<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">FYI, I've updated my EoE patches and added a new one.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><b>0001-eoe-addif-delif-tools.patch<o:p></o:p></b></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">This has been updated so that if the "eoe_autocreate" flag is 1 (true) then static "eoe_interfaces" can still be used, resulting in a combination of static and dynamic EoE ifaces. I'm doing this so I can have static iface ports for my
switch devices (EL6601, EL6614 modules) and dynamic iface ports for my Yaskawa sigma 7 amps which support configuration via EoE.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><b>0002-eoe-via-rtdm.patch<o:p></o:p></b></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Line number changes due to the above patch.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><b>0003-eoe-ip.patch<o:p></o:p></b></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">This is a new patch to fix some EoE bugs to do with the "ethercat ip" command. The ip command allows you to set the MAC, IP address, subnet mask, gateway, DNS server and name on an EoE device. This command was returning errors saying
it had timed out. This was due to the EoE frame thread receiving and dropping the reply from the ip command. I'm not sure if this became a problem due to the mailbox patches or whether it would have been a problem anyway. Note: the ip command would also
drop mailbox replies that were meant to go to the EoE frame thread handler.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">To resolve this I have created two EoE mailbox reply caches. One for the EoE frame thread and one for the ip command.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Secondly the EtherCAT master was packing the ip command data, so if an item was not being set subsequent items would not leave a space for it and dynamically sizing the data structure. The ETG.1000.6 standard shows the ip command (EoE
Init Request) data structure requires the data to have fixed positions and to leave space for unused items. It is also a fixed size. I have confirmed this with Beckhoff.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Regards,<o:p></o:p></p>
<p class="MsoNormal">Graeme Foot.<o:p></o:p></p>
</div>
</body>
</html>