[etherlab-dev] EoE IP command patch

Fri Jul 12 04:18:34 CEST 2019

Hi,

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

So the idea is that if you are using RTDM, you basically can't have callback locking.

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.

By default the master sets master->send_cb = ec_master_internal_send_cb
ec_master_internal_send_cb calls ecrt_master_send_ext()

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

Apart from that there's also a comment in my patch header:
Have also removed some send_cb and receive_cb calls as they look like they are creating a loop

But I don't remember what that was all about.

Regards,
Graeme.

From: Gavin Lambert <gavin.lambert at tomra.com>
Sent: Friday, 12 July 2019 1:08 PM
To: Graeme Foot <Graeme.Foot at touchcut.com>; etherlab-dev at etherlab.org
Subject: RE: EoE IP command patch

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:image001.png at 01D538B5.07AD1F80]
[TOMRA]<http://www.compacsort.com>[Facebook]<https://www.facebook.com/Compacsort>[Linkedin]<https://www.linkedin.com/company/compac-sorting-equipment/>[Youtube]<https://vimeo.com/compacsort>[twitter]<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<mailto: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/1789c40e/attachment-0003.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 11438 bytes
Desc: image001.png
URL: <http://lists.etherlab.org/pipermail/etherlab-dev/attachments/20190712/1789c40e/attachment-0030.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 1629 bytes
Desc: image002.png
URL: <http://lists.etherlab.org/pipermail/etherlab-dev/attachments/20190712/1789c40e/attachment-0031.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.png
Type: image/png
Size: 1750 bytes
Desc: image003.png
URL: <http://lists.etherlab.org/pipermail/etherlab-dev/attachments/20190712/1789c40e/attachment-0032.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image004.png
Type: image/png
Size: 1855 bytes
Desc: image004.png
URL: <http://lists.etherlab.org/pipermail/etherlab-dev/attachments/20190712/1789c40e/attachment-0033.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image005.png
Type: image/png
Size: 1970 bytes
Desc: image005.png
URL: <http://lists.etherlab.org/pipermail/etherlab-dev/attachments/20190712/1789c40e/attachment-0034.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image006.png
Type: image/png
Size: 20278 bytes
Desc: image006.png
URL: <http://lists.etherlab.org/pipermail/etherlab-dev/attachments/20190712/1789c40e/attachment-0035.png>