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@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.
_______________________________________________ etherlab-dev mailing list etherlab-dev@etherlab.org http://lists.etherlab.org/mailman/listinfo/etherlab-dev
