Re: [etherlab-dev] Multiple mailbox protocols and other issues

From: etherlab-dev [mailto:etherlab-dev-boun...@etherlab.org] On Behalf Of Gavin Lambert > On 2 February 2015 20:18, quoth Knud Baastrup: > > 16_improved_ethercat_rescan_performance.patch: > > The SII data and PDOs will now be stored when the EtherCAT master is > > in > its > > operation phase. T

Re: [etherlab-dev] How to send the data EC-Master to EC-Slave by using program

Hi, This may be of help to you: http://lists.etherlab.org/pipermail/etherlab-users/2014/002645.html http://lists.etherlab.org/pipermail/etherlab-users/2014/002647.html Graeme. From: etherlab-dev [mailto:etherlab-dev-boun...@etherlab.org] On Behalf Of veeranjaneyulu Sent: Friday, 20 February 20

Re: [etherlab-dev] [QUARANTINE] [PATCH] My patchset roundup July 2015

Hi, Re: gavinl-2004-sdo_write_size. What I have been doing to allow one SDO Request object for all data sizes is to call ecrt_sdo_request_read() every time before calling ecrt_sdo_request_write(). This sets the size specific to the object you are about to write at the expense of extra time an

Re: [etherlab-dev] Possible Realtime Issues with Ethercat Master and RT Preempt Kernel

Hi, Just a thought for the day, how many EtherCAT slaves do you have and what's the last slaves "DC system time transmission delay"? Use the command "ethercat slaves -v" and check the last slaves "DC system time transmission delay" value. If you have a linear topology then the complete wire t

Re: [etherlab-dev] Possible Realtime Issues with Ethercat Master and RT Preempt Kernel

lman, Scott [mailto:scott.till...@bhemail.com] Sent: Wednesday, 3 February 2016 9:02 p.m. To: Graeme Foot; Dr.-Ing. Matthias Schöpfer; etherlab-dev@etherlab.org Subject: RE: [etherlab-dev] Possible Realtime Issues with Ethercat Master and RT Preempt Kernel Hi Graeme, Since you brought up the typi

Re: [etherlab-dev] Possible Realtime Issues with Ethercat Master and RT Preempt Kernel

a.m. To: 'Tillman, Scott'; Graeme Foot; Dr.-Ing. Matthias Schöpfer; etherlab-dev@etherlab.org Subject: RE: [etherlab-dev] Possible Realtime Issues with Ethercat Master and RT Preempt Kernel On 3 February 2016 21:02, quoth Tillman, Scott: > Since you brought up the typical process cycle

Re: [etherlab-dev] [PATCH] Default branch patchset

Sent: Wednesday, 4 May 2016 11:13 a.m. To: Graeme Foot Subject: RE: [etherlab-dev] [PATCH] Default branch patchset On Wednesday, 4 May 2016 10:55, quoth Graeme Foot: > Are you interested in a patch that can read the SII information for a slave from > disk (if the slave has SII problems)? &g

Re: [etherlab-dev] DC synchronous question

Hi, This question is more for the etherlab-users forum (etherlab-us...@etherlab.org). The question is a couple of weeks old but I haven't noticed any responses so I'll give you a few things to start looking at. You need to do a few things with EtherCAT Dist

Re: [etherlab-dev] "Master still waiting for devices!" problem.

I can think of four possible errors at the moment: 1) Your ethercat configuration file isn't matching the correct MAC address. In /etc/sysconfig/ethercat you have "MASTER0_DEVICE="ff:ff:ff:ff:ff:ff"". ff:ff:ff:ff:ff:ff matches the first available device, looking at devices in the order the d

Re: [etherlab-dev] "Master still waiting for devices!" problem.

Hi, My CX2100 patch is attached. Graeme. From: 周甫霖 Sent: Thursday, 19 January 2017 4:14:33 PM To: Graeme Foot Cc: etherlab-dev@etherlab.org Subject: Re: [etherlab-dev] "Master still waiting for devices!" problem. Hi Graeme, I think that 1) and 2

Re: [etherlab-dev] Pre-announcement: unofficial patchset update (Gavin Lambert)

d_reference_slave_clock_64bit_time.patch) It takes a fair bit of time creating and maintaining patches so everyone's effort has been much appreciated. Regards, Graeme Foot -Original Message- From: etherlab-dev [mailto:etherlab-dev-boun...@etherlab.org] On Behalf Of Knud Baastru

Re: [etherlab-dev] Pre-announcement: unofficial patchset update (Gavin Lambert)

> > Mere moments ago, quoth I: > > On 28 April 2017 11:59, quoth Graeme Foot: > > > 2) Your 0054 patch successfully moved the slave sdo request processing > > > from the master fsm's idle state to be called every cycle of the master > > > thread. >

[etherlab-dev] EoE patchs and questions

have found that if I send the command below the receive mailbox starts to function again (until it doesn't): ethercat reg_write -p3 0x808 -tuint64 0 Has anyone else come across this? At the moment I suspecting a Slave firmware bug (EL6614). Does anyone have any other ideas? Regar

Re: [etherlab-dev] EoE patchs and questions

. Thanks, Graeme. From: Gavin Lambert Sent: Friday, 16 February 2018 7:47:17 PM To: Graeme Foot; etherlab-dev@etherlab.org Subject: RE: EoE patchs and questions Those sound like great changes to have. I suspect the EoE-OP thing came from an assumption that the slave

Re: [etherlab-dev] ec_lock_* vs. ec_ioctl_lock in master/ioctl.c

when compiling to enable RTDM (and compile rtdm-ioctl.o). So in summary: ec_ioctl_lock_up() and ec_ioctl_lock_down_interruptible() are for the hard realtime loop function calls, otherwise use the standard lock calls. Regards, Graeme Foot -Original Message- From: etherlab-dev

Re: [etherlab-dev] EoE patchs and questions

> -Original Message- > From: Esben Haabendal [mailto:esbenhaaben...@gmail.com] On Behalf Of Esben > Haabendal > Sent: Thursday, 1 March 2018 2:02 AM > To: Graeme Foot > Cc: etherlab-dev@etherlab.org > Subject: Re: [etherlab-dev] EoE patchs and questions > >

Re: [etherlab-dev] ec_lock_* vs. ec_ioctl_lock in master/ioctl.c

> -Original Message- > From: Esben Haabendal [mailto:esbenhaaben...@gmail.com] On Behalf Of Esben > Haabendal > Sent: Wednesday, 28 February 2018 8:23 PM > To: Graeme Foot > Cc: etherlab-dev@etherlab.org > Subject: Re: [etherlab-dev] ec_lock_* vs. ec_ioctl_l

Re: [etherlab-dev] ec_lock_* vs. ec_ioctl_lock in master/ioctl.c

> From: Esben Haabendal [mailto:esbenhaaben...@gmail.com] On Behalf Of Esben > Haabendal > > >> Graeme Foot writes: > >> > >> > The ec_ioctl_lock_up() and ec_ioctl_lock_down_interruptible() calls > >> > were added to protect the following fun

Re: [etherlab-dev] EoE patchs and questions

aaben...@gmail.com] On Behalf Of Esben Haabendal Sent: Friday, 2 March 2018 10:50 PM To: Graeme Foot Cc: etherlab-dev@etherlab.org Subject: Re: [etherlab-dev] EoE patchs and questions Graeme Foot writes: >> -Original Message- >> From: Esben Haabendal [mailto:esbenhaaben...@gmail.

Re: [etherlab-dev] ec_lock_* vs. ec_ioctl_lock in master/ioctl.c

Hi, The email's getting a little hard to read so I'll try to summarise what I'm doing here first and reply to specifics below. The primary problem with RTAI is that you cannot use Linux locks in RTAI hard realtime calls. So the base 0017 and 0018 patches are useless for RTAI. Secondly RTAI /

Re: [etherlab-dev] Community contribution

Hi, I would also be interested in an etherlab related ethercat conference, but it's unlikely that I would be able to get to it. I'm based in New Zealand. My best chance of getting to that part of the world (though very small) is that I could be able to go to Hannover Messe in 2019, though that

Re: [etherlab-dev] ec_lock_* vs. ec_ioctl_lock in master/ioctl.c

user space applications. Regards, Graeme. -Original Message- From: etherlab-dev [mailto:etherlab-dev-boun...@etherlab.org] On Behalf Of Graeme Foot Sent: Tuesday, 6 March 2018 1:40 PM To: Esben Haabendal Cc: etherlab-dev@etherlab.org Subject: Re: [etherlab-dev] ec_lock_* vs

Re: [etherlab-dev] ec_lock_* vs. ec_ioctl_lock in master/ioctl.c

Hi, I found a couple of bugs in my patches. New patches attached. Graeme. -Original Message- From: etherlab-dev [mailto:etherlab-dev-boun...@etherlab.org] On Behalf Of Graeme Foot Sent: Wednesday, 7 March 2018 10:53 AM To: Gavin Lambert Cc: etherlab-dev@etherlab.org Subject: Re

Re: [etherlab-dev] ec_lock_* vs. ec_ioctl_lock in master/ioctl.c

s. Graeme. -Original Message- From: Koch Daniel [mailto:d...@paul.eu] On Behalf Of PAUL-SOFTWARE Sent: Friday, 18 May 2018 6:33 PM To: Graeme Foot Subject: AW: [etherlab-dev] ec_lock_* vs. ec_ioctl_lock in master/ioctl.c Hi Graeme, may i ask on which revision/patch-set the patch

Re: [etherlab-dev] Missing Vendor ID / Product Code

ything dodgy with it. Graeme. From: Gavin Lambert Sent: Wednesday, 8 August 2018 3:13 PM To: Graeme Foot ; etherlab-us...@etherlab.org Subject: RE: Missing Vendor ID / Product Code There’s lots of things that can cause that. Most often, I’ve seen this when packets get lost or corrupted, so t

Re: [etherlab-dev] Missing Vendor ID / Product Code

etry.patch Regards, Graeme Foot. From: etherlab-dev On Behalf Of Graeme Foot Sent: Friday, 12 October 2018 11:38 AM To: Gavin Lambert ; etherlab-dev@etherlab.org Subject: Re: [etherlab-dev] Missing Vendor ID / Product Code Hi, I've had a chance to play with my testrig and have managed to co

Re: [etherlab-dev] Missing Vendor ID / Product Code

use it until their turn comes up. In these cases if ec_read_mbox_locked() fails the datagram state is also set to EC_DATAGRAM_INVALID so the patch should also cover this case. Regards, Graeme. From: etherlab-dev On Behalf Of Graeme Foot Sent: Monday, 4 March 2019 2:36 PM To: etherlab-de

Re: [etherlab-dev] Missing Vendor ID / Product Code

datagram queue has the issue due to not abandoning the fsm, but also not using the datagram. My patch will plug that hole now by not incrementing the queue index if the datagram is not used (if flagged with EC_DATAGRAM_INVALID). Regards, Graeme. From: Gavin Lambert Sent: Tuesday, 11 June 2019

Re: [etherlab-dev] Missing Vendor ID / Product Code

's more of an issue after the parallel-slave patches as you initialise more modules sooner so it's more likely to happen. Cheers, Graeme. From: Gavin Lambert Sent: Tuesday, 11 June 2019 12:41 PM To: Graeme Foot ; etherlab-dev@etherlab.org Subject: RE: Missing Vendor ID / Product Code

[etherlab-dev] pcap logging patch

as other information in it and the Debug IFace option was not suitable to set up at a client site. Regards, Graeme Foot Kinetic Engineering Design Ltd. 0001-pcap-logging.patch Description: 0001-pcap-logging.patch ___ etherlab-dev mailing list ethe

Re: [etherlab-dev] EoE IP command patch

ook like they are creating a loop But I don't remember what that was all about. Regards, Graeme. From: Gavin Lambert Sent: Friday, 12 July 2019 1:08 PM To: Graeme Foot ; etherlab-dev@etherlab.org Subject: RE: EoE IP command patch Regarding patch 0002, I'm curious why the callbacks are b

[etherlab-dev] Small fix for EoE commit @ rev 2597

Hi Florian, I've come across a small bug in the default branch from commit @ rev 2597 (0e145bb05859) "Implemented EoE Set IP parameter request via command-line tool". In master/fsm_slave.c, line 141 if (fsm->eoe_request) { fsm->soe_request->state = EC_INT_REQUEST_FAILURE; wa

[etherlab-dev] Hot plugged modules failing to read DC register

Hi, I've had occasional issues with EL7332 and EL7342 modules where they will go to SafeOp + Error if you try and use them in DC mode. I've finally had some time to look into it a little further. When the modules go to SafeOp + Error the master outputs the message "Slave has no System Time re

Re: [etherlab-dev] Hot plugged modules failing to read DC register

. From: etherlab-dev On Behalf Of Graeme Foot Sent: Tuesday, 24 September 2019 5:20 PM To: etherlab-dev@etherlab.org Subject: [etherlab-dev] Hot plugged modules failing to read DC register Hi, I've had occasional issues with EL7332 and EL7342 modules where they will go to SafeOp + Error i

Re: [etherlab-dev] Hot plugged modules failing to read DC register

eg read request. I'm not using any patch to disable automatic rescan as far as I'm aware. I'm only using your patchset and the extra's I've submitted. Cheers, Graeme. From: Gavin Lambert Sent: Thursday, 26 September 2019 1:13 PM To: Graeme Foot ; etherlab-dev@ether

Re: [etherlab-dev] Hot plugged modules failing to read DC register

: EL5101 EL7332 EL7342 Next step, talking to Beckhoff. Cheers, Graeme. From: Gavin Lambert Sent: Thursday, 26 September 2019 1:46 PM To: Graeme Foot ; etherlab-dev@etherlab.org Subject: RE: Hot plugged modules failing to read DC register Is this happening straight from boot, or is it initially wor

Re: [etherlab-dev] Hot plugged modules failing to read DC register

o the cached version (if you are using that patch). It's generally only a problem if slaves are being powered up after the master is already running (e.g.: a remote IO cabinet). Graeme. From: Gavin Lambert Sent: Thursday, 26 September 2019 2:28 PM To: Graeme Foot ; etherlab-dev@etherlab.o

Re: [Etherlab-dev] Improved debugging and behavior on sick SII contents

run before checking the dc registers (which may also be initialised from the EEPROM). This state now blocks until bit 0 is set (PDI operation/EEPROM loaded bit) and error's out if there is a timeout. Regards, Graeme Foot. 0002-retry-dc-register.patch Description: 0002-retry-dc-register.patch -

Re: [Etherlab-dev] Improved debugging and behavior on sick SII contents

2 September 2020 10:24 pm To: Graeme Foot Cc: etherlab-dev@etherlab.org Subject: Re: Improved debugging and behavior on sick SII contents Hi, Graeme, On Mon, Sep 21, 2020 at 09:40:37PM +, Graeme Foot wrote: > I see you checked in some extra debugging on SII content a couple of > week

Re: [Etherlab-dev] Ethercat mailbox gateway and TwinSAFE loader issues

Hi Mark, The mbg readme has the following note: The Mailbox Header has a Cnt parameter (bits 5-7 of the last byte of the header). If this value is zero the slave should always accept the incoming mailbox request. If the value is non-zero (1-7) then the slave will only accept the request

Re: [Etherlab-dev] Register to read jitter

Hi Martin, Is this the one you are after? Register System Time Difference (0x092C:0x092F) [cid:image002.png@01D8FF21.C0EE0E60] Regards, Graeme. From: Etherlab-dev On Behalf Of Steih, Martin Sent: Friday, 26 November 2021 22:19 To: etherlab-dev@etherlab.org Subject: [Etherlab-dev] Register t