[etherlab-dev] EoE IP command patch

[Gavin Lambert]

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.)

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.

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.


Gavin Lambert
Senior Software Developer

[cid:logo_compac_5dcf97ef-52f5-498c-8b9b-728410ddffaf.png]
[cid:compacicon_82e8a8c7-154a-4a32-9720-a5badb6258e0.png]<http://www.compacsort.com> [cid:facebook_fa85b924-53b9-45cc-8162-0564f64ec3a3.png] <https://www.facebook.com/Compacsort>  [cid:linkedin_4ec016ad-84fa-443c-85a3-b9615a4ccef8.png] <https://www.linkedin.com/company/compac-sorting-equipment/>  [cid:youtube_32142163-fc27-4aed-b14d-e8a377f98a6d.png] <https://vimeo.com/compacsort>  [cid:twitter_d89338d8-98c8-4b65-9a9e-7b1333160b0d.png] <https://twitter.com/compacsort>

COMPAC SORTING EQUIPMENT LTD | 4 Henderson Pl | Onehunga | Auckland 1061 | New Zealand
Switchboard: +64 96 34 00 88 | tomra.com<http://www.tomra.com>

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.

From: Graeme Foot
Sent: Thursday, 7 February 2019 10:35
To: etherlab-dev at etherlab.org
Subject: [etherlab-dev] EoE IP command patch

Hi,

FYI, I've updated my EoE patches and added a new one.

0001-eoe-addif-delif-tools.patch

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.


0002-eoe-via-rtdm.patch

Line number changes due to the above patch.


0003-eoe-ip.patch

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.

To resolve this I have created two EoE mailbox reply caches.  One for the EoE frame thread and one for the ip command.

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.


Regards,
Graeme Foot.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.etherlab.org/pipermail/etherlab-dev/attachments/20190712/6dd033c9/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: logo_compac_5dcf97ef-52f5-498c-8b9b-728410ddffaf.png
Type: image/png
Size: 11438 bytes
Desc: logo_compac_5dcf97ef-52f5-498c-8b9b-728410ddffaf.png
URL: <http://lists.etherlab.org/pipermail/etherlab-dev/attachments/20190712/6dd033c9/attachment-0006.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: compacicon_82e8a8c7-154a-4a32-9720-a5badb6258e0.png
Type: image/png
Size: 1629 bytes
Desc: compacicon_82e8a8c7-154a-4a32-9720-a5badb6258e0.png
URL: <http://lists.etherlab.org/pipermail/etherlab-dev/attachments/20190712/6dd033c9/attachment-0007.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: facebook_fa85b924-53b9-45cc-8162-0564f64ec3a3.png
Type: image/png
Size: 1750 bytes
Desc: facebook_fa85b924-53b9-45cc-8162-0564f64ec3a3.png
URL: <http://lists.etherlab.org/pipermail/etherlab-dev/attachments/20190712/6dd033c9/attachment-0008.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: linkedin_4ec016ad-84fa-443c-85a3-b9615a4ccef8.png
Type: image/png
Size: 1855 bytes
Desc: linkedin_4ec016ad-84fa-443c-85a3-b9615a4ccef8.png
URL: <http://lists.etherlab.org/pipermail/etherlab-dev/attachments/20190712/6dd033c9/attachment-0009.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: youtube_32142163-fc27-4aed-b14d-e8a377f98a6d.png
Type: image/png
Size: 1970 bytes
Desc: youtube_32142163-fc27-4aed-b14d-e8a377f98a6d.png
URL: <http://lists.etherlab.org/pipermail/etherlab-dev/attachments/20190712/6dd033c9/attachment-0010.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: twitter_d89338d8-98c8-4b65-9a9e-7b1333160b0d.png
Type: image/png
Size: 20278 bytes
Desc: twitter_d89338d8-98c8-4b65-9a9e-7b1333160b0d.png
URL: <http://lists.etherlab.org/pipermail/etherlab-dev/attachments/20190712/6dd033c9/attachment-0011.png>