Re: [Etherlab-dev] Register to read jitter

[Graeme Foot]

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 to read jitter

Hi all,

Does anybody know how to read the current jitter of the bus? If I recall 
correctly, there was a register to do that. I just can't remember. Any 
suggestions?

Thanks in advance

i. A. Martin Steih
Entwicklung

[cid:image003.png@01D8FF21.C0EE0E60]

Lachmann & Rink GmbH
martin.st...@lachmann-rink.de | 
www.lachmann-rink.de
fon: +49 2734 2817 430

Hommeswiese 129 | 57258 Freudenberg
Geschäftsführer: Dipl.-Ing. Arjan Bijlard, Dipl.-Inf. Claudius Rink | 
Amtsgericht Siegen, HRB 2600
-- 
Etherlab-dev mailing list
Etherlab-dev@etherlab.org
https://lists.etherlab.org/mailman/listinfo/etherlab-dev

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

[Graeme Foot]

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 if the value is different
  to the previous mailbox request Cnt value.

(I can’t dig up where I got this information at the moment.)

Comparing the logs the Cnt values sent by the TwinSAFE Loader are the same in 
both cases.  However the Cnt value responses from the device 1001 differ.  In 
the TwinCAT side the sent Cnt value does not clash with the slaves internal Cnt 
value, whereas on the etherlab mbg side it does.

i.e. the 1001 response reply for the el side is:
2 -> 1
3 -> 2
...
3 -> timeout

So I suspect the slaves internal Cnt value is 3, so on receiving a request with 
3 means it thinks it’s a duplicate and is ignored.  So it looks like it is bad 
luck.  It looks like TwinCAT has previously communicated with device 1001 so 
it’s count is misaligned enough not to have a problem.

You could do a trial on the TwinCAT side by sending approx. 5 CoE mailbox calls 
to the 1001 device so that it’s internal counter is the same as the etherlab 
mbg start condition and see how TwinCAT deals with the problem (you could log 
the EtherCAT slave network with Wire Shark.)  It’s also possible TwinCAT just 
internally sends a cnt value of 0.

You could also check you’ve got the latest TwinSAFE loader.  The latest version 
might have its own retry built in (or not).


Regards,
Graeme.

From: Etherlab-dev  On Behalf Of Mark Verrijt
Sent: Saturday, 27 March 2021 5:13 am
To: etherlab-dev@etherlab.org
Subject: [Etherlab-dev] Ethercat mailbox gateway and TwinSAFE loader issues

Hi,

We ran into some problems using ethercat_mbg together with the TwinSAFE loader 
and found some stuff that may be of interest to others aswell:

This setup does work:
0  0:0  PREOP  +  EK1100
1  0:1  PREOP  +  EL6910, TwinSAFE PLC
while this setup does NOT work (fails with a timeout when using loader with 
--list):
0  0:0  PREOP  +  EK1100
1  0:1  PREOP  +  EL6910, TwinSAFE PLC
2  0:2  PREOP  +  EK1110 EtherCAT-Verl�ngerung

I checked what was happening with wireshark when using the twincat master+mbg, 
and compared it to what I saw whilst using the ethercat master+mbg for etherlab.

1. With twincat I see that when a request is done to the master via the mbg it 
responds with a Cnt value (bits [4-6] of last byte of the mailbox header) of 0. 
With etherlab mbg this value is increasing with each next message, which also 
seems to be fine. I could not find in the spec Graeme used 
(https://www.ethercat.org/memberarea/download/ETG8200_V1i0i0_G_R_MailboxGateway.pdf)
 what it should do.

2. When a request is done to the master via the mbg a response shorter than 16 
bytes will be zero padded to make it equal to 16 bytes with twincat mbg, 
etherlab mbg simply sends a shorter message, which also seems to be fine.

3. A difference of more importance: There is a discrepancy between the way the 
Cnt value is updated for the two different master+mbg combinations. In some 
situations this causes a timeout because the request Cnt (coming from the 
loader) is equal to the slave Cnt value, which the slave will ignore and thus a 
timeout occurs. I have added the raw data tracing for both the master+mbg 
combinations if anybody is interested.
I'm not quite sure where to properly fix this, and am thus asking for some 
advice/help.

For now I made a retry work-around in the CommandMbg class which simply retires 
once with a different Cnt value in the request (Cnt-1 and wrapped to 1-7) which 
"solves" the problem. I have attached it as a patch.

I myself would like a clean fix however. If somebody could point me in the 
right direction I would be grateful.

Kind regards,
Mark
-- 
Etherlab-dev mailing list
Etherlab-dev@etherlab.org
https://lists.etherlab.org/mailman/listinfo/etherlab-dev

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

[Graeme Foot]

Hi Florian,

I've attached two patch files rebased to the default branch.  I haven't built 
them so hopefully I got them correct.  The second patch is the most important.  
It reorders the state machine from:
  Base --> [ DCCap ] --> DataLink --> SII
To:
  Base --> DataLink --> [ DCCap ] --> SII

Where the DataLink state will block until the EEPROM read is complete (with a 
500ms timeout).

The first patch may not be required but it retries getting the SII if there are 
any errors which could happen if the comms are a little unstable after a hot 
plug.  It also provides a quick sanity check on the vendor_id and product_code.

The patches are also available at:
https://1drv.ms/u/s!AoLeUQXl-H0MiSiDmBK-pHX5bxTB?e=quRDYQ
https://1drv.ms/u/s!AoLeUQXl-H0MiSnV6f7xJeddqgxQ?e=279l5e


Regards,
Graeme.


-Original Message-
From: Florian Pose  
Sent: Tuesday, 22 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 
> weeks ago.  Have you identified slaves with consistent SII issues, or 
> are they intermittent?  If they are intermittent then it may be due to 
> the master reading the SII contents before the slave has completed 
> finished reading it in from the EEPROM, so the master ends up getting garbage 
> / uninitialized values.

the reason was, that we started developing some slaves and connected some 
uninitialized Trinamic slaves that contained only ones in the SII.
That made the master think that the mailbox sizes were 64k, which lead to some 
problems. :-)

But we never came across such things with regular slaves.

> If it’s intermittent, I wrote a patch for Gavin’s patchset which may 
> help.  The patch reorders the fsm_slave_scan states so that the 
> datalink states (which read register 0x0110) are 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.

Good idea, if that helps for those cases, I'd like to merge it. Can you send me 
a link to a PR / patch?

--
Thanks,
Florian


0002-retry-dc-register.patch
Description: 0002-retry-dc-register.patch


0001-slave-scan-retry.patch
Description: 0001-slave-scan-retry.patch
-- 
Etherlab-dev mailing list
Etherlab-dev@etherlab.org
http://lists.etherlab.org/cgi-bin/mailman/listinfo/etherlab-dev

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

[Graeme Foot]

Hi Florian,

I see you checked in some extra debugging on SII content a couple of weeks ago. 
 Have you identified slaves with consistent SII issues, or are they 
intermittent?  If they are intermittent then it may be due to the master 
reading the SII contents before the slave has completed finished reading it in 
from the EEPROM, so the master ends up getting garbage / uninitialized values.

If it's intermittent, I wrote a patch for Gavin's patchset which may help.  The 
patch reorders the fsm_slave_scan states so that the datalink states (which 
read register 0x0110) are 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
-- 
Etherlab-dev mailing list
Etherlab-dev@etherlab.org
http://lists.etherlab.org/cgi-bin/mailman/listinfo/etherlab-dev

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

[Graeme Foot]

Hi,

There is no "AL status message" occurring in the syslog.  As such there is also 
no acknowledgement.

I just mentioned the reg_read request as an aside to say that I can't manually 
query the state of the slave while it is in SAFEOP+ERROR.

The error flag is set and the slave goes to SAFEOP+ERROR due to DC failing to 
sync.
DC fails to sync due to the master not setting the DC time offset.
The master does not set the DC time offset due to the has_dc_system_time flag 
not being set.
The has_dc_system_time flag is not set because the slave does not respond to 
the 0x0910 reg 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@etherlab.org
Subject: RE: Hot plugged modules failing to read DC register

I'm not talking about a reg_read request.

When the slave first goes into SAFEOP+ERROR, the master should detect this 
during its regular slave scan cycle (fsm_master_state_read_al_status).  It then 
calls ec_fsm_change_ack to acknowledge the ERROR state - as it does this, it 
should report something like this to the syslog (even at debug 0 level):

kernel: [49369.927687] EtherCAT ERROR 0-main-2: AL status message 0x001B: "Sync 
manager watchdog".
kernel: [49369.953541] EtherCAT 0-main-2: Acknowledged state SAFEOP.

This is the message that tells you why the slave was unhappy and went to the 
ERROR state in the first place.  After this, the slave should be in SAFEOP (no 
ERROR), and the master will usually then bring it back to INIT and do a full 
reconfigure and back to OP (if the master app is still running).

If you have the quick-op patch applied, and the AL status was 0x001B and not 
some other error (and the master hasn't restarted since the slave entered the 
error state), then instead of going back to INIT in the above case it will try 
to go straight back from SAFEOP to OP to reduce the downtime.  As mentioned in 
the patch notes, this is fine in most cases but it can upset some DC slaves (as 
it may not give them enough time to resync), so you may want to disable this 
feature via configure.  (You can clearly see in the syslogs when it's 
attempting a quick return to OP.)

The slave should always accept acknowledging the ERROR state and returning to 
INIT.

The "slave has error_flag set" thing is different; that's referring to 
slave->error_flag, which is only set when the slave fails to respond correctly 
to requests (such as refusing to perform AL state changes or not responding to 
internal register requests), despite still responding to the broadcast AL state 
request (used to determine the number of active slaves).  The only way to clear 
this flag is to rescan, either via "ethercat rescan" or by the automatic rescan 
that it performs when the number of slaves changes (as it normally does during 
a genuine comms interruption).

So have a look further back in the logs to see why the error_flag is being set 
in the first place.

Though also make sure that you're not using any extra patches which disable the 
automatic rescan.  I recall someone on this list a while ago suggesting this 
was a good idea; it isn't.


Gavin Lambert
Senior Software Developer


[cid:image001.png@01D5746C.903BDD30]
[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>[instagram]<https://www.instagram.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 mailto:graeme.f...@touchcut.com>>
Sent: Thursday, 26 September 2019 12:32
To: Gavin Lambert mailto:gavin.lamb...@tomra.com>>; 
etherlab-dev@etherlab.org<mailto:etherlab-dev@etherlab.org>
Subject: RE: Hot plugged modules failing to read DC register

Hi Gavin,

When 0x0910 returns a working counter of 0 the master assumes the slave only 
supports delay measurement and the slave->has_dc_system_time flag remains zero. 
 If the flag is zero a few DC configuration steps are missed.  Subsequently, 
when the slave DC Assign Active value is set the slave has not been set up to 
use DC correctly and fails to sync.

So without the patch (extracts from attached "DC Sync Error.txt"):
[  270.369125] EtherCAT DEBUG 0-main-3: Ready for requests.
[  270.376908] EtherCAT DEBUG

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

[Graeme Foot]

Hi,

I have attached a patch that will retry up to 200ms for a slave to respond to 
reading the DC register 0x0910 during slave configuration.

It requires the scan_jiffies_start variable in the ec_fsm_slave_scan struct 
that was introduced in a previous patch: 0001-slave-scan-retry.patch.

Graeme.

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 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 register; delay measurement only." (with debug level 1).  This 
occurs due to the datagram reading register 0x0910 returning a working counter 
of zero.

I created a quick hack to retry reading the register up to 100 times before 
failing.  After approx. 90ms the EL7342 module I'm testing with successfully 
returned the datagram and the slave entered Op state successfully.

In my test setup I also have an EL5101 module that was doing the exact same 
thing (and taking around the same time), but I've never really had issues with 
them before.  I suspect the difference is that if you have incorrect settings 
on the EL7342 module and try to run a motor it can error out and reset itself, 
causing a situation equivalent to a hot plug.

Without my hack both modules need to wait for the SII read to complete for a 
similar length of time, so it looks like the slaves do not respond to the 
0x0910 register request until the EEPROM read is complete.  Does anyone know if 
this is expected behaviour, or know of a better solution than to retry reading 
the register (up to 200ms ???)?


Regards,
Graeme.


0002-retry-dc-register.patch
Description: 0002-retry-dc-register.patch
___
etherlab-dev mailing list
etherlab-dev@etherlab.org
http://lists.etherlab.org/mailman/listinfo/etherlab-dev

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

[Graeme Foot]

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;
wake_up_all(>slave->master->request_queue);
}

should be

if (fsm->eoe_request) {
fsm->eoe_request->state = EC_INT_REQUEST_FAILURE;
wake_up_all(>slave->master->request_queue);
}

(i.e.: fsm->soe_request should be fsm->eoe_request)

Regards,
Graeme.
___
etherlab-dev mailing list
etherlab-dev@etherlab.org
http://lists.etherlab.org/mailman/listinfo/etherlab-dev

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

[Graeme Foot]

Hi,

Unfortunately "0008-fsm_sii-loading-check.patch" (below) didn't fix my main 
problem.  It turns out it is an inherent problem with how the masters external 
datagram ring works.  I have attached a patch that plugs the hole causing the 
problem I was having but there may be other cases where issues could occur.

Patch: 
/features/parallel-slave/0009-ec_master_exec_slave_fsms-external-datagram-fix.patch


The guts of the problem:

ec_master_exec_slave_fsms() calls ec_master_get_external_datagram() to get a 
datagram from the external datagram ring.  The datagram is then passed to 
ec_fsm_slave_exec() of the slaves with some work to do.  This call will then 
return either 1 for fsm still in progress or 0 for fsm is complete.  The master 
assumes that if the fsm is still in progress then the datagram has been 
consumed and is in use, but there are various cases where this is not true.  If 
any of these cases occur then in the first loop of ec_master_exec_slave_fsms() 
these slaves fsm's may be executed multiple times while another slaves fsm is 
waiting on its datagram to return.

If too many slaves, or cycles, occur during this time then the waiting slaves 
datagram either gets its state set to EC_DATAGRAM_INVALID or gets reused by 
another slave.  This can lead to "cancelled" datagram replies or the two slaves 
getting the results from the second slaves datagram (as the first datagram 
index will be replaced and its reply is lost).


In my case this was occurring due to using the "0001-load-sii-from-file.patch" 
patch.  During the SII config stage of a slave this patch will create a kthread 
to attempt to read the SII file from disk.  In the meantime the 
ec_fsm_slave_exec() command will continue returning a value of 1 (fsm in 
progress) but will not be using the presented datagrams (setting the datagram 
state to EC_DATAGRAM_INVALID).

During initial startup and configuration of the master the 
ec_master_exec_slave_fsms() call is made from ec_master_idle_thread() in a loop 
with (in my configuration) a call to schedule() before resuming the loop.  This 
means that multiple loops may occur before a reply to a slaves datagram 
returns, leaving plenty of time for the in-use datagrams to be recycled 
resulting in its state or data being overwritten.


The patch I have attached now also tests the datagrams state for 
EC_DATAGRAM_INVALID before incrementing the external datagram ring index.  This 
solves my problem where the datagrams state is being set to EC_DATAGRAM_INVALID 
while waiting for the kthread to complete.

I suspect there may be other instances where this problem could occur.  One 
case I have thought of, but haven't been able to confirm, is when multiple 
protocols try to access a slaves mailbox at the same time (e.g. COE, EOE, FOE 
etc).  Only one protocol is allowed to communicate at a time.  The other 
protocols will be offered a datagram from the ring, but they aren't able to 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-dev@etherlab.org
Subject: Re: [etherlab-dev] Missing Vendor ID / Product Code

Hi,

I think I've finally solved the problem.  The slaves with the issue are 
returning with the "EEPROM not loaded" bit set when reading the SII information 
(bit 12 if the EEPROM status word).  If this bit is set then the slave has not 
yet finished reading the SII information from the EEPROM and the data returned 
may not be valid.  The master code was not checking for this bit.  I have 
attached a patch to do so:
/features/parallel-slave/0008-fsm_sii-loading-check.patch

The patch checks if the bit is set and keeps re-reading the EEPROM data until 
it is not.  At this point the data returned is still incorrect so a complete 
read is requested (where a write is first sent asking for the slave to load the 
data that needs to be read).  There is a 500ms timeout waiting for the bit to 
be clear.  If the bit does not clear then the EEPROM load may have failed (e.g. 
incorrect CRC value).


My previous patch (features/sii-read-failure/0001-sii-read-retry.patch) should 
no longer be required, but it may help to make reading of the SII data more 
robust.  I've attached the latest version of this one also.  It is now:
features/sii-read-failure/0001-slave-scan-retry.patch


Regards,
Graeme Foot.


From: etherlab-dev 
mailto:etherlab-dev-boun...@etherlab.org>> 
On Behalf Of Graeme Foot
Sent: Friday, 12 October 2018 11:38 AM
To: Gavin Lambert mailto:gavin.lamb...@tomra.com>>; 
etherlab-dev@etherlab.org<mailto: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 consistently 
reproduce the problem wh

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

[Graeme Foot]

Hi,

I've had a chance to play with my testrig and have managed to consistently 
reproduce the problem when hot-plugging a module (I haven't had the problem 
again on a production machine from a normal startup that I can test on yet).

My system:
- CX2020
- EK1110 (alias 10001)
- EK1100 (alias 2)
- EL1008 (alias 1)

I start the system without the EL1008 plugged in and get it running.  I then 
plug in the EL1008 and the SII information fails to read, resulting in a zero 
alias, vendorID and product code etc.  I have attached a patch which resolves 
the issue on my testrig (but I don't know if it will resolve my production 
issue).

With --enable-sii-override set, the patch detects a zero vendorID or product 
code (hopefully no one has a device with a zero product code) and then retries 
scanning the slave after a 100ms timeout.  If --enable-sii-override is not set 
then it will do the retry if reading the SII size fails.

One strange thing I found during testing was that:
- When --enable-sii-override is not set ec_fsm_sii_success() would fail during 
the ec_fsm_slave_scan_state_sii_size() state; but
- When --enable-sii-override is set ec_fsm_sii_success() does not fail during 
the ec_fsm_slave_scan_state_sii_device() state, so I instead check for a zero 
vendorID or product code.

Gavin, the patch is against your previous patchset.  I put the patch under:
features/sii-read-failure/0001-sii-read-retry.patch

Let me know if you think there's anything 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 the initial discovery datagrams get lost or 
fail.  Usually bad wiring or shielding is the culprit.

I think it might be possible to get something similar due to an unfortunate 
timing coincidence – if the devices are being connected “live” then a dodgy 
plug-in could make the device visible in the initial device count scan, but 
then disconnected before it finishes the identity discovery, but then 
reconnected again before it does the next device count scan (so it doesn’t try 
again).  Replugging the devices (with less unfortunate timing) or restarting 
the etherlab service should both recover from that case, however.

Or, of course, you might have found a bug. 

It's hard to say for sure what actually happened without seeing syslogs and/or 
reproducing it.

From: Graeme Foot
Sent: Wednesday, 8 August 2018 14:12
To: etherlab-us...@etherlab.org<mailto:etherlab-us...@etherlab.org>
Subject: [etherlab-users] Missing Vendor ID / Product Code

Hi,

I updated my EtherCAT system to use Gavin's patch set (revision 10, 20171108).  
It has been running fine on a few machines, but have just had a machine being 
commissioned where one of the slave modules had a zero Vendor ID and Product 
Code (and I suspect it failed to read any information from the slave).  
Unfortunately it occurred while I was not available so our engineers reverted 
to the previous version (which detected the module correctly) and shipped the 
machine, so I have very minimal information and no logs.

The module with the problem was the 17th module, the first EL2612 of 5.  It is 
directly after an EL9410 power module.  It has an explicit alias set.  The 
engineers had tried repowering the whole system and replacing the module.

Until I get a machine to test on with the same behaviour I was wondering if 
anyone else has had problems with slaves not initialising correctly.

Thanks,
Graeme Foot.


0001-sii-read-retry.patch
Description: 0001-sii-read-retry.patch
___
etherlab-dev mailing list
etherlab-dev@etherlab.org
http://lists.etherlab.org/mailman/listinfo/etherlab-dev

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

[Graeme Foot]

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 <gav...@compacsort.com>
Cc: etherlab-dev@etherlab.org
Subject: Re: [etherlab-dev] ec_lock_* vs. ec_ioctl_lock in master/ioctl.c

Hi Gavin,

I have attached updated eoe patches to maintain compatibility with your 
patchset for non-RTAI / RTDM applications.

Patch 0001:
This will now continue with the existing behaviour of auto-create and 
auto-delete of eoe ports as the eoe slaves are detected and removed.  It does 
contain the fix for removing the lock from the transmit callback so eoe users 
will probably want this update even if they want to keep existing behaviour.

Patch 0002:
Still only targeted at RTAI / RTDM users, but will now maintain existing 
behaviour (internal locking via the internal callbacks) for Linux 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 <esben.haaben...@gmail.com>
Cc: etherlab-dev@etherlab.org
Subject: 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 / RTDM cannot use callbacks, so EoE does not work for this 
framework.

I put the patches in the features branch of Gavin's patchset as they should be 
optional and especially patch 2 (0002-eoe-via-rtdm.patch) is specifically for 
RTAI / RTDM for EoE.  I haven't looked too hard at making this one generic as 
it does break the previous patches I mentioned (base 0017 and 0018).  But it 
also needs to break them as the whole point of it is to use an application 
level lock (i.e. RTAI lock) instead (as per the design of the vanilla Etherlab 
master).  So no, the patch does not support "plain" user-space applications 
(i.e. not using RTDM) as my focus was only for RTDM applications.  Patch 2 
could probably have a few more defines to make sure it only affects RTDM users 
and keeps 0017/0018 active for non-RTDM installs.

patch 1 (0001-eoe-addif-delif-tools.patch) only looks at changing the lifetime 
options of the eoe interfaces so anyone should be able to use this.

patch 2 (0002-eoe-via-rtdm.patch) is targeted to add the ability for RTDM users 
to provide a user space alternate to the callbacks framework.  If people prefer 
this method to allow "plain" Linux user space applications to supply their own 
locking then it could be extended.  But it does mean that the base patches 
"0017-Master-locks-to-avoid-corrupted-datagram-queue.patch" and 
"0018-Use-call-back-functions.patch" do need to be removed.

So using patch 2 is a matter of preference: Patch 2 uses the Vanilla EtherLab 
EtherCAT master approach of "the user application knows best" as to when a lock 
can be acquired, but also covers the "realtime RTAI can't use Linux locks" 
issue; OR don't use patch 2 and go with the patches 0017/0018 approach where 
the master handles this locking (which as I said is not an option for RTAI).



> From: Esben Haabendal [mailto:esbenhaaben...@gmail.com] On Behalf Of 
> Esben Haabendal
> 
> Hi Graeme
> 
> Need to get one thing straight first.
> 
> RTDM user-space is not the same as "plain" Linux user-space.
> I know that you are 100% aware that, but your replies to me seems less clear 
> about it.
> 
> Your 0002-eoe-via-rtdm.patch does not seem usable for "plain" user-space 
> applications, so does not apply to the applications we support.
> 
> >> > These 4 functions are special.  The master should be written (and 
> >> > mostly seems to be) in a fashion that between a
> >> > ecrt_master_activate() and ecrt_master_deactivate() the above 
> >> > calls do not require any locks to synchronize with the master 
> >> > code, except for the EOE thread which uses callbacks.
> >> 
> >> Well, mostly is the same as not in my world.  If they mostly do not 
> >> require any locks, they do require locks.
> >
> > When I say mostly, I mean the vanilla Etherlab version is ok, but 
> > the patch that added ec_ioctl_lock_up() and ec_ioctl_lock_down() 
> > broke this.  I do not use this patch.
> 
> Do you mean that the patches (and I guess you mean 
> 0017-Master-locks-to-avoid-corrupted-datagram-queue.patch and
> 0018-Use-call-back-functions.patch) introduces the need for locking?
>

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

[Graeme Foot]

> From: Esben Haabendal [mailto:esbenhaaben...@gmail.com] On Behalf Of Esben 
> Haabendal
> 
> >> Graeme Foot <graeme.f...@touchcut.com> writes:
> >> 
> >> > The ec_ioctl_lock_up() and ec_ioctl_lock_down_interruptible() calls 
> >> > were added to protect the following functions when multiple 
> >> > send/receive loops are
> >> > running:
> >> > - ecrt_master_send()
> >> > - ecrt_master_receive()
> >> > - ecrt_master_domain_process()
> >> > - ecrt_master_domain_queue()
> >> >
> >> > In my opinion any locking on these functions should be at the 
> >> > application level instead.
> >> 
> >> Well, I have a different opinion on that.
> >> 
> >> Implementation of locking is inherently difficult to get right.  You 
> >> both have to ensure against race conditions while avoiding deadlocks.
> >> But you also do not want to block for too long.
> >> 
> >> While I do acknowledge that for trivial cases where there are only a 
> >> single application, it is not a big program for that single 
> >> application to maintain synchronization, I don't think that it is a 
> >> good solution to let each application developer in the more 
> >> complicated situations (like multiple independent processes) have to 
> >> do this without any help from etherlabmaster.  Forcing all (or at 
> >> least some) application developers to solve this same problem again 
> >> and again should not be the best we can do.
> >
> > These 4 functions are special.  The master should be written (and 
> > mostly seems to be) in a fashion that between a ecrt_master_activate() 
> > and ecrt_master_deactivate() the above calls do not require any locks 
> > to synchronize with the master code, except for the EOE thread which 
> > uses callbacks.
> 
> Well, mostly is the same as not in my world.  If they mostly do not require 
> any locks, they do require locks.
> 

When I say mostly, I mean the vanilla Etherlab version is ok, but the patch 
that added ec_ioctl_lock_up() and ec_ioctl_lock_down() broke this.  I do not 
use this patch.


> I guess some of the confusion I have is caused by the fact that it is unclear 
> exactly which functions are allowed to be called between
> ecrt_master_activate() and ecrt_master_deactivate(), and which functions are 
> not.  Do we have such a list?  Or how can I create such a list exactly?  And 
> would it be possible to enforce this directly in the API, so if you call a 
> function you are not allowed to call, you get an error back instead of 
> introducing random breakage by modifying unsynchronized shared data 
> structures?
> 

The functions that I think should not require locks between 
ecrt_master_activate() and ecrt_master_deactivate() are:
- ecrt_master_receive()
- ecrt_domain_process()
- ecrt_domain_state()
- ecrt_master_state()
- ecrt_domain_queue()
- ecrt_master_reference_clock_time()
- ecrt_master_sync_slave_clocks()
- ecrt_master_sync_reference_clock()
- ecrt_master_64bit_reference_clock_time_queue()
- ecrt_master_64bit_reference_clock_time()
- ecrt_master_application_time()
- ecrt_master_send()
- ecrt_master_send_ext()
- ecrt_master_deactivate_slaves()

And with some of my recent patchs
- ecrt_master_eoe_is_open()
- ecrt_master_eoe_process()
- ecrt_master_rt_slave_requests()
- ecrt_master_exec_slave_requests()

There may be some others I don't use.


> As for the EOE thread, I might be overlooking something obvious.  But how are 
> you supposed to use callbacks when using the library API?
> 
> As far as I read the code, if you are using EoE and not RTDM, you will always 
> use the standard ec_master_internal_send_cb() and
> ec_master_internal_receive_cb() callbacks.  See ec_ioctl_activate().
> 

If you do not set EoE callbacks (with ecrt_master_callbacks()) there will be NO 
callbacks once the master goes active.  (It will not use 
ec_master_internal_send_cb() and ec_master_internal_receive_cb().  It will not 
start an EoE processing thread.  You will get a "No EoE processing because of 
missing callbacks!" message in your system log.)

If your application is in kernel space then you can specify callback functions 
and then use application level locking.  If your application is in user space, 
then you cannot specify callback functions as the kernel cannot call back into 
user space.  This is why I created my latest patch "0002-eoe-via-rtdm.patch".  
This patch lets you create your own EoE processing thread in your own 
application.  This of course also lets you use application level locking.


> And with them, I don't see how you are supposed to do locking at the 
> application level.  I wi

Re: [etherlab-dev] EoE patchs and questions

[Graeme Foot]

> -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 <graeme.f...@touchcut.com>
> Cc: etherlab-dev@etherlab.org
> Subject: Re: [etherlab-dev] EoE patchs and questions
> 
> Hi Graeme
> 
> Graeme Foot <graeme.f...@touchcut.com> writes:
> > So the first patch does a few things:
> >
> > 1) adds explicit eoe_addif and eoe_delif tool functions so that you
> >can manually add/remove an eoe iface without the slave existing
> > 2) no longer deletes and eoe iface if the slave disappears
> 
> This is a behavioral change compared to how eoe interface work now.  And it 
> will break our current system, which relies on the interfaces being created 
> and deleted together with the slaves.

The changes have added a couple of settings to the ethercat config file 
(EOE_INTERFACES and EOE_AUTOCREATE).  The default for EOE_AUTOCREATE is true, 
so eoe interfaces will be autocreated as EOE slaves are connected.  The only 
"breaking" behavioral change here is that they will no longer be deleted when 
the slave is removed.  The only issue I have with this is that if you connect a 
slave that does not yet have an alias set, it will auto-create using position 
naming (e.g. eoe0s4).  Once the alias is set it will auto-create using the 
alias naming (e.g. eoe0a16000) but keep the position named eoe port.  As this 
is usually at setup and configuration time then you are likely to reboot and it 
will be gone.  (Or you can explicitly call the eoe_delif function.)

> 
> With EtherCAT being a dynamic structure, I don't see this new way is supposed 
> to work in general use-case, where the bus configuration is not guaranteed to 
> be fixed.

When the EOE slave is removed the port transitions to a disconnected state 
(like pulling the plug out of a normal network card).  My (unfounded) feeling 
is that this would be preferable to other software using the port rather than 
deleting the interface all together.  It also means that if you have added the 
port to a bridge (my use case) then it will remain in the bridge and resume 
once it is plugged back in again.  If it is deleted then it is removed from the 
bridge and the next time it is plugged in again it will need to be manually 
re-added it to the bridge.

I would think that even in a dynamic structure if an EOE module has been 
plugged in once it is likely to be plugged in again at some stage.

> 
> Would it be possible to make this new behavior optional, so that the default 
> behavior is as it is now?

Sure.  Two options:
1) Have another ethercat config file option: EOE_AUTODELETE (default true)
2) Have EOE_AUTOCREATE also mean that it will auto-delete.

I prefer option 2 for ease of implementation, though option 1 would be better 
if my assumptions above are correct.  Try the attached completely untested (and 
manually edited) patch file for option 2.

> 
> /Esben
>

I'm interested to know what your application is to have such a dynamic 
structure.


Regards,
Graeme.


0001b-eoe-addif-delif-tools.patch
Description: 0001b-eoe-addif-delif-tools.patch
___
etherlab-dev mailing list
etherlab-dev@etherlab.org
http://lists.etherlab.org/mailman/listinfo/etherlab-dev

Re: [etherlab-dev] EoE patchs and questions

[Graeme Foot]

Hi,

I’m off from work for the weekend, but I did view the contents of 0x808 (size 
8) before and after doing a write of zero and all the values stayed the same. 
SM1 is configured with its default values so I’m assuming writing a zero will 
set it back to its defaults, so will remain the same. Needs more testing but 
ran out of time this week.

I got to the point of writing a zero to SM1 due to noticing that the rx 
communications resumed when I manually changed the state of the slave from OP 
to PREOP. So I followed the steps in the state machine. That was the command 
that did it. Other things I tried like rescans or unplugging the coupler 
(keeping power on the EoE slave didn’t work).

I don’t know of any slaves that might require OP mode to run as I’m new to EoE 
too. From my memory of the code on initial startup it remains in PREOP and its 
only on a master deactivate that it remains in OP (and it does so by putting 
EoE slaves back into OP after all slaves have been set to PREOP).

Time for more testing next week. Yes I will be  wiresharking the Ethercat 
frames. I’ve been checking the Ethernet side so far. Will need to grab another 
computer to check the Ethercat side.

Thanks,
Graeme.


From: Gavin Lambert <gav...@compacsort.com>
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 had to be in 
OP to transfer EoE frames; there was previously a similar assumption regarding 
the DC reference clock that was fixed in 
[559f2f]<https://sourceforge.net/p/etherlabmaster/code/ci/559f2f9c5b08700f2e4722f498799236a2c9f78a/>.
  I don’t have any experience with EoE myself but a quick glance through the 
manual for EL6614 does suggest that it will happily do EoE in PREOP and above.  
Do you think there could be any older slaves that might need OP for that?

The register write to 0x808 as a recovery from that condition seems a bit 
peculiar – most of those registers are read-only while SM1 is enabled – though 
you’re writing 0 to 0x80E, which should disable the SM, which then ought to 
stop it working entirely, unless something reconfigures it.

Perhaps inspecting other SM registers might be interesting?  Or see if there’s 
anything noticeable around that time in a Wireshark trace (if you have some way 
to detect exactly when it stops)?  Does the problem still happen with fewer 
patches applied?

From: Graeme Foot
Sent: Friday, 16 February 2018 19:01
To: etherlab-dev@etherlab.org
Subject: [etherlab-dev] EoE patchs and questions

Hi,

I've been setting up my system to use EoE (Ethernet over EtherCAT) with an RTAI 
user space application.

I've updated my master to revision 33b922ec1871 (default branch) and applied 
the gavinl (Gavin Lambert) patch set 20171108.
Linux 2.6.32.11
RTAI 3.8.1


Firstly I have a bit of a different use case for my EoE.  The current 
implementation auto creates and removes the eoe interfaces as the EoE capable 
slaves are configured and removed.  This means the interface is not available 
until the slave is scanned, and is not available if it is removed.  The eoe 
interface is also temporarily destroyed on a bus rescan.  In my use case I want 
to bridge the eoe interface to a real Ethernet interface.  So I want the eoe 
interface to always exists whether the slave is plugged in or not.

So the first patch does a few things:
1) adds explicit eoe_addif and eoe_delif tool functions so that you can 
manually add/remove an eoe iface without the slave existing
2) no longer deletes and eoe iface if the slave disappears
3) will relink a slave to an eoe iface when it is configured
4) will let you configure eoe ifaces via the sysconfig/ethercat config file
5) will let you turn off auto creation of eoe ifaces via the sysconfig/ethercat 
config file
6) no longer keeps slaves with EoE capability in OP mode when the master is 
deactivated

The above is made possible by using the netif_carrier_on() and 
netif_carrier_off() functions of the iface.  (The same as having a normal 
network interface up, but not plugged in.)

The other thing the patch does is fix a race condition bug in the eoe iface 
code.  The current implementation uses a struct list_head queue with a 
semaphore to protect it between the iface tx callback and the ethercat thread.  
Sleeps are not allowed in the ifaces tx callback as it is in an interrupt 
context.  To fix this I have changed the queue to a ring buffer so that it no 
longer needs a lock.

FYI, when the race condition occurred I was getting:
BUG: scheduling while atomic
Call Trace:
[] ? ktime_get_real+0x0/0x29
[] ? ktime_get+0x0/0x88

Florian you may be interested in this patch, especially the bug fix part.


The second patch is so that I can run the EoE pump without callbacks.  As I am 
using a user space RTAI application I cannot use callbacks as the

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

[Graeme Foot]

>
> 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.
> > > However, I have my Linux environment set to run at 100Hz, so this
> > > thread would only fire once every 10ms.  Each SDO read/write request
> > > would take approx. 30ms to complete.  I didn't want to change Linux to
> > > run at 1000Hz so I
> > > created patch "etherlabmaster-0010-
> > > allow_app_to_process_sdo_requests_from_realtime.patch".
> >
> > Maybe I'm missing something about how the RTAI version works, but all I
> did
> > was to move the logic from inside fsm_master to inside fsm_slave; AFAIK
> > both of these execute on the same thread (either the master IDLE or master
> > OPERATION thread).  This is independent of the application realtime loop
> > either way, so this should not have changed how frequently they run; it
> just
> > allows multiple slave requests to run in parallel rather than forcing them
> to
> > execute sequentially, so it should be a net performance gain.
> >
> > Though it does seem reasonable in your use case to want to run the slave
> > FSMs more often.  I don't see how you could do that safely, though -- you
> > can't run ec_master_exec_slave_fsms outside of the master_sem lock, and
> > your RTAI task might interrupt Linux while it's still holding that lock,
> which will
> > deadlock your RTAI task.
>
> Are you configuring with --enable-hrtimer?  After having a quick look at the
> code, I can see a potential performance degradation from the patch if you
> aren't using it (or did enable it but didn't call
> ec_master_set_send_interval with an appropriate value after activating the
> master).  Perhaps you could try enabling that instead of using your patch
> and see if it helps?
>

Hi,

I don't use ec_master_set_send_interval() or --enable-hrtimer since my masters 
operational thread has always run at 10ms (100Hz) anyway.  (I probably should 
so will look at adding that in at some stage.)  My Linux kernel is configured 
to run at 100Hz and the master thread is not realtime so is scheduled by the 
Linux scheduler (RTAI).  Because Linux is set to 100Hz, it only runs the 
masters operation thread once every 10ms.

Prior to your SDO patch, ec_fsm_master_action_process_sdo() was being called by 
the masters fsm, but from its idle state.  So it would only be called after all 
other processing and housekeeping was complete and was only being fired approx 
once every 800ms on my setup with 50 odd slaves.  After the patch 
ec_master_exec_slave_fsms() is now called every time the masters operational 
thread fires.  All good except that on my system that is still only once every 
10ms.

So my new patch allows ec_master_exec_slave_fsms() to be called from my 
realtime context.  As you pointed out the master_sem lock would cause a 
deadlock, so I don't use it.  Because I don't use the lock I have instead added 
some flags to track whether it is currently safe to make the 
ec_master_exec_slave_fsms() call.  It's generally just the rescan thats a 
problem.

I don't know if the patch will be useful for anyone else, but is useful if 
Linux is configured for 100Hz.  It may also be useful on short cycle time 
systems, e.g. 100 - 250us cycle times, where you want to process the SDO's 
faster.  Even if Linux is set to 1000Hz is will only schedule the master 
operational thread at 1ms.  The master thread may also be delayed if the Linux 
side gets some heavy CPU usage.


Thanks for thinking about it.  I like getting feedback for my patches as its 
easy to overlook potential bugs or alternate solutions which can be better.


Graeme.



___
etherlab-dev mailing list
etherlab-dev@etherlab.org
http://lists.etherlab.org/mailman/listinfo/etherlab-dev

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

[Graeme Foot]

Hi,

I just had a play with your patchset the other day to try to resolve some very 
slow SDO read/write timings.

First off, I also prefer #3.  I use buildroot to create my Linux environment 
and buildroot applies patches in alphabetical order (at least in my version 
which is now pretty old), so the number at the front is important.  Buildroot 
also requires that the patch starts with the name of the package (and 
optionally a revision number), but that is easy for me to prefix.


I would prefer breaking change patches to be last in the list if possible.


When I tried to use your patchset (and the EtherCAT revision they were for) the 
computer would freeze just after starting my application and going realtime.  
We use RTAI and I read your notes re that it wasn't tested with RTAI.  I didn't 
have much time to look into problem but I suspect there may have been a lock 
that ended up in a call from the realtime context that was blocked due to be 
held in the master thread.  I ended up cherry picking the changes I needed 
(patch 0054 (sdo requests via slave fsm) and 0038 (sdo write request)).  

FYI: We are still using Linux kernel 2.6.32.11 and had a compilation issue with 
one of the patches due to header file differences.  Unfortunately I seem to 
have deleted the info as to what it was.


As to other potential patches (Note: my patches are against 2526 (2eff7c993a63) 
on the stable-1.5 branch):

1) RTAI has issues with fprintf calls from the realtime context.  It should 
instead use rt_printk.  My patch 
"etherlabmaster-0001-replace_fprintf_calls_with_EC_PRINT_ERR.patch" defines a 
macro that replaces fprintf calls if USE_RTDM is defined.


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.  
However, I have my Linux environment set to run at 100Hz, so this thread would 
only fire once every 10ms.  Each SDO read/write request would take approx. 30ms 
to complete.  I didn't want to change Linux to run at 1000Hz so I created patch 
"etherlabmaster-0010-allow_app_to_process_sdo_requests_from_realtime.patch".

This patch optionally allows the slave request processing to be called from 
within my application in the realtime thread.  I added two new functions, one 
to set whether slave request processing is expected to be processed by the 
master thread as usual, or by your app.  The second function needs to be called 
periodically by your app.  Note: if the master is idle (ie your app is not 
running) then sdo request processing will be handled as normal.  In my app I 
process the slave requests once every 2ms (every second realtime cycle) at the 
end of the realtime cycle.  At this rate, SDO read/writes are handled within 
6ms (a couple of extra ms due to other application timings).


3) One last patch you may be interested in.  I was having problems with my 
distributed clock setup.  Some changes I had made a while ago caused my system 
to have a very/very slow drift (approx 1ms over 63 days).  Every now and then 
our machines would start running roughly which a repower would resolve.  It 
turned out to be due to the machines not having been repowered for a few weeks 
and the drift would eventually cause the EtherCAT frame to be sent out at about 
the time of the DC sync events in the slaves and due to jitter the frames 
randomly falling either side of the event.  To help diagnose this I added a 
function to queue and read the dc reference slave clocks 64bit time.  
Effectively it does nothing except put the whole 64bit clock time into the 
EtherCAT frame so that wireshark has a long running time reference (rather than 
just the 32bit low part that rolls over every 4 odd seconds).  Once I put that 
in, the drift (even though very small) became very obvious.  
(etherlabmaster-0008-read_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 
Baastrup
Sent: Thursday, 27 April 2017 11:11 p.m.
To: Gavin Lambert <gav...@compacsort.com>
Cc: etherlab-dev@etherlab.org
Subject: Re: [etherlab-dev] Pre-announcement: unofficial patchset update (Gavin 
Lambert)

Hi Gavin,

I am also in favor of #3 and suggest that naming is "auto generated" based on 
the first line of the commit message like done with git-format-patch.

"By default, each output file is numbered sequentially from 1, and uses the 
first line of the commit message (massaged for pathname safety) as the 
filename." (https://git-scm.com/docs/git-format-patch)


It could be great if it was possible to maintain backwards compatibility in the 
patch-serie or alternatively ensure that breaking patches are put on top or in 
a separate serie.


BR, Knud


-Original Message

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

[Graeme Foot]

Hi,


My CX2100 patch is attached.


Graeme.



From: 周甫霖 <erixc...@mapacode.tw>
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) was done correctly in my case.
For 3), I'll check dmesg.
For 4), I found the thread in 2013:
http://lists.etherlab.org/pipermail/etherlab-users/2013/002074.html
But I can't get the attachment since I'm not in the etherlab-user mail list.
Is there any other way to get the attachment?

Thank you for your response.
Best regards - Erix Chou

2017-01-19 5:27 GMT+08:00 Graeme Foot 
<graeme.f...@touchcut.com<mailto:graeme.f...@touchcut.com>>:

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 drivers are loaded (in the DEVICE_MODULES key).  So you may have 
sepecified a MAC address that is not matching your device



2) You are not loading your device module.


In /etc/sysconfig/ethercat you have "DEVICE_MODULES=".  This specifies the 
network driver modules (ethercat versions) that you want to run (space 
delimited list).  You should put your module first in the list if you use a 
generic MAC address (ie: ff:ff:ff:ff:ff:ff) in the setting above.


eg:

DEVICE_MODULES="cpsw e1000 e1000e"



3) Your driver doesn't work.


Check dmesg for any errors.



4) Your driver is not correctly integrating with the EtherCAT master.


There's various functions that your driver needs to interact with the master.  
But from memory the one that tells the master that a device is available is:

ecdev_offer();



But the guts of it is that no offered net devices match the requirements of the 
MASTER0_DEVICE config setting.



I wrote a patch for the CX2100 device a while ago.  You could look it up in the 
forums to check how it interacts with the master (or I could send it if you 
can't find it).  Look for the ecdev_... methods and the notes about the skb's.



Regards,

Graeme.






From: etherlab-dev 
<etherlab-dev-boun...@etherlab.org<mailto:etherlab-dev-boun...@etherlab.org>> 
on behalf of 周甫霖 <erixc...@mapacode.tw<mailto:erixc...@mapacode.tw>>
Sent: Wednesday, 18 January 2017 9:26:42 PM
To: etherlab-dev@etherlab.org<mailto:etherlab-dev@etherlab.org>
Subject: [etherlab-dev] "Master still waiting for devices!" problem.

Hi all,

First appreciate the implement of etherlabmaster.
I'm devolping a non-native supported ethernet device to be able to work as a 
RTDM EtherCAT master.
What the device is one part of TI AM335x SoC and is named "cpsw".
Everything smoothly while adapting driver code, building module file, and 
installing.
But I was stuck by a problem when I try to start EtherCAT master.
Following is my steps and message shown by dmesg:

# /etc/init.d/ethercat start
Starting EtherCAT master 1.5.2  done

[   30.849754] EtherCAT: Requesting master 0...
[   30.854265] EtherCAT ERROR 0: Master still waiting for devices!

More information:

# /opt/etherlab/bin/ethercat master
Master0
  Phase: Waiting for device(s)...
  Active: no
  Slaves: 0
  Ethernet devices:
Main: a0:f6:fd:22:bd:ed (waiting...)
  Link: DOWN
  Tx frames:   0
  Tx bytes:0
  Rx frames:   0
  Rx bytes:0
  Tx errors:   0
  Tx frame rate [1/s]:  0  0  0
  Tx rate [KByte/s]:  0.00.00.0
  Rx frame rate [1/s]:  0  0  0
  Rx rate [KByte/s]:  0.00.00.0
Common:
  Tx frames:   0
  Tx bytes:0
  Rx frames:   0
  Rx bytes:0
  Lost frames: 0
  Tx frame rate [1/s]:  0  0  0
  Tx rate [KByte/s]:  0.00.00.0
  Rx frame rate [1/s]: -509579 -509608 -335544
  Rx rate [KByte/s]:   845836.0 -469824.0 163840.0
  Loss rate [1/s]:  0  0  0
  Frame loss [%]: 0.00.00.0
  Distributed clocks:
Reference clock: None
Application time: 0
  2000-01-01 00:00:00.0



Could anyone kindly advice what is the key point to go forword form "waiting 
device"?

Best regards - Erix Chou



--
動程科技有限公司
台南市安平區建平十七街159號七樓之一
周甫霖 Erix Chou
E-mail：erixc...@mapacode.tw<mailto:erixc...@mapacode.tw>
TEL：06-2970665
Mobile：0985946776


etherlabmaster-1.5-2266-d_cx2100.patch
Description: etherlabmaster-1.5-2266-d_cx2100.patch
___
etherlab-dev mailing list
etherlab-dev@etherlab.org
http://lists.etherlab.org/mailman/listinfo/etherlab-dev

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

[Graeme Foot]

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 drivers are loaded (in the DEVICE_MODULES key).  So you may have 
sepecified a MAC address that is not matching your device



2) You are not loading your device module.


In /etc/sysconfig/ethercat you have "DEVICE_MODULES=".  This specifies the 
network driver modules (ethercat versions) that you want to run (space 
delimited list).  You should put your module first in the list if you use a 
generic MAC address (ie: ff:ff:ff:ff:ff:ff) in the setting above.


eg:

DEVICE_MODULES="cpsw e1000 e1000e"



3) Your driver doesn't work.


Check dmesg for any errors.



4) Your driver is not correctly integrating with the EtherCAT master.


There's various functions that your driver needs to interact with the master.  
But from memory the one that tells the master that a device is available is:

ecdev_offer();



But the guts of it is that no offered net devices match the requirements of the 
MASTER0_DEVICE config setting.



I wrote a patch for the CX2100 device a while ago.  You could look it up in the 
forums to check how it interacts with the master (or I could send it if you 
can't find it).  Look for the ecdev_... methods and the notes about the skb's.



Regards,

Graeme.






From: etherlab-dev  on behalf of 周甫霖 

Sent: Wednesday, 18 January 2017 9:26:42 PM
To: etherlab-dev@etherlab.org
Subject: [etherlab-dev] "Master still waiting for devices!" problem.

Hi all,

First appreciate the implement of etherlabmaster.
I'm devolping a non-native supported ethernet device to be able to work as a 
RTDM EtherCAT master.
What the device is one part of TI AM335x SoC and is named "cpsw".
Everything smoothly while adapting driver code, building module file, and 
installing.
But I was stuck by a problem when I try to start EtherCAT master.
Following is my steps and message shown by dmesg:

# /etc/init.d/ethercat start
Starting EtherCAT master 1.5.2  done

[   30.849754] EtherCAT: Requesting master 0...
[   30.854265] EtherCAT ERROR 0: Master still waiting for devices!

More information:

# /opt/etherlab/bin/ethercat master
Master0
  Phase: Waiting for device(s)...
  Active: no
  Slaves: 0
  Ethernet devices:
Main: a0:f6:fd:22:bd:ed (waiting...)
  Link: DOWN
  Tx frames:   0
  Tx bytes:0
  Rx frames:   0
  Rx bytes:0
  Tx errors:   0
  Tx frame rate [1/s]:  0  0  0
  Tx rate [KByte/s]:  0.00.00.0
  Rx frame rate [1/s]:  0  0  0
  Rx rate [KByte/s]:  0.00.00.0
Common:
  Tx frames:   0
  Tx bytes:0
  Rx frames:   0
  Rx bytes:0
  Lost frames: 0
  Tx frame rate [1/s]:  0  0  0
  Tx rate [KByte/s]:  0.00.00.0
  Rx frame rate [1/s]: -509579 -509608 -335544
  Rx rate [KByte/s]:   845836.0 -469824.0 163840.0
  Loss rate [1/s]:  0  0  0
  Frame loss [%]: 0.00.00.0
  Distributed clocks:
Reference clock: None
Application time: 0
  2000-01-01 00:00:00.0



Could anyone kindly advice what is the key point to go forword form "waiting 
device"?

Best regards - Erix Chou
___
etherlab-dev mailing list
etherlab-dev@etherlab.org
http://lists.etherlab.org/mailman/listinfo/etherlab-dev

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

[Graeme Foot]

Hi,

Jesper originally needed the patch due to his module requiring a 3kb SII (which 
he generated from the TwinCAT xml), but the module only had 2kb of memory.  The 
patch loads the first 32 bytes of the xml:
- alias
- vendor_id
- product_code
- revision
- serial number

from this it tries to find first a revision based file, then a generic product 
file
- 1st: ethercat/ec_%08x_%08x_%08x.bin(vendor_id, product_code, revision)
- 2nd: ethercat/ec_%08x_%08x. bin(vendor_id, product_code)

The alias is read from SII, so that is fine.  Revision specific SII's is also 
covered.  If a file can't be found then the remaining SII information is read.


I needed this patch due to our early Yaskawa amps having a faulty SII.  The amp 
also did not allow new SII's to be uploaded.  Downloading the SII from a newer 
amp and reading it from file for the older amp worked well.


So the cases where it is needed is if the SII memory is not big enough, or the 
SII memory is faulty and the module does not allow new SII information to be 
uploaded.


I have attached the patch.


Regards,
Graeme.


-Original Message-
From: Gavin Lambert [mailto:gav...@compacsort.com] 
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)?
> 
> It can look up the SII "firmware" using the hotplug/udev framework
(original
> patch from Jesper Smith) or directly from a given directory via a 
> couple
of
> defines (my changes).

It's an interesting idea, certainly.  It's probably not something I'd make use 
of myself (all the slaves I'm using have good SII data) but I know there are 
slaves out there where the vendor has forgotten to program the EEPROM fully.

The naming convention bothers me, though; I would expect the SII data needs to 
differ between different revisions of the slave as well (it certainly does for 
my slaves).

Another problem is that without real SII data on the slaves themselves, they 
can't hold unique aliases, which is something else that I consider mandatory on 
my networks, at least.  So I'm inclined to think that the "correct"
reaction is to reprogram such slaves with their correct SII rather than trying 
to patch it at runtime.

Although at least part of the SII must be working, otherwise you wouldn't be 
able to get the vendor/product ids (unless you're using an ENI file like 
TwinCAT, but that's a massive departure from the Etherlab model).

I'm not opposed to including it anyway (if for no other reason than keeping 
handy patches in one place makes them less likely to get lost in the mists of 
time) but I'm curious what your motivating cases were?




2635-graemef-load_SII_from_file.patch
Description: 2635-graemef-load_SII_from_file.patch
___
etherlab-dev mailing list
etherlab-dev@etherlab.org
http://lists.etherlab.org/mailman/listinfo/etherlab-dev

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

[Graeme Foot]

Hi,

I saw some patches sent to the forum a while ago with regards to adding a call 
to check if the return packets had been received yet.  Not sure if it was a 
blocking call or one that you had to poll.  Searching for "Knowing when the 
packet has finished cycle" and "Waiting for network receive".

One of the other process cycle options is to split read PDO's and write PDO's 
into two different domains.  Some of the recent Beckhoff TwinCAT literature 
describes how this can be useful in reducing response times.

Graeme.

-Original Message-
From: Tillman, 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 typical process cycle: I have been using a process 
similar the second one you describe.  I was very surprised when I was doing my 
initial development that the output frame and the return frame were overlaid, 
requiring double buffering of the output data.  It seems like you should be 
able to configure the domain to place the return data in a separate (possibly 
neighboring) memory area.  As it is the double buffering is the same idea, but 
causes an extra memcpy just prior to sending the domain data.

More problematic is the absence of any way to block (in user-space) waiting for 
the domain's return packet.  As it is I am setting up my clock at 0.5ms to 
handle a 1ms frame time:

 - sleep to output time for frame N
 - memcpy buffered output states to domain frame
 - ecrt_domain_queue and ecrt_master_send
 - pre-calculate data for next output cycle (like servo trajectories which 
don't need immediate input data)
 - sleep to input time for frame N return data
 - trigger computations requiring latest input data (servo loop closure for 
instance)
 - notify lower priority tasks of input changes (sensor reaction logics)
 - sleep to output time for frame N+1

This is working well and has a near constant frame transmit delay minimizing 
output frame jitter.  It would be nice to have some kind of blocking system 
where I could just setup a thread to block waiting for the next return frame 
rather than assuming a return time of, at most, half out actual cycle time.

Are these two things there somewhere and I've just missed them, or is there a 
good reason they haven't been implemented?  It seems like these two items would 
minimize the overhead and maximize the processing time available for most 
applications.

-Scott Tillman

-Original Message-
From: etherlab-dev [mailto:etherlab-dev-boun...@etherlab.org] On Behalf Of 
Graeme Foot
Sent: Tuesday, February 02, 2016 6:36 PM
To: Dr.-Ing. Matthias Schöpfer <schoep...@robolab.de>; etherlab-dev@etherlab.org
Subject: 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 transmission time (master -> slaves -> master) will be approximately twice 
this value.  Plus some overhead for the network card driver to process the 
sending and receiving.

If you use the traditional cycle of:
- cycle sleep
- master_receive
- domain_process
- calc
- domain_queue
- master_send
- cycle sleep
- ...

Then you only have the sleep time available for the EtherCAT frames to go out 
and return.  If the calc time takes too long on a particular cycle then there 
may not be enough time for the frames to return and be ready.


Another problem is if you do have a widely varying calc time then you get a 
widely varying send time (and slave read time).  If using distributed clocks 
this may not be a problem (unless you miss the DC window), but without DC 
synchronization you can get some variance with when the IO on the slaves are 
being switched (or when a motor gets a new position Target).

The way I get around this is to use the following sequence:
- cycle sleep
- master_receive
- domain_process
- write cached values to domains
- domain_queue
- master_send
- calc - writing to cached values
- cycle sleep
- ...

The drawbacks of the above is that you need to calc and write values to a 
cached location else the master_receive / domain_process calls will overwrite 
your calced values with the returned packets data.  It also adds an extra cycle 
before read data is available.  You also have extra time overhead in managing 
the cached values and writing them before the send.  The upside is you have a 
consistent send time and have nearly all of the scan period available for the 
frames to be sent and received allowing you to perform the calculations in 
para

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

[Graeme Foot]

Hi,

Yes, the EC_WRITE_* macros should still be used when writing to the cached 
write memory, but then a straight memcpy from the cache to the domain memory is 
fine.

Graeme.


-Original Message-
From: Gavin Lambert [mailto:gav...@compacsort.com] 
Sent: Thursday, 4 February 2016 11:48 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: I have been using a 
> process similar the second one you describe.  I was very surprised 
> when I was doing my initial development that the output frame and the 
> return frame were overlaid, requiring double buffering of the output 
> data.  It seems like you should be able to configure the domain to 
> place the return data in a separate (possibly
> neighboring) memory area.  As it is the double buffering is the same 
> idea, but causes an extra memcpy just prior to sending the domain data.

The expectation is that you'll use the EC_WRITE_* macros to insert values into 
the domain memory; this takes care of byte-swapping to little-endian for you if 
you happen to be running on a big-endian machine.  You can usually only get 
away with a blanket memcpy if you know your master code will only ever run on 
little-endian machines.

> More problematic is the absence of any way to block (in user-space) 
> waiting for the domain's return packet.  As it is I am setting up my 
> clock at 0.5ms to handle a 1ms frame time:
[...]
> Are these two things there somewhere and I've just missed them, or is 
> there a good reason they haven't been implemented?  It seems like 
> these two items would minimize the overhead and maximize the 
> processing time available for most applications.

There isn't really a way to do that; it's a fundamental design choice of the 
master.  The EtherCAT-custom drivers disable interrupts and operate purely in 
polled mode in order to reduce the latency of handling an interrupt and 
subsequent context-switching to a kernel thread and then a user thread.  What 
gets sacrificed along the way is any ability to wake up a thread when the 
packet arrives, since nothing actually knows that the packet has arrived until 
polled.

To put it another way, when the datagram arrives back from the slaves, it just 
sits in the network card's hardware buffer until the buffer read is triggered 
by an explicit call to ec_master_receive().

The generic drivers have interrupts enabled (so the packets will be immediately 
read out of the hardware buffer into a kernel buffer) but the master still 
treats it as a polled device and won't react until explicitly asked to receive.

With some patches (such that ec_master_receive will tell you if it has received 
all the datagrams back, or similar) you could call this repeatedly (perhaps 
with short sleeps) shortly after sending the datagrams to detect as soon as 
they're back again, but obviously this will increase the processor load and 
give the system less time to do non-realtime things.  If you have some idle 
cores then this may not be a problem, however, and the quicker reaction may be 
worth it.

Having said that, as long as your calculation time is fairly constant, it's 
probably better to use the "classic" cycle structure than to do this -- the 
exact same input values will be read either way, as they're captured at the 
"input latch time" of the slave, which is typically either just after the last 
or in anticipation of the next datagram exchange.


___
etherlab-dev mailing list
etherlab-dev@etherlab.org
http://lists.etherlab.org/mailman/listinfo/etherlab-dev

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

[Graeme Foot]

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 transmission time (master -> slaves -> master) will be approximately twice 
this value.  Plus some overhead for the network card driver to process the 
sending and receiving.

If you use the traditional cycle of:
- cycle sleep
- master_receive
- domain_process
- calc
- domain_queue
- master_send
- cycle sleep
- ...

Then you only have the sleep time available for the EtherCAT frames to go out 
and return.  If the calc time takes too long on a particular cycle then there 
may not be enough time for the frames to return and be ready.


Another problem is if you do have a widely varying calc time then you get a 
widely varying send time (and slave read time).  If using distributed clocks 
this may not be a problem (unless you miss the DC window), but without DC 
synchronization you can get some variance with when the IO on the slaves are 
being switched (or when a motor gets a new position Target).

The way I get around this is to use the following sequence:
- cycle sleep
- master_receive
- domain_process
- write cached values to domains
- domain_queue
- master_send
- calc - writing to cached values
- cycle sleep
- ...

The drawbacks of the above is that you need to calc and write values to a 
cached location else the master_receive / domain_process calls will overwrite 
your calced values with the returned packets data.  It also adds an extra cycle 
before read data is available.  You also have extra time overhead in managing 
the cached values and writing them before the send.  The upside is you have a 
consistent send time and have nearly all of the scan period available for the 
frames to be sent and received allowing you to perform the calculations in 
parallel.  Due to this you can also potentially reduce the overall cycle time, 
negating the problem of the reads being delayed an extra cycle.


Regards,
Graeme.


-Original Message-
From: etherlab-dev [mailto:etherlab-dev-boun...@etherlab.org] On Behalf Of 
Dr.-Ing. Matthias Schöpfer
Sent: Monday, 1 February 2016 9:27 p.m.
To: etherlab-dev@etherlab.org
Subject: Re: [etherlab-dev] Possible Realtime Issues with Ethercat Master and 
RT Preempt Kernel

Hi Thomas Winding,

thanks for your answer!

We are running kernel 3.12.31-rt45, since the newer kernel versions do not seem 
to run as reliable regarding real time at least on our hardware.

ethercat is from the mecurical repository and we use the e1000e driver.

Most of our problems we might have solved, since we had an issue with our cycle 
time / calculations where sometimes, our cycle lasted 600-800 microseconds, 
which seems to be way to long. We are now down to < 220 microseconds.

In rare cases, when we start the software, we still constantly running in the 
mentioned issues. When we stop and restart, everything is fine. I wonder, if we 
sometimes hit a misfortuned timing. As of lately, I was not able to reproduce 
it.

Regarding your suspicion: I wonder, if it is better to sync the transmits to 
the 1 ms cycle instead of the receives?!

Regards,

Matthias Schöpfer

On 02/01/2016 09:07 AM, Thomas Winding wrote:
> Hi Matthias Schöpfer
> 
> I have seen the same problem. I am also running at 1 ms and using 
> clock_nanosleep.
> 
>  I suspect that the problem arise when you send a new telegram before you 
> have received the previously send telegram.
> 
> Which version of the ethercat are you using?
> Which version of kernel are you using?
> 
> Best regard,
> 
> Thomas Winding
> 
> -Original Message-
> From: etherlab-dev [mailto:etherlab-dev-boun...@etherlab.org] On 
> Behalf Of Dr.-Ing. Matthias Schöpfer
> Sent: 26. januar 2016 14:22
> To: etherlab-dev@etherlab.org
> Subject: [etherlab-dev] Possible Realtime Issues with Ethercat Master 
> and RT Preempt Kernel
> 
> Hi!
> 
> We started using etherlab/ethercat and are quite impressed. Nice work!
> 
> We are running Linux with a RT_PREEMPT Kernel and e1000e ethercat driver. We 
> have to run at a cycle time of 1ms and we have jitter from clock_nanosleep of 
> about 15 microsecs max.
> 
> Nevertheless, we suffer from time to time from these:
> 
> EtherCAT WARNING 0: 2 datagrams UNMATCHED!
> EtherCAT 0: Domain 0: Working counter changed to 9/9.
> EtherCAT 0: Domain 0: Working counter changed to 0/9.
> 
> Especially, when we apply load to the system. From previous projects, I 
> experienced these effects when IRQ/Kernel Thread was not set to appropriate 
> RT Level.
> 
> My Question: has anybody experienced similar problems, and would it be worth 
> to investigate it. And if I decide to patch the kernel module, where is a 
> good starting point.
> 
> Thanks and regards,
> 
>   Matthias Schöpfer
> 
> --
> Dr. Matthias Schöpfer
> mz robolab 

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

[Graeme Foot]

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 and processing.  It does however 
ensure the size is matched correctly to the object you are about to write to.

I like the idea of this change for speed but I would probably still be calling 
ecrt_sdo_request_read() before the first write to confirm things are as 
expected.

Also as you say, the SDO Request must be created with the largest expected data 
size.  The largest I have come across so far is a STRING[16] (16 bytes).  Has 
anyone seen larger?


Regards,
Graeme.


-Original Message-
From: etherlab-dev [mailto:etherlab-dev-boun...@etherlab.org] On Behalf Of 
Gavin Lambert
Sent: Friday, 10 July 2015 7:14 p.m.
To: etherlab-dev@etherlab.org; Florian Pose
Subject: [QUARANTINE] [etherlab-dev] [PATCH] My patchset roundup July 2015
Importance: Low

Hi all,

It's been a while since I last posted my current patchset for Etherlab, so it 
seemed like a good time to share the newest ones.

As with the last set, this is based on stable-1.5 (specifically
4b0b906df1b40a1b5610282117b2c22581890575) and contains both my own patches and 
patches from others in the community, and I'm sharing them in case people find 
them useful and that hopefully they'll make it into mainline.

Having said that, it appears that some of the patches in here have made it into 
the default branch already; I haven't had time yet to inspect them and rebase 
my patchset onto that branch, but it's on my TODO list. :)

The series file included in the archive shows the intended application order 
(though you'll probably want to skip some of them if you're on default already).

Short descriptions (commit notes) are at the top of each patch; detailed 
descriptions for the older patches can be found in previous emails, but I'll 
give a bit more background on the newer patches below.  The older patches are 
unchanged except for possible defuzzing.

Before that though, just a reminder that patch 0006 dc_sync_vs_sys_time is 
only a partial fix; it works for slaves that have AssignActivate bits 0x3000 
set, and that don't mind the offset between SM events and SYNC events changing, 
but won't help other slaves -- they'll need a more comprehensive fix (fully 
recalculating the Sync Start Time).  It's probably not something I will do 
because my slaves do work with this, and I'm not sufficiently familiar with the 
way DC sync is calculated in Etherlab.

The new patches are the gavinl-2000 series, as follows:

gavinl-2001-reg_readwrite:
This adds an API ecrt_reg_request_readwrite and tool command 
reg_readwrite which will write register data and read back the values before 
the write in a single FPRW datagram.  This can be useful to ensure that the 
data is coherent and you don't miss an update.  It assumes Knud's rt-mutex 
patch has been applied; if not you'll have to switch the locking calls back.

gavinl-2002-reg_req_info:
This enhances some of the debug-level logging for register requests.

gavinl-2003-sdo_complete_upload:
This adds an API ecrt_master_sdo_upload_complete and extends tool 
command upload to support reading entire objects from a slave via SDO 
Complete Access (where supported by the slave).  As with the existing download 
functionality only Complete Access from subindex 0 is supported; future 
extension might be to support access from index 1 as well.  Note that when 
using the tool upload it will default to the octet_string data type, so you 
can use something like ethercat upload -p0 INDEX | hd to see the data 
formatted nicely.  It also assumes use of Knud's rt-mutex patch.

gavinl-2004-sdo_write_size:
This might be a little more controversial. :)  This modifies the 
ecrt_sdo_request_write API (so it's a breaking change) to also include the 
size of data to be written (this must be less than or equal to the size 
specified at the time the request was created).  Combined with the existing 
ecrt_sdo_request_index API, this allows you to re-use one request object for 
any SDO on the same slave, provided the initial size is large enough.
Previously you had to use at least one object per different object size, as 
there was no way to set the write size other than at creation time, and the 
write size was also altered whenever you did a read.  (Possible non-breaking 
alternative would be to make ecrt_sdo_request_set_data_size or something, but 
that seems messier.)

gavinl-2005-sdo_async_complete:
This is another breaking API change, which adds a boolean complete
parameter to ecrt_slave_config_create_sdo_request and 
ecrt_sdo_request_index.  This allows realtime requests to use Complete 
Access; prior to this patch this was only available to the non-realtime API.
(If this is judged to be *too* 

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

[Graeme Foot]

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 2015 5:29 p.m.
To: etherlab-dev@etherlab.org
Subject: [etherlab-dev] How to send the data EC-Master to EC-Slave by using 
program

Dear sir/mam

i am L.Veeranjaneyulu i am studying m.tech(embedded systems) in vel tech 
university chennai .By using EtherCAT i am doing project work in my m.tech .i 
have doubt how to interface the ethercat master and slave(Raspberry pi board)  
before that i have done basic testing it means master and slave communication 
below like this
1.successfully i installed Ethercat master(1.5.0)SOEM pacakges in one linux PC
2.EC_slave code is downloading in internet and insatlling another linux PC

and one more doubt by using program  how to pass the some dummy data EtherCAT 
master to slave  please help me as soon as possible
___
etherlab-dev mailing list
etherlab-dev@etherlab.org
http://lists.etherlab.org/mailman/listinfo/etherlab-dev

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

[Graeme Foot]

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. The stored SII data and PDOs will be detached from 
  the slaves prior to a scanning and re-attached during the scanning 
  without the need to fetch the SII data and PDOs once again. The SII 
  data and PDOs will however only be stored if the slave have a serial 
  number defined as this serial number will be used when re-attaching the SII 
  data and PDOs.

 Ooh, thanks for that one.  That's one of the performance holes that I was 
 planning on investigating myself soonish.



Hi,

None of my modules seem to have serial numbers (Beckhoff IO and yaskawa amps), 
or is that a bug that's got a patch?  I'm running the original 1.5.2 (+ misc 
patches).

G.
___
etherlab-dev mailing list
etherlab-dev@etherlab.org
http://lists.etherlab.org/mailman/listinfo/etherlab-dev