Re: [Etherlab-users] Embedded PC with out of the box support for igh-ethercat

[Graeme Foot]

Hi Nicola,



I received a Delivery Delayed email, So you might get it eventually:

n...@entidi.it<mailto:n...@entidi.it>

Server at entidi.it (2a02:6b8::311) returned '400 4.4.7 Message delayed'

27/11/2023 3:10:28 AM - Server at entidi.it (2a02:6b8::311) returned '451 
4.4.397 Error communicating with target host. -> 421 4.2.1 Unable to connect -> 
SocketError: Failed to connect. Winsock error code: 10051, Win32 error code: 
10051'





Re Buildroot, our project is commercial so we can supply all open source 
components and configuration to any customer who requests it (no one has so 
far).  We do this by supplying them a firmware update that contains all of the 
sources and config.



However, I'm happy to share the buildroot and related config files for the 
CX5230 (attached).  It uses:

  *   crosstool-ng 1.25.0 (building for x86_64, config attached)
  *   Buildroot 2022.05, released June 6th, 2022
  *   Linux Kernel 4.19.266 (vanilla, no patches except the patch by RTAI)
  *   RTAI 5.3 2023-01-04 update (it needed a couple of patches, attached)
 *   https://github.com/mmorandi/RTAI/tree/main/userfiles/downloads/RTAI
  *   EtherLab master
 *   https://gitlab.com/etherlab.org/ethercat.git
 *   stable-1.5 - eb35635b778cc56e12bb7c863618d7605eaf9884
 *   GavilL's Etherlab Master unofficial patchset - 20190904
 *   https://sourceforge.net/u/uecasm/etherlab-patches/ci/default/tree/



Note: we've created our own etherlabmaster buildroot package to use Gavin's 
patchset.  We've also created a few more patches (attached):

  *   previous patches not picked up by Gavin:

base/0033-retry-dc-register.patch

base/0034-Overlapped-PDOs-not-fitting-into-max-datagram-size-fix.patch

base/0035-Only-read-alias-from-0x0012-reg-if-SII-alias-is-zero.patch

features/diag/0003-diag2.patch(our version of diagnostics)

features/json-xml/0001-json-xml-tool-output.patch (alternate output 
formatting)

  *   new patches:

features/sii-file/0002-rename-request-firmware-direct.patch

features/sii-file/0003-kernel-updates.patch

base/0037-replace-linux-rtmutex-with-locks.h.patch

base/0038-ccat-AV-fix-on-link-down-on-startup.patch

base/0039-ccat-poll_rx-fix-only-getting-one-frame.patch



I think there's still a bug in the IGB network driver if you want to use it as 
an EtherCAT master port, but it looked OK for normal networking.  (We saw a 
couple of patches here: 
https://github.com/tormach/etherlab_master/commits/master/devices/igb)



Our Linux commandline options are:

nomodeset isolcpus=1 idle=poll tsc=reliable acpi_irq_nobalance irqaffinity=0



idle=poll was need to get the latency and jitter under control.





Regards,

Graeme.





-Original Message-

From: Fontana Nicola mailto:n...@entidi.it>>

Sent: Tuesday, November 28, 2023 3:04 AM

To: Luis Matos mailto:luis.ma...@agicore.pt>>; Graeme 
Foot mailto:graeme.f...@touchcut.com>>; 
etherlab-users@etherlab.org<mailto:etherlab-users@etherlab.org>

Subject: Re: [Etherlab-users] Embedded PC with out of the box support for 
igh-ethercat



Il giorno dom, 26/11/2023 alle 23.39 +, Luis Matos ha scritto:

> ...

> Às 23:14 de 26/11/2023, Graeme Foot escreveu:

> > ...

> > We build our system using Buildroot with the EtherLab EtherCAT

> > master and RTAI.  We've never used an arm based CPU, just x86 (and now 
> > x86_64).

> > ...



Many thanks for the answer, this was exactly the info I was looking for. For 
some reason your email never hit my mailbox, so I'm answering via Luis.



I plan to use buildroot on a headless PC as well but with plain preempt_rt. 
What I always fear when changing hardware is to loose weeks because you need to 
enable or disable some obscure flag when building the kernel.



Did you meet any issues or a vanilla kernel should just work out of the box? 
Sharing the buildroot config file would be awesome, but I can understand this 
is not always possible.



Thank you again.

--

Nicola


<>
<>
<>
<>
-- 
Etherlab-users mailing list
Etherlab-users@etherlab.org
https://lists.etherlab.org/mailman/listinfo/etherlab-users

Re: [Etherlab-users] Embedded PC with out of the box support for igh-ethercat

[Graeme Foot]

Hi Nicola,

We've been using Beckhoff CX2020's for around 12 years on over 300 machines 
running at 1000Hz (1ms).  They are now end of life'ing so have nearly completed 
updating our system to be able to work with CX5230's (needed new Linux kernel 
etc).  They are a bit slower than the CX2020's but have the power we need for 
our machines.  We run them headless connected to a Windows HMI PC.

If we need more power or a faster cycle in the future we've also briefly tested 
the new Ryzen CX2033 which looks like it runs around 3 times faster than the 
CX5230 for our system.

We build our system using Buildroot with the EtherLab EtherCAT master and RTAI. 
 We've never used an arm based CPU, just x86 (and now x86_64).

So, the Beckhoff PC's in our experience are fine for Linux.  Each system has an 
order code for purchasing it with a blank disk (aka no operating system or 
TwinCAT).  You just need to get past the hard sell.  Of course you are on your 
own once you buy it if it's not a hardware issue as they know nothing except 
TwinCAT, but that's the case with any PC you go with.

A summary of our system:
* CX2020 (soon to be CX5230)
* Linux 2.6.32 32bit (and now Linux 4.19 64bit)
* Our application uses approx. 21-35% of CPU time @ 1000Hz on CX2020 (25-63% on 
the CX5230, slower CPU and 64bit is a bit slower than 32bit Linux)
* RTAI
* thttpd to provide a web based configuration and diagnostic interface
* The majority of the root filesystem is provided by initrd with mount points 
for a small amount of config files that need permanent storage (CFast cards).  
So very minimal and infrequent HDD access and no problems with power outages or 
storage corruptions.  On a normal machine shutdown we do send a halt command to 
Linux to be nice.  We have had one CFast card release it's magic smoke, but we 
don't know why, we suspect it was a hardware failure.
* A couple of decades ago we had UPS's on a few machines, but the UPS's would 
fail more often than there were power cuts.  Also our machines can't do 
anything without power, so for us its just better to let the system turn off.
* We've used FSoE on four machines (using the EK1960 and various other TwinSAFE 
modules).  It was a machine with complex safety requirements (light curtains, 
deadman switches, bypasses plus other).  I wrote a Mailbox Gateway server for 
the EtherLab master so you could download the safety program to the TwinSAFE 
PLC (using the TwinSAFE Loader program supplied by Beckhoff) via the EtherLab 
master.  We looked at the costings of FSoE vs a standard Safety Relay on our 
standard machines a while back and although it was close FSoE was more 
expensive and more complex so we stayed with Safety Relays.

Regards,
Graeme


-Original Message-
From: Etherlab-users  On Behalf Of Fontana 
Nicola
Sent: Friday, November 24, 2023 9:37 PM
To: etherlab-users@etherlab.org
Subject: [Probable Spam] [Etherlab-users] Embedded PC with out of the box 
support for igh-ethercat

Hi all,

I'm in the process of trying to "standardize" the hardware stack I'm using

My requirements are:

1. a PC easily connectable to EtherCAT
2. native support for igh-ethercat
3. OPC/UA server via open62541
4. reliable 5 ms scan time

Lately I'm using Beckhoff CX9020-0100 but its performances are (mildly
put) crap. I fear to use other Beckhoff solutions because they seem to not 
support Linux natively (the fact that they keep pushing for TwinCAT is quite 
annoying).

I am also quite interested to know what do you use in general, how do you 
handle power outages (or more general the poweroff procedure) to avoid storage 
corruptions and if you use FSoE. Those would be a really great FAQs.

Thank you.
--
Nicola

--
Etherlab-users mailing list
Etherlab-users@etherlab.org
https://lists.etherlab.org/mailman/listinfo/etherlab-users
-- 
Etherlab-users mailing list
Etherlab-users@etherlab.org
https://lists.etherlab.org/mailman/listinfo/etherlab-users

Re: [Etherlab-users] EL3204 Analog PDO Data Issue

[Graeme Foot]

Hi David,

In cyclic_task() it looks like you are missing ecrt_domain_queue(domain1) just 
before ecrt_master_send().

I haven't checked for any further problems.

Regards,
Graeme.

From: Etherlab-users  On Behalf Of David 
Meehan
Sent: Thursday, November 9, 2023 7:15 AM
To: etherlab-users@etherlab.org
Subject: [Etherlab-users] EL3204 Analog PDO Data Issue

Hi all,

I'm completely new to EtherCAT, so bear with me. I'm in the process of trying 
to bring up an EL3204 4-channel analog input terminal. I'm running into an 
issue where it doesn't look like I'm getting any PDO data back. The working 
counter seems stuck at [0/1]. I have some code based on the dc_user example 
project (see code below). Our system has the following slave terminals.

// Taken from:
// > ethercat slaves
// 0  0:0  PREOP  +  EK1100 EtherCAT-Koppler (2A E-Bus)
// 1  0:1  PREOP  +  EL1809 16K. Dig. Eingang 24V, 3ms
// 2  0:2  PREOP  +  EL2809 16K. Dig. Ausgang 24V, 0.5A
// 3  0:3  PREOP  +  EL6224 (IO Link Master)
// 4  0:4  PREOP  +  EL7031 1K. Schrittmotor-Endstufe (24V, 1.5A)
// 5  0:5  PREOP  +  EL3204-0200 4K. Ana. Ein. PT1000 (RTD)

For right now I'm only interested in setting up the EL3204. I ran the "ethercat 
cstruct" command to get the sync manager and pdo listings for slave 5. Using 
those I was able to create a ec_pdo_entry_reg_t registration list containing 
the 4 channel values. I pass the sync info objects through 
ecrt_slave_config_pdos, and pass the domain registration list through 
ecrt_domain_reg_pdo_entry_list. Everything seems to work and the slave node 
goes to OP state after activating the master.  I printed out the byte offset 
mappings and it looks like ec  master was able to allocate a data buffer and 
assign the PDOs. Everything looks good.

But I'm still not getting any PDO data. Everything is reporting back as 0 and 
the WC is not incrementing. I ran a little experiment and setup some SDO 
request objects and tried reading back the sensor values using SDOs instead of 
PDOs, and it worked! The readings I'm getting back from the SDOs match the 
values I was seeing in TwinCAT. So I know the comms are good.

Anyway, if anyone has any suggestions, it would be appreciated.

Thanks,
Dave M



/*
*
*  Copyright (C) 2007-2022  Florian Pose, Ingenieurgemeinschaft IgH
*
*  This file is part of the IgH EtherCAT Master.
*
*  The IgH EtherCAT Master is free software; you can redistribute it and/or
*  modify it under the terms of the GNU General Public License version 2, as
*  published by the Free Software Foundation.
*
*  The IgH EtherCAT Master is distributed in the hope that it will be useful,
*  but WITHOUT ANY WARRANTY; without even the implied warranty of
*  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General
*  Public License for more details.
*
*  You should have received a copy of the GNU General Public License along
*  with the IgH EtherCAT Master; if not, write to the Free Software
*  Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA
*
*  ---
*
*  The license mentioned above concerns the source code only. Using the
*  EtherCAT technology and brand is only permitted in compliance with the
*  industrial property and similar rights of Beckhoff Automation GmbH.
*
/

#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include  /* sched_setscheduler() */

#include "ecrt.h"

//

// Application parameters
#define FREQUENCY 1000
#define CLOCK_TO_USE CLOCK_MONOTONIC
#define MEASURE_TIMING

// Taken from ethercat slaves
// 0  0:0  PREOP  +  EK1100 EtherCAT-Koppler (2A E-Bus)
// 1  0:1  PREOP  +  EL1809 16K. Dig. Eingang 24V, 3ms
// 2  0:2  PREOP  +  EL2809 16K. Dig. Ausgang 24V, 0.5A
// 3  0:3  PREOP  +  EL6224 (IO Link Master)
// 4  0:4  PREOP  +  EL7031 1K. Schrittmotor-Endstufe (24V, 1.5A)
// 5  0:5  PREOP  +  EL3204-0200 4K. Ana. Ein. PT1000 (RTD)

// Taken from ethercat cstruct

/* Master 0, Slave 5, "EL3204-0200"
* Vendor ID:   0x0002
* Product code:0x0c843052
* Revision number: 0x001200c8
*/

ec_pdo_entry_info_t slave_5_pdo_entries[] = {
{0x6000, 0x01, 1}, /* Underrange */
{0x6000, 0x02, 1}, /* Overrange */
{0x, 0x00, 4}, /* Gap */
{0x6000, 0x07, 1}, /* Error */
{0x, 0x00, 7}, /* Gap */
{0x6000, 0x0f, 1}, /* TxPDO State */
{0x6000, 0x10, 1}, /* TxPDO Toggle */
{0x6000, 0x11, 16}, /* Value */
{0x6010, 0x01, 1}, /* Underrange */
{0x6010, 0x02, 1}, /* Overrange */
{0x, 0x00, 4}, /* Gap */
{0x6010, 0x07, 1}, /* Error */
{0x, 0x00, 7}, /* Gap */
{0x6010, 0x0f, 1}, /* TxPDO State */
{0x6010, 0x10, 1}, /* TxPDO Toggle */
{0x6010, 0x11, 16}, /* Value */
{0x6020, 0x01, 1}, /* Underrange */

Re: [Etherlab-users] DMS72E4331 slave refuses to go OP

[Graeme Foot]

Hi,

There's kind of not enough info to go on, but here's some thoughts:

1) Re SAFEOP + ERROR: It looks like you are only using one domain.  Do you have 
the esi (.xml) file for the slave?  If so, does it require the read and write 
PDO's to be separated into separate read and write domains?  (a fair number of 
drives require this and some require it even if not stated in the esi file.)

You can also check the notLRW flag under the "ethercat slaves -v" command, but 
I've also had a slave that did not report this requirement but had a bug that 
required overlapping PDO's or separate domains (it did not like consecutive 
PDO's which is the Etherlab master default).


2) Re Alarm 0x001B: Have you confirmed that your realtime loop is active and at 
the correct cycle time when you are activating your master (and bringing the 
slaves to OP).  I see in your ethercat.c, app_ethercat_start() method that you 
are running a loop at 500us until the master is at EC_AL_STATE_OP (or 100s).  
Is this method returning ACTION_DONE or ACTION_WAITING?  When does the 0x001B 
alarm occur in relation to this method?  Have you confirmed you continue the 
ethercat realtime loop after app_ethercat_start() regardless of the result?

I suspect the SAFEOP + ERROR is a configuration problem and the 0x001B sync 
error a subsequent realtime loop problem.

Regards,
Graeme.

-Original Message-
From: Etherlab-users  On Behalf Of Fontana 
Nicola
Sent: Friday, September 15, 2023 8:32 AM
To: etherlab-users@etherlab.org
Subject: [Etherlab-users] DMS72E4331 slave refuses to go OP

Hi all,

I've an EtherCAT chain of 8 slaves, the last one being a driver I never used 
before.

After the ecrt_master_activate() call, everything goes OP but that
driver: it keeps giving me a "Sync manager watchdog" error (AL status 0x001B). 
Attached the kernel log (debug level 1) of that run.

Has anyone experienced this kind of issue? Is there some workaround I can try? 
I disabled the watchdog (EC_WD_DISABLE to all SMs [1]) and wrote 0 to the ESC 
register 0x410 but the error simply changed to "Invalid watchdog configuration" 
(AL status 0x001F).

According to the FAQ in the old website [2], configuration failures are most 
likely caused by wrong SII implementation: is this the case?

[1] 
https://gitlab.com/entidi/libmachinery/-/blob/master/src/ethercat-slaves.c?ref_type=heads#L773
[2] 
https://web.archive.org/web/20210922180832/https://www.etherlab.org/en/ethercat/faq.php

Thank you in advance.
--
Nicola

-- 
Etherlab-users mailing list
Etherlab-users@etherlab.org
https://lists.etherlab.org/mailman/listinfo/etherlab-users

Re: [Etherlab-users] Looking for etherCAT test cases

[Graeme Foot]

Hi Raz,

We user EtherCAT for multi-axis coordinated motion control along with PLC style 
IO control.  Used for running profile cutting machines.  
(https://kineticusa.com/)

I can only see a need for encryption if your app is connecting to enterprise 
level systems, but that doesn’t have much to do with the EtherCAT side.  
Speaking of the enterprise side, EtherCAT do have the “EtherCAT Automation 
Protocol (EAP)” 
https://www.ethercat.org/en/downloads/downloads_BB6D7FF18F2B47DDB3474168D50EE864.htm.
  I personally don’t see a need for that (unless you are trying to communicate 
with a TwinCAT master) as there are many alternative options that can be 
integrated into an application.  e.g. MQTT, CoAP, XMPP, AMQP, DDS, netrpc, roll 
your own etc.

One thing I’ve had in the back of my mind for a while is a Soft TwinSAFE logic 
controller (to provide similar functionality to the Beckhoff EL6910 module).  
It could be possible through time based redundancy and diversity.  Of course 
certification for a commercial environment is a major problem.

The main thing I’m waiting on is version 1.6 to include all of the GavinL 
patchset functionality.

Regards,
Graeme.

From: Etherlab-users  On Behalf Of Raz
Sent: Friday, 16 December 2022 20:15
To: Etherlab Users 
Subject: [Etherlab-users] Looking for etherCAT test cases

Hey everyone
I am interested to know what sort of applications EtherCAT is used for and how 
to extend it, for
example, should we add encryption  ?

Thank you
Raz
-- 
Etherlab-users mailing list
Etherlab-users@etherlab.org
https://lists.etherlab.org/mailman/listinfo/etherlab-users

[Etherlab-users] Patch for --enable-regalias

[Graeme Foot]

Hi,

I have attached a patch for the --enable-regalias option.

--enable-regalias enables reading slave aliases from register 0x0012.  When 
enabled all slaves read 0x0012, replacing any alias value read from the SII.  
However, if you set a new alias on a slave (with the "ethercat alias" function) 
the 0x0012 register is not updated (and is readonly to the master so can't be). 
 This requires the slave to be repowered/restarted for the register to update.  
So if you restart the master without repowering/restarting the slave, the 
master will read the old alias from the 0x0012 register.

The patch will now only read register 0x0012 if the SII alias is non-zero.  
This slightly shortens the slave scan for most slaves (that have aliases) and 
allows the master to use the correct alias on restart.  However, if you are 
resetting the alias (setting it to zero) the slave will still require a 
repower/reset.

Note you shouldn't be setting aliases via the "ethercat alias" function on 
slaves with dials/dipswitches, or slaves that only support 0x0012 (and not SII 
aliases), so we can ignore any issues these slaves could have.

The patch is based on mercurial revision 2679 (33b922ec1871) and the gavinl 
patchset 20171108.


Regards,
Graeme Foot.


0001-Only-read-alias-from-0x0012-reg-if-SII-alias-is-zero.patch
Description: 0001-Only-read-alias-from-0x0012-reg-if-SII-alias-is-zero.patch
-- 
Etherlab-users mailing list
Etherlab-users@etherlab.org
https://lists.etherlab.org/mailman/listinfo/etherlab-users

Re: [Etherlab-users] Kjellberg Q3000 slave problems

[Graeme Foot]

Hi Martin,

I found a workaround last night.  I have split the read and write PDO's into 
separate read and write domains.  I had not tried this earlier as the flag 
requiring this is not set in the slave and TwinCAT is working from one domain.  
However TwinCAT is using overlapped PDO's which I did not try as that does not 
suit our application.

Re: the dc sync settings in the ESI file, I tried enabling SM-Synchron cyclic 
operation mode under TwinCAT and the slave exhibited similar problems.  After 
talking to the supplier they recommended not using DC or SM-Synchron mode at 
all.  So I tried hardcoding removing the DC supported flag from the slave but 
it made no difference.

So it is now working, but still with a manually loaded SII file via the loading 
firmware from file mechanism.

Thanks,
Graeme.


From: Steih, Martin 
Sent: Tuesday, 22 November 2022 20:39
To: Graeme Foot 
Subject: AW: Kjellberg Q3000 slave problems

Hi,

Are you sure it does not support dc sync?


  
Synchron
FreeRun/SM-Synchron
#x0
0
0
0
  


I found this in your ESI file under Q3000, and the problem description you just 
sent is precisely the same one we face when dc sync settings are not correct or 
fitting.

i. A. Martin Steih
Projektleiter
Entwicklung

[cid:image001.png@01D8FF20.1CB46390]<https://www.lachmann-rink.de/>

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

Hommeswiese 129, 57258 Freudenberg | Otto-Hahn-Straße 18-20, 44227 Dortmund
Geschäftsführer: Dipl.-Ing. Arjan Bijlard, Dipl.-Inf. Claudius Rink | 
Amtsgericht Siegen, HRB 2600
Von: Etherlab-users 
mailto:etherlab-users-boun...@etherlab.org>>
 Im Auftrag von Graeme Foot
Gesendet: Dienstag, 15. November 2022 08:02
An: etherlab-users@etherlab.org<mailto:etherlab-users@etherlab.org>
Betreff: [Etherlab-users] Kjellberg Q3000 slave problems

Hi,

We are trying to get a Kjellberg Q3000 plasma slave up and running in our 
system.  Unfortunately it is getting to SAFEOP and going to SAFEOP + Error.  
Also while in SAFEOP it drops 1 or two packets out of three, causing the master 
to enter an endless rescan loop.  The Q3000 gets to OP successfully under 
TwinCAT.  I have wireshark logs of both startup sequences and can't find 
anything obvious that is causing the issue.


  *   I'm using the 1.5.2 master with the GavinL patchset.
  *   I have enabled the --enable-regalias option as this slave uses the 0x0012 
register to specify the slave alias.
  *   There are errors in the slaves SII.  I have generated an SII using 
TwinCAT and I'm loading it via the firmware loading patch (using 
EC_SII_OVERRIDE).  As far as I can tell it is correct.  (I needed to increase 
the esi files Eeprom ByteSize to 4096 so that it would include the categories 
information, as per: https://etherlab.org/en/ethercat/faq.php).  I've attached 
the SII bin file in case anyone is interested.
  *   I gather the slave firmware uses the ET9300 slave stack code version 5.10.
  *   The slave allows LWR (i.e. both read and write data in the same domain)
  *   It supports distributed clocks, but not DC Sync.
  *   It looks like TwinCAT configures the read and write domain data to 
overlap.  Our master does not.

The Sync manager config is the same between TwinCAT and EtherLab
SM0: 0010800026000100
SM1: 0014800022000100
SM2: 0018250064000100
SM3: 001c41002100

The FMMU config is mostly the same, the only difference I can see is the 
virtual start address and that they overlap
TwinCAT:
FMMU0: 00012507001800020100
FMMU1: 00014107001c00010100
EtherLab:
FMMU0: 0f002507001800020100
FMMU1: 34004107001c00010100

TwinCAT also sets up a third FMMU for what I assume is a slave working counter 
status domain.
FMMU2: 000901000d0800010100

One thing that the TwinCAT master does that EtherLab does not is set the "Error 
Ack" flag to true when requesting a slave state change.  E.g.:
EtherCAT datagram: Cmd: 'APWR' (2), Len: 2, Adp 0x1, Ado 0x120, Cnt 1
Header
AL Ctrl (0x120): 0x0011, Al Ctrl: INIT, Error Ack
   0001 = Al Ctrl: INIT (0x1)
  ...1  = Error Ack: True
  ..0.  = Id: False
Working Cnt: 1

I've attached the esi file.  As far as I can tell there's nothing particularly 
special about the slave.  We are using the Q3000 (460-480V) slave 
(ProductCode="#x3023"), but they are all the same configuration.


Tomorrow I'll try patching the master to set the Error Ack flag in the INIT 
state change datagram, but apart from that I'm currently out of ideas for 
things to try.  Does anyone have any other ideas from problem slaves you've 
encountered?

Regards,
Graeme Foot



-- 
Etherlab-users mailing list
Etherlab-users@et

Re: [Etherlab-users] Implementation of Safety - Terminals EL6900, EL1904 and EL2904

[Graeme Foot]

Hi Uwe,

We have implemented FSoE with an EK1960, an EL1904 and an EL2904 in the past.  
The EK1960 is a bit different to the EL6900 as it also has it's own IO.  
However it seems like your PDO configuration is missing a lot of data both in 
what the device thinks it has configured (Currently mapped PDO entries) and 
what you are attempting to write (Entries to map).

First check that your project has been loaded on the EL6900 correctly, has been 
activated and the whole system repowered.  Also verify the project crc.  (We 
use the Beckhoff TwinSAFE Loader application to load the safety program via 
Linux.  This requires a Mailbox Gateway Server, which is a patch I submitted to 
EtherLab a while ago.)  The safety program is what defines the PDO layout on 
the EL6900.  The master cstruct command may give you the correct PDO mapping 
but it's a while ago so I'm not sure on that one.  I remember configuring my 
structs manually based on what was in the safety program as shown by TwinCAT.  
E.g.: in TwinCAT 3, if you go to I/O, Devices, Device 1, Term 1 (EL6900), 
Process Data tab it should show you the expected PDO layout for the terminal.

[cid:image001.png@01D8B6E2.EB61F800]

[cid:image002.png@01D8B6E2.EB61F800]

Order the PDO's by Sync Manager, then PDO Assignment, then PDO Content.  Don't 
worry if you have duplicate index:subindex values.  They should be unique 
within a particular PDO group.  However you will need to use 
"ecrt_slave_config_reg_pdo_entry_pos" rather than 
"ecrt_slave_config_reg_pdo_entry" if you have any duplicates.

For each safety device (EL1904, EL2904) the EL6900 controls, your application 
must copy 48 input bits and 48 output bits (6 bytes) between the EL6900's PDO 
and each safety devices PDO's within your realtime read-calc-write loop.  e.g. 
copy:
EL6900 TxPDO 0x1a00 -> EL1904 RxPDO 0x1600 (length 48 bits)
EL6900 TxPDO 0x1a01 -> EL2904 RxPDO 0x1600 (length 48 bits)
EL1904 TxPDO 0x1a00 -> EL6900 RxPDO 0x1600 (length 48 bits)
EL2904 TxPDO 0x1a00 -> EL6900 RxPDO 0x1601 (length 48 bits)

I think I got those the right way around.  You will also need to check which 
blocks the EL1904/EL2904 actually map to based on you safety program.

Also for housekeeping, I put all of the safety related PDO's in their own 
domain.

Regards,
Graeme.


From: Etherlab-users  On Behalf Of 
Stegemann Uwe
Sent: Tuesday, 23 August 2022 02:02
To: etherlab-users@etherlab.org
Subject: [Etherlab-users] Implementation of Safety - Terminals EL6900, EL1904 
and EL2904


Hi erveryone,

I want to setup TwinSafe Logic Terminals, EL6900, EL2904 and EL1904.I've 
created a Safety-Project with TwinCat3 and downloaded the safety-logic to the 
EL6900. I use the default settings from TwinCat3. Now I want to implement it to 
the etherlab-master.
The Default PDO-Mapping of the EL6900 - Terminal:

SM0: PhysAddr 0x1000, DefaultSize  256, ControlRegister 0x26, Enable 1
SM1: PhysAddr 0x1100, DefaultSize  256, ControlRegister 0x22, Enable 1
SM2: PhysAddr 0x1200, DefaultSize2, ControlRegister 0x24, Enable 1
  RxPDO 0x1600 "FSOE RxPDO-Map 001"
PDO entry 0x7000:01,  8 bit, "FSOE Command"
PDO entry 0x7001:01,  8 bit, "SubIndex 001"
PDO entry 0x7000:03, 16 bit, "FSOE CRC 001"
PDO entry 0x7000:02, 16 bit, "FSOE ConnID"
  RxPDO 0x1601 "FSOE RxPDO-Map 002"
PDO entry 0x7010:01,  8 bit, "FSOE Command"
PDO entry 0x7011:01,  8 bit, "SubIndex 001"
PDO entry 0x7010:03, 16 bit, "FSOE CRC 001"
PDO entry 0x7010:02, 16 bit, "FSOE ConnID"
  RxPDO 0x17f0 "DEVICE RxPDO-Map Standard In Vars"
PDO entry 0xf201:01,  1 bit, "SubIndex 001"
PDO entry 0xf201:02,  1 bit, "SubIndex 002"
PDO entry 0xf201:03,  1 bit, "SubIndex 003"
PDO entry 0xf201:04,  1 bit, "SubIndex 004"
PDO entry 0xf201:05,  1 bit, "SubIndex 005"
PDO entry 0xf201:06,  1 bit, "SubIndex 006"
PDO entry 0xf201:07,  1 bit, "SubIndex 007"
PDO entry 0xf201:08,  1 bit, "SubIndex 008"
  RxPDO 0x17ff "DEVICE RxPDO-Map Control"
PDO entry 0xf200:01, 16 bit, "Control"
SM3: PhysAddr 0x1d00, DefaultSize2, ControlRegister 0x20, Enable 1
  TxPDO 0x1a00 "FSOE TxPDO-Map 001"
PDO entry 0x6000:01,  8 bit, "FSOE Command"
PDO entry 0x6001:01,  8 bit, "SubIndex 001"
PDO entry 0x6000:03, 16 bit, "FSOE CRC 001"
PDO entry 0x6000:02, 16 bit, "FSOE ConnID"
  TxPDO 0x1a01 "FSOE TxPDO-Map 002"
PDO entry 0x6010:01,  8 bit, "FSOE Command"
PDO entry 0x6011:01,  8 bit, "SubIndex 001"
PDO entry 0x6010:03, 16 bit, "FSOE CRC 001"
PDO entry 0x6010:02, 16 bit, "FSOE ConnID"
  TxPDO 0x1bff "DEVICE TxPDO-Map Status"
PDO entry 0xf100:01,  3 bit, "Safety Project State"
PDO entry 0x:00,  4 bit, "Gap"
PDO entry 0xf100:08,  1 bit, "Login Active"
PDO entry 0xf100:09,  1 bit, "Input Size Mismatch"
PDO entry 0xf100:0a,  1 bit, "Output Size Mismatch"
PDO entry 0x:00,  4 bit, "Gap"
PDO entry 0xf100:0f,  1 bit, "TxPDO State"
PDO entry 0xf100:10,  1 bit, "TxPDO Toggle"

When I want to add PDOs, 

Re: [Etherlab-users] data cannot be transferred or stored to the application because of local control

[Graeme Foot]

Hi Vincent,

>From the doco:
Set counter limits For writing to index 0x80n1:1B "Reset counter value" and 
index 0x80n1:1A "Limit counter value" the value 0x72657375 (ASCII: "user") must 
be set in 0xF008 "Code word"

https://download.beckhoff.com/download/Document/io/ethercat-terminals/el5102en.pdf
 page 151

Regards,
Graeme.


From: Etherlab-users  On Behalf Of 
BUSSIERES Vincent
Sent: Friday, 4 March 2022 07:32
To: etherlab-users@etherlab.org
Subject: [Etherlab-users] data cannot be transferred or stored to the 
application because of local control

Dear Etherlab users,

I'd like to configure limit counter of a Beckhoff EL5102 counter module via Coe 
0x8001 :0x1A.
I try < ethercat download -ax -px -tuint32 0x8001 0x1A 0x > command but 
I get the following error message : < data cannot be transferred or stored to 
the application because of local control >

Have you got an idea ?

Regards

-- 
Etherlab-users mailing list
Etherlab-users@etherlab.org
https://lists.etherlab.org/mailman/listinfo/etherlab-users

Re: [Etherlab-users] Using DC to syncronise to reference slave clock

[Graeme Foot]

but couldn't found usage of ARMW command. Is there 
any example for ARMW command?

Best regards,
Celil





Hi,



How should we use DC to synchronize to the slave reference clock? I implemented 
it by looking at the rtai_rtdm example. But it's not working as desired.



I guess I'm missing something. I would expect to change my sleep times to 
synchronize to slave clock. I couldn't see something like that.



* How can I stop drifting my send time relative to slave clock?



* Also, how can I measure the time I'm sending relative to cycle start of the 
slave clock? Can I just modulo the value returned by 
ecrt_master_reference_clock_time() to the cycle time?



For a little background:



We are using EtherCAT master for several years. We are using PREEMPT_RT patch 
with ubuntu 16.04, kernel 4.9.178. We had downloaded Gavin Lambert's unofficial 
patch sets a few years ago.



Normally we are using master PC as the master clock. This option is mentioned 
as option a in various mails in the mail list.



With this method we successfully integrated many servo motor drives from 
several vendors. We are generally using 1ms and 2ms cycle times on different 
machines.



We have recently added Mitsubishi Jet EtherCAT series to our database. Although 
this drive is working fine under lab conditions, somehow it gave 
synchronization errors from time to time at the machine. There are 4 drives and 
several IOs from Beckhoff on the bus.



Mitsubishi engineers claim that, the problem occurs because we are not 
synchronized to the slave reference clock. And ask us to change our mechanism 
to synchronize the master PC to the reference slave. This method is also 
described as the option b in mail list.



So I copied the related blocks from rtai_rtdm example in the examples folder. I 
modified RTAI specific functions to user space functions. At our lab we are 
testing two Jet drives connected to our master PC. The drives are changing to 
OP mode and I can control the position and speed.

There is no error in dmesg messages. Also no error on the display of the 
drives. But I hear knocking sounds in every few minutes while rotating.

It seems my send time is drifting relative to slave clock. But I don't see how 
can I stop drifting.



Best regards,



Celil


--- Begin Message ---
Hi,

I have attached a test app to have a look at.  It is a (very) cut down version 
of how my app works.  Of course I use RTAI, so it won't be compatible with your 
Xenomi environment.


In main.c at the top of runECat() I have a list of EtherCAT devices and their 
addresses.  It is hard coded here but can of course be loaded from a config 
file.  The device names match devices in the etherCATSlaves.c file.

etherCATMaster.c contains the code to configure and run the master.  
etherCATSlaves.c contains each slave's code.

yaskawaSGDV_create()
- configures the device and gets the PDO command offsets

yaskawaSGDV_prepareToRun()
- calculates each commands address (after the domains are populated and 
allocated)
- sets cyclic synchronous position mode (optional, the mode can be set at any 
time while running)
- sets the control word to zero, just in case

yaskawaSGDV_run()
- is called once each scan.  add code here to control the axis

yaskawaSGDV_prepareToStop()
- is called when the app is closing.  add any code here to clean up your axis


Note: In this app the prepareToStop() functions are called once and then the 
app is shut down immediately.  In reality you should continue your realtime 
cycle until all of the devices are stopped, disabled and safe to turn off.  The 
app also relies on some of my patches.


I hope this helps

Regards,
Graeme.



-Original Message-
From: etherlab-users [mailto:etherlab-users-boun...@etherlab.org] On Behalf Of 
Graeme Foot
Sent: Wednesday, 16 August 2017 10:42 a.m.
To: Rahul Deshpande ; etherlab-users@etherlab.org
Subject: Re: [etherlab-users] No CoE communication

Hi,

I've been asked to let you know what master version and patches I'm using.  I'm 
still running an old version (2526 from the stable-1.5 branch, 12/02/2013).  
The script I use to download it is attached (004-etherlab_master).

I use buildroot to create my linux system, so the script  tar's the master 
folder and puts it in the buildroot downloads folder.  Note: I also use a 
really old buildroot from 2012 with a few modifications, but I have attached 
the mk file that it uses.

The patches that I apply are also attached.

The build options I use are:
--with-linux-dir=""
--enable-cycles
--enable-rtdm
--enable-e100
--enable-e1000
--enable-e1000e
--enable-cx2100


I use RTAI, but that shouldn't make any difference.


Regards,
Graeme.


-Original Message-----
From: etherlab-users [mailto:etherlab-users-boun...@etherlab.org] On Behalf Of 
Graeme Foot
Sent: Tuesday, 15 August 2017 12:39 p.m.
To: Rahul Deshpande ; etherlab-users@etherlab.org
Subject: Re: [etherlab-users] No CoE communication

Remember to reply-all to mail the for

[Etherlab-users] patch file to add json/xml output to ethercat graph and slaves commands

[Graeme Foot]

Hi,

I've attached a patch file that adds json and xml output options for the graph 
and slaves ethercat master commands.  It's written against Gavin Lamberts 
20171108 patch set.

I'm currently only using json output from the slaves command.  I also added the 
options for the graph command as I was originally intending to use it as a 
basis for a layout page but I ended up needing more information that was 
supplied by the slaves command.

Regards,
Graeme Foot.


0001-json-xml-tool-output.patch
Description: 0001-json-xml-tool-output.patch
-- 
Etherlab-users mailing list
Etherlab-users@etherlab.org
https://lists.etherlab.org/mailman/listinfo/etherlab-users

Re: [Etherlab-users] Patchset for large FMMU

[Graeme Foot]

Hi Nabila,

I have attached the patch.

(Please note that I use EtherLab revision hg:33b922ec1871 and Gavin Lamberts 
patchset “Etherlab master patchset 20171108” so hopefully it applies cleanly to 
your configuration.)

Regards,
Graeme.


From: Nabila Gina Nastiti 
Sent: Tuesday, 23 November 2021 21:45
To: Graeme Foot 
Subject: Patchset for large FMMU

Dear Mr. Foot,

My name is Nabila Gina Nastiti. I found your post to Mr. Gellen titled "Running 
a large number of Slave" as below :
https://www.mail-archive.com/etherlab-users@etherlab.org/msg03587.html

In your post, you mentioned about a patchset for Mr. Gellen problem. I would 
like to kindly ask, could you share this patchset to me? I have been trying to 
find it however I could not find it anywhere.

I thank you in advance for your attention and help.

Best regards

Nabila Gina Nastiti


0001-Overlapped-PDOs-not-fitting-into-max-datagram-size-fix.patch
Description: 0001-Overlapped-PDOs-not-fitting-into-max-datagram-size-fix.patch
-- 
Etherlab-users mailing list
Etherlab-users@etherlab.org
https://lists.etherlab.org/mailman/listinfo/etherlab-users

Re: [Etherlab-users] strange behaviour with sdo configuration

[Graeme Foot]

Hi Vincent,

Using ecrt_slave_config_sdo8() is fine for a boolean value.  The log you sent 
was trying to set a value of 0x90, but for a Boolean it would need to be either 
0x00 or 0x01.  The error could have been due to trying to set an out of range 
value (though it should have been a different error code).

The only reference on google I can find for 0x0821 (except for error number 
listings) is https://github.com/OpenEtherCATsociety/SOEM/issues/311, but that 
doesn't look relevant.  This is related to how the PDO configuration is set up.

Being a new module it may be a firmware bug.  It's probably time to talk to the 
Beckhoff office that supplied the module for support.

Let us know if you find anything further, I may want to use the module in the 
future.

Regards,
Graeme


From: BUSSIERES Vincent 
Sent: Monday, 18 October 2021 21:01
To: Graeme Foot ; etherlab-users@etherlab.org
Subject: RE: strange behaviour with sdo configuration


Hi Graeme,



Thanks for your reply. I noticed that "Enable C reset" is a boolean, but I use 
"ecrt_slave_config_sdo8" function to set its value. I don't find another 
function to write only in a boolean.



It seems that there is a problem with EL5102 because at the first start, I can 
read its state (PREOP) with ethercat tool. I try to download sdo using download 
command and I get the same error message. I do the same with 8001:1b (uint32) 
and get the same error.


hemeriadm@CT:/opt/etherlab/bin$ ./ethercat slaves
0  0:0  PREOP  +  EK1100 EtherCAT-Koppler (2A E-Bus)
1  0:1  PREOP  +  EL5102 2K. Inc. Encoder 5V (RS422,TTL)
2  0:2  PREOP  +  EL5101-0010 1K. Inc. Encoder 5V (20 Mio. Inkremente/s)
3  0:3  PREOP  +  0x009a:0x00030924
4  0:4  PREOP  +  0x009a:0x00030924

./ethercat download -a0 -p1 -tint32 0x8001 0x1b 0
SDO transfer aborted with code 0x0821: Data cannot be transferred or stored 
to the application because of local control

[ 1161.448299] EtherCAT DEBUG 0: ecrt_master_sdo_download(master = 
0x820ec9de, slave_position = 1, index = 0x8000, subindex = 0x01, data = 
0xce5642c8, data_size = 1, abort_code = 0x9602e91e)
[ 1161.448303] EtherCAT DEBUG 0-main-1: Scheduling SDO download request.
[ 1161.455021] EtherCAT DEBUG 0-main-1: Processing SDO request...
[ 1161.455027] EtherCAT DEBUG 0-main-1: Downloading SDO 0x8000:01.
[ 1161.455029] EtherCAT DEBUG: 01
[ 1161.455033] EtherCAT DEBUG 0-main-1: Expedited download request:
[ 1161.455034] EtherCAT DEBUG: 00 20 2F 00 80 01 01 00 00 00
[ 1161.479016] EtherCAT DEBUG 0-main-1: Download response:
[ 1161.479018] EtherCAT DEBUG: 00 20 80 00 80 01 21 00 00 08
[ 1161.479029] EtherCAT ERROR 0-main-1: SDO download 0x8000:01 (1 bytes) 
aborted.
[ 1161.479038] EtherCAT ERROR 0-main-1: SDO abort message 0x0821: "Data 
cannot be transferred or stored to the application because of local control".
[ 1161.479042] EtherCAT ERROR 0-main-1: Failed to process SDO request.
Regards








____
De : Graeme Foot mailto:graeme.f...@touchcut.com>>
Envoyé : dimanche 17 octobre 2021 21:34
À : BUSSIERES Vincent; 
etherlab-users@etherlab.org<mailto:etherlab-users@etherlab.org>
Objet : RE: strange behaviour with sdo configuration


Hi Vincent,



Looking at the EL5102 documentation 0x8000:01 is "Enable C reset" and is 
Boolean.  It looks like are trying to set a value of 0x90.  It should be set to 
a value of either 0x00 to disable (default) or 0x01 to enable.



Regards,

Graeme.



From: BUSSIERES Vincent 
mailto:vincent.bussie...@hemeria-group.com>>
Sent: Friday, 15 October 2021 20:02
To: Graeme Foot mailto:graeme.f...@touchcut.com>>; 
etherlab-users@etherlab.org<mailto:etherlab-users@etherlab.org>
Subject: RE: strange behaviour with sdo configuration



Dear All,



When I configure sdos I get the following error:



SDO abort message 0x0821: "Data cannot be transferred or stored to the 
application because of local control".



Could you tell what is local control and why I get this error when I configure 
sdo only?



Regards



..

[ 1484.880041] EtherCAT 0:   Datagram domain0-0-main: Logical offset 
0x, 44 byte, type LRW at 1bb3a22b.
[ 1484.880041] EtherCAT DEBUG 0: Stopping master thread.
[ 1484.880045] EtherCAT DEBUG 0: Master IDLE thread exiting...
[ 1484.880048] EtherCAT 0: Master thread exited.
[ 1484.880049] EtherCAT DEBUG 0: FSM datagram is f8a4fd2a.
[ 1484.880050] EtherCAT 0: Starting EtherCAT-OP thread.
[ 1484.880165] EtherCAT DEBUG 0: mmap()
[ 1484.880166] EtherCAT DEBUG 0: Operation thread running with fsm interval = 
4000 us, max data size=45000
[ 1484.880167] EtherCAT WARNING 0: 1 datagram UNMATCHED!
[ 1484.880168] EtherCAT DEBUG 0: Vma fault, virtual_address = ab9367f9, 
offset = 0, page = d5c21541
[ 1484.887120] EtherCAT DEBUG 0-main-1: Processing internal SDO request...
[ 1484.887121] EtherCAT DEBUG 0-main-1: Downloading SDO 0

Re: [Etherlab-users] strange behaviour with sdo configuration

[Graeme Foot]

Hi Vincent,

Looking at the EL5102 documentation 0x8000:01 is "Enable C reset" and is 
Boolean.  It looks like are trying to set a value of 0x90.  It should be set to 
a value of either 0x00 to disable (default) or 0x01 to enable.

Regards,
Graeme.

From: BUSSIERES Vincent 
Sent: Friday, 15 October 2021 20:02
To: Graeme Foot ; etherlab-users@etherlab.org
Subject: RE: strange behaviour with sdo configuration

Dear All,

When I configure sdos I get the following error:

SDO abort message 0x0821: "Data cannot be transferred or stored to the 
application because of local control".

Could you tell what is local control and why I get this error when I configure 
sdo only?

Regards

..
[ 1484.880041] EtherCAT 0:   Datagram domain0-0-main: Logical offset 
0x, 44 byte, type LRW at 1bb3a22b.
[ 1484.880041] EtherCAT DEBUG 0: Stopping master thread.
[ 1484.880045] EtherCAT DEBUG 0: Master IDLE thread exiting...
[ 1484.880048] EtherCAT 0: Master thread exited.
[ 1484.880049] EtherCAT DEBUG 0: FSM datagram is f8a4fd2a.
[ 1484.880050] EtherCAT 0: Starting EtherCAT-OP thread.
[ 1484.880165] EtherCAT DEBUG 0: mmap()
[ 1484.880166] EtherCAT DEBUG 0: Operation thread running with fsm interval = 
4000 us, max data size=45000
[ 1484.880167] EtherCAT WARNING 0: 1 datagram UNMATCHED!
[ 1484.880168] EtherCAT DEBUG 0: Vma fault, virtual_address = ab9367f9, 
offset = 0, page = d5c21541
[ 1484.887120] EtherCAT DEBUG 0-main-1: Processing internal SDO request...
[ 1484.887121] EtherCAT DEBUG 0-main-1: Downloading SDO 0x8000:01.
[ 1484.887122] EtherCAT DEBUG: 90
[ 1484.887123] EtherCAT DEBUG 0-main-1: Expedited download request:
[ 1484.887123] EtherCAT DEBUG: 00 20 2F 00 80 01 90 00 00 00
[ 1484.895117] EtherCAT DEBUG 0: Configuration changed (aborting state check).
[ 1484.895119] EtherCAT DEBUG 0-main-0: Checking system time offset.
[ 1484.911104] EtherCAT WARNING 0: No app_time received up to now, abort DC 
time offset calculation.
[ 1484.911105] EtherCAT DEBUG 0: Requesting OP...
[ 1484.947171] EtherCAT DEBUG 0-main-1: Download response:
[ 1484.947172] EtherCAT DEBUG: 00 20 80 00 80 01 21 00 00 08
[ 1484.947174] EtherCAT ERROR 0-main-1: SDO download 0x8000:01 (1 bytes) 
aborted.
[ 1484.947176] EtherCAT ERROR 0-main-1: SDO abort message 0x0821: "Data 
cannot be transferred or stored to the application because of local control".
[ 1484.947177] EtherCAT ERROR 0-main-1: Failed to process SDO request.


____
De : Graeme Foot mailto:graeme.f...@touchcut.com>>
Envoyé : vendredi 15 octobre 2021 01:45
À : BUSSIERES Vincent; 
etherlab-users@etherlab.org<mailto:etherlab-users@etherlab.org>
Objet : RE: strange behaviour with sdo configuration


Hi Vincent,



1) I think 4339:05 relates to CoE object 0x10F3:05.  Set the value to 0.



Try setting it manually via the ethercat command line before starting your app 
to start with.  If that helps, set it via your app before going active.





2) Some slave modules support diagnostic messages.  These are on the slave 
itself, under the 0x10F3 CoE index.  The EtherLab master doesn't have a 
framework to automatically read them and It's a reasonably big topic to get 
your head around.  Here's a starting point:

https://infosys.beckhoff.com/english.php?content=../content/1033/el34x3/1859331211.html=210180382886825810



Note: a lot of diagnostic ID's are module specific.  They can be found in the 
modules esi file (Beckhoff EL5xxx.xml) under the  node.  There's 
only around 11 for this module, but the page above lists common diag messages.





3) I have found that for Beckhoff modules that only support fixed PDO entries, 
if you get the PDO configuration wrong (e.g. your cstruct was generated for an 
older revision of the module) you will get errors the first time you apply the 
config (listed in dmesg).  The modules PDO settings are however updated with 
the new, but incorrect information.  Internally the module will ignore these 
mistakes and use its fixed PDO config.  Note: this is why you should only use 
the cstruct command after a clean boot of a slave.



If you restart your app, without repowering the slave, then no errors will be 
reported this second time because the PDO configuration you are applying now 
matches what the slave is reporting, even though it's wrong.



I have found some modules do not get to OP when they have these PDO config 
errors, though usually I find they get to SAFEOP + Error.



I'm just speculating that this particular module may have an issue with 
applying an incorrect PDO configuration in combination with applying SDO 
configuration.





4) As a new thought, what SDO configuration calls are you making?  This module 
supports CoE complete access.  If you are setting multiple subindex entries 
under one index, try setting it as a complete access call instead.





Note: we also use the EL5101.  For this and most other modules we also call the 

Re: [Etherlab-users] strange behaviour with sdo configuration

[Graeme Foot]

Hi Vincent,

1) I think 4339:05 relates to CoE object 0x10F3:05.  Set the value to 0.

Try setting it manually via the ethercat command line before starting your app 
to start with.  If that helps, set it via your app before going active.


2) Some slave modules support diagnostic messages.  These are on the slave 
itself, under the 0x10F3 CoE index.  The EtherLab master doesn't have a 
framework to automatically read them and It's a reasonably big topic to get 
your head around.  Here's a starting point:
https://infosys.beckhoff.com/english.php?content=../content/1033/el34x3/1859331211.html=210180382886825810

Note: a lot of diagnostic ID's are module specific.  They can be found in the 
modules esi file (Beckhoff EL5xxx.xml) under the  node.  There's 
only around 11 for this module, but the page above lists common diag messages.


3) I have found that for Beckhoff modules that only support fixed PDO entries, 
if you get the PDO configuration wrong (e.g. your cstruct was generated for an 
older revision of the module) you will get errors the first time you apply the 
config (listed in dmesg).  The modules PDO settings are however updated with 
the new, but incorrect information.  Internally the module will ignore these 
mistakes and use its fixed PDO config.  Note: this is why you should only use 
the cstruct command after a clean boot of a slave.

If you restart your app, without repowering the slave, then no errors will be 
reported this second time because the PDO configuration you are applying now 
matches what the slave is reporting, even though it's wrong.

I have found some modules do not get to OP when they have these PDO config 
errors, though usually I find they get to SAFEOP + Error.

I'm just speculating that this particular module may have an issue with 
applying an incorrect PDO configuration in combination with applying SDO 
configuration.


4) As a new thought, what SDO configuration calls are you making?  This module 
supports CoE complete access.  If you are setting multiple subindex entries 
under one index, try setting it as a complete access call instead.


Note: we also use the EL5101.  For this and most other modules we also call the 
reset command as our first SDO config item to ensure there are no unexpected 
configuration options set, e.g.:
ecrt_slave_config_sdo32(dev->slaveConfig, 0x1011, 0x01, 0x64616F6C);

Graeme.


From: BUSSIERES Vincent 
Sent: Friday, 15 October 2021 12:00
To: Graeme Foot ; etherlab-users@etherlab.org
Subject: RE: strange behaviour with sdo configuration


Thank you Graeme for these thoughts.

I used a similar module (EL5101), I hadn't this problem but pdo assignment was 
different. I used cstruct command to get pdo informations.



1) With which value should I set the value in index 4339:5 ?



2) How can I see diagnostic messages ? with dmesg?



3) Is it possible to encounter PDO error only during sdo configuration? I don't 
understand why at the second start there is no PDO error ?



Regards


De : Graeme Foot mailto:graeme.f...@touchcut.com>>
Envoyé : jeudi 14 octobre 2021 23:36
À : BUSSIERES Vincent; 
etherlab-users@etherlab.org<mailto:etherlab-users@etherlab.org>
Objet : RE: strange behaviour with sdo configuration


Hi Vincent,



I don't have a module to play with so no real idea.  But here's some thoughts:



1) The Beckhoff esi file "Beckhoff EL5xxx.xml" file shows setting the value in 
index 4339:5 to  on transition from Init to PreOp:



  IP

  4339

  5

  





You could try setting this value before activating your master.  I think 4339 
is decimal so relates to 0x10F3:05.



0x10F3:05 is the Diagnostics Flags value.  This is 0x0001 by default which 
reports the presence of a DiagMessage as an emergency.





2) The module supports diagnostics.  Check the Diagnostic messages for issues 
during the startup with and without the SDO configs.





3) On first application start from a cold boot, without any of the SDO config 
calls, check the dmesg log for any errors with assigning the PDO's for the 
module.  It may be that if PDO errors are encountered along with the SDO config 
calls the module stays in PREOP + Error.  But without the SDO config calls it 
may get to OP OK.



On the second start the PDO's will already have been changed so the master / 
slave won't report any errors (even though the module will ignore the changes 
internally as they are fixed PDO's).  Due to no PDO errors being reported the 
second time it may be why the SDO config calls succeed.





Regards,

Graeme.





From: Etherlab-users 
mailto:etherlab-users-boun...@etherlab.org>>
 On Behalf Of BUSSIERES Vincent
Sent: Friday, 15 October 2021 09:11
To: etherlab-users@etherlab.org<mailto:etherlab-users@etherlab.org>
Subject: [Etherlab-users] strange behaviour with sdo configuration



Dear Etherlab users,



I bought a 

Re: [Etherlab-users] strange behaviour with sdo configuration

[Graeme Foot]

Hi Vincent,

I don't have a module to play with so no real idea.  But here's some thoughts:

1) The Beckhoff esi file "Beckhoff EL5xxx.xml" file shows setting the value in 
index 4339:5 to  on transition from Init to PreOp:

  IP
  4339
  5
  


You could try setting this value before activating your master.  I think 4339 
is decimal so relates to 0x10F3:05.

0x10F3:05 is the Diagnostics Flags value.  This is 0x0001 by default which 
reports the presence of a DiagMessage as an emergency.


2) The module supports diagnostics.  Check the Diagnostic messages for issues 
during the startup with and without the SDO configs.


3) On first application start from a cold boot, without any of the SDO config 
calls, check the dmesg log for any errors with assigning the PDO's for the 
module.  It may be that if PDO errors are encountered along with the SDO config 
calls the module stays in PREOP + Error.  But without the SDO config calls it 
may get to OP OK.

On the second start the PDO's will already have been changed so the master / 
slave won't report any errors (even though the module will ignore the changes 
internally as they are fixed PDO's).  Due to no PDO errors being reported the 
second time it may be why the SDO config calls succeed.


Regards,
Graeme.


From: Etherlab-users  On Behalf Of 
BUSSIERES Vincent
Sent: Friday, 15 October 2021 09:11
To: etherlab-users@etherlab.org
Subject: [Etherlab-users] strange behaviour with sdo configuration

Dear Etherlab users,



I bought a Beckhoff EtherCAT Terminal, 2-channel encoder interface EL5102. This 
product has just been released.

I encounter problems when I configure sdos with < ecrt_slave_config_sdo8 > or < 
ecrt_slave_config_create_sdo_request > functions called before < 
ecrt_master_activate > as for my other slaves.

This slave doesn't switch at the OP State and stay in PRE-OP State with error < 
E > :



"1 0:1 PREOP E EK5102 2K. Inc. Encoder 5V (RS422, TTL)"



I noticed that when I comment sdo configuration methods and run my application, 
slave switches to OP State.

After being switched one time to OP, if I uncomment configuration methods and 
run once again my application, slave behaviour seems to be OK, slave switches 
to OP State.



I don't understand why after the fisrt boot, there is such a problem ?



Could you help solving this problem ?



Best regards
-- 
Etherlab-users mailing list
Etherlab-users@etherlab.org
https://lists.etherlab.org/mailman/listinfo/etherlab-users

Re: [Etherlab-users] EoE messages are disturbing CoE communication

[Graeme Foot]

Hi Ferdinand,

It looks like a kernel version compatibility issue.  I'm still using Linux 
Kernel 2.6.11 so I can't really help beyond saying maybe try an older Kernel 
(one of the LTS's, 4.19 maybe?) or look up the changes made to the kernel for 
those data types and try adding your adding your own patches to compensate.

Someone else may be able to help further.

Regards,
Graeme.

From: Ferdinand Postema - LR 
Sent: Thursday, 26 August 2021 22:07
To: Graeme Foot ; etherlab-users@etherlab.org
Subject: RE: EoE messages are disturbing CoE communication

Hi Graeme,

Thanks for your quick response and the link to the Gavin Lambert patch set!

I try to compile the IgH ethercat master with this patch set, but I get a 
compile error.

Some OS properties:
Dirtribution:   Ubuntu 20.04
Linux:5.11.0-27-lowlatency
Gcc:   9.3.0-17ubuntu1-20.04
Ld:  2.34

I'm using the following commands:

cd /home/ferdi/hg
hg clone -u 33b922ec1871 http://hg.code.sf.net/p/etherlabmaster/code 
ethercat_patch
cd ethercat_patch
hg clone http://hg.code.sf.net/u/uecasm/etherlab-patches .hg/patches
hg qpush -a
./bootstrap
./configure --prefix=/usr/local --disable-8139too --enable-generic --disable-eoe
make
make modules

I get the following compile error:

make -C "/usr/src/linux-headers-5.11.0-27-lowlatency" 
M="/home/ferdi/hg/ethercat_patch" modules
make[1]: Entering directory '/usr/src/linux-headers-5.11.0-27-lowlatency'
  CC [M]  /home/ferdi/hg/ethercat_patch/examples/mini/mini.o
  LD [M]  /home/ferdi/hg/ethercat_patch/examples/mini/ec_mini.o
  CC [M]  /home/ferdi/hg/ethercat_patch/master/cdev.o
In file included from /home/ferdi/hg/ethercat_patch/master/master.h:46,
 from /home/ferdi/hg/ethercat_patch/master/cdev.c:42:
/home/ferdi/hg/ethercat_patch/master/device.h:95:20: error: field 
'timeval_poll' has incomplete type
   95 | struct timeval timeval_poll;
  |^~~~
/home/ferdi/hg/ethercat_patch/master/cdev.c:91:14: error: initialization of 
'vm_fault_t (*)(struct vm_fault *)' {aka 'unsigned int (*)(struct vm_fault *)'} 
from incompatible pointer type 'int (*)(struct vm_fault *)' 
[-Werror=incompatible-pointer-types]
   91 | .fault = eccdev_vma_fault
  |  ^~~~
/home/ferdi/hg/ethercat_patch/master/cdev.c:91:14: note: (near initialization 
for 'eccdev_vm_ops.fault')
cc1: some warnings being treated as errors
make[3]: *** [scripts/Makefile.build:287: 
/home/ferdi/hg/ethercat_patch/master/cdev.o] Error 1
make[2]: *** [scripts/Makefile.build:518: /home/ferdi/hg/ethercat_patch/master] 
Error 2
make[1]: *** [Makefile:1848: /home/ferdi/hg/ethercat_patch] Error 2
make[1]: Leaving directory '/usr/src/linux-headers-5.11.0-27-lowlatency'
make: *** [Makefile:946: modules] Error 2

Any suggestions?

Kind regards,

Ferdinand Postema

From: Graeme Foot mailto:graeme.f...@touchcut.com>>
Sent: 23 August 2021 23:11
To: Ferdinand Postema - LR 
mailto:f.n.post...@tudelft.nl>>; 
etherlab-users@etherlab.org<mailto:etherlab-users@etherlab.org>
Subject: RE: EoE messages are disturbing CoE communication

Hi Ferdinand,

The vanilla Etherlab master does not separate the different mailbox protocols.  
However, the Gavin Lambert patchset applied to the master does.  The patchset 
can be found at:
https://sourceforge.net/u/uecasm/etherlab-patches/ci/default/tree/#readme<https://urldefense.proofpoint.com/v2/url?u=https-3A__sourceforge.net_u_uecasm_etherlab-2Dpatches_ci_default_tree_-23readme=DwMFAg=XYzUhXBD2cD-CornpT4QE19xOJBbRy-TBPLK0X9U2o8=xcqiP100iU6SF3NlGrtZl-C3jz-A5-phbUVoejbCeyo=PTHySrPZbwZRPvGbLGnLsOyMeB-1CBVY6mNTpspgSNM=uLpG6imAGxxaNePvyg9tgzKEslVGNq6AloGI6HlHZ4w=>

If you have Ethernet over EtherCAT (EoE) enabled it requires the 
ecrt_master_callbacks() method to be used to provide synchronization between 
the master realtime thread and the EoE thread.


Note: This method needs to be called from a kernel space application, with 
kernel space callback methods.  If you have a user space only application 
things become a lot more complex.

If you don't want to use EoE then disabling it is fine and the above patchset 
should sort out the rest.


Regards,
Graeme.

From: Etherlab-users 
mailto:etherlab-users-boun...@etherlab.org>>
 On Behalf Of Ferdinand Postema - LR
Sent: Tuesday, 24 August 2021 04:12
To: etherlab-users@etherlab.org<mailto:etherlab-users@etherlab.org>
Subject: [Etherlab-users] EoE messages are disturbing CoE communication

Hello,

I'm using a Beckhoff EL6695 Ethercat Bridge terminal. This terminal can do many 
things, but I use it to exchange variables between 2 masters (IgH master and a 
CX2040). This device is also capable of multiple mailbox protocols (CoE, EoE 
and AoE).

Recently I updated the IgH-master. Before the master was updated, I experienced 
an intermittent (rar

Re: [Etherlab-users] EoE messages are disturbing CoE communication

[Graeme Foot]

Hi Ferdinand,

The vanilla Etherlab master does not separate the different mailbox protocols.  
However, the Gavin Lambert patchset applied to the master does.  The patchset 
can be found at:
https://sourceforge.net/u/uecasm/etherlab-patches/ci/default/tree/#readme

If you have Ethernet over EtherCAT (EoE) enabled it requires the 
ecrt_master_callbacks() method to be used to provide synchronization between 
the master realtime thread and the EoE thread.


Note: This method needs to be called from a kernel space application, with 
kernel space callback methods.  If you have a user space only application 
things become a lot more complex.

If you don't want to use EoE then disabling it is fine and the above patchset 
should sort out the rest.


Regards,
Graeme.

From: Etherlab-users  On Behalf Of 
Ferdinand Postema - LR
Sent: Tuesday, 24 August 2021 04:12
To: etherlab-users@etherlab.org
Subject: [Etherlab-users] EoE messages are disturbing CoE communication

Hello,

I'm using a Beckhoff EL6695 Ethercat Bridge terminal. This terminal can do many 
things, but I use it to exchange variables between 2 masters (IgH master and a 
CX2040). This device is also capable of multiple mailbox protocols (CoE, EoE 
and AoE).

Recently I updated the IgH-master. Before the master was updated, I experienced 
an intermittent (rarely) startup problem: Sometimes the  communication could 
not be established. Bringing the slaves to INIT and then back to OP resolved 
the problem. After the upgrade, it was almost not possible to get the 
communication up and running. After many hours of debugging I discovered that 
the problem is that the EoE messages are disturbing the CoE communication. I 
disabled the EoE protocol in the IgH-master with the -disable-eoe option when 
configuring and building the software. Now I'm able to get the communication 
running with de newer version of the IgH-master. But the occasional startup 
problems remain...

While using wireshark to debug the problem further I still see EoE messages. 
These messages originate from the terminal and not from the IgH master. But 
these messages do disturb the CoE communication. The following short sample of  
a wireshark trace shows the problem:

No.   TimeSourceDestination   Proto Length  Info
875   0.0300:0a:cd:30:30:f3 ff:ff:ff:ff:ff:ff ECAT  1052  'FPWR': Len: 
1024, Adp 0x1, Ado 0x1000, Wc 0  Mbx(CoE SDO Req : 'Initiate Upload' (2) 
Idx=0x1c12 Sub=0)
876   0.00024202:0a:cd:30:30:f3 ff:ff:ff:ff:ff:ff ECAT  1052  'FPWR': Len: 
1024, Adp 0x1, Ado 0x1000, Wc 1  Mbx(CoE SDO Req : 'Initiate Upload' (2) 
Idx=0x1c12 Sub=0)
877   0.0200:0a:cd:30:30:f3 ff:ff:ff:ff:ff:ff ECAT  60'FPRD': Len: 
8, Adp 0x1, Ado 0x808, Wc 0
878   0.00024002:0a:cd:30:30:f3 ff:ff:ff:ff:ff:ff ECAT  60'FPRD': Len: 
8, Adp 0x1, Ado 0x808, Wc 1
879   0.0200:0a:cd:30:30:f3 ff:ff:ff:ff:ff:ff ECAT  1052  'FPRD': Len: 
1024, Adp 0x1, Ado 0x1600, Wc 0
880   0.000244fe80::d9ac:9249:59ff:e2c5 ff02::1:2   EoE-DHCPv6  1052
  EoE(Solicit XID: 0xaa5bf0 CID: 0001000120481c730001052d4758 )
881   0.0500:0a:cd:30:30:f3 ff:ff:ff:ff:ff:ff ECAT  1052  'FPWR': Len: 
1024, Adp 0x1, Ado 0x1000, Wc 0  Mbx(CoE SDO Req : 'Initiate Upload' (2) 
Idx=0x1c13 Sub=0)
882   0.00023702:0a:cd:30:30:f3 ff:ff:ff:ff:ff:ff ECAT  1052  'FPWR': Len: 
1024, Adp 0x1, Ado 0x1000, Wc 1  Mbx(CoE SDO Req : 'Initiate Upload' (2) 
Idx=0x1c13 Sub=0)
883   0.0200:0a:cd:30:30:f3 ff:ff:ff:ff:ff:ff ECAT  60'FPRD': Len: 
8, Adp 0x1, Ado 0x808, Wc 0
884   0.00024202:0a:cd:30:30:f3 ff:ff:ff:ff:ff:ff ECAT  60'FPRD': Len: 
8, Adp 0x1, Ado 0x808, Wc 1
885   0.0200:0a:cd:30:30:f3 ff:ff:ff:ff:ff:ff ECAT  1052  'FPRD': Len: 
1024, Adp 0x1, Ado 0x1600, Wc 0
886   0.000243fe80::d9ac:9249:59ff:e2c5 ff02::1:2   EoE-DHCPv6  1052
  EoE(Solicit XID: 0xaa5bf0 CID: 0001000120481c730001052d4758 )

In frame 875/876, the IgH master requests an SDO-upload
In frame 877/878, the IgH master checks the SM-status to check if a mailbox 
message is ready to be read.
In frame 879/880, the IgH master reads the mailbox message, expecting a 
response to the SDO-upload request, but receives an EoE message. This EoE 
message is probably generated by the slave much earlier, but was not read by 
the master. Due to this EoE message, the master aborts the 'upload RxPDO 
assignment/mapping'
In frame 881-886, the same happens when the IgH master tries to upload the 
TxPDO assignment/mapping. Apparently, another EoE message was already queued 
for transmission to the master.

I think the IgH master does not properly separate these mailbox protocols. The 
one should never influence the other. I think to realize this, would require a 
large change in the IgH master.

Maybe a quick fix would be to ignore the other mailbox protocol messages during 
CoE communication (or when -disable-eoe is specified) and re-read the mailbox 
until a CoE meassage is read.

I hope this 

Re: [Etherlab-users] Configuring EL7047 stepper driver

[Graeme Foot]

Hi Nicola,

The first thing is don't try to configure slaves via the ethercat command line 
utility.  You need to run an application (see the examples folder for various 
example applications).
The second thing is don't try to manually configure each slave by direct SDO 
calls, there are functions that do all of that for you that you call as part of 
the application.

The applications first step is to configure the slaves using for example:
  ecrt_master_get_slave
  ecrt_master_slave_config
  ecrt_slave_config_pdos
  ecrt_slave_config_create_sdo_request
  ecrt_slave_config_reg_pdo_entry
  ecrt_slave_config_sdo8 etc
  ecrt_slave_config_dc

A devices default configuration can be retrieved using the "ethercat cstruct" 
command.  You can then modify it if your slave allows modification.  You can 
download the slaves esi file from Beckhoff if you want to use a non-standard 
configuration, using it as a reference to set up your own cstruct data.

Once ready, the application calls ecrt_master_activate() and then calls the 
following commands (as a minimum) in a realtime loop:
  ecrt_master_receive
  ecrt_domain_process
  ecrt_domain_queue
  ecrt_master_send

The application will bring the slaves up from PREOP to OP, applying the 
configuration along the way.  If a slave is repowered the master will 
automatically re-apply the configuration and bring it back to OP.

Regards,
Graeme

-Original Message-
From: Etherlab-users  On Behalf Of Fontana 
Nicola
Sent: Sunday, 25 July 2021 01:02
To: etherlab-users@etherlab.org
Subject: [Etherlab-users] Configuring EL7047 stepper driver

Hi all,

I think this issue is not related to the ethercat software per-se but maybe 
someone has already met something similar or can point me into the right 
direction.

I'm trying to configure the EL7047 stepper driver in position controller mode 
without encoder (by default it is in velocity mode):


https://www.beckhoff.com/en-en/products/i-o/ethercat-terminals/el7xxx-compact-drive-technology/el7047.html

No matter what: it stays in PREOP state after having configured it.
Whenever I try to put it in SAFEOP/OP I get:

Failed to set SAFEOP state, slave refused state change (PREOP + ERROR).
AL status message 0x001E: "Invalid input configuration".

Here is the full script I'm using:

https://gitlab.com/-/snippets/2153453

It runs successfully and I am sure the settings are changed (I checked them 
many times). For a couple of parameters, with a datatype smaller than a byte 
but bigger than boolean, I had to explicitely set the datatype to `uint8`, and 
AFAIK this is the only thing that "stinks".

The Beckhoff manual keeps reporting TwinCAT screenshots instead of explaining 
how things work but (1) I do not have access to TwinCAT and (2) I have less 
than zero interest in depending on a software blob.

Not sure it is relevant, but here is the output of `ethercat sl`:

0  0:0  PREOP  +  EK1100 EtherCAT-Koppler (2A E-Bus)
1  0:1  PREOP  +  EL1809 16K. Dig. Eingang 24V, 3ms
2  0:2  PREOP  +  EL1809 16K. Dig. Eingang 24V, 3ms
3  0:3  PREOP  +  EL1809 16K. Dig. Eingang 24V, 3ms
4  0:4  PREOP  +  EL2809 16K. Dig. Ausgang 24V, 0.5A
5  0:5  PREOP  +  EL2808 8Ch. Dig. Output 24V, 0.5A
6  0:6  PREOP  +  EL7047 1K. Schrittmotor-Endstufe (50V, 5A)

Ciao.
--
Nicola


-- 
Etherlab-users mailing list
Etherlab-users@etherlab.org
https://lists.etherlab.org/mailman/listinfo/etherlab-users
-- 
Etherlab-users mailing list
Etherlab-users@etherlab.org
https://lists.etherlab.org/mailman/listinfo/etherlab-users

Re: [Etherlab-users] Etherlab patch with SII_PATH

[Graeme Foot]

Hi James,

The patch is part of Gavin Lamberts patch set:
https://sourceforge.net/u/uecasm/etherlab-patches/ci/default/tree/

Specifically: features/sii-file/0001-load-sii-from-file.patch

Adds the ability to override the slave's SII data with a file (useful if the 
slave's SII EEPROM is too small to hold the correct data).

The functionality is disabled by default.
At configure time, you can use --enable-sii-override to activate it, using the 
standard udev/hotplug lookup process.
At configure time, you can use --enable-sii-override=/lib/firmware (or another 
path) to activate it using a direct loading method.
It will cooperate as expected with features/sii-cache, although note that it’s 
not as efficient as it could be (it will reload some of the values that 
features/sii-cache already read when checking the SII cache; but trying to 
improve this would make the code really awkward).


Regards,
Graeme.

From: James Benway 
Sent: Friday, 25 June 2021 02:03
To: Graeme Foot 
Subject: Etherlab patch with SII_PATH

Hi Graeme,

I am working on an etherlab project which requires a slave that does not 
support rewriting of the sii information and the slave is missing default 
PDO/sync information.  I have come across an old etherlab-users 
thread<https://etherlab-users.etherlab.narkive.com/wSM75pfA/problem-reading-sii-configuration-from-slave>
 in which you discuss a patch of the etherlab master with support of optional 
slave configuration via local ESI files.  Do you still happen to have access to 
this source code?  If so, would you be so kind as to let me know where I can 
find it so I do not have to reinvent the wheel?

Thank you!

--
James Benway
Senior Embedded Systems Engineer
Dynamic Systems Inc.
[cid:image001.png@01D769A9.262F69F0]


The contents of this e-mail and any attachments are confidential. They are 
intended for the named recipient(s) only.  If you are not the intended 
recipient of this message, please notify the sender immediately and delete the 
message and any attachments. Thank you.
-- 
Etherlab-users mailing list
Etherlab-users@etherlab.org
https://lists.etherlab.org/mailman/listinfo/etherlab-users

Re: [Etherlab-users] Ethercat slave

[Graeme Foot]

Hi Vincent,

We have developed a slave using an Infineon XMC4800 development board (V2).  
All our slave required was the EtherCAT interface and a 100base T ethernet port 
for a small run of slaves, so we didn't need to develop a custom slave.

Infineon provides the DAVE development environment that runs within Microsoft 
Visual Studio.  The DAVE projects use the Beckhoff SSC tools (Slave Stack Code) 
for the base EtherCAT API.  I don't know how well DAVE would support 
non-Infineon products.

Our slave has uses two projects, a bootloader and the main application.  The 
bootloader allows firmware updates via FoE.

I found the Infineon forums reasonably helpful and they had quite a few helpful 
examples.  The biggest hurdle was that a number of the relevant examples were 
for the previous Beckhoff SSC (V5.11) and I was using V5.12, so I needed to 
work out a few of the required changes myself.  (This was in 2019, not sure 
what versions things are now.)

The ETG forum will also be required: 
https://www.ethercat.org/memberarea/en/forum.htm.  One of the forums posts bug 
fixes for each SSC release version.

Another issue is licensing.  The XMC4800 development board came with its own 
slave license.  If you are developing from scratch with FPGA's for example you 
will need to purchase slave licenses by the bundle.  Separately you will also 
need to:
- Apply to ETG for a Vendor ID.  This is only given out to organizations, not 
individuals.  This gives you access to the SSC and gives you your unique vendor 
ID.
- Purchase the Conformance Test Tool (CTT) license.  This is an annual license 
that is required for the entire time you want to sell / distribute / support 
your own EtherCAT slaves.  (Available from your local Beckhoff office.)  You 
must test all slaves / firmware releases against the CTT to be able to sell / 
distribute your slaves.


Regards,
Graeme.


From: Etherlab-users  On Behalf Of 
BUSSIERES Vincent
Sent: Tuesday, 8 June 2021 08:36
To: etherlab-users@etherlab.org
Subject: [Etherlab-users] Ethercat slave

Sorry for that irrelevant question, but I'd like to develop an EtherCAT slave 
on a PC.
Has any of you ever done that and with which EtherCAT stack ?

Best regards

Vincent BUSSIERES
Responsable Technique Logiciel

[1572337113342]
ZE Ma Campagne
36, Impasse Félix Nadar
16000 ANGOULEME
Tel: 33 (0)9.72.40.36.52
www.hemeria-group.com
P Afin de contribuer au respect de l'environnement, merci de n'imprimer ce 
courriel qu'en cas de nécessité.
Ce message et les fichiers pouvant être attachés sont confidentiels, réservés à 
l'usage unique des destinataires et n'engagent HEMERIA sous aucune forme que ce 
soit.
This email and any files transmitted with it are confidential, intented solely 
for the unique use of the recipients and don't commit HEMERIA.



-- 
Etherlab-users mailing list
Etherlab-users@etherlab.org
https://lists.etherlab.org/mailman/listinfo/etherlab-users

Re: [Etherlab-users] Running a large number of slaves

[Graeme Foot]

Hi Nir,

I had a bit more of a look.  The "if (fmmu->logical_domain_offset >= 
candidate_start)" condition ratchets up the candidate_start until the FMMU is 
not overlapped with any previous FMMUs.

However, the test as to whether the FMMU no longer fits in the current datagram 
should occur for all FMMUs.

I have attached a patch that moves the size check outside of the above 
condition.  In doing so I have also changed datagram_first_fmmu to be set to 
valid_fmmu.

I have also added a number of checks to ensure the combined size of overlapped 
FMMUs, that need to be handled as a block, do not exceed the maximum datagram 
size.

Please note that I haven’t checked to see if it compiles.

Regards,
Graeme.

From: Graeme Foot
Sent: Thursday, 6 May 2021 10:49
To: 'Geller, Nir' ; Gavin Lambert 
; Richard Hacker ; 
etherlab-users@etherlab.org
Subject: RE: [Etherlab-users] Running a large number of slaves


Hi Nir,



I don't use overlapping PDO’s and don't know the constraints on them, but 
looking at the code, if you remove the "if (fmmu->logical_domain_offset >= 
candidate_start)" condition there will be a couple of problems.



1) When creating the first datagram the "emplace_datagram()" call will receive 
an incorrect data size.  The data size is calculated by "valid_start - 
datagram_offset".  "valid_start" for the current FMMU assumes that it is at the 
end of the previous FMMU, but due to the overlap it is still at the start of 
the previous FMMU.  On the other hand it looks like the datagrams working 
counter will include counts for the first FMMU, and be missed for the second 
datagram.  The domain working counter should however be correct.



2) It looks like a slave with more than 2 overlapping FMMU's can stack their tx 
and rx data separately.  If a datagram fills up after the first 2 FMMU's the 
data will be split between two datagrams which probably won't work at all.  
e.g. if 3 won’t fit, 1 & part of 2 will end up in the first datagram, the rest 
of 2, 3 & 4 will end up in the second datagram:

rx: ---1 ---3---

tx: --2- ---4



(I have come across slaves with more than 2 FMMU’s, but don’t know if they can 
also be overlapped.)



So, I don’t think this is the correct fix.





There is a “TODO overlapping PDOs" section in slave_config.c that look’s like 
it is a thought on how to deal with the problem, but it looks like it is trying 
to align pairs of rx/tx data rather than allowing the example in #2 above.



I suspect the answer will be for “ec_domain_finish()” to refer back to the 
slave and if it has overlapping pdo’s make sure all pdo’s from the slave make 
it into the same datagram.  I’m out of time to look further at the moment.



Regards,

Graeme.





-Original Message-
From: Etherlab-users 
mailto:etherlab-users-boun...@etherlab.org>>
 On Behalf Of Geller, Nir
Sent: Wednesday, 5 May 2021 21:20
To: Gavin Lambert mailto:gavin.lamb...@tomra.com>>; 
Richard Hacker mailto:h...@igh.de>>; 
etherlab-users@etherlab.org<mailto:etherlab-users@etherlab.org>
Subject: Re: [Etherlab-users] Running a large number of slaves



I think I got caught in a very specific situation that isn't handled properly 
by the code.



I will try to describe it more accurately.



The last slave in the topology supports overlapping PDOs, therefore Rx and Tx 
FMMUs logical_domain_offset have the same value.

Suppose until the last slave the accumulated domain size is 1400, the last 
slave's Rx PDO size is 30, and the Tx PDO size is 150.



The last slave's Rx FMMU is handled first by the loop.

The condition

if (fmmu->logical_domain_offset + fmmu->data_size - datagram_offset > 
(EC_MAX_DATA_SIZE)) is not met, and candidate_start is set to the value of the 
Rx FMMU logical_domain_offset.



The Tx FMMU is handled second by the loop, but this time the condition if 
(fmmu->logical_domain_offset >= candidate_start) is not met.



Being the last slave in the topology, the loop ends, and only 1 LRW datagram in 
size > 1500 is created after the condition if (domain->data_size > 
datagram_offset)



Removing completely the condition

if (fmmu->logical_domain_offset >= candidate_start)



fixes the error, but I'm not sure if it safe.

What do you think?



Thanks,



Nir.





-Original Message-

From: Gavin Lambert mailto:gavin.lamb...@tomra.com>>

Sent: Wednesday, May 5, 2021 1:25 AM

To: Geller, Nir 
mailto:nir.gel...@servotronix.com>>; Richard Hacker 
mailto:h...@igh.de>>; 
etherlab-users@etherlab.org<mailto:etherlab-users@etherlab.org>

Subject: RE: [Etherlab-users] Running a large number of slaves



I've never used overlapped PDOs myself, but something doesn't sound right in 
your description below.



As I understand it, overlapping only supports overlapping the input and output 
FMMUs on the same slave; you can never overlap d

Re: [Etherlab-users] Running a large number of slaves

[Graeme Foot]

Hi Nir,



I don't use overlapping PDO’s and don't know the constraints on them, but 
looking at the code, if you remove the "if (fmmu->logical_domain_offset >= 
candidate_start)" condition there will be a couple of problems.



1) When creating the first datagram the "emplace_datagram()" call will receive 
an incorrect data size.  The data size is calculated by "valid_start - 
datagram_offset".  "valid_start" for the current FMMU assumes that it is at the 
end of the previous FMMU, but due to the overlap it is still at the start of 
the previous FMMU.  On the other hand it looks like the datagrams working 
counter will include counts for the first FMMU, and be missed for the second 
datagram.  The domain working counter should however be correct.



2) It looks like a slave with more than 2 overlapping FMMU's can stack their tx 
and rx data separately.  If a datagram fills up after the first 2 FMMU's the 
data will be split between two datagrams which probably won't work at all.  
e.g. if 3 won’t fit, 1 & part of 2 will end up in the first datagram, the rest 
of 2, 3 & 4 will end up in the second datagram:

rx: ---1 ---3---

tx: --2- ---4



(I have come across slaves with more than 2 FMMU’s, but don’t know if they can 
also be overlapped.)



So, I don’t think this is the correct fix.





There is a “TODO overlapping PDOs" section in slave_config.c that look’s like 
it is a thought on how to deal with the problem, but it looks like it is trying 
to align pairs of rx/tx data rather than allowing the example in #2 above.



I suspect the answer will be for “ec_domain_finish()” to refer back to the 
slave and if it has overlapping pdo’s make sure all pdo’s from the slave make 
it into the same datagram.  I’m out of time to look further at the moment.



Regards,

Graeme.





-Original Message-
From: Etherlab-users  On Behalf Of Geller, 
Nir
Sent: Wednesday, 5 May 2021 21:20
To: Gavin Lambert ; Richard Hacker ; 
etherlab-users@etherlab.org
Subject: Re: [Etherlab-users] Running a large number of slaves



I think I got caught in a very specific situation that isn't handled properly 
by the code.



I will try to describe it more accurately.



The last slave in the topology supports overlapping PDOs, therefore Rx and Tx 
FMMUs logical_domain_offset have the same value.

Suppose until the last slave the accumulated domain size is 1400, the last 
slave's Rx PDO size is 30, and the Tx PDO size is 150.



The last slave's Rx FMMU is handled first by the loop.

The condition

if (fmmu->logical_domain_offset + fmmu->data_size - datagram_offset > 
(EC_MAX_DATA_SIZE)) is not met, and candidate_start is set to the value of the 
Rx FMMU logical_domain_offset.



The Tx FMMU is handled second by the loop, but this time the condition if 
(fmmu->logical_domain_offset >= candidate_start) is not met.



Being the last slave in the topology, the loop ends, and only 1 LRW datagram in 
size > 1500 is created after the condition if (domain->data_size > 
datagram_offset)



Removing completely the condition

if (fmmu->logical_domain_offset >= candidate_start)



fixes the error, but I'm not sure if it safe.

What do you think?



Thanks,



Nir.





-Original Message-

From: Gavin Lambert mailto:gavin.lamb...@tomra.com>>

Sent: Wednesday, May 5, 2021 1:25 AM

To: Geller, Nir 
mailto:nir.gel...@servotronix.com>>; Richard Hacker 
mailto:h...@igh.de>>; 
etherlab-users@etherlab.org

Subject: RE: [Etherlab-users] Running a large number of slaves



I've never used overlapped PDOs myself, but something doesn't sound right in 
your description below.



As I understand it, overlapping only supports overlapping the input and output 
FMMUs on the same slave; you can never overlap data from different slaves 
(otherwise they would corrupt the data).  As such, while the 
logical_domain_offset of the input and output of one slave might be the same, 
afterwards it should be incremented by the max of both and the next slave 
should always have a strictly higher value.  (That appears to agree with the 
log message output.)







Gavin Lambert

Senior Software Developer







COMPAC SORTING EQUIPMENT LTD | 4 Henderson Pl | Onehunga | Auckland 1061 | New 
Zealand

Switchboard: +49 2630 96520 | https://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: Geller, Nir 
mailto:nir.gel...@servotronix.com>>

Sent: Wednesday, 5 May 2021 2:27 am

To: Geller, Nir 
mailto:nir.gel...@servotronix.com>>; Gavin Lambert 
mailto:gavin.lamb...@tomra.com>>; Richard Hacker 
mailto:h...@igh.de>>; 
etherlab-users@etherlab.org

Subject: RE: [Etherlab-users] Running a large number of slaves



Hi,



I've 

Re: [Etherlab-users] Etherlab-master & linuxcnc

[Graeme Foot]

Hi Michele,

I use ecrt_master_create_domain() to create three domains.  One for general 
modules and the other two for the modules that require LRD & LWR.

I configure each slaves PDO’s by calling ecrt_slave_config_pdos() and then 
ecrt_slave_config_reg_pdo_entry() for each PDO entry I want to attach too.  
ecrt_slave_config_reg_pdo_entry() takes a domain parameter, so this is where 
you choose which domain is suitable for the entry.  From what I understand, the 
first entry from a sync group to be placed into a domain will place all entries 
from that sync group into the domain.  The master will return an error if you 
try to put entries from the same sync group into different domains.

In the realtime loop you call:
  ecrt_master_receive()
  ecrt_domain_process() <- called for each of your three domains

  ecrt_domain_queue() <- called for each of your three domains
  ecrt_master_send()


Regards,
Graeme.

From: Etherlab-users  On Behalf Of 
michele.barsac...@libero.it
Sent: Tuesday, 12 January 2021 5:16 am
To: etherlab-users@etherlab.org
Subject: [Etherlab-users] Etherlab-master & linuxcnc


Hi,

i'am using etherlab-master with linuxcnc-ethercat project with good results.

I try to configure a new drive (ESTUN ED3M) that has the "enablenotLRW=yes"  
flag setted. I should probably configure two domains, one LRD and one LWR. Do 
you have some examples to configure multiple domains? Is there documentation to 
explain this feature?

I have consulted on the subject several forums but I have not found
anything concrete.

I'm not very expert, i'm new of ethercat!

Thanks,

Michele


-- 
Etherlab-users mailing list
Etherlab-users@etherlab.org
https://lists.etherlab.org/mailman/listinfo/etherlab-users

Re: [Etherlab-users] dynamic PDO unmapping

[Graeme Foot]

Hi Vincent,


Some further thoughts:


- If your drive can handle splitting your input PDOs and your output PDOs into 
two different domains (i.e. put the drives inputs into your common domain and 
the drives outputs into its own domain that can be stopped) then you can still 
read your drives status while not sending the outputs.  The input domains 
watchdog can then probably also remain active and the drive can handle a 
communication loss.


- If you can map the operation mode request index/subindex (and maybe target 
velocity, updated from your actual velocity) into your drives output PDO as 
extra items, then you could continue all PDO communications (from a common 
domain) and swap the drive into velocity mode and let the drives internal 
controlled stop routine decelerate the motor.  You then also shouldn't need a 
custom routine installed on the drive.


Of course none of these options are actually safety rated as they all rely on 
the EtherCAT master doing something.  It might still be worth investigating 
further a drive logic only solution (maybe similar to the second option above, 
but where the slave logic puts the drive into velocity mode, so the torque from 
the PDO may be ignored anyway).

Regards,
Graeme.



From: Etherlab-users  on behalf of 
BUSSIERES Vincent 
Sent: Friday, 18 September 2020 03:01
To: Sebastien BLANCHET; etherlab-users@etherlab.org
Subject: Re: [Etherlab-users] dynamic PDO unmapping

Dear All,

Thanks a lot for your help. I placed servo drive slave into its own domain. 
Obviously I needed to desactivate heartbeat.
It may not be the best solution but it works

Regards

Vincent BUSSIERES
Responsable Technique Logiciel


ZE Ma Campagne
36, Impasse Félix Nadar
16000 ANGOULEME
Tel: 33 (0)9.72.40.35.08
www.hemeria-group.com
? Afin de contribuer au respect de l'environnement, merci de n'imprimer ce 
courriel qu'en cas de nécessité.
Ce message et les fichiers pouvant être attachés sont confidentiels, réservés à 
l'usage unique des destinataires et n'engagent HEMERIA sous aucune forme que ce 
soit.
This email and any files transmitted with it are confidential, intented solely 
for the unique use of the recipients and don't commit HEMERIA.




-Message d'origine-
De : Etherlab-users  De la part de 
Sebastien BLANCHET
Envoyé : jeudi 17 septembre 2020 12:29
À : etherlab-users@etherlab.org
Objet : Re: [Etherlab-users] dynamic PDO unmapping

Hi,

I think that it would be preferable to stop the drive without 
breaking/modifying the EtherCAT communication, so that you can continue to 
monitor the drive when it is stopping.

Which servo drive do you have ?

If you have a Kollmorgen AKD,

- You can configure DRV.DISMODE to trigger a controlled stop when the drive is 
disabled. In this case you can stop the motion by disabling the drive with the 
ControlWorld Object (0x6040:0x0),

- You can also trigger a MACRO with a digital input. In this case it opens many 
other possibilities.

Regards,
--
Sebastien BLANCHET


On 9/17/20 10:14 AM, BUSSIERES Vincent wrote:
> Thank you for your answers. I'll try to place each slave into its own domain 
> and I'll keep you informed of the result.
>
> To my mind, the best solution, would be the servo slave itself, when it 
> detects a fault condition, should go into a state where it ignores whatever 
> values the master is sending. I have already asked to the slave vendor, I'm 
> still waiting for his answer. I don't this it will be possible
>
> Best regards
>
> Vincent BUSSIERES
> Responsable Technique Logiciel
>
>
> ZE Ma Campagne
> 36, Impasse Félix Nadar
> 16000 ANGOULEME
> Tel: 33 (0)9.72.40.35.08
> www.hemeria-group.com
--
Etherlab-users mailing list
Etherlab-users@etherlab.org
http://lists.etherlab.org/cgi-bin/mailman/listinfo/etherlab-users
--
Etherlab-users mailing list
Etherlab-users@etherlab.org
http://lists.etherlab.org/cgi-bin/mailman/listinfo/etherlab-users
-- 
Etherlab-users mailing list
Etherlab-users@etherlab.org
http://lists.etherlab.org/cgi-bin/mailman/listinfo/etherlab-users

Re: [Etherlab-users] dynamic PDO unmapping

[Graeme Foot]

Hi,


As far as I'm aware you would need to place each slave into its own domain and 
then not queue the domain for the slave you want to skip.


Otherwise if a domain is queued, the whole domain data is sent.  I think you 
would need to deactivate the master and reconfigure all the slaves to change 
the domains and exclude a slave from it.


Another option you could investigate is to see if you could stop the slave 
responding to the PDO's at the slave end.  One option would be to place the 
slave into PREOP.  It may take a number of cycles to transition, and the slave 
probably won't continue to run your embeded program so it's not a great option. 
 Otherwise the slave may have some SDO's that control whether it responds to 
the incoming PDO information, but not likely and also has SDO delays.



The best option would be the first one (with multiple domains) as you have a 
small number of slaves.  Each domain will add a little extra overhead to the 
frame, but as there are few slaves they should all still fit fine in one 
ethercat frame.



Regards,

Graeme.



From: Etherlab-users  on behalf of 
BUSSIERES Vincent 
Sent: Thursday, 17 September 2020 07:54
To: etherlab-users@etherlab.org
Subject: [Etherlab-users] dynamic PDO unmapping

Hello,


I'd like to unmapp PDOs dynamically or to stop sending PDO data to a particular 
slave.

My EtherCAT network includes 6 slaves, among them digital inputs / outputs 
modules and servodrives modules.

I have developped safety functions embeded into the servodrives modules. For 
instance, in case of emergency stop, the embeded program reads digital safety 
emerency input and configures a torque setpoint to stop the motor very quickly.

The problem is that EtherCAT master sends PDO frames continuously to all the 
slaves, in particular torque setpoint PDO to servodrive. Therefor the setpoint 
configured in embeded program is replaced by the one sent by EtherCAT master.



So I'd like to know if it is possible to stop sending temporarly PDO to a 
particular slave or unmapp these PDOs.



Best regards



Vincent BUSSIERES

Responsable Technique Logiciel



[1572337113342]

ZE Ma Campagne

36, Impasse Félix Nadar

16000 ANGOULEME

Tel: 33 (0)9.72.40.35.08

www.hemeria-group.com
P Afin de contribuer au respect de l'environnement, merci de n'imprimer ce 
courriel qu'en cas de nécessité.

Ce message et les fichiers pouvant être attachés sont confidentiels, réservés à 
l'usage unique des destinataires et n'engagent HEMERIA sous aucune forme que ce 
soit.
This email and any files transmitted with it are confidential, intented solely 
for the unique use of the recipients and don't commit HEMERIA.






-- 
Etherlab-users mailing list
Etherlab-users@etherlab.org
http://lists.etherlab.org/cgi-bin/mailman/listinfo/etherlab-users

Re: [Etherlab-users] EK1960 (TwinSAFE PLC) "This object does not exist" error and related warnings

[Graeme Foot]

Hi,

I'm testing an EK1960 TwinSAFE PLC device.  It integrates a TwinSAFE PLC and a 
bunch of safe inputs and outputs.  I am creating the safety project in TwinCAT 
3.1.4024.10 (with Visual Studio 2019 16.5 Community).

I have exported the safety project and successfully loaded it onto the EK1960 
(via TwinSAFE Loader and the EtherCAT Mailbox Gateway server I wrote last year).

I have created my pdoEntries, pdos and syncs structures based off TwinCAT 3's 
Process Data information that is available if I map the EK1960 safety project 
to an EK1960 device under the I/O section of TwinCAT.  There are multiple pdo 
entries with the same index and subIndex (with 0x6000 and 0x7000 indexes).  I 
am using ecrt_slave_config_reg_pdo_entry_pos() to access the pdo entries to 
avoid this being a problem.

I get the slave configured and into OP and it is running happily, however the 
slave does not allow PDO config and mapping so I get a bunch of startup errors 
with "This object does not exist" and related warnings


The slave does not contain the pdos being configured (0x1600, 0x17F0, 0x1A00, 
0x1BF0, 0x1BFE) or the pdo entry indexes (0x6000, 0x7000).  The master reports 
"This object does not exist in the object directory" for each of them.

The EtherLab master does however correctly map the Sync Manager and FMMU 
settings correctly (and match those that would be requested via TwinCAT).

So the question is, is there a way to get the master to skip checking and 
setting the pdo mapping for this slave and just go straight to configuring the 
sync manager and fmmu information?  (I'm using GavinL's patchset 20171108, a 
little old but AFAIK the latest patchset doesn't have this ability.)


(Doing so would also help me for slaves with multiple revisions, where the data 
hasn't changed but the index it gets it from has.)


Regards,
Graeme.
-- 
Etherlab-users mailing list
Etherlab-users@etherlab.org
http://lists.etherlab.org/cgi-bin/mailman/listinfo/etherlab-users

Re: [etherlab-users] AL States

[Graeme Foot]

Hi Vincent,

If the master operational state is different to each slaves operational state.  
If the master phase is in Operation (via the "ethercat master" command) it 
means that ecrt_master_activate() has been called and the master can activate 
the slaves that have been configured and realtime operation has begun.

If a slave is not configured the master does not know about it so it will stay 
in PREOP.
If a slave has a different alias to the one configured the master can not 
correctly connect to it so it will stay in PREOP.

For all slaves the master does know about, and can connect to, the master will 
attempt to bring them into OP mode.  However, each slave needs to be brought to 
OP mode via a state machine that takes a little time.  If you are not using 
Gavin Lamberts patchset the master will do so one slave at a time.  If you are 
using his patchset then it will do ~ 16 slaves in parallel at a time, so 
somewhat faster.

Conversely, when you call ecrt_master_deactivate() all known and connected 
slaves are returned to PREOP and then the master goes to the Idle phase.

Also, just to add a little extra, if the master is idle you can use the 
"ethercat states" command to manually request a state on a particular slave.  
So a slave could actually be in OP state while the master is idle.



So to directly answer your question "Can master be considered as OP state if at 
least one slave is in OP state?": No.





If you have called ecrt_master_activate(), and it returned success, your master 
is operational, until you call ecrt_master_deactivate().  However, whether you 
consider your system ready to use will probably depend in whether all your 
required slaves are up and running at the OP state.



And for extra credit, slaves can be hot connected and comms can be interrupted. 
 If the master is active it will handle slaves disappearing and appearing and, 
for configured slaves, run through their state machines to get them back to OP 
mode automatically.  So if you have a group of slaves that can be disconnected 
(on purpose), put them in a separate domain and use ecrt_domain_state() to 
check the wc_state parameter to ensure that group of slaves is fully 
operational for the functions they need to perform.


Regards,
Graeme.


From: BUSSIERES Vincent 
Sent: Friday, 3 July 2020 8:15 AM
To: Graeme Foot ; etherlab-users@etherlab.org
Subject: RE: AL States


Hi,



Indeed, some slaves are not in OP state. There are 6 slaves on my network, two 
of them are in PREOP state.

I can get their states using ethercat slaves -v command but when I run ethercat 
master command, master is in OP state.

Can master be considered as OP state if at least one slave is in OP state?



Best reagards

____
De : Graeme Foot mailto:graeme.f...@touchcut.com>>
Envoyé : lundi 29 juin 2020 00:12
À : BUSSIERES Vincent; 
etherlab-users@etherlab.org<mailto:etherlab-users@etherlab.org>
Objet : RE: AL States


Hi,



If you are using ecrt_master_state() the al_states parameter is filled in by 
all slaves with an OR operation.  So for each bit that is set you can interpret 
that as at least one slave was in that state.  If there is a state bit set you 
are not happy with (or expecting) then you will need to interrogate each slave 
individually to find out which slave(s) are in that state, using 
ecrt_slave_config_state().



On startup (or comms interruption and recovery) you can expect to see slaves at 
different stages on the way to OP mode.  If you are fully operational and you 
have a PREOP bit set, then you likely have a device that is not known so is not 
configured, or has the wrong address so it is not being attached to correctly.  
If a slave stays in SAFEOP then you probably have a configuration error, check 
the logs to figure out the problem.



Regards,

Graeme.



From: etherlab-users 
mailto:etherlab-users-boun...@etherlab.org>>
 On Behalf Of BUSSIERES Vincent
Sent: Friday, 26 June 2020 9:25 PM
To: etherlab-users@etherlab.org<mailto:etherlab-users@etherlab.org>
Subject: [etherlab-users] AL States



Hello,



I'd like to display AL state in my HMI.



AL states are :
· Bit0 : INIT
· Bit1 : PREOP
· Bit2 : SAFEOP
· Bit3 : OP



But when I read AL states, states are respetively :


· 0x02  (0010)
· 0x03  (0011)
· 0x0a  (1010)
· 0x0e  (1110)
· 0x0a  (1010)



So, in some cases I don't know in which state I am ?

How can I determine AL State ?



Regards



Vincent BUSSIERES

Responsable Technique Logiciel



[1572337113342]

ZE Ma Campagne

36, Impasse Félix Nadar

16000 ANGOULEME

Tel: 33 (0)9.72.40.35.08

www.hemeria-group.com<https://webmail.nexeya.fr/owa/redir.aspx?C=GK_BqKCZef7LtPZnqnd_LGYr1NG9sz4Smy3iKIwO-pXqtJC7VgzXCA..=http%3a%2f%2fwww.hemeria-group.com%2f>
P Afin de contribuer au respect de l'environnement, merci de n'imprimer ce 

Re: [etherlab-users] Slave lost forever after power cycling

[Graeme Foot]

Hi,

This is a link to information on the "Second Slave Address" (alias):
https://infosys.beckhoff.com/english.php?content=../content/1033/ethercatsystem/2469080715.html=

It says EtherCAT support three ways of retrieving a slaves alias address.

1) Via register 0x0012 after the EEPROM has been read.  This address can be set 
via the master or from dip switches at the slave.  This is the most common 
option and should be supported by all slaves that use EEPROMs.

2) InputWord/Identification Value/Data Word.  Alias address is stored at a 
custom location in the slaves process data area (default location 0x1000).  I 
don't think the EtherLab master supports this method.

3) Explicit Device Identification via AL status register 0x0134 during startup. 
 This method is not supported by the EtherLab master.  The master will receive 
AL status messages, but as far as I can see it always expects them to be alarm 
messages.  If you look in your dmesg info are you seeing either of:
- AL status message 0x: "description"
- Unknown AL status code 0x.


The document also says that the esi file (xml file) should contain information 
as to which addressing methods the slave supports.  Can you tell from the esi 
file which method is being used?  Can you send through the esi file?


Regards,
Graeme Foot.


From: Joachim Sällvin 
Sent: Tuesday, 18 February 2020 10:38 PM
To: Graeme Foot ; Gavin Lambert 
; etherlab-users@etherlab.org
Subject: Sv: Slave lost forever after power cycling

Hi,

Thank you.

It is the module you've suggested.

We've tried with the DIP switches and with the tool provided by the drive 
vendor we can see that the "Second Address" parameter is affected correctly by 
the DIP switch settings. However I can not see that the DIP switch settings 
affects the alias address when I ask "ethercat slaves". Thus, setting an alias 
address by using DIP switches doesn't seem to work, at least not together with 
etherlab. I am puzzledthe vendor claims that this works perfectly well with 
TwinCAT.

Best Regards,

Joachim Sällvin
____
Från: Graeme Foot mailto:graeme.f...@touchcut.com>>
Skickat: den 17 februari 2020 20:31
Till: Joachim Sällvin 
mailto:joachim.sall...@corpowerocean.com>>; 
Gavin Lambert mailto:gavin.lamb...@tomra.com>>; 
etherlab-users@etherlab.org<mailto:etherlab-users@etherlab.org> 
mailto:etherlab-users@etherlab.org>>
Ämne: RE: Slave lost forever after power cycling


Hi,



Is it this module here (or similar)?

https://www.nord.com/cms/media/documents/datasheets/TI_275281117_SK_TU4-ECT_EN_4217_screen.pdf



The back of this unit has dip switches:

Second Address (DIP 2..10)

The "Second Address" can be set via this switch and controlled in parameter 
P181.

If all DIP switches 2..10 are moved to the "OFF" position, the "Second Address" 
can be set via parameter P160.



This means that if you set an alias on this slave via the "ethercat alias" 
command it will only remain active until the unit is repowered.  If the dip 
switches are set it will apply an alias based on the dip switches.  If the dip 
switches are all off it will use the P160 parameter.



Use the dip switches or P160 to set your alias for this unit, not the "ethercat 
alias" command.



Regards,

Graeme Foot.



From: etherlab-users 
mailto:etherlab-users-boun...@etherlab.org>>
 On Behalf Of Joachim Sällvin
Sent: Tuesday, 18 February 2020 6:01 AM
To: Gavin Lambert mailto:gavin.lamb...@tomra.com>>; 
etherlab-users@etherlab.org<mailto:etherlab-users@etherlab.org>
Subject: Re: [etherlab-users] Slave lost forever after power cycling



Thank you very much for your reply.



It seems like the position on the slave network doesn't matter. What matters i 
the alias addressing of this particular slave. When I don't give the TU4 slave 
any alias address I can power-cycle it without loosing it. But as soon as I've 
given it an alias address and power-cycle it is lost (not every time but 
almost).



What might cause this? It seems like the EEPROM/Sii of the slave overwritten at 
start-up when it has been given an alias address. Is there a way to prevent 
this? How does this work "under the hood"?

I use "sudo ethercat -p1 alias 2" for example to give the slave on position 1 
the alias address 2. Nothing wrong here I presume since it seems to work for 
other slaves.



I've been in contact with the vendor of the TU4 module and they claim that this 
module is working in big volumes (thousands) on the market. All their other 
customers use TwinCAT and they haven't heard of this problem. I have also tried 
three different TU4 modules to exclude the possibility of one failing 
individual.



Examples:



1.All slaves have alias addresses => TU4-ECT lost after power-cycling.

$ sudo ethercat slaves

0  1:0  PREOP  +  AXL F BK EC, Axioline EtherCAT 

Re: [etherlab-users] Slave lost forever after power cycling

[Graeme Foot]

Hi,

Is it this module here (or similar)?
https://www.nord.com/cms/media/documents/datasheets/TI_275281117_SK_TU4-ECT_EN_4217_screen.pdf

The back of this unit has dip switches:
Second Address (DIP 2..10)
The "Second Address" can be set via this switch and controlled in parameter 
P181.
If all DIP switches 2..10 are moved to the "OFF" position, the "Second Address" 
can be set via parameter P160.

This means that if you set an alias on this slave via the "ethercat alias" 
command it will only remain active until the unit is repowered.  If the dip 
switches are set it will apply an alias based on the dip switches.  If the dip 
switches are all off it will use the P160 parameter.

Use the dip switches or P160 to set your alias for this unit, not the "ethercat 
alias" command.

Regards,
Graeme Foot.

From: etherlab-users  On Behalf Of Joachim 
Sällvin
Sent: Tuesday, 18 February 2020 6:01 AM
To: Gavin Lambert ; etherlab-users@etherlab.org
Subject: Re: [etherlab-users] Slave lost forever after power cycling

Thank you very much for your reply.

It seems like the position on the slave network doesn't matter. What matters i 
the alias addressing of this particular slave. When I don't give the TU4 slave 
any alias address I can power-cycle it without loosing it. But as soon as I've 
given it an alias address and power-cycle it is lost (not every time but 
almost).

What might cause this? It seems like the EEPROM/Sii of the slave overwritten at 
start-up when it has been given an alias address. Is there a way to prevent 
this? How does this work "under the hood"?
I use "sudo ethercat -p1 alias 2" for example to give the slave on position 1 
the alias address 2. Nothing wrong here I presume since it seems to work for 
other slaves.

I've been in contact with the vendor of the TU4 module and they claim that this 
module is working in big volumes (thousands) on the market. All their other 
customers use TwinCAT and they haven't heard of this problem. I have also tried 
three different TU4 modules to exclude the possibility of one failing 
individual.

Examples:

1.All slaves have alias addresses => TU4-ECT lost after power-cycling.

$ sudo ethercat slaves

0  1:0  PREOP  +  AXL F BK EC, Axioline EtherCAT Fieldbus coupler

1  2:0  PREOP  +  TU4-ECT

2  3:0  PREOP  +  ifm IO-Link Master AL1930

3  4:0  PREOP  +  ifm IO-Link Master AL1332



Power-cycling...

$ sudo ethercat slaves

0  1:0  PREOP  +  AXL F BK EC, Axioline EtherCAT Fieldbus coupler

1  2:0  PREOP  +  ifm IO-Link Master AL1930

2  3:0  PREOP  +  ifm IO-Link Master AL1930

3  4:0  PREOP  +  ifm IO-Link Master AL1332



2. No slave has an alias address => No problem after power-cycling.

$ sudo ethercat slaves

0  0:0  PREOP  +  AXL F BK EC, Axioline EtherCAT Fieldbus coupler

1  0:1  PREOP  +  ifm IO-Link Master AL1930

2  0:2  PREOP  +  ifm IO-Link Master AL1332

3  0:3  PREOP  +  TU4-ECT



Power-cycling...

$ sudo ethercat slaves

0  0:0  PREOP  +  AXL F BK EC, Axioline EtherCAT Fieldbus coupler

1  0:1  PREOP  +  ifm IO-Link Master AL1930

2  0:2  PREOP  +  ifm IO-Link Master AL1332

3  0:3  PREOP  +  TU4-ECT



3. All slaves but the TU4 has alias addresses => No problem



$ sudo ethercat slaves

0  1:0  PREOP  +  AXL F BK EC, Axioline EtherCAT Fieldbus coupler

1  2:0  PREOP  +  ifm IO-Link Master AL1930

2  3:0  PREOP  +  ifm IO-Link Master AL1332

3  3:1  PREOP  +  TU4-ECT



Power-cycling...

$ sudo ethercat slaves

0  1:0  PREOP  +  AXL F BK EC, Axioline EtherCAT Fieldbus coupler

1  2:0  PREOP  +  ifm IO-Link Master AL1930

2  3:0  PREOP  +  ifm IO-Link Master AL1332

3  3:1  PREOP  +  TU4-ECT



Best regards,



Joachim Sällvin


Från: Gavin Lambert mailto:gavin.lamb...@tomra.com>>
Skickat: den 16 februari 2020 23:58
Till: Joachim Sällvin 
mailto:joachim.sall...@corpowerocean.com>>; 
etherlab-users@etherlab.org<mailto:etherlab-users@etherlab.org> 
mailto:etherlab-users@etherlab.org>>
Ämne: RE: Slave lost forever after power cycling


Have you tried putting it in different positions on the slave network?  Perhaps 
it only vanishes when downstream of a particular slave; then the problem might 
be with that slave's configuration.



Etherlab typically assumes that all slaves are configured with DL auto-open 
mode (so that slaves that are connected or rebooted are automatically brought 
into the virtual ring network), but it's possible that one of your upstream 
slaves has been configured in the explicit open mode instead.



Gavin Lambert
Senior Software Developer


[cid:image001.png@01D5E634.B3939860]
[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/

Re: [etherlab-users] Debugging inconsistent slave behaviour

[Graeme Foot]

Hi Jakub,

It's kind of hard to say without more info.  But here's a few things to check 
(from very simple onwards):

1) check that the drives are going to OP mode ("ethercat slaves" command).  If 
they are not in OP mode they won't be handling PDO frames.

2) do an "ethercat slaves -v" command and check that your app is using the 
correct vender ID and product code to connect to it.

3) do an "ethercat slaves -v" command and compare the two types of drives, in 
particular the "Flags: Enable notLRW" flag.  If one of them is true, then you 
need to split the read and write PDO's into two different domains for that 
drive.

4) from a fresh power up of your amps, and before you start your app, do the 
"ethercat cstruct" command on the two types of amps and compare them.  If they 
are not the same, make sure your code is accounting for the differences.

5) before starting your amp run the command "ethercat debug 1" to set the 
masters debug output level to 1.  Start the app.  Once started check the dmesg 
log and look for any configuration errors

Regards,
Graeme Foot.

From: etherlab-users  On Behalf Of 
j.sikor...@utwente.nl
Sent: Saturday, 30 November 2019 5:52 AM
To: etherlab-users@etherlab.org
Cc: s.mi...@utwente.nl; f.k...@utwente.nl
Subject: [etherlab-users] Debugging inconsistent slave behaviour


Dear Etherlab Users,



For a few years now I've been enthusiastically using Etherlab master along with 
Gavin Lambert's patchset (up to kernel 4.4) to drive a handful of Technosoft 
Motion iPOS4808 BX-CAT slaves in various robotics projects. My framework 
involves   wrapped in custom C++ code. I thought that by now I have a 
reliable plug-and-play software stack. Unfortunately, I was proven wrong when I 
tried to use my code with another drive from the same family (iPOS3602 VX-CAT).



I managed to narrow down the problem to an issue with  PDO exchange. 
When I run the cyclic process, I keep on receiving empty datagrams from the 
3602 slaves regardless of what I do. Running the same code on the same machine 
with iPOS4808 slaves connected through the same cable works just fine. I can 
also read all CoE fields in 3602 slaves via SDO ("sudo ethercat upload" in 
console) with no problem. The manufacturer (Technosoft) claims that their 
Ethercat functionality should be consistent across the entire iPOS ...-CAT 
family, but something is clearly not right.



Since I have never ran into similar issues, I miss the know-how that would 
allow me to dig deep enough to establish the source of the problem (even the 
simple fact whether it's a problem with the slaves or the master). Hence, I 
thought I may check here, whether a similar situation has happened to anyone 
before. If you had any tips on how I could investigate the problem further, I 
would be much obliged.



Thank you very much in advance for any help.



Yours sincerely,

Jakub Sikorski



Doctoral Candidate

Surgical Robotics Laboratory

University of Twente

7500 AE Enschede

The Netherlands
___
etherlab-users mailing list
etherlab-users@etherlab.org
http://lists.etherlab.org/mailman/listinfo/etherlab-users

Re: [etherlab-users] cx2100 vs CCAT drivers

[Graeme Foot]

Hi James,

The CX2100 driver is indeed to make the CX2100 available as a network interface 
for the EtherCAT master.  This was written and made available a year or so 
before the CCat driver.  The CCat driver was also under development for a 
little time before it became stable and was contributed by a Beckhoff employee 
to support the Linux community.

I still use the CX2100 driver as it does exactly as I want.  I have a separate 
user space application which hooks into the i2c channel to interact with the 
nav buttons and LCD screen.

I have not yet looked into replacing the CX2100 driver with the CCat driver and 
haven't looked into its capabilities, but for a new project I would be 
evaluating using the CCat driver.

Regards,
Graeme.

From: James Benway 
Sent: Tuesday, 26 November 2019 2:19 AM
To: Graeme Foot 
Subject: cx2100 vs CCAT drivers

Hi Mr. Foot,

I am picking up a project where Mr. Dave Page left off which utilizes the 
etherLab master on Beckhoff CX2030+CX2100 hardware.  The project currently uses 
a fork of the stable-1.5 branch with a few patches developed prior to 2016.  I 
am migrating the project to a newer kernel and working in the applicable 
patches released over the past few years in Gavin's repo.  As I was scanning 
through the patches I can across your CX2100 driver.  However, I am a bit 
confused as to its purpose and was hoping you could shed some light.  Is the 
CX2100 driver's purpose to set up an interface to use the device as a standard 
ethernet adapter?  Is it intended to supplement or replace the ccat driver?

Thank you in advance for any assistance you can provide,

--
James Benway
Senior Embedded Systems Engineer
Dynamic Systems Inc.
[cid:image001.png@01D5A446.D883CD00]


The contents of this e-mail and any attachments are confidential. They are 
intended for the named recipient(s) only.  If you are not the intended 
recipient of this message, please notify the sender immediately and delete the 
message and any attachments. Thank you.
___
etherlab-users mailing list
etherlab-users@etherlab.org
http://lists.etherlab.org/mailman/listinfo/etherlab-users

Re: [etherlab-users] Diagnostics, crc and phy errors

[Graeme Foot]

Hi,

It looks like it is just a dodgy link between device 5 and device 6.

To resolve, try the following (depending on what you have handy and assuming 
your drives are linked by patch cables):
- Unplug and replug the patch cable at both ends a few times (to try and get 
better contact)
- Take out the patch cable and use contact cleaner on the ends and the ports
- Toss the patch cable and replace (and use contact cleaner if you have it)


The incoming port shows phy errors if the link to the prior component is lost 
for a long enough time that the phy can detect the drop.  If it’s slightly less 
dodgy than that, a bad cable, noise or other then it can just show up as crc 
errors.  I don’t know for sure, but if the transmit wires have a dodgy 
connection but the receive wires are OK, for example, it could only show up as 
a phy / crc error in one direction.

It is unlikely to be an error on device 5 itself (unless the eth port is 
damaged).  If the device itself has a problem I often see the two devices 
either side of it with errors, with no error on the problem device in the 
middle.  e.g. (modifying your example):


2019-10-31 16:24:08.476


P0

P1


crc

phy

fwd

crc

phy

fwd

0:D2 CoE Driv

0

0

0

0

0

25

1:D2 CoE Driv

0

0

25

0

0

25

2:D2 CoE Driv

0

0

25

0

0

25

3:D2 CoE Driv

0

0

25

0

0

25

4:D2 CoE Driv

0

0

25

0

93

25

5:D2 CoE Driv

0

0

0

0

0

0

6:D2 CoE Driv

0

98

25

0

0

25

7:D2 CoE Driv

0

0

25

0

0

25

8:D2 CoE Driv

0

0

25

0

0

25

9:D2 CoE Driv

0

0

25

0

0

25



This usually indicates that the device in the middle repowered / reset, so the 
devices either side report the error, but the device causing the problem loses 
its count when it repowered / reset.  This is the case I have often found with 
bad Beckhoff EL modules.


Regards,
Graeme

From: etherlab-users  On Behalf Of Ignacio 
Rosales Gonzalez
Sent: Monday, 4 November 2019 11:55 PM
To: etherlab-users@etherlab.org
Subject: [etherlab-users] Diagnostics, crc and phy errors

Hello everybody,

I've suffering some errors in two machines.
In both of them the dmesg shows the same

 [ 2093.602142] EtherCAT 0: Domain 0: Working counter changed to 18/111.
 [ 2093.608661] EtherCAT 0: 6 slave(s) responding on main device.
 [ 2093.640855] EtherCAT 0: Scanning bus.
 [ 2094.939242] EtherCAT 0: Bus scanning completed in 1332 ms.
 [ 2094.939248] EtherCAT 0: Using slave main-0 as DC reference clock.
 [ 2097.856277] EtherCAT 0: Domain 0: Working counter changed to 0/111.
 [ 2097.876311] EtherCAT 0: 37 slave(s) responding on main device.
 [ 2097.876312] EtherCAT 0: Slave states on main device: SAFEOP, OP + ERROR.
 [ 2098.032585] EtherCAT 0: Scanning bus.

But logging the output of the new command ethercat crc I obtain different 
behaviours,

In one of them the crc counter and phy counter of one of servos practically go 
up at same time.

In the other only the phy counter in one servo is increased:




2019-10-31 16:24:08.476


P0

P1


crc

phy

fwd

crc

phy

fwd

0:D2 CoE Driv

0

0

0

0

0

25

1:D2 CoE Driv

0

0

25

0

0

25

2:D2 CoE Driv

0

0

25

0

0

25

3:D2 CoE Driv

0

0

25

0

0

25

4:D2 CoE Driv

0

0

25

0

0

25

5:D2 CoE Driv

0

0

25

0

93

25

6:D2 CoE Driv

0

98

25

0

0

25

7:D2 CoE Driv

0

0

25

0

0

25

8:D2 CoE Driv

0

0

25

0

0

25

9:D2 CoE Driv

0

0

25

0

0

25




The easy solution obviously is try to reconnect all wires and change servos, 
but could anyone explain whats the difference between the two cases and give me 
some ligth in order to solve this kind of problems?
For example in the the second case the phy counter is incremented in P0 of 
servodrive 6 and in P1 of servodrive 5. Is this a symphtom of an error in 
connection between 5 and 6 or an error of the servodrive 5?

Kind regards

Ignacio Rosales
___
etherlab-users mailing list
etherlab-users@etherlab.org
http://lists.etherlab.org/mailman/listinfo/etherlab-users

Re: [etherlab-users] Control loop at higher frequencies

[Graeme Foot]

Hi,

It is sounding like the data time on the wire is taking too long (> 250us).

Besides doubling the "DC system time transmission delay" of the last slave, you 
can also check the "Diff [ns]" value of your first slave.  This may give you a 
more accurate idea if you have a star topology, as the return trip of the frame 
from the last slave bypasses the fingers of the stars.  e.g.:

ethercat slaves -v -p0

=== Master 0, Slave 0 ===
Alias: 10001
Device: Main
State: OP
Flag: +
Identity:
  Vendor Id:   0x0002
  Product code:0x04562c52
  Revision number: 0x0011
  Serial number:   0x
DL information:
  FMMU bit operation: no
  Distributed clocks: yes, 64 bit
  DC system time transmission delay: 0 ns
Port  Type  Link  LoopSignal  NextSlave  RxTime [ns]  Diff [ns]   NextDc 
[ns]
   0* EBUS  upopenyes -   3638440690   0   0
   1  MII   upopenyes 1   36384424101720 560
   2  N/A   down  closed  no  --   -   -
   3  N/C   down  closed  no  --   -   -

You will also need to add on 2 * "master to first slave transmission delay" 
which you will probably need to guess.  If you use a Beckhoff CX2020 (or 
similar) where the CX2100 is directly connected to the EBus this will likely be 
around 150us.  If your master has an ethernet port and the first slave is an 
amp or a coupler this may be around 550us or more (depending on cable length).  
You could also calc the frame transmission time.  Your frame length is 782 
bytes.  So that should take ~ 6 - 7us.  Plus whatever other overheads the 
ethernet card / driver has.

Reducing the number of configured slaves (even with them still physically 
plugged in) will reduce the ec_master_domain_queue() and ec_master_send() 
overhead time, getting the frame to the wire quicker.  It will also reduce the 
frame length and the related frame transmission time (especially if you remove 
slaves with bigger datagram overhead).  It looks like this is enough to result 
in the total frame roundtrip time being reduce enough for it to return and be 
ready by the time that ec_master_receive() is called.


Just FYI, I have a machine downstairs at the moment with 42 slaves (14 of which 
are amps), linear topology.  The last slaves transmission delay is 19560ns.  
The first slaves Diff is 39390ns.  The EtherCAT frame size is 886 bytes.  The 
ec_master_receive() to ec_master_send() time is approx 23us.  So your values 
sound in line with what I have, except that the wireshark output is showing a 
large cycle time.

In general it's looking like the time on the wire is taking longer than it 
should.  How are you capturing the EtherCAT frame data?  e.g.: a switch between 
your master and first slave?  If so, try moving it further down the chain, 
doing an "ethercat rescan" and check the transmission delays.  See if the 
switch is causing a large delay between those slaves.

What is your network card and driver used by the master?  What is your realtime 
system?  If you are using tshark on the master PC there might be delays being 
introduced in the network card driver.


Regards,
Graeme.


From: etherlab-users  On Behalf Of Jordan 
Palacios
Sent: Thursday, 31 October 2019 4:36 AM
To: etherlab-users@etherlab.org
Subject: [etherlab-users] Control loop at higher frequencies

Hi.

We've been working with the etherlab master for some time now. On our current 
setup we have around 40 slaves and our control loop runs at 1Khz without any 
issues. We use the stable version of etherlab with the 20180622 patchset.

Recently we've tried increasing the loop frequency to achieve a better control. 
The target frequency is 4Khz. After some troubles we managed a stable control 
at 2Khz. Then we went for the 4Khz and this is where we have hit a roadblock.

A warning like this is generated each second:

[11547.183302] EtherCAT WARNING 0: 4000 datagrams UNMATCHED!
[11547.619399] EtherCAT WARNING: Datagram 88040b6bf318 (domain0-0-main) was 
SKIPPED 4004 times.

As per what Florian explained 
here this 
means that the answer to the last datagram sent has not been received yet. I 
don't think this is related to the rate at which we execute the control loop. 
We have instrumented it and is steady at 250us with a jitter below 10us (see 
attachment). Furthermore, we have also enabled the ethercat master debug 
interface. Here is a sample of the traffic output using tshark:

 7807 0.975750173 MS-NLB-PhysServer-19_95:2e:e1:b0 → BroadcastECAT 810 
'LRW': Len: 782, Adp 0x0, Ado 0x0, Wc 69
 7808 0.975757725 Congatec_2e:e1:b0 → BroadcastECAT 810 'LRW': Len: 782, 
Adp 0x0, Ado 0x0, Wc 0
 7809 0.976000284 MS-NLB-PhysServer-19_95:2e:e1:b0 → BroadcastECAT 810 
'LRW': Len: 782, Adp 0x0, Ado 0x0, Wc 69
 7810 0.976007872 Congatec_2e:e1:b0 → BroadcastECAT 810 'LRW': Len: 782, 

Re: [etherlab-users] Question on use of EL3064 (Beckhoff ADC)

[Graeme Foot]

Hi,

Please post questions to the 
etherlab-users@etherlab.org<mailto:etherlab-users@etherlab.org> forum.

For simple slaves:
1) plug the slave into the ethercat fieldbus
2) run the "ethercat cstruct" command, with the -p parameter for the new slave
3) copy and paste the pdo structures into your code.  (I rename mine with the 
slaves product code for better reuse.)
4) to use a configuration for a slave use the following functions:
ecrt_master_slave_config()
 ecrt_slave_config_pdos()
5) to get pdo domain offsets for particular entries use the following function:
ecrt_slave_config_reg_pdo_entry()
6) to configure slave settings use the following functions:
ecrt_slave_config_sdo()
 ecrt_slave_config_sdo8()
 ecrt_slave_config_sdo16()
 ecrt_slave_config_sdo32()
7) if DC is supported use:
ecrt_slave_config_dc()
Note: you can find the assign active value from the slaves ESI 
xml file or documentation.

For slaves with multiple configuration options:
1) locate the matching module and revision Device entry
2) check for AlternativeSmMapping options
Option 1) if the default configuration is the one you want, follow the steps 
above
Option 2) continue with the steps below
3) check the RxPdo / TxPdo options that match the Sm Mapping that you want to 
use
4) build your own cstruct's based on items 2 & 3
(this can be hard)
5) follow steps 4-7 from the simple slave

For slaves that allow custom pdo configurations:
1) get the default cstruct and if it doesn't have what you want modify it with 
parameters that are allowed to be PDO items until it is
(you need to do a lot of reading of the slave documentation)
2) follow steps 4-7 from the simple slave


As for the EL3064, it is a slave that supports multiple configuration options.  
I wanted to use the Standard configuration, which is the default configuration, 
so I followed the "Slave with multiple configuration options, Option 1" 
approach.


Regards,
Graeme.

From: Sy Meshkat 
Sent: Wednesday, 10 July 2019 6:01 AM
To: Graeme Foot 
Subject: RE: Question on use of EL3064 (Beckhoff ADC)

Dear Graeme,

Thanks a lot for your great help - it worked!

In order for us not to bother you with emails, asking a similar question about 
various Beckhoff slaves, could you kindly tell me: In order to come up with the 
PDO structure you used for EL3064 (below), did you use an existing source OR 
you conceived the solution from scratch yourself?

It will help us to know where this source is OR how you approached the solution 
from the basic Beckhoff (EL3064) xml file.  We want to know if we can formulate 
the process rather than look at each case as a new one.

Thanks a lot again!

Best regards,
 Sy Meshkat
 [cid:image001.jpg@01D53708.E5341740]
DSP Control Group, Inc.
4445 W 77th Street
Minneapolis, MN 55435

general .   t:  1 + ( 952 ) 831 - 9556
fax f:  1 + ( 952 ) 831 - 4697
cell c:  1 + ( 612 ) 309 - 5478
directe:  1 + ( 952 ) 831 - 2349
website i:   www.dspcg.com<http://www.dspcg.com/>
 
-
NOTICE: The foregoing message (including all attachments) is covered by the 
Electronic Communications Privacy Act, 18 U.S.C. Sections 2510-2521, is 
CONFIDENTIAL. If you are not the intended recipient of this message, you are 
hereby notified that any retention, dissemination, distribution or copying of 
this communication is strictly prohibited. Please reply to the sender that you 
have received this message in error; then delete it

________
From: Graeme Foot [mailto:graeme.f...@touchcut.com]
Sent: Monday, July 8, 2019 5:44 PM
To: Sy Meshkat
Cc: etherlab-users@etherlab.org<mailto:etherlab-users@etherlab.org>
Subject: RE: Question on use of EL3064 (Beckhoff ADC)

Hi,

This is the PDO structures we use for EL3064 modules (available if you run the 
"ethercat cstruct" command for your module):

ec_pdo_entry_info_t EL3064_pdoEntries[] = {
// Ch.1 (0)
{0x6000, 0x01, 1}, /* Underrange */
{0x6000, 0x02, 1}, /* Overrange */
{0x6000, 0x03, 2}, /* Limit 1 */
{0x6000, 0x05, 2}, /* Limit 2 */
{0x6000, 0x07, 1}, /* Error */
{0x, 0x00, 1}, /* Gap */
{0x, 0x00, 6}, /* Gap */
{0x6000, 0x0f, 1}, /* TxPDO State */
{0x6000, 0x10, 1}, /* TxPDO Toggle */
{0x6000, 0x11, 16}, /* Value */

// Ch.2 (10)
{0x6010, 0x01, 1}, /* Underrange */
{0x6010, 0x02, 1}, /* Overrange */
{0x6010, 0x03, 2}, /* Limit 1 */
{0x6010, 0x05, 2}, /* Limit 2 */
{0x6010, 0x07, 1}, /* Error */
{0x, 0x00, 1}, /* Gap */
{0x, 0x00, 6}, /* Gap */
{0x6010, 0x0f, 1}, /* TxPDO State */
{0x6010, 0x10, 1}, /* TxPDO Toggle */
{0x6010, 0x11, 16}, /* Value */

 

Re: [etherlab-users] Question on use of EL3064 (Beckhoff ADC)

[Graeme Foot]

Hi,

This is the PDO structures we use for EL3064 modules (available if you run the 
"ethercat cstruct" command for your module):

ec_pdo_entry_info_t EL3064_pdoEntries[] = {
// Ch.1 (0)
{0x6000, 0x01, 1}, /* Underrange */
{0x6000, 0x02, 1}, /* Overrange */
{0x6000, 0x03, 2}, /* Limit 1 */
{0x6000, 0x05, 2}, /* Limit 2 */
{0x6000, 0x07, 1}, /* Error */
{0x, 0x00, 1}, /* Gap */
{0x, 0x00, 6}, /* Gap */
{0x6000, 0x0f, 1}, /* TxPDO State */
{0x6000, 0x10, 1}, /* TxPDO Toggle */
{0x6000, 0x11, 16}, /* Value */

// Ch.2 (10)
{0x6010, 0x01, 1}, /* Underrange */
{0x6010, 0x02, 1}, /* Overrange */
{0x6010, 0x03, 2}, /* Limit 1 */
{0x6010, 0x05, 2}, /* Limit 2 */
{0x6010, 0x07, 1}, /* Error */
{0x, 0x00, 1}, /* Gap */
{0x, 0x00, 6}, /* Gap */
{0x6010, 0x0f, 1}, /* TxPDO State */
{0x6010, 0x10, 1}, /* TxPDO Toggle */
{0x6010, 0x11, 16}, /* Value */

// Ch.3 (20)
{0x6020, 0x01, 1}, /* Underrange */
{0x6020, 0x02, 1}, /* Overrange */
{0x6020, 0x03, 2}, /* Limit 1 */
{0x6020, 0x05, 2}, /* Limit 2 */
{0x6020, 0x07, 1}, /* Error */
{0x, 0x00, 1}, /* Gap */
{0x, 0x00, 6}, /* Gap */
{0x6020, 0x0f, 1}, /* TxPDO State */
{0x6020, 0x10, 1}, /* TxPDO Toggle */
{0x6020, 0x11, 16}, /* Value */

// Ch.4 (30)
{0x6030, 0x01, 1}, /* Underrange */
{0x6030, 0x02, 1}, /* Overrange */
{0x6030, 0x03, 2}, /* Limit 1 */
{0x6030, 0x05, 2}, /* Limit 2 */
{0x6030, 0x07, 1}, /* Error */
{0x, 0x00, 1}, /* Gap */
{0x, 0x00, 6}, /* Gap */
{0x6030, 0x0f, 1}, /* TxPDO State */
{0x6030, 0x10, 1}, /* TxPDO Toggle */
{0x6030, 0x11, 16}, /* Value */
};

ec_pdo_info_t EL3064_pdos[] = {
{0x1a00, 10, EL3064_pdoEntries + 0}, /* TxPDO-Map Channel 1 */
{0x1a02, 10, EL3064_pdoEntries + 10}, /* TxPDO-Map Channel 2 */
{0x1a04, 10, EL3064_pdoEntries + 20}, /* TxPDO-Map Channel 3 */
{0x1a06, 10, EL3064_pdoEntries + 30}, /* TxPDO-Map Channel 4 */
};

ec_sync_info_t EL3064_syncs[] = {
{0, EC_DIR_OUTPUT, 0, NULL, EC_WD_DISABLE},
{1, EC_DIR_INPUT, 0, NULL, EC_WD_DISABLE},
{2, EC_DIR_OUTPUT, 0, NULL, EC_WD_DISABLE},
{3, EC_DIR_INPUT, 4, EL3064_pdos + 0, EC_WD_DISABLE},
{0xff}
};

To configure it and use it you call something like the following commands on 
startup:

slaveConfig = ecrt_master_slave_config(master, alias, position, vendorID, 
productCode);
ecrt_slave_config_pdos(slaveConfig, EC_END, EL3064_syncs);

value1Offset = ecrt_slave_config_reg_pdo_entry(slaveConfig, 
EL3064_pdoEntries[9].index,
   EL3064_pdoEntries[9].subindex, domain, );
value2Offset = ecrt_slave_config_reg_pdo_entry(slaveConfig, 
EL3064_pdoEntries[19].index,
   EL3064_pdoEntries[19].subindex, domain, );
value3Offset = ecrt_slave_config_reg_pdo_entry(slaveConfig, 
EL3064_pdoEntries[29].index,
   EL3064_pdoEntries[29].subindex, domain, );
value4Offset = ecrt_slave_config_reg_pdo_entry(slaveConfig, 
EL3064_pdoEntries[39].index,
   EL3064_pdoEntries[39].subindex, domain, );

status1Offset = ecrt_slave_config_reg_pdo_entry(slaveConfig, 
EL3064_pdoEntries[0].index,
EL3064_pdoEntries[9].subindex, domain, );
statue2Offset = ecrt_slave_config_reg_pdo_entry(slaveConfig, 
EL3064_pdoEntries[10].index,
EL3064_pdoEntries[19].subindex, domain, );
status3Offset = ecrt_slave_config_reg_pdo_entry(slaveConfig, 
EL3064_pdoEntries[20].index,
EL3064_pdoEntries[29].subindex, domain, );
status4Offset = ecrt_slave_config_reg_pdo_entry(slaveConfig, 
EL3064_pdoEntries[30].index,
EL3064_pdoEntries[39].subindex, domain, );

The module returns a value between 0 and 32767 (int16 value) to represent 0 - 
10V.  From that you can figure out your scale factor.  You can use a LRW 
(read/write) domain.

Regards,
Graeme.

From: Sy Meshkat 
Sent: Tuesday, 9 July 2019 6:33 AM
To: Graeme Foot 
Subject: Question on use of EL3064 (Beckhoff ADC)

Dear Graeme,

This is Sy Meshkat with DSP Control Group.  Rahul and I talked/wrote to you 
about Yaskawa EtherCAT Sigma drive in summer of 2017.  Thanks to your helps our 
application is application is working fine.

Now, the question I have is weather you have any example of Beckhoff EL3064 
Analog to Digital Converter as part of Linux EtherLab application stack.  This 
is a simple 4 channel ADC, but we couldn't find this hardware in IgH's EtherCAT 
master's hardware.

Best regards,
 Sy Meshkat
 [cid:image001.jpg@01D5363E.BF036280]
DSP Control Group, Inc.
4445 W 77th Street
Minneapolis, MN 55435

general .   t:  1 + ( 952 ) 831 - 9556
fax f:  1 + ( 952 ) 831 - 4697
cell c:  1 + ( 612 ) 309 - 5478
directe:  1 + ( 952 ) 831 - 2349
website i:   www.dspcg.com<http://

Re: [etherlab-users] A question about ecrt_master_reference_clock_time

[Graeme Foot]

Hi,

The long answer:
A call to ecrt_master_sync_slave_clocks() queues a request to sync slaves to 
the ref slave.  ecrt_master_send() will then send the request (along with any 
other queued datagrams).  ecrt_master_receive() will process the returned 
datagrams, of which ecrt_master_sync_slave_clocks() returns the reference 
slaves system time (i.e. the time of the slave, minus the slaves transmission 
delay).  ecrt_master_reference_clock_time() can then be used to query the 
returned value from ecrt_master_sync_slave_clocks().

The short answer:
ecrt_master_reference_clock_time() returns the value retrieved by the previous 
ecrt_master_sync_slave_clocks() datagram.

Regards,
Graeme.


-Original Message-
From: etherlab-users  On Behalf Of Mohsen 
Alizadeh Noghani
Sent: Saturday, 29 December 2018 5:29 AM
To: etherlab-users@etherlab.org
Subject: [etherlab-users] A question about ecrt_master_reference_clock_time

Hello everyone.

When "ecrt_master_reference_clock_time" is called, does EtherCAT Master read 
the reference clock at that instant (i.e. it communicates with the reference 
slave specifically for reading its clock), or does the clock value already 
exist in the datagram received by "ecrt_master_receive", and thus function just 
parses the datagram?

Best,
Mohsen
___
etherlab-users mailing list
etherlab-users@etherlab.org
http://lists.etherlab.org/mailman/listinfo/etherlab-users
___
etherlab-users mailing list
etherlab-users@etherlab.org
http://lists.etherlab.org/mailman/listinfo/etherlab-users

Re: [etherlab-users] Syncing master to the reference slave: should I care?

[Graeme Foot]

FYI option 2 is the default method for TwinCAT.



Either method is fine, as long as you take care to reduce timing errors.  You 
should call ecrt_master_application_time() just before the ecrt_master_send() 
to reduce the amount of time variation between telling the master the PC's time 
and that time going on the wire.



If you are using distributed clocks you care about drift.  If you are doing 
coordinated motion on your robot you should probably be using distributed 
clocks.  If "all the clocks are drifting, as long as they are synchronized with 
respect to each other" then that is actually what you are trying to achieve 
anyway.  You choose one clock as the master for the system and sync the rest to 
it.  The main thing you need to achieve is make sure the master always sends 
out its frame so that it reaches all of the slaves before the slaves 
distributed clock SYNC0 events fire.





I use option 2 for a few reasons:



- Linux calculates a Timebase Frequency on startup.  It is only a quick 
calculation so that it does not hold up booting Linux for too long, but that 
also means it is not particularly accurate, and can be different each time you 
reboot Linux.  This affects the speed of your PC's clock so, if you use option 
1, each time you reboot Linux your system may run at a different speed.  (Note, 
I use RTAI and the time base can be calibrated and set so that it is the same 
each time, however I auto calibrate my PC to my reference slave clock.)



- I use Yaskawa axes that do not like too great a drift compensation.  If the 
timebase calculation above is too far out my axes can have issues and lose 
their sync.



- I figure a slaves clock is most likely to more similar to the rest of the 
slaves clocks, so there will be minimal drift compensation (opinion, not 
confirmed).



- If you use option 1 you rely on the time between calling 
ecrt_master_application_time() and the frame going on the wire and the position 
of the message in that frame being as constant as possible otherwise the slaves 
will get a lot of jitter in their drift compensations.  The Etherlab master has 
multiple code paths which take various amounts of time each cycle so you cannot 
control this jitter.  Using option 2 often means that the slaves have a much 
more stable drift compensation and all you need to really care about in your 
application code is that you keep waking up in time to process the datagrams, 
do your calculation and send out the new data before the slaves need it.  You 
don't really care too much about jitter here.





Lastly, if you are getting timing error's using option 2 then your master time 
compensation method is probably wrong.  I don't use the timing method from the 
rtai_rtdm_dc example so I don't know what might be wrong there.



Regards,

Graeme





-Original Message-
From: etherlab-users  On Behalf Of Mohsen 
Alizadeh Noghani
Sent: Saturday, 17 November 2018 9:46 PM
To: etherlab-users@etherlab.org
Subject: [etherlab-users] Syncing master to the reference slave: should I care?



Hello everyone.

In terms of choosing the reference clock in the network, there are two options. 
In the first method, PC clock is chosen as the reference and in the second one, 
slave 0's clock is the reference.

1- Syncing slave 0's clock to the master (application) time: this is the method 
used by default by the EtherLab master.

2- Syncing master (application) time to slave 0: requires implementing the 
synchronization algorithm by the user, as seen in "rtai_rtdm_dc"

example. This method boasts lower drift, as the slave's clock is more stable.



However, in my experience, the latter method is more prone to master's jitter, 
and thus less reliable during a long-term run (e.g. a 24h test under stress).

My area of application is robot motion control.

The question is, using the first method, should I care about clock drift? I 
feel that, even if all the clocks are drifting, as long as they are 
synchronized with respect to each other, there shouldn't be any issues.

Best,

Mohsen

___

etherlab-users mailing list

etherlab-users@etherlab.org

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

Re: [etherlab-users] Regular "working counter changes" error

[Graeme Foot]

It's toggling between 13 and 21 slave responding.  Maybe check the Ethernet 
cable / connection between them.

Also try the crc and diag commands to check for communication errors.

Regards,
Graeme.

From: etherlab-users  On Behalf Of 
law_...@aliyun.com
Sent: Sunday, 18 November 2018 2:01 AM
To: etherlab-users 
Subject: [etherlab-users] Regular "working counter changes" error

Dear all,

I am running Etherlab master with Gavin's patches to drive some IO modules 
and servo drivers.
All the slaves are successfully configured and switched to OP. But I got a lot 
of working counter
warnings begin from it is started. Part of the dmesg log is shown below:


[ 4764.420650] EtherCAT 0: Domain 0: 670 working counter changes - now 13/21.

[ 4765.424640] EtherCAT 0: Domain 0: 669 working counter changes - now 21/21.

[ 4766.428629] EtherCAT 0: Domain 0: 669 working counter changes - now 13/21.

[ 4767.432619] EtherCAT 0: Domain 0: 670 working counter changes - now 13/21.

[ 4768.436609] EtherCAT 0: Domain 0: 669 working counter changes - now 21/21.

[ 4769.440597] EtherCAT 0: Domain 0: 669 working counter changes - now 13/21.

[ 4770.444586] EtherCAT 0: Domain 0: 670 working counter changes - now 13/21.

[ 4771.448576] EtherCAT 0: Domain 0: 669 working counter changes - now 21/21.

Some information of my system:  CPU: AMD ryzen5 1600x, Intel I211 network 
card, LMDE2(Debian8),
Kernel: 4.9.0-0.bpo.8-rt-amd64 (rt-preempt),  IgH EtherCAT master 1.5.2 
d5f6daedadc3+,
I am using the generic driver.

I believe this is not a timing problem of the realtime master thread. 
Because I have isolated serval cores (6-11)
for realtime tasks, and the max jitter of realtime thread is no more than 5us.
mint@lmde ~ $ sudo cyclictest -p80 --smp
[sudo] password for mint:
# /dev/cpu_dma_latency set to 0us
WARN: Running on unknown kernel version...YMMV
policy: fifo: loadavg: 0.32 0.09 0.03 1/872 17643
T: 0 (17345) P:80 I:1000 C:  58319 Min:  1 Act:2 Avg:3 Max: 
 34
T: 1 (17346) P:80 I:1500 C:  38879 Min:  1 Act:5 Avg:4 Max: 
113
T: 2 (17347) P:80 I:2000 C:  29159 Min:  1 Act:3 Avg:4 Max: 
 42
T: 3 (17348) P:80 I:2500 C:  23327 Min:  1 Act:3 Avg:4 Max: 
 43
T: 4 (17349) P:80 I:3000 C:  19439 Min:  1 Act:3 Avg:5 Max: 
 32
T: 5 (17350) P:80 I:3500 C:  16662 Min:  1 Act:3 Avg:4 Max: 
 27
T: 6 (17351) P:80 I:4000 C:  14579 Min:  2 Act:3 Avg:3 Max: 
  4
T: 7 (17352) P:80 I:4500 C:  12959 Min:  2 Act:3 Avg:3 Max: 
  5
T: 8 (17353) P:80 I:5000 C:  11663 Min:  2 Act:3 Avg:3 Max: 
  5
T: 9 (17354) P:80 I:5500 C:  10603 Min:  2 Act:3 Avg:3 Max: 
  5
T:10 (17355) P:80 I:6000 C:   9719 Min:  2 Act:4 Avg:3 Max: 
  4
T:11 (17356) P:80 I:6500 C:   8972 Min:  2 Act:3 Avg:3 Max: 
  4

I have tried to use DC but the errors still happen. Related codes:
ecrt_domain_queue(domain1);
clock_gettime(CLOCK_TO_USE, );
ecrt_master_application_time(master, TIMESPEC2NS(time));
ecrt_master_sync_reference_clock(master);
ecrt_master_sync_slave_clocks(master);
ecrt_master_send(master);
The sync functions are called after ecrt_domain_queue() as suggested in 
other mail threads.


I have also tried the igb driver instead of generic, but the problem still.



Can anyone help explain what is happening and what should I do to get rid of 
these errors please?

Thanks in advance,

Yours,
Jancon


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

Re: [etherlab-users] Measuring the frequency of master sending the frames to network

[Graeme Foot]

Two options:

1) You can use wireshark on another computer.

- Plug in a switch inline somewhere on your EtherCAT network, make sure it 
forwards without delay
- Also plug your second computer into the switch, make sure you disable all 
protocols on the network card (but not the card itself)

1a)
- In your application cycle call ecrt_master_sync_slave_clocks()
- Run your application and use wireshart to log your data
- Run the command:
"C:\Program Files\Wireshark\tshark.exe" -r data.pcap -T fields -e 
ecat.reg.dc.systimeL > data.txt
(replacing data.pcap and data.txt with your input and output filenames)

1b) If you have gavinl's patchset
- In your application cycle call ecrt_master_64bit_reference_clock_time_queue()
- Run your application and use wireshart to log your data
- Run the command:
"C:\Program Files\Wireshark\tshark.exe" -r data.pcap -T fields -e 
ecat.reg.dc.systime > data.txt
(replacing data.pcap and data.txt with your input and output filenames)

- Filter out the appropriate information from data.txt and analyse.  Note: 
wireshark will see each packet twice, once going out and once coming back in.  
If the switch is before your reference slave then the timestamp will only be in 
the returning packet, if it's after then it will be in both.


2) analyse the info within your app

2a)
- In your application cycle call ecrt_master_sync_slave_clocks()
- get the 32bit clock value using ecrt_master_reference_clock_time()

2b) If you have gavinl's patch set
- In your application cycle call ecrt_master_64bit_reference_clock_time_queue()
- get the 64bit clock value using ecrt_master_64bit_reference_clock_time()

- Analyse the results yourself in the app, or log to file


Notes:
- The wireshark message timestamp is not accurate enough by itself, hence using 
the distributed clock reference slave timestamp
- EtherCAT frames are broadcast messages so you don't need to do anything 
special on the switch for your wireshark PC to be able to see them
- See: https://www.wireshark.org/docs/dfref/e/ecat.html for a list of possible 
tshark ethercat fields
- The EtherCAT master syncs reference slave using the lower 32bits of the dc 
clock.  If your application is running at 1khz then this value rolls over every 
4.2 odd seconds, so gets more complicated to track long running time.  Gavinl's 
patchset adds the ability to read the whole 64bit timestamp using 
ecrt_master_sync_slave_clocks().

Regards,
Graeme Foot.



From: etherlab-users  On Behalf Of Mohsen 
Alizadeh Noghani
Sent: Tuesday, 2 October 2018 10:50 PM
To: etherlab-users@etherlab.org
Subject: [etherlab-users] Measuring the frequency of master sending the frames 
to network

In motion control applications, smooth motion and small error often requires an 
update rate of at least 1 KHz.
When defining a task in RTAI, we can set its execution frequency. Therefore, if 
we set the frequency to 2 KHz, the master is expected to send EtherCAT frames 
every 0.5 ms + jitter.
Other than using a network probe (e.g. Beckhoff ET2000) connected to another PC 
and analyzing the timestamps, is there a reliable way for measuring this 
frequency? In other words, I want to stress test the master for a few hours and 
make sure that all frames are sent before the real-time deadlines.
Best,
Mohsen

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

[etherlab-users] Missing Vendor ID / Product Code

[Graeme Foot]

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

Re: [etherlab-users] Slave DC start time calculation

[Graeme Foot]

Yeah, that case probably is better just as an error, but the interface does not 
currently allow an error return value.  Could just log the condition and set 
all values to zero.

The "cycle time" name is erroneous regardless if you want to maintain backwards 
compatibility.  I was just trying to enable the last parameter so that the code 
could be a little better at self documenting.  So, for your example, if you 
also wanted a small sync1 shift of say 1000 you could then have 
ecrt_slave_config_dc(sc, 25, 0, 75, 1000).

Having ecrt_slave_config_dc(sc, 25, 0, 751000, 0) could lead to confusion 
when reading the code in the future.  Also, a parameter that does nothing, can 
lead to frustration for people using the function for the first time.


But I'm happy either way, now I know what it does.

Graeme.


From: Gavin Lambert [mailto:gavin.lamb...@tomra.com]
Sent: Monday, 21 May 2018 12:57 PM
To: Graeme Foot <graeme.f...@touchcut.com>; Philippe Leuba 
<ple...@swissonline.ch>
Cc: etherlab-users@etherlab.org
Subject: RE: [etherlab-users] Slave DC start time calculation

I would be inclined to treat that as an error, or as DC sync outputs disabled.  
(It does need to treat all parameters == 0 as valid but disabled.)  The sync1 
cycle time can’t be used directly as a sync0 cycle time anyway – the whole 
thing is meaningless if there isn’t a sync0 cycle time.

The fact that sync1 cycle isn’t actually a cycle time makes me a little wary of 
the whole idea of separating cycle and shift like this.

Remember that ecrt_slave_config_dc(sc, 25, 0, 75, 0) causes a SYNC0 
cycle of 250us and a SYNC1 cycle of 1000us – it’s impossible to calculate the 
latter without a SYNC0 cycle time.

From: Graeme Foot [mailto:graeme.f...@touchcut.com]
Sent: Monday, 21 May 2018 12:36
To: Gavin Lambert <gavin.lamb...@tomra.com<mailto:gavin.lamb...@tomra.com>>; 
Philippe Leuba <ple...@swissonline.ch<mailto:ple...@swissonline.ch>>
Cc: etherlab-users@etherlab.org<mailto:etherlab-users@etherlab.org>
Subject: RE: [etherlab-users] Slave DC start time calculation

Hi,

That bit I'm unsure of.  It's based on the assumption that if the sync0 cycle 
time is zero, then sync1 won't occur.  So it will set the sync0 cycle time to 
the requested sync1 cycle time instead (and adjusting the sync0 shift time), 
setting sync1 cycle and shift times to zero, meaning sync1 will be triggered at 
the same time as sync0, at the time sync1 was meant to be triggered.

This is to avoid the mod (%) call occurring on a zero sync0_cycle_time.

Is there a better alternative for this case?

Graeme.


From: Gavin Lambert [mailto:gavin.lamb...@tomra.com]
Sent: Monday, 21 May 2018 11:52 AM
To: Graeme Foot <graeme.f...@touchcut.com<mailto:graeme.f...@touchcut.com>>; 
Philippe Leuba <ple...@swissonline.ch<mailto:ple...@swissonline.ch>>
Cc: etherlab-users@etherlab.org<mailto:etherlab-users@etherlab.org>
Subject: RE: [etherlab-users] Slave DC start time calculation

Why are you adjusting dc_sync[0] from sync1_*?  That doesn’t seem like it would 
ever be a sensible thing to do, unless I’m missing something.

From: Graeme Foot [mailto:graeme.f...@touchcut.com]
Sent: Monday, 21 May 2018 11:20
To: Philippe Leuba <ple...@swissonline.ch<mailto:ple...@swissonline.ch>>; Gavin 
Lambert <gavin.lamb...@tomra.com<mailto:gavin.lamb...@tomra.com>>
Cc: etherlab-users@etherlab.org<mailto:etherlab-users@etherlab.org>
Subject: RE: [etherlab-users] Slave DC start time calculation

I would propose the attached patch (completely untested).

This allows the sync1 offset to be used in a fashion compatible with any 
existing codebase (hopefully) by adding the sync1 cycle time together with the 
sync1 shift time, then splitting them out based on the sync0 cycle time.  The 
only braking case I can think of is if someone has used a sync1 shift 
parameter, not noticing that it is currently not doing anything.

It will also handle a case where the combined time, that will be passed to 
register 0x9A4, will be negative (logging a config error).  It will also handle 
a case where the sync0 cycle time is zero (not sure if this is allowed with a 
non-zero sync1 cycle???) and set up the dc to set the sync0 cycle time instead, 
adjusting the sync0 shift time by the sync1 shift time.

Philippe, in your case you would then call:
ecrt_slave_config_dc(sc, 0x0700, 50, 25, 0, 1000);

or (for backwards compatibility)
ecrt_slave_config_dc(sc, 0x0700, 50, 25, 1000, 0);


Graeme.


From: etherlab-users [mailto:etherlab-users-boun...@etherlab.org] On Behalf Of 
Philippe Leuba
Sent: Friday, 18 May 2018 8:11 PM
To: Gavin Lambert <gavin.lamb...@tomra.com<mailto:gavin.lamb...@tomra.com>>
Cc: etherlab-users@etherlab.org<mailto:etherlab-users@etherlab.org>
Subject: Re: [etherlab-users] Slave DC start time calculation

Good idea, this should work for different kin

Re: [etherlab-users] Slave DC start time calculation

[Graeme Foot]

I would propose the attached patch (completely untested).

This allows the sync1 offset to be used in a fashion compatible with any 
existing codebase (hopefully) by adding the sync1 cycle time together with the 
sync1 shift time, then splitting them out based on the sync0 cycle time.  The 
only braking case I can think of is if someone has used a sync1 shift 
parameter, not noticing that it is currently not doing anything.

It will also handle a case where the combined time, that will be passed to 
register 0x9A4, will be negative (logging a config error).  It will also handle 
a case where the sync0 cycle time is zero (not sure if this is allowed with a 
non-zero sync1 cycle???) and set up the dc to set the sync0 cycle time instead, 
adjusting the sync0 shift time by the sync1 shift time.

Philippe, in your case you would then call:
ecrt_slave_config_dc(sc, 0x0700, 50, 25, 0, 1000);

or (for backwards compatibility)
ecrt_slave_config_dc(sc, 0x0700, 50, 25, 1000, 0);


Graeme.


From: etherlab-users [mailto:etherlab-users-boun...@etherlab.org] On Behalf Of 
Philippe Leuba
Sent: Friday, 18 May 2018 8:11 PM
To: Gavin Lambert <gavin.lamb...@tomra.com>
Cc: etherlab-users@etherlab.org
Subject: Re: [etherlab-users] Slave DC start time calculation

Good idea, this should work for different kind of slaves and did not break 
backward compatibility.

How to proceed now ?

Philippe

On May 18, 2018, at 7:24 AM, Gavin Lambert 
<gavin.lamb...@tomra.com<mailto:gavin.lamb...@tomra.com>> wrote:
I don’t think it makes sense to start using the sync1_shift_time parameter, as 
that would introduce incompatibility with other code (that perhaps hasn’t 
upgraded to that build yet, or hasn’t noticed or doesn’t care about the change 
in start time), and introduce some additional ambiguity.

In theory (completely untested air code) something like this might be more 
correct:

cycle = sync0->cycle_time + sync1->cycle_time – (sync1->cycle_time % 
sync0->cycle_time);

From: Philippe Leuba [mailto:ple...@swissonline.ch]
Sent: Friday, 18 May 2018 16:34
To: Gavin Lambert <gavin.lamb...@tomra.com<mailto:gavin.lamb...@tomra.com>>
Cc: Graeme Foot <graeme.f...@touchcut.com<mailto:graeme.f...@touchcut.com>>; 
etherlab-users@etherlab.org<mailto:etherlab-users@etherlab.org>
Subject: Re: [etherlab-users] Slave DC start time calculation

Hi Gavin,

Thanks for the detailed explanation, this explain why the code is like it is. 
This works for slaves that are doing oversampling but not for mine that just 
want to shift the SYNC1 a bit.

Now if we want a solution working  for all kind of possibles slave 
configurations we will need to use the sync1_shift_time parameter of the 
ecrt_slave_config_dc into the loop...

What do you think ?

Philippe

On May 18, 2018, at 5:15 AM, Gavin Lambert 
<gavin.lamb...@tomra.com<mailto:gavin.lamb...@tomra.com>> wrote:
The SYNC1 Cycle register (0x09A4) is a little weird; it acts as both a cycle 
and shift in one register, depending on the value of the SYNC0 Cycle (0x09A0).


  *   Where SYNC0 Cycle is X and SYNC1 Cycle is 0, SYNC0 and SYNC1 occur at the 
same time – thus same cycle, no shift.
  *   Where SYNC0 Cycle is X and SYNC1 Cycle is less than X, SYNC1 occurs at 
(SYNC1 Cycle) ns after the SYNC0, but otherwise at the same cycle rate – thus 
it acts as a shift.
  *   Where SYNC0 Cycle is X and SYNC1 Cycle is equal to X, SYNC1 occurs at 
every second SYNC0 – thus it acts as a 2X cycle with no shift.
  *   Where SYNC0 Cycle is X and SYNC1 Cycle is equal to 2X, SYNC1 occurs at 
every third SYNC0 – thus it acts as a 3X cycle with no shift.
  *   Where SYNC0 Cycle is X and SYNC1 Cycle is greater than X but not an exact 
multiple, it acts as a combination of cycle and shift as above.

(Under the hood, it always does behave as a shift that fires exactly once 
non-overlapping offset from the SYNC0 pulse.  Or to put it another way, SYNC0 
starts the timer but doesn’t reset it if already running, and it fires SYNC1 
once when the timer finishes.)

The ecrt_slave_config_dc method essentially just sets the cycle values into the 
registers directly, while using the sync0_shift to calculate the overall DC 
start time relative to the master cycle.  The sync1_shift parameter is ignored 
and should always be 0 because there’s nothing it can actually do with it.

Exactly what these mean is slave-specific; some slaves want a simple shift at 
the same cycle rate because they use one to control output timing and the other 
to control input timing.  Other slaves might want a subordinated cycle (SYNC1 
occurring at the master cycle rate, SYNC0 occurring more frequently) because 
they want to oversample inputs.  Or there can be a number of other scenarios.  
The slave documentation should tell you what settings you need relative to your 
master cycle.

For what it’s worth, I do have a subordinated slave – it uses 
ecrt_slave_config_dc(sc, 25,

Re: [etherlab-users] Slave DC start time calculation

[Graeme Foot]

Hi,

This piece of code is getting a start time that is in sync with the initial app 
time from a multiple of the sync0/sync1 cycle times, adjusted by the sync0 
shift time.

https://download.beckhoff.com/download/Document/io/ethercat-development-products/ethercat_esc_datasheet_sec2_registers_2i7.pdf
says the sync1 cycle time is the "Time between SYNC1 pulses and SYNC0 pulse in 
ns".

However 
https://infosys.beckhoff.com/english.php?content=../content/1033/tcsystemmanager/reference/ethercat/html/EtherCAT_DistributedClocks.htm=
 (Twincat DC settings) and the information for my yaskawa drives are saying 
that the sync1 cycle time should be a multiple of the sync0 cycle time, and the 
sync1 offset is the offset between the sync0 and sync1 interrupts.

The master code doesn’t even look like it uses the sync1 shift time, and 
information from my Yaskawa slave says it's sync1 cycle time is readonly and 
matches the sync0 cycle time.


So:
- It looks like the first documents registers 0x09A4:0x09A7 should actually be 
called sync1 shift time.
- It does not look like there is currently any slave support for a different 
(from sync0) sync1 cycle time.
(anyone got a slave out there that does?)
- The EtherLab master should not be using sync1 cycle time in the calculation 
you mention below.
- The EtherLab master should be sending sync1 shift time to 0x09A4:0x09A7 
instead of the sync1 cycle time.
- TwinCAT is probably using its cycle time "multiple" parameters to figure out 
how often to send the PDO requests for each slave (just a guess).


In your case, set the second to last parameter to zero, i.e.:
ecrt_slave_config_dc(sc, 0x0700, 50, 25, 0, 0);

You have already adjusted the sync0 shift time (third to last parameter) anyway.


Regards,
Graeme.



From: etherlab-users [mailto:etherlab-users-boun...@etherlab.org] On Behalf Of 
Philippe Leuba
Sent: Friday, 18 May 2018 7:11 AM
To: etherlab-users@etherlab.org
Subject: Re: [etherlab-users] Slave DC start time calculation

Hi,

I have changed how to calculate the slave start time by taking only the 
sync0->cycle_time as cycle time.
The results is good and I can see in the log that the 'remainder' is almost the 
same for all slaves.

@Florian: Why did you did this change on 2016-09-16 ?

Best regards

Philippe

On May 16, 2018, at 6:22 PM, Philippe Leuba 
> wrote:
Hi All,

I can not understand how to configure correctly my slaves with the 
ecrt_slave_config_dc() function.

I use nine EL7211-9014 servo controllers and the XML declarations is:



DC
DC-Synchron
#x700
0
3
0
1000



SYNC0 and SYNC1 should be fired at each cycle.

My realtime cycle is at 500us, so initially I used:

ecrt_slave_config_dc(sc, 0x0700, 50, 3, 1000, 0);

but I sometimes faced some hiccup on some motor movements (almost always on the 
same motor, but sometimes not), most probably due to frames late regarding SYNC 
events, so I increased the sync1_shift to half of the cycle time:

ecrt_slave_config_dc(sc, 0x0700, 50, 25, 1000, 0);

This help, but I’m still not convinced that it is correct.

How can I debug this, I did not see any error on slaves COEs 1c32 or 1c33 ?

Startup debug messages are the followings:

EtherCAT DEBUG 0-12: Checking for synchrony.
EtherCAT DEBUG 0-12: 19 ns difference after 1 ms.
EtherCAT DEBUG 0-12: app_start_time=64456682505935
EtherCAT DEBUG 0-12:   app_time=64460192975876
EtherCAT DEBUG 0-12: start_time=64460292975876
EtherCAT DEBUG 0-12:  cycle=501000
EtherCAT DEBUG 0-12: shift_time=25
EtherCAT DEBUG 0-12:  remainder=263941
EtherCAT DEBUG 0-12:  start=64460293462935
EtherCAT DEBUG 0-12: Setting DC cyclic operation start time to 64460293462935.
EtherCAT DEBUG 0-12: Setting DC AssignActivate to 0x0700.
-
-
-
EtherCAT DEBUG 0-13: Checking for synchrony.
EtherCAT DEBUG 0-13: 9 ns difference after 1 ms.
EtherCAT DEBUG 0-13: app_start_time=64456682505935
EtherCAT DEBUG 0-13:   app_time=64460854977928
EtherCAT DEBUG 0-13: start_time=64460954977928
EtherCAT DEBUG 0-13:  cycle=501000
EtherCAT DEBUG 0-13: shift_time=25
EtherCAT DEBUG 0-13:  remainder=444993
EtherCAT DEBUG 0-13:  start=64460955283935
EtherCAT DEBUG 0-13: Setting DC cyclic operation start time to 64460955283935.
EtherCAT DEBUG 0-13: Setting DC AssignActivate to 0x0700.

I’m really surprised that the remainder can be so different, so I looked in the 
source code and can not understand the logic:

// set DC start time
start_time = master->app_time + EC_DC_START_OFFSET; // now + X ns (X being 
1 = 100 ms)

if (sync0->cycle_time) {
// find correct phase
if (master->has_app_time) {
u64 diff, start;
u32 remainder, cycle;

diff = start_time - master->app_start_time;
cycle = sync0->cycle_time + sync1->cycle_time;
remainder = do_div(diff, cycle);

 

Re: [etherlab-users] How to perform DC time synchronisation the right way?

[Graeme Foot]

Hi,



Firstly, there is no way of checking if the frame transfer is complete.



One comment, to reduce the jitter and offset of the master application time, 
place the clock_gettime(), ecrt_master_application_time(), 
ecrt_master_sync_reference_clock(), ecrt_master_sync_slave_clocks() calls after 
ecrt_domain_queue() (and before ecrt_master_send()).



It doesn't matter how long "do a lot of stuff" takes as long as the application 
time is set just before the send and your cycle start time is in sync with the 
initial call to ecrt_master_application_time().





Traditional cycle:

- master receive

- domain process

- perform application calcs

- domain queue

- dc sync

- master send



-> as long as the time to master send and the time on the wire is shorter than 
sync0 offset then you are all good.





Alternate option:

- cycle time 0, wakeup

- domain queue

- dc sync

- master send

- sleep for data over wire time

- wakeup

- master receive

- domain process

- perform application calcs

- sleep



-> you need to determine the appropriate sleep time between the master send and 
receive to allow for software overhead and time on the wire.



Note: You can guess a time on the wire by using the "ethercat slaves -v" 
command.  Look up the "DC system time transmission delay" on your last slave 
and double it.





I do something a little different.  My cycle:

- master receive

- domain process

- write cached PDO values

- domain queue

- dc sync

- master send

- perform application calcs (writes to PDO data is cached)



This has the advantage of a very short turnaround with minimal jitter between 
the receive and send.  It allows nearly a whole cycle for the data to be on the 
wire.  It also allows for up to the remainder of that cycle to be used for 
application calculations, in parallel to the data being on the wire.  The 
drawbacks are:

- The domain process step will overwrite any PDO data changes you have made 
while performing your application calcs, so you need to cache your changes 
somewhere else then apply them after the domain process step

- You add 1 extra cycle delay for the PDO data being read.



However, your cycle time can generally also be reduced by an amount since the 
"app calc time" and "data on the wire time" are now in parallel.



The traditional cycle takes around three cycles between writing data and 
receiving its results (3 * 1ms = 3ms turnaround)

My cycle can often be reduced to at least ½ of the traditional cycle.  Even 
though it has the extra cycle overhead it still has a better turnaround (4 * 
0.5ms = 2ms turnaround)



I personally don't reduce my cycle time (I keep it at 1ms) as I'm happy at the 
extra cycle delay and some of our controllers can have quite a large 
calculation overhead.





Just some info on timing from one of our controllers (around 55 slaves)

- 30us to perform master receive through to master send

- 150us to perform application calcs





One last comment.  Assuming a linear topology, the EtherCAT frames are sent out 
through all of the slaves and once it reaches the last slave it returns through 
all of the slaves.  It should take a similar time between outgoing and 
returning.  Only the outgoing data needs to arrive before the Sync0 event.  So 
with my method you can allow nearly the whole cycle for the data to be on the 
wire as long as your Sync0 events are configured to be after the cycle half 
time.  If it's not a linear topology, this does not apply.





Regards,

Graeme.





-Original Message-

From: etherlab-users [mailto:etherlab-users-boun...@etherlab.org] On Behalf Of 
Michael Ruder

Sent: Wednesday, 16 May 2018 4:34 AM

To: etherlab-users@etherlab.org

Subject: [etherlab-users] How to perform DC time synchronisation the right way?



Hello,



I am progressing quite well with EtherLab and am currently working on 
synchronizing outputs/movement with the Master time. We are using the Master 
1.5.2 from the 1.5.2 branch, ec_generic driver with PREEMPT RT (kernel 4.14.28).



In our application, we need to be synchronized to the real time (UTC). We use a 
GPS receiver and Chrony to synchronize our PC clock to within a few 
microseconds.



Now I want to have the slaves also synchronized to this time frame and have the 
following dilemma:



- normally, I would like to call



// cycle begins



ecrt_master_receive(master);

ecrt_domain_process(domain1);



// do a lot of stuff



clock_gettime(CLOCK_REALTIME, );

ecrt_master_application_time(master, ((time.tv_sec - 946684800ULL) * 
10ULL + time.tv_nsec));



ecrt_master_sync_reference_clock(master);

ecrt_master_sync_slave_clocks(master);



ecrt_domain_queue(domain1);

ecrt_master_send(master);



// cycle ends, wait for next cycle



However, as the "lot of stuff" takes different amounts of time, this seems to 
be not good, as this means a few hundred microseconds jitter as to when the 
application time is set in our (1 ms long) cycle.



- therefore, I 

Re: [etherlab-users] Cyclic Synchronous Position mode

[Graeme Foot]

Note: from your previous email you are also delaying the send to the start of 
the next cycle, which adds another cycle of delay.

Graeme.

From: etherlab-users [mailto:etherlab-users-boun...@etherlab.org] On Behalf Of 
Graeme Foot
Sent: Wednesday, 16 May 2018 10:57 AM
To: Michael Ruder <rude...@gmx.de>; etherlab-users@etherlab.org
Subject: Re: [etherlab-users] Cyclic Synchronous Position mode


It's something like



--

t = 0.0 : master receive datagram 0, receive actual position -2

t = 0.1 : master send datagram 1 (target position 1)

t = 0.2 : drive receive datagram 1 (actual position -1 returned)

t = 0.5 : drive sync 0, target position 1 becomes active, actual position 0 is 
recorded

--

t = 0.0 : master receive datagram 1, receive actual position -1

t = 1.1 : master send datagram 2

t = 1.2 : drive receive datagram 2 (actual position 0 returned)

t = 1.5 : drive sync 0, target position 2 becomes active, actual position 1 is 
recorded

--

t = 2.0 : master receive datagram 2, receive actual position 0

t = 2.1 : master send datagram 3

t = 2.2 : drive receive datagram 3 (actual position 1 returned)

t = 2.5 : drive sync 0, target position 3 becomes active, actual position 2 is 
recorded

--

t = 3.0 : master receive datagram 3, receive actual position 1

t = 3.1 : master send datagram 4

t = 3.2 : drive receive datagram 4 (actual position 2 returned)

t = 3.5 : drive sync 0, target position 4 becomes active, actual position 3 is 
recorded





So you are comparing Target Position 4 with Actual Position 1 which, due to the 
sync0 time, is around 2 ½ cycles old.



What you need to do is find the Following Error PDO index, add that to your 
drive PDO data, and use it.



I use Yaskawa Drives so don't know what the ELMO one is (and you need to log in 
to get the ESI file so I can't look it up).  On the Yaskawa drive it is index 
0x60F4:00.





Note: the above assumes that your master is waking at cycle time zero; the 
slave distributed clocks are nicely synced; you have an appropriate Sync Shift 
Time (say 500us); and the ecrt_master_send() is called so that the drive 
receives its datagram before the sync event.





Regards,

Graeme.





-Original Message-
From: etherlab-users [mailto:etherlab-users-boun...@etherlab.org] On Behalf Of 
Michael Ruder
Sent: Wednesday, 16 May 2018 4:52 AM
To: etherlab-users@etherlab.org<mailto:etherlab-users@etherlab.org>
Subject: [etherlab-users] Cyclic Synchronous Position mode



Hello,



I am currently experimenting with the Cyclic Synchronous Position mode of ELMO 
drives. I am using EtherLab 1.5.2 from the 1.5.2 branch with ec_generic on a 
PREEMPT RT system (kernel 4.14.28).



If I compare the current position the drive reports in the frame I receive 
after I send a frame with a new target position, I see a certain offset between 
this current position and the new target position that I do not understand. If 
I divide the offset by the current velocity, I receive a constant time delay of 
about 3.45 ms (which means 3.45 cycles, as we have

1 ms cycle time).



>From my understanding, the new target position should become active some time 
>after the frame has been received (depending on several 0x1c32 values), while 
>the inputs are sampled at some other moment (depending on serveral 0x1c33 
>values). This could explain the 0.45 cycles as being the delay between input 
>sampling and activating the output value.



However, this still does not explain the 3 cycle delay. One cycle I could 
understand because I compare the just sent target position with the right 
afterwards received current position, which is from the previous cycle.

But where do the other 2 come from? I could not find any documentation about a 
FIFO like buffer in the drives.



Also, for precise synchronisation, I would need to know the 0.45 ms delay not 
just approximately by measureing it. Unfortunately, all 0x1c32/0x1c33 (index 6 
and 9) are 0 for my slaves. Is there some "general" information on those delays?



I am using SYNC0 (with period 1 ms like my cycle). The SYNC0 offset does not 
affect the above offset, which seems however understandable as all 
0x1c3x-delays are relative to the SYNC0 moment. The SYNC0 offset however does 
of course affect the real time moment the axis reaches the position.



Thanks for any help,

--

.  -Michael

___

etherlab-users mailing list

etherlab-users@etherlab.org<mailto:etherlab-users@etherlab.org>

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

Re: [etherlab-users] Cyclic Synchronous Position mode

[Graeme Foot]

It's something like



--

t = 0.0 : master receive datagram 0, receive actual position -2

t = 0.1 : master send datagram 1 (target position 1)

t = 0.2 : drive receive datagram 1 (actual position -1 returned)

t = 0.5 : drive sync 0, target position 1 becomes active, actual position 0 is 
recorded

--

t = 0.0 : master receive datagram 1, receive actual position -1

t = 1.1 : master send datagram 2

t = 1.2 : drive receive datagram 2 (actual position 0 returned)

t = 1.5 : drive sync 0, target position 2 becomes active, actual position 1 is 
recorded

--

t = 2.0 : master receive datagram 2, receive actual position 0

t = 2.1 : master send datagram 3

t = 2.2 : drive receive datagram 3 (actual position 1 returned)

t = 2.5 : drive sync 0, target position 3 becomes active, actual position 2 is 
recorded

--

t = 3.0 : master receive datagram 3, receive actual position 1

t = 3.1 : master send datagram 4

t = 3.2 : drive receive datagram 4 (actual position 2 returned)

t = 3.5 : drive sync 0, target position 4 becomes active, actual position 3 is 
recorded





So you are comparing Target Position 4 with Actual Position 1 which, due to the 
sync0 time, is around 3 ½ cycles old.



What you need to do is find the Following Error PDO index, add that to your 
drive PDO data, and use it.



I use Yaskawa Drives so don't know what the ELMO one is (and you need to log in 
to get the ESI file so I can't look it up).  On the Yaskawa drive it is index 
0x60F4:00.





Note: the above assumes that your master is waking at cycle time zero; the 
slave distributed clocks are nicely synced; you have an appropriate Sync Shift 
Time (say 500us); and the ecrt_master_send() is called so that the drive 
receives its datagram before the sync event.





Regards,

Graeme.





-Original Message-
From: etherlab-users [mailto:etherlab-users-boun...@etherlab.org] On Behalf Of 
Michael Ruder
Sent: Wednesday, 16 May 2018 4:52 AM
To: etherlab-users@etherlab.org
Subject: [etherlab-users] Cyclic Synchronous Position mode



Hello,



I am currently experimenting with the Cyclic Synchronous Position mode of ELMO 
drives. I am using EtherLab 1.5.2 from the 1.5.2 branch with ec_generic on a 
PREEMPT RT system (kernel 4.14.28).



If I compare the current position the drive reports in the frame I receive 
after I send a frame with a new target position, I see a certain offset between 
this current position and the new target position that I do not understand. If 
I divide the offset by the current velocity, I receive a constant time delay of 
about 3.45 ms (which means 3.45 cycles, as we have

1 ms cycle time).



>From my understanding, the new target position should become active some time 
>after the frame has been received (depending on several 0x1c32 values), while 
>the inputs are sampled at some other moment (depending on serveral 0x1c33 
>values). This could explain the 0.45 cycles as being the delay between input 
>sampling and activating the output value.



However, this still does not explain the 3 cycle delay. One cycle I could 
understand because I compare the just sent target position with the right 
afterwards received current position, which is from the previous cycle.

But where do the other 2 come from? I could not find any documentation about a 
FIFO like buffer in the drives.



Also, for precise synchronisation, I would need to know the 0.45 ms delay not 
just approximately by measureing it. Unfortunately, all 0x1c32/0x1c33 (index 6 
and 9) are 0 for my slaves. Is there some "general" information on those delays?



I am using SYNC0 (with period 1 ms like my cycle). The SYNC0 offset does not 
affect the above offset, which seems however understandable as all 
0x1c3x-delays are relative to the SYNC0 moment. The SYNC0 offset however does 
of course affect the real time moment the axis reaches the position.



Thanks for any help,

--

.  -Michael

___

etherlab-users mailing list

etherlab-users@etherlab.org

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

Re: [etherlab-users] Sync problems and DC mode

[Graeme Foot]

The following function get the time from the slave at which the EtherCAT frame 
went through it
ecrt_master_reference_clock_time(master->master, >reference_time);

The following function will update the masters time with the last slaves time 
plus the app time period
ecrt_master_application_time(master->master, 
master->reference_time+master->app_time_period);


One problem is that the ecrt_master_application_time() call may not be exactly 
one master->app_time_period value beyond the slaves reference time.  There are 
many sources of jitter in your application, from the realtime wakeup time to 
various amounts of processing time since the wakeup to the above function call. 
 So you need to relate the ecrt_master_application_time() to your app's clock 
time.

Another thing you need to do for option B is relate the previous 
master->reference_time to the ecrt_master_reference_clock_time() and adjust 
your apps's time base to account for drift.  You can then sleep and wake up 
your rt thread in keeping with your slaves time period.


Graeme.

From: Ignacio Rosales Gonzalez [mailto:naro...@gmail.com]
Sent: Wednesday, 24 January 2018 12:57 a.m.
To: Graeme Foot <graeme.f...@touchcut.com>
Cc: Boris Skegin <boris.skegin...@googlemail.com>; etherlab-users@etherlab.org
Subject: Re: [etherlab-users] Sync problems and DC mode

Thanks for your reply Graeme!
I would try your changes for the A method (a EtherCAT master is the master 
clock:) putting domain_queue the first.
By the way for the B method (Slave DC master is the master clock) what is wrong 
in this approach?:

  // send process data
  rtapi_mutex_get(>mutex);

  // queue domain data
ecrt_domain_queue(master->domain);


//get the DC slave reference clock time and save in master->reference_time
ecrt_master_reference_clock_time(master->master, >reference_time);

// sync slaves to ref clock
ecrt_master_sync_slave_clocks(master->master);

//update master time with time got from dc ref slave
  ecrt_master_application_time(master->master, 
master->reference_time+master->app_time_period);

// send domain data

  ecrt_master_send(master->master);
  rtapi_mutex_give(>mutex);

Best regards,
Ignacio Rosales


2018-01-23 2:18 GMT+01:00 Graeme Foot 
<graeme.f...@touchcut.com<mailto:graeme.f...@touchcut.com>>:
As Boris says, master->app_time needs to actually match your PC's time 
(converted to your app's timeframe).

Another change you could try is as below.  From line 1115:

  // send process data
  rtapi_mutex_get(>mutex);

  // queue domain data
  ecrt_domain_queue(master->domain);

  // update application time
  master->app_time = rt_get_app_time();
  ecrt_master_application_time(master->master, master->app_time);

  // sync ref clock to master
  ecrt_master_sync_reference_clock(master->master);

  // sync slaves to ref clock
  ecrt_master_sync_slave_clocks(master->master);

  // send domain data
  ecrt_master_send(master->master);
  rtapi_mutex_give(>mutex);


You want as constant a time between calling ecrt_master_application_time() and 
ecrt_master_send() as possible.  The calls to ecrt_domain_queue() call takes 
variable amounts of processing time, so do that first.  Also call 
ecrt_master_sync_reference_clock() every cycle to ensure the reference slave 
gets lot of small updates rather than a few big updates.  This helps all slaves 
keep sync better.  It also avoids another source of variable processing time 
between ecrt_master_application_time() and ecrt_master_send().


Graeme.


-Original Message-
From: etherlab-users 
[mailto:etherlab-users-boun...@etherlab.org<mailto:etherlab-users-boun...@etherlab.org>]
 On Behalf Of Boris Skegin
Sent: Tuesday, 23 January 2018 2:07 p.m.
To: etherlab-users@etherlab.org<mailto:etherlab-users@etherlab.org>; Ignacio 
Rosales Gonzalez <naro...@gmail.com<mailto:naro...@gmail.com>>
Subject: Re: [etherlab-users] Sync problems and DC mode

Hello.

> With this version
> <https://github.com/narogon/linuxcnc-ethercat/commit/e4ab86ba6167ced53
> 2e49904059df580062b2d97#diff-059a684a933530837771b5a249433ff3>
> (also as attachment lcec_main.c) I get the servos sync and OP but it
> seems that the PDO doesn't arrive for some of the slaves (no idea why).

master->app_time += master->app_time_period;  means that you just sum
up constant cycle times of  the LinuxCNC thread. So any latency information 
gets lost here.

Rather  make  master->app_time  be equal to something like
rt_get_time() transferred to EtherCAT time.

I also think that a proper value for sync0Shift  can help a lot.

If however nothing of that helps, then proceed  to  Graeme Foot's option b) .

BTW, what exactly is your kernel and network card and do you really use an 
adopted ( non-generic) network driver?

Regards,
boris
___

Re: [etherlab-users] Sync problems and DC mode

[Graeme Foot]

The Sync0shift values should be the same for all slaves (with the same time 
base), so that they all apply their PDO data at the same shift time from the 
start of the period.  This allows you to send the PDO information any time 
between the start of the period and the sync time without the slave missing the 
information.  The distributed clock framework makes sure all the slaves clocks 
are in sync so that the sync0 time occurs at the same time on all the slaves.

I have a period of 1000us, so I use a shift time of 500us.  So I can use up to 
half of by period to receive, calc and send new PDOs.  Note: the send time 
includes the time the frame is on the wire.


Graeme.

From: etherlab-users [mailto:etherlab-users-boun...@etherlab.org] On Behalf Of 
Ignacio Rosales Gonzalez
Sent: Wednesday, 24 January 2018 12:47 a.m.
To: Boris Skegin 
Cc: etherlab-users@etherlab.org
Subject: Re: [etherlab-users] Sync problems and DC mode

Hello,
First of all  many thanks for your help!


If you look below, master->app_time is not really used in the code.
I get the dc ref slave clock with 
ecrt_master_reference_clock_time(master->master, >reference_time); and 
save in master->reference_time
after that

 ecrt_master_sync_slave_clocks(master->master); // sync slaves to ref clock
 ecrt_master_application_time(master->master, 
master->reference_time+master->app_time_period); //update master time with time 
got from dc ref slave

Could you help me with the Sync0shift values??  The topology of my network is 
line one.

Master - S1 - S2 - S3 . and so on until S25.

I suppose I must set a very small one for the first slave and increase it a 
little for the next ones, no??

The kernel is Linux debian 3.4-9-rtai-686-pae #1 SMP PREEMPT Debian 
3.4.55-4linuxcnc i686 GNU/Linux
what is the default one of the linuxcnc 2.7 debian wheezy

The network card is a realtek r8169

Thanks again
Regards,

Ignacio Rosales




2018-01-23 2:06 GMT+01:00 Boris Skegin 
>:
Hello.

> With this version
> 
> (also as attachment lcec_main.c) I get the servos sync and OP but it seems
> that the PDO doesn't arrive for some of the slaves (no idea why).

master->app_time += master->app_time_period;  means that you just sum
up constant cycle times of  the LinuxCNC thread. So any latency
information gets lost here.

Rather  make  master->app_time  be equal to something like
rt_get_time() transferred to EtherCAT time.

I also think that a proper value for sync0Shift  can help a lot.

If however nothing of that helps, then proceed  to  Graeme Foot's option b) .

BTW, what exactly is your kernel and network card and do you really
use an adopted ( non-generic) network driver?

Regards,
boris

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

Re: [etherlab-users] Sync problems and DC mode

[Graeme Foot]

As Boris says, master->app_time needs to actually match your PC's time 
(converted to your app's timeframe).

Another change you could try is as below.  From line 1115:

  // send process data
  rtapi_mutex_get(>mutex);

  // queue domain data
  ecrt_domain_queue(master->domain);

  // update application time
  master->app_time = rt_get_app_time();
  ecrt_master_application_time(master->master, master->app_time);

  // sync ref clock to master
  ecrt_master_sync_reference_clock(master->master);

  // sync slaves to ref clock
  ecrt_master_sync_slave_clocks(master->master);

  // send domain data
  ecrt_master_send(master->master);
  rtapi_mutex_give(>mutex);


You want as constant a time between calling ecrt_master_application_time() and 
ecrt_master_send() as possible.  The calls to ecrt_domain_queue() call takes 
variable amounts of processing time, so do that first.  Also call 
ecrt_master_sync_reference_clock() every cycle to ensure the reference slave 
gets lot of small updates rather than a few big updates.  This helps all slaves 
keep sync better.  It also avoids another source of variable processing time 
between ecrt_master_application_time() and ecrt_master_send().


Graeme.


-Original Message-
From: etherlab-users [mailto:etherlab-users-boun...@etherlab.org] On Behalf Of 
Boris Skegin
Sent: Tuesday, 23 January 2018 2:07 p.m.
To: etherlab-users@etherlab.org; Ignacio Rosales Gonzalez 
Subject: Re: [etherlab-users] Sync problems and DC mode

Hello.

> With this version
>  2e49904059df580062b2d97#diff-059a684a933530837771b5a249433ff3>
> (also as attachment lcec_main.c) I get the servos sync and OP but it 
> seems that the PDO doesn't arrive for some of the slaves (no idea why).

master->app_time += master->app_time_period;  means that you just sum
up constant cycle times of  the LinuxCNC thread. So any latency information 
gets lost here.

Rather  make  master->app_time  be equal to something like
rt_get_time() transferred to EtherCAT time.

I also think that a proper value for sync0Shift  can help a lot.

If however nothing of that helps, then proceed  to  Graeme Foot's option b) .

BTW, what exactly is your kernel and network card and do you really use an 
adopted ( non-generic) network driver?

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

Re: [etherlab-users] EtherCAT stack time requirement per domain is too long

[Graeme Foot]

> -Original Message-

> From: Sy Meshkat [mailto:sy.mesh...@dspcg.com]

> Sent: Friday, 12 January 2018 12:42 p.m.

> To: Graeme Foot <graeme.f...@touchcut.com>

> Subject: FW: EtherCAT stack time requirement per domain is too long

>

>

> Sorry, it actually takes 400 microseconds --> 8*400 microseconds = 3.2 ms

>

> -Original Message-

> From: Sy Meshkat [mailto:sy.mesh...@dspcg.com]

> Sent: Thursday, January 11, 2018 5:39 PM

> To: 'graeme.f...@touchcut.com'

> Subject: EtherCAT stack time requirement per domain is too long

>

>

> Dear Graeme,

>

> This is Sy, I supervise Rahul Deshpande with his EtherCAT project. In the

> past, Rahul has written several emails to you and your help has proven

> invaluable.

>

>

> Our EtharCat core in Linux works properly and we use it in a coordinated

> motion control application using multiple Yaskawa Ethercat Sigmas.

>

> In reviewing various timings, the time EtherCAT stack requires to process

> each domain, in our application is about 300 microseconds.  This is too

> long, especially because we have 8 Sigma 5 drives which means it takes 8*300

> microseconds = 3.2 ms to process all domains per cycle!

>

> What was your experience in your application? Did you notice that stack time

> requirement to process a domain was that long?  If so, how could we reduce

> it?

>

> Thanks in advance!

>

> Sy Meshkat





Hi,



(Remember to send or cc to the etherlab users forum.)



We use a Beckhoff CX2020 pc (1.4GHz Celeron single core).  We have machines 
with up to around 20 axes.  The cycle time is 1000Hz (1ms per cycle).  The 
Yaskawa axes use 65 bytes of PDO data per axis (I use a few more than just the 
standard parameters).  I use three domains for the application:

- Yaskawa axes read domain

- Yaskawa axes write domain

- Read/Write domain for all other modules.



My three domains with the 20 odd axes (and various digital and analogue IO) 
take approximately 30us to perform the following functions:

- ecrt_master_receive()

- ecrt_domain_process() (x3)

- ecrt_domain_state() (x3)

- ecrt_master_state()

- do some funky stuff with my data

- ecrt_domain_queue() (x3)

- ecrt_master_reference_clock_time()

- ecrt_master_sync_slave_clocks()

- ecrt_master_64bit_reference_clock_time_queue()

- ecrt_master_application_time()

- ecrt_master_send()

- some distributed clock calculations



My total processing time per cycle is approximately 160us, so around 16% of my 
cycle time.  This includes the above the above EtherCAT processing and all 
logic required to process the data.  It does not include command calls from our 
external control application, which get processed via the Linux context.





It sounds like you are creating two domains per axis.  If so, you don't need to 
do this.  You just need one domain per type of function (read, write, 
read/write) and add the IO from each module as appropriate.



>From memory you are using Xenomi.  What network card driver are you using?  I 
>don't think you can use the generic driver with Xenomi to achieve realtime 
>EtherCAT, you certainly can't with RTAI (which I use).



In RTAI there is a utility you can use (cat /proc/rtai/scheduler | grep 
'transitions') that will tell you if you are making any syscalls from your 
realtime context.  If you do so, then you drop out of realtime and are running 
code under the Linux context, which can take any amount of time.  Check if 
Xenomi has a similar utility.



Check that you have a stable realtime system with as little jitter as possible.



Other than that, put timers around various sections of the code and see if you 
can pinpoint any particularly slow functions.





Here is an example of the statistics page from our application for a machine 
running 16 axes:

[cid:image001.png@01D38DF5.579569B0]



I've circled the EtherCAT processing time in red and the axis specific logic 
time in green.





Regards,
Graeme.


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

Re: [etherlab-users] problem with ethercat xml

[Graeme Foot]

I've attached the output from some of the ethercat commands from my amp.  Note, 
my slave is configured to alias 12, so the -a12 just filters to only show 
information for the yaskawa amp.



Prior to starting the app:



(see attached: Before running app.txt)



On power up, the struct command shows the amps default PDO configuration.  In 
my case it shows:

0x6040 : control word

0x607a : target position

0x6041 : status word

0x6064 : actual position



The xml command reflects the same information.





After starting the app:



(see attached: After running app.txt)



After running the app the struct command now shows my selected PDO 
configuration.  The xml command also now reflects this information.





In "Before running app.txt" I also sent the ethercat slaves –v command (–v = 
verbose, gives more information about the slave(s)).  Under the COE details 
section you can see that both "Enable PDO Assign" and "Enable PDO 
Configuration" are yes.  This means you can choose to use a different PDO 
configuration from the default.





Re your question: I was getting you to run the struct command to see if there 
was any default configuration in there for your amp.  You can use this 
configuration (as per mine above) as a starting point for simple amp operation, 
setting some of the configuration parameters via SDO's.  I wanted more 
functionality than the default configuration so have changed my PDO 
configuration to suit.



Since you do not have any PDO's configured by default, it means you are either 
(1) running the command after the amp is being configured (and failing); or (2) 
the failed configuration has been saved to the EEPROM at some stage; or (3) it 
doesn't have any default PDO configuration.



If its case #2 then you can try resetting the amp back to its default 
parameters with the command (replacing –a12 with your appropriate slave alias 
or position information):

ethercat download –a12 0x1011 0x01 0x64616F6C



The 0x1011:01 parameter is "Restore all default parameters".  The 0x64616F6C 
value is a special value to ensure you don't call it by mistake.  This value 
actually represents the bytes for the ASCII characters "load" (where l is the 
LSB).  You will then need to repower the amp.





I have also attached the dmesg commands and output of what I would expect to 
happen as the app configures the amp.  It may help you pin down where it starts 
to deviate.



Also check that the amp can be configured and run in TwinCAT.  You can download 
a copy of TwinCAT and run in trial mode for a month or so (TwinCAT 2 might be 
easier than TwinCAT 3?).  If it does work then you might be able to see if 
there's any special configuration options required for you amp.



Beyond that, if you can confirm everything else in your app is working, you can 
contact Yaskawa support.  They won't help you with anything beyond that amp, 
but can be very helpful with setting up the amp.





Regards,

Graeme.







-Original Message-

From: Rahul Deshpande [mailto:rahulg...@gmail.com]

Sent: Saturday, 26 August 2017 9:04 a.m.

To: Graeme Foot <graeme.f...@touchcut.com>

Cc: etherlab-users <etherlab-users@etherlab.org>

Subject: Re: problem with ethercat xml



Hi Graeme,



I updated the eeprom from twincat. And it did not have any details in the xml 
apart from version and product code. Only after I ran the application which had 
the code to configure sync managers it populated the xmlwith those values.



I was a little confused when in previous mail you said that get the pdo config 
from ethercat struct and then put it in the application.

Can you please clarify on that ?.



Thank you,

Rahul





On 8/25/17, Rahul Deshpande <rahulg...@gmail.com> wrote:

> Hi Graeme,

>

> I was going through the ethercat commands. I came across 'ethercat

> struct' and 'ethercat xml'. When I used the 'ethercat xml' in pre-op

> and op mode I got the following xml (PFA).

>

> Before and after running the application(In which we have configured

> the pdos from the example you had sent), the 'ethercat struct' and

> 'ethercat xml' produce the same data which does not consist of PDO

> config settings.

>

> Is this a case of corrupt EEPROM or that we are unable to configure

> PDOs in our application ?

>

> Regards,

> Rahul

>
# ethercat struct -a12
/* Master 0, Slave 7
 * Vendor ID:   0x0539
 * Product code:0x0221
 * Revision number: 0x00030001
 */

ec_pdo_entry_info_t slave_7_pdo_entries[] = {
{0x6040, 0x00, 16}, /* Comm */
{0x607a, 0x00, 32}, /* Comm */
{0x6041, 0x00, 16}, /* Repl */
{0x6064, 0x00, 32}, /* Repl */
};

ec_pdo_info_t slave_7_pdos[] = {
{0x1601, 2, slave_7_pdo_entries + 0}, /* 2nd Receive PDO mappingersion */
{0x1a01, 2, slave_7_pdo_entries + 2}, /* 2nd Transmit PDO mapping??ion */
};

ec_sync_info_t slave_7_syncs[] = {
{0, EC_DIR

Re: [etherlab-users] No CoE communication

[Graeme Foot]

Hi,

I don't know for sure, but I suspect you are having issues with your network.  
I don't know Xenomi so can't comment on what might be wrong, but I don't think 
you should be getting any datagram timeouts on startup while the EtherCAT 
system is idle (i.e. before you start your app).

For comparison I have attached my startup log.

You could also try monitoring your EtherCAT network with wireshark to see what 
packets are going through.

Graeme.


-Original Message-
From: Rahul Deshpande [mailto:rahulg...@gmail.com] 
Sent: Thursday, 24 August 2017 5:26 a.m.
To: Graeme Foot <graeme.f...@touchcut.com>
Cc: etherlab-users@etherlab.org
Subject: Re: No CoE communication

Hi Graeme,

Thanks for the application. I tried implementing your master without the 
patches and with my application.

It does not reach the application stage and throws this error prior to login.
I get the following errors (PFA). It throws a reception of CoE dictionary 
request failed'

Regards,
Rahul



On 8/23/17, Graeme Foot <graeme.f...@touchcut.com> wrote:
> Hi,
>
> I have attached a test app to have a look at.  It is a (very) cut down 
> version of how my app works.  Of course I use RTAI, so it won't be 
> compatible with your Xenomi environment.
>
>
> In main.c at the top of runECat() I have a list of EtherCAT devices 
> and their addresses.  It is hard coded here but can of course be 
> loaded from a config file.  The device names match devices in the 
> etherCATSlaves.c file.
>
> etherCATMaster.c contains the code to configure and run the master.
> etherCATSlaves.c contains each slave's code.
>
> yaskawaSGDV_create()
> - configures the device and gets the PDO command offsets
>
> yaskawaSGDV_prepareToRun()
> - calculates each commands address (after the domains are populated 
> and
> allocated)
> - sets cyclic synchronous position mode (optional, the mode can be set 
> at any time while running)
> - sets the control word to zero, just in case
>
> yaskawaSGDV_run()
> - is called once each scan.  add code here to control the axis
>
> yaskawaSGDV_prepareToStop()
> - is called when the app is closing.  add any code here to clean up 
> your axis
>
>
> Note: In this app the prepareToStop() functions are called once and 
> then the app is shut down immediately.  In reality you should continue 
> your realtime cycle until all of the devices are stopped, disabled and safe 
> to turn off.
> The app also relies on some of my patches.
>
>
> I hope this helps
>
> Regards,
> Graeme.
>
>
>
> -Original Message-
> From: etherlab-users [mailto:etherlab-users-boun...@etherlab.org] On 
> Behalf Of Graeme Foot
> Sent: Wednesday, 16 August 2017 10:42 a.m.
> To: Rahul Deshpande <rahulg...@gmail.com>; etherlab-users@etherlab.org
> Subject: Re: [etherlab-users] No CoE communication
>
> Hi,
>
> I've been asked to let you know what master version and patches I'm using.
> I'm still running an old version (2526 from the stable-1.5 branch, 
> 12/02/2013).  The script I use to download it is attached 
> (004-etherlab_master).
>
> I use buildroot to create my linux system, so the script  tar's the 
> master folder and puts it in the buildroot downloads folder.  Note: I 
> also use a really old buildroot from 2012 with a few modifications, 
> but I have attached the mk file that it uses.
>
> The patches that I apply are also attached.
>
> The build options I use are:
> --with-linux-dir=""
> --enable-cycles
> --enable-rtdm
> --enable-e100
> --enable-e1000
> --enable-e1000e
> --enable-cx2100
>
>
> I use RTAI, but that shouldn't make any difference.
>
>
> Regards,
> Graeme.
>
>
> -Original Message-
> From: etherlab-users [mailto:etherlab-users-boun...@etherlab.org] On 
> Behalf Of Graeme Foot
> Sent: Tuesday, 15 August 2017 12:39 p.m.
> To: Rahul Deshpande <rahulg...@gmail.com>; etherlab-users@etherlab.org
> Subject: Re: [etherlab-users] No CoE communication
>
> Remember to reply-all to mail the forum as well.
>
> Line 85 has: #define Yaskawa_Sigma7  0x0539, 0x02200301 This is 
> different to my drive, so it may still be the Sigma 7 id causing a 
> mismatch, but it is the id being returned from the ethercat struct command.
>
> Other than that, I've got no idea.
>
> Graeme.
>
>
> -Original Message-
> From: Rahul Deshpande [mailto:rahulg...@gmail.com]
> Sent: Tuesday, 15 August 2017 3:57 a.m.
> To: Graeme Foot <graeme.f...@touchcut.com>
> Subject: No CoE communication
>
> Hi Graeme,
>
> I understand I have been mailing a lot, my questions may seem repetitive.
>
> The positive now is I was able to get to OP state by forcefully 
> setting 1c12 and 1c13 

Re: [etherlab-users] No CoE communication

[Graeme Foot]

Remember to reply-all to mail the forum as well.

Line 85 has: #define Yaskawa_Sigma7  0x0539, 0x02200301
This is different to my drive, so it may still be the Sigma 7 id causing a 
mismatch, but it is the id being returned from the ethercat struct command.

Other than that, I've got no idea.

Graeme.


-Original Message-
From: Rahul Deshpande [mailto:rahulg...@gmail.com] 
Sent: Tuesday, 15 August 2017 3:57 a.m.
To: Graeme Foot <graeme.f...@touchcut.com>
Subject: No CoE communication

Hi Graeme,

I understand I have been mailing a lot, my questions may seem repetitive.

The positive now is I was able to get to OP state by forcefully setting 1c12 
and 1c13 to 0 (PDO assignment fro SM2 and SM3).

I am still not able to configure the PDOs though. What I have narrowed down to 
is, somehow CoE communication just does not happen. I was going through the 
etherlab forum and came across a post where they mentioned some sdo's had to be 
set prior to configuring the PDOs. Is it that ?

Also, It would be great if I could just reach out to you on your phone if thats 
not an issue. Could sort out my problems faster and not disturb you with 
constant emails. Do let me know if thats an option.
Thank you so much.

Regards,
Rahul
--- Begin Message ---
Hi Graeme,

Sorry for the confusion, The sigma 5 was there with me only for a
month. They replaced it and gave me a sigma 7. So I had to change the
product code and vendor id.

I followed your instructions and upon running ethercat struct I got
the following values.


/* Master 0, Slave 0

 * Vendor ID:   0x0539

 * Product code:0x02200301

 * Revision number: 0x00080003

 */



ec_sync_info_t slave_0_syncs[] = {

{0, EC_DIR_OUTPUT, 0, NULL, EC_WD_DISABLE},

{1, EC_DIR_INPUT, 0, NULL, EC_WD_DISABLE},

{2, EC_DIR_OUTPUT, 0, NULL, EC_WD_ENABLE},

{3, EC_DIR_INPUT, 0, NULL, EC_WD_DISABLE},

{0xff}





I didnt get any other value with respect to pdos. I replaced these
values in the sync of my application. Still I get the same errors of
pdo not assigned properly. I have attached the dmesg logs.

Do we really need to configure PDOs to get the drive into OP state ?.
Or is it absolutely necessary and that just configuring the PDOs will
get me to OP state ?.

In the previous mail, I had sent the application. Just wanted to
confirm if I have defined the domains in the correct way.

Also is the domain like a pipe in IPC ?. Does it just help in
establishing a link and then the PDOs are transferred between master
and slave ?

Thank you,
Rahul

On 8/10/17, Graeme Foot <graeme.f...@touchcut.com> wrote:
> You don't need any patches to get running.
>
> The patches I use are a CX2100 driver, some RTAI fixes (your using Xenomi),
> some patches to increase the performance of the SDO's and some distributed
> clock fixes.
> It's only the distributed clock fixes which you will need at some stage,
> best to get them from Gavin's patchset as he keeps them up to date with the
> latest release.  Mine are a few years old now.
>
> Looking at your log it looks like it is completely failing to configure the
> PDO's.  You also have a different drive to mine (Yours: 0x0539,
> 0x02200301;  mine: 0x0539, 0x0221) so the PDO configuration may not
> be the same.  To get the PDO's for your drive, repower your system
> (including the drive) to reset it, then use the "ethercat struct" command.
> This will output the default PDO's required by the drive.
>
>
> What is the results for the following commands:
>
> ethercat struct   (after repowering the system, before running your app)
>
> ethercat debug 1
> 
> dmesg
>
>
>
> Regards,
> Graeme.
>
>
>
> -Original Message-
> From: Rahul Deshpande [mailto:rahulg...@gmail.com]
> Sent: Friday, 11 August 2017 3:20 a.m.
> To: Graeme Foot <graeme.f...@touchcut.com>
> Subject: Re: Yaskawa sigma 5 application
>
> Hi Graeme,
>
> Ignore the previous main.c. The one attached in this mail is what I am using
> to communicate with the drive.
>
> On 8/10/17, Rahul Deshpande <rahulg...@gmail.com> wrote:
>> Hi Graeme,
>>
>> I noticed you mentioned that I could be needing patches in order to
>> get yaskawa work with the master. Do we need all the patches on your
>> name or just a selective few ?.
>>
>> At this point I am trying to get to OP state but even after changing
>> the application I cannot surpass it. I have attached the new
>> application that I wrote and also the logs. These logs are obtained
>> after running the 'ethercat debug 1' command before running the
>> application. It is throwing an error for each domain that I have
>> defined.
>>
>> Looking forward to your reply.
>>
>> Thank you,
>> R

Re: [etherlab-users] Yaskawa sigma 5 application

[Graeme Foot]

You don't need any patches to get running.  

The patches I use are a CX2100 driver, some RTAI fixes (your using Xenomi), 
some patches to increase the performance of the SDO's and some distributed 
clock fixes.
It's only the distributed clock fixes which you will need at some stage, best 
to get them from Gavin's patchset as he keeps them up to date with the latest 
release.  Mine are a few years old now.

Looking at your log it looks like it is completely failing to configure the 
PDO's.  You also have a different drive to mine (Yours: 0x0539, 0x02200301; 
 mine: 0x0539, 0x0221) so the PDO configuration may not be the same.  
To get the PDO's for your drive, repower your system (including the drive) to 
reset it, then use the "ethercat struct" command.  This will output the default 
PDO's required by the drive.


What is the results for the following commands:

ethercat struct (after repowering the system, before running your app)

ethercat debug 1

dmesg



Regards,
Graeme.



-Original Message-
From: Rahul Deshpande [mailto:rahulg...@gmail.com] 
Sent: Friday, 11 August 2017 3:20 a.m.
To: Graeme Foot <graeme.f...@touchcut.com>
Subject: Re: Yaskawa sigma 5 application

Hi Graeme,

Ignore the previous main.c. The one attached in this mail is what I am using to 
communicate with the drive.

On 8/10/17, Rahul Deshpande <rahulg...@gmail.com> wrote:
> Hi Graeme,
>
> I noticed you mentioned that I could be needing patches in order to 
> get yaskawa work with the master. Do we need all the patches on your 
> name or just a selective few ?.
>
> At this point I am trying to get to OP state but even after changing 
> the application I cannot surpass it. I have attached the new 
> application that I wrote and also the logs. These logs are obtained 
> after running the 'ethercat debug 1' command before running the 
> application. It is throwing an error for each domain that I have 
> defined.
>
> Looking forward to your reply.
>
> Thank you,
> Rahul
>
___
etherlab-users mailing list
etherlab-users@etherlab.org
http://lists.etherlab.org/mailman/listinfo/etherlab-users

Re: [etherlab-users] Yaskawa sigma 5 application

[Graeme Foot]

> -Original Message-
> From: Rahul Deshpande [mailto:rahulg...@gmail.com] 
> Sent: Friday, 4 August 2017 4:17 a.m.
> To: Graeme Foot <graeme.f...@touchcut.com>
> Subject: Yaskawa sigma 5 application
> 
> Hi Graeme,
> 
> Building up on the previous mail. I made a few changes to my application. 
> I am still an amateur at this and have just been introduced to motion 
> control last month. I have modified the example/xenomai/main.c file to 
> suit my needs. I have attached the file. I am setting the PDOs as you had 
> mentioned. I read on some of the etherlab group archive mails that I need 
> to set the sdo's as well.
> 
> My understanding is that the SDO's consist of the data that needs to be 
> processed and the PDO's are just a way to communicate this data from slave 
> to master and vice versa. Is there any specific way to configure these ?. 
> I just intend to write a simple application.
> 
> Thank you,
> Rahul
>


Hi,

Note: Remember to always post to the etherlab forum.


1) From you attached file it looks like you have a sigma 7 rather than sigma 5 
amp.  I haven't got my hands on one yet (in the pipeline) but should be similar 
to the sigma 5.  To make sure you have the correct PDO structures use the 
"ethercat struct" command.  It will output the currently configured (or default 
if not changed) structures to work with the device.  (The items below are for 
sigma 5, but should be similar.)


2) PDO's vs SDO's:
- PDO's are the workhorse of EtherCAT.  The PDO data is communicated every 
cycle.  PDO's are realtime.  
- SDO's are generally just used to set up initial configuration parameters.  
They can be used to read/write non-PDO parameters while running, but they are 
not realtime and take multiple cycles to be sent and be returned.  They should 
also only be used for values that do not change often. 


3) You don't need to call these:
ecrt_slave_config_sdo8( sc_dig_out_01, 0x1C12, 0, 0 ); /* clear sm pdo 0x1c12 */
ecrt_slave_config_sdo16( sc_dig_out_01, 0x1C12, 1, 0x1601 ); /* download pdo 
1C12 index */
ecrt_slave_config_sdo16( sc_dig_out_01, 0x1C12, 2, 0x1602 ); /* download pdo 
1C12 index */
ecrt_slave_config_sdo16( sc_dig_out_01, 0x1C12, 3, 0x1606 ); /* download pdo 
1C12 index */
ecrt_slave_config_sdo8( sc_dig_out_01, 0x1C12, 0, 3 ); /* set number of RxPDO */
ecrt_slave_config_sdo8( sc_dig_out_01, 0x1C13, 0, 0 ); /* clear sm pdo 0x1c12 */
ecrt_slave_config_sdo16( sc_dig_out_01, 0x1C13, 1, 0x1A01 ); /* download pdo 
1C13 index */
ecrt_slave_config_sdo16( sc_dig_out_01, 0x1C13, 2, 0x1A03 ); /* download pdo 
1C13 index */
ecrt_slave_config_sdo16( sc_dig_out_01, 0x1C13, 3, 0x1A06 ); /* download pdo 
1C13 index */
ecrt_slave_config_sdo8( sc_dig_out_01, 0x1C13, 0, 3 ); /* set number of TxPDO */

That’s what ecrt_slave_config_pdos() does.


4) There are some settings that you need to set and flash before running the 
drive (and repower the drive after flashing them).
- If it's an absolute motor that you will be running in incremental mode, you 
need to (0x2002.1 = 1)
- If you do not have limit switches you will need to disable them (in 0x250a.3 
and 0x250b.0)
- If you have external regen resistors, you need to set 0x2600
- possibly some others I forget


5) You are blinking the first 8 bits of 0x6040.  That won't be doing much of 
anything that you can see.
- First thing is, is the slave in Operational mode when you go to realtime?
- Second, to enable the drive you need to go through a state machine of setting 
control bits and confirming each state with status bits

set: Control.EnableVoltage & Control.QuickStop
wait until: Status.ReadyToSwitchOn
set: Control.SwitchOn
wait until: Status.SwitchedOn
set: Control.EnableOperation
wait until: Status.OperationEnabled

You will need to set 0x6060:00 (Mode of operation) to the mode you want to run 
with (e.g. 8=cyclic position)

You should now be good to send target position values (0x607a:00).  I you don't 
have a position generator they you could try velocity mode (Mode of operation 
9) and ramp up and down the value (for acceleration / deceleration).


Regards,
Graeme.





/**
 *
 *  $Id: main.c,v 3bdd7a747fae 2012/09/20 13:28:25 fp $
 *
 *  Copyright (C) 2009-2010  Moehwald GmbH B. Benner
 * 2011  IgH Andreas Stewering-Bone
 * 2012  Florian Pose <f...@igh-essen.com>
 *
 *  This file is part of the IgH EtherCAT master
 *
 *  The IgH EtherCAT Master is free software; you can redistribute it and/or
 *  modify it under the terms of the GNU General Public License version 2, as
 *  published by the Free Software Foundation.
 *
 *  The IgH EtherCAT master is distributed in the hope that it will be useful,
 *  but WITHOUT ANY WARRANTY; without even the implied warranty of
 *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU

Re: [etherlab-users] experience with CU1128 | EtherCAT junction

[Graeme Foot]

Never used them, but just had a quick look at the doco (just cos I was curious).

- It mentions the ability to Hot Connect any of the ports, but there's no 
configuration behind this, just the usual hardware support.
- It is detected as three ESC's (as that's what it has internally), each one 
being identified by a different RevisionNumber (but same product code)
- Primary ESC 1:  ProductCode="#x04685432" 
RevisionNo="#x0001"
- Sub ESC 2:  ProductCode="#x04685432" RevisionNo="#x00010001"
- Sub ESC 3:  ProductCode="#x04685432" RevisionNo="#x00010002"
- It can be used as a distributed clock reference clock
- There's no PDO or CoE data / configuration

So I would expect you just need to set up three slaves as above, then the 
master can report on the status of their ports (via reg information).

One thing to note is that TwinCat knows that the sub ESC's are sub devices but 
I don't think the EtherLab master supports this, so you may need to place Sub 
ESC 2 and Sub ESC 3 further down your list of slaves.  (i.e. Sub ESC 2 after 
the devices connected to port 3, and Sub ESC 3 after the devices connected to 
port 5.)  See page 12 for a diagram on how the ports relates to the the three 
ESC's.


Regards,
Graeme.
 

-Original Message-
From: etherlab-users [mailto:etherlab-users-boun...@etherlab.org] On Behalf Of 
Matthieu Bec
Sent: Wednesday, 19 April 2017 6:55 a.m.
To: etherlab-users@etherlab.org
Subject: [etherlab-users] experience with CU1128 | EtherCAT junction

Hi,

Has anyone had experience using a "CU1128 | EtherCAT junction" from Beckhoff 
(*) with the etherlab master?

It seemingly looks like a dumb device, but the documentation hints at 
particular steps to set it up with TwinCAT:

```
Topological configuration
With the CU1128, special attention should be paid to the sequence of the 
EtherCAT slaves. Since the CU1128 has 7 junction ports, drop lines connected to 
ports must and can be clearly identified in practice. If incorrect information 
is provided in the configuration (TwinCAT System Manager file *.tsm), the 
system cannot start.
```

Regards,
Matthieu

(*) 
https://download.beckhoff.com/download/document/io/infrastructure-components/cu1128en.pdf




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

Re: [etherlab-users] Beckhoff EL7031

[Graeme Foot]

Hi,

We don't use Simulink, so unfortunately I won't be much help there.  As I said 
below, on the EL7031 you need to "Every cycle, set the motors TargetPosition 
(7010:11), even if its stationary."  Here is a link to a post which talks about 
creating a motion profile for a simple move (and a bunch of other things).
http://lists.etherlab.org/pipermail/etherlab-users/2016/002906.html

That is of course a very simple example and doesn't even consider acceleration. 
 You can dynamically calculate simple motion profiles based on the kinematic 
equations (i.e. 
http://www.physicsclassroom.com/class/1DKin/Lesson-6/Kinematic-Equations).  But 
you will also most likely want to apply smoothing to the motion profiles and 
coordinate multiple axes together.

With some quick googling (simulink motion profile) here are some links that may 
help get started for Simulink, though most of what I've found seems to only 
deal with point to point moves:
https://au.mathworks.com/matlabcentral/fileexchange/16352-advanced-setpoints-for-motion-systems?requestedDomain=www.mathworks.com
http://www.dct.tue.nl/New/Lambrechts/Advanced_Setpoints.pdf
http://mme.uwaterloo.ca/~mte360/files/Matlab%20Simulink%20Tutorial.pdf


Regards,
Grame.



-Original Message-
From: Ewan Houston [mailto:e.housto...@research.gla.ac.uk] 
Sent: Tuesday, 18 April 2017 2:08 a.m.
To: Graeme Foot <graeme.f...@touchcut.com>
Cc: etherlab-users@etherlab.org
Subject: Re: Beckhoff EL7031

Hi Graeme,

I am currently building a Simulink model to operate the hardware.

>From your previous description of how to control the EL7031 I see that I have 
>to program my PDOs and SDOs into my m file for the EL7031. I think that is 
>mostly fine. How do I calculate and implement the motion profile from there? I 
>know how to add PDOs and SDOs to the m file but am lost after that. 

Cheers,

Ally.


On 10 Oct 2016, at 23:31, Graeme Foot <graeme.f...@touchcut.com> wrote:

> Hi,
> 
> Sure.  Have also cc'ed the forum in case anyone has anything else to add.
> 
> 
> Some general notes:
> - We only use EL7041's in production so have done limited testing on EL7031's 
> but they are very similar.
> 
> - Make sure you've got the latest firmware on the module.  Some of the 
> earlier firmwares motion was a little rough.
> 
> - I use the steppers in position controller mode (8012:01 = 3).  In this mode 
> you need to set the target position of the motor every cycle.  It is up to 
> you to calculate your own position / velocity profile.  Steppers don't like 
> sudden movement so you need to ramp up and down the velocity by an 
> acceleration, and you might also want to apply some jerk smoothing.
> 
> - I don't use the modules in Distributed Clock mode.  Never been able to make 
> it work and never had time to figure out why.  Not too much of a problem for 
> my situation.  If you find out how to use it successfully then let us know.
> 
> - Values that I read from a config file and set per module are:
>  Max Current   (8010:01) -> set to suit motor
>  Reduced Current   (8010:02) -> generally I set this to 1/2 of max current
>  Nominal Voltage   (8010:03) -> this module only allows 24V
>  Motor Coil Resistance (8010:04) -> set to suit motor
>  Motor Full Steps  (8010:06) -> ours are 200
>  Max Speed Range   (8012:05) -> generally set to 3 (2400 RPM for a 200 
> step / rev motor)
>  Reversed  (8012:09) -> if the motor goes the wrong direction set 
> this value
> I set these values before activating the master switching my app to realtime.
> 
> 
> I'm using the following pdo setup:
> 
> ec_pdo_entry_info_t EL7031_pdoEntries[] = {
>// 0x1602, stepper control (0)
>{0x7010, 0x01, 1},// Enable
>{0x7010, 0x02, 1},// Reset 
>{0x7010, 0x03, 1},// Reduce torque 
>{0x, 0x00, 5},//   spacer 
>{0x, 0x00, 8},//   spacer 
> 
>// 0x1603, stepper pos (5)
>{0x7010, 0x11, 32},   // Target position
> 
> 
>// 0x1a03, stepper status (6)
>{0x6010, 0x01, 1},// Ready to enable 
>{0x6010, 0x02, 1},// Ready 
>{0x6010, 0x03, 1},// Warning 
>{0x6010, 0x04, 1},// Error 
>{0x6010, 0x05, 1},// Moving positive 
>{0x6010, 0x06, 1},// Moving negative 
>{0x6010, 0x07, 1},// Torque reduced 
>{0x, 0x00, 1},//   spacer 
>{0x, 0x00, 3},//   spacer
>{0x6010, 0x0c, 1},// Digital input 1 
>{0x6010, 0x0d, 1},// Digital input 2 
>{0x1c32, 0x20, 1},// Sync error 
>{0x, 0x00, 1},//   spacer 
>{0x1803, 0x09, 1},// *** unknown ***
> 
> };
> 
> ec_pdo_info_t EL7031_pdos[] = {
>{0x1602, 5, EL7031_pdoEntries + 0},
>{0x1603, 1, EL7031_

Re: [etherlab-users] Patch for Distributed Clock?

[Graeme Foot]

Hi,


Thats one of the older forum postings and is code for an older version of the 
master (revision 2266).  The changeset I sent is for master revision 2526 
(still old but I haven't needed to move on yet).


Have a look at this one:

http://lists.etherlab.org/pipermail/etherlab-users/2016/003026.html


Note: there is a bug in the ecMod_syncDistClock() funciton from that post. It 
should probably instead be (changed line in bold):


int32_t ecMod_syncDistClock(
void *this/**< pointer to module etherCATModule_s */
)
{
  etherCATModule_s *ecMod = this;
  uint32_t  masterTime;

  // cache lower 32 bits of prev master time and get now
  masterTime  = (uint32_t)ecMod->m_dcTime;
  ecMod->m_dcTime = app_getTimeNS();


  // use the dc ref slave to adjust the masters time base

  // get lower 32 bit of clock time from reference slave (after first scan)
  if (ecMod->m_getDCDiff)
  {
int  res;
uint32_t slaveTime;
res = ecrt_master_reference_clock_time(ecMod->master, );

switch (res)
{
  case 0 :
  {
// calc time diff
ecMod->m_dcDiff = masterTime - slaveTime;
  } break;

  default :
  {
// no ref clock found or datagram failure
ecMod->m_dcDiff = 0;
  }
}
  }
  else
  {
ecMod->m_dcDiff= 0;
ecMod->m_getDCDiff = true;
  }

  // call to sync slaves to ref slave
  // (which is used for ecrt_master_reference_clock_time)
  ecrt_master_sync_slave_clocks(ecMod->master);

  // set master time in nano-seconds
  ecrt_master_application_time(ecMod->master, ecMod->m_dcTime);


  return 0;
}




Graeme.





From: Jiarui Lian <je...@bertec.com>
Sent: Friday, 13 January 2017 04:57
To: Graeme Foot
Subject: not found Re: Patch for Distributed Clock?

Hi, Graeme:

I couldn't found the following functions in your patch:
(as you mentioned in: 
http://lists.etherlab.org/pipermail/etherlab-users/2012/001642.html)
1) ecrt_master_setup_distributed_clock()
2) ecrt_master_sync_slave_clocks_diff()
3) I have changed the ref_sync_datagram to 4 bytes instead of 8.

Did you send the wrong patch, or you change the function names?
Thanks!

Jerry

____
From: "Graeme Foot" <graeme.f...@touchcut.com>
To: "Jiarui Lian" <je...@bertec.com>
Cc: "etherlab-users" <etherlab-users@etherlab.org>
Sent: Wednesday, January 11, 2017 5:05:53 PM
Subject: Re: Patch for Distributed Clock?


Hi,


I've attached an hg changeset of the patches I use.  You can get the DC related 
ones from it.  If you look in the etherlab-dev forum you will also find Gavin's 
patchsets which will be more up to date.


Do a search for "etherlab-users dc" (or similar) to find posts related to how 
to set up distributed clocks.  eg:

http://lists.etherlab.org/pipermail/etherlab-users/2016/003014.html


But to answer you question:


A system requires one master clock that all other clocks in the system sync to. 
 That clock can either be the clock in the EtherCAT master or it can be a clock 
on one of the slaves (the dc reference slave).  Separate to that, all dc slaves 
on the bus need to be synced to a reference slave clock.  This should be the 
first slave on the bus that supports dc.  The EtherLAB master will 
automatically select this for you, or with the patch you can select it yourself.

Generally the EtherCAT master clock has too much jitter to provide a nice 
stable system, so instead I use option two where my dc reference slave is the 
master clock and I adjust the EtherCAT master clock to it (this is the default 
option used by TwinCAT).

Also note (as described in the post I linked to above), there are two levels of 
dc support in slaves.  DC clock level support (alot of simple IO slaves have 
this) and the ability to sync the IO to the dc clock (generally only more 
advanced slaves support this).  The DC reference slave only requires the DC 
clock level of support.

In your case, if your AX5206 slave is the first slave it can be both the 
reference slave and the DC clock master.

Regards,
Graeme.

PS: Our system uses various IO modules and amps.  Our dc reference slave is 
often our first IO module (an EL1008).


____
From: Jiarui Lian <je...@bertec.com>
Sent: Thursday, 12 January 2017 06:39
To: Graeme Foot
Subject: Patch for Distributed Clock?

Hi, Dear Mr. Graeme Foot:

I am studying IgH-EtherCAT-Master to control AX5206, and I saw your post in 
2012:
http://lists.etherlab.org/pipermail/etherlab-users/2012/001642.html

* Would you mind to send a copy of the patch to me?
* And a question, when you said: "pick a ref slave and update my master time 
based on the ref slave time."
  Does your system consist of at least two slaves with DC capability?
 Master(Jitter)  Slave.1 (DC, Ref-to-Master)  Slave.2(DC, 
Ref-to-Slaves) 

Re: [etherlab-users] Patch for Distributed Clock?

[Graeme Foot]

Hi,


I've attached an hg changeset of the patches I use.  You can get the DC related 
ones from it.  If you look in the etherlab-dev forum you will also find Gavin's 
patchsets which will be more up to date.


Do a search for "etherlab-users dc" (or similar) to find posts related to how 
to set up distributed clocks.  eg:

http://lists.etherlab.org/pipermail/etherlab-users/2016/003014.html


But to answer you question:


A system requires one master clock that all other clocks in the system sync to. 
 That clock can either be the clock in the EtherCAT master or it can be a clock 
on one of the slaves (the dc reference slave).  Separate to that, all dc slaves 
on the bus need to be synced to a reference slave clock.  This should be the 
first slave on the bus that supports dc.  The EtherLAB master will 
automatically select this for you, or with the patch you can select it yourself.

Generally the EtherCAT master clock has too much jitter to provide a nice 
stable system, so instead I use option two where my dc reference slave is the 
master clock and I adjust the EtherCAT master clock to it (this is the default 
option used by TwinCAT).

Also note (as described in the post I linked to above), there are two levels of 
dc support in slaves.  DC clock level support (alot of simple IO slaves have 
this) and the ability to sync the IO to the dc clock (generally only more 
advanced slaves support this).  The DC reference slave only requires the DC 
clock level of support.

In your case, if your AX5206 slave is the first slave it can be both the 
reference slave and the DC clock master.

Regards,
Graeme.

PS: Our system uses various IO modules and amps.  Our dc reference slave is 
often our first IO module (an EL1008).



From: Jiarui Lian <je...@bertec.com>
Sent: Thursday, 12 January 2017 06:39
To: Graeme Foot
Subject: Patch for Distributed Clock?

Hi, Dear Mr. Graeme Foot:

I am studying IgH-EtherCAT-Master to control AX5206, and I saw your post in 
2012:
http://lists.etherlab.org/pipermail/etherlab-users/2012/001642.html

* Would you mind to send a copy of the patch to me?
* And a question, when you said: "pick a ref slave and update my master time 
based on the ref slave time."
  Does your system consist of at least two slaves with DC capability?
 Master(Jitter)  Slave.1 (DC, Ref-to-Master)  Slave.2(DC, 
Ref-to-Slaves)  MoreSlaves
  In my case, I have only one slave with DC:
 Master(Jitter)  Slave.1(AX5206, DC) --- MoreSlaves
  Any suggestion to me?


Thanks, your help is appreciated!

Sincerely,
Jerry
Bertec Corp.


etherlabmaster-1.5.2-changesets.hg
Description: etherlabmaster-1.5.2-changesets.hg
___
etherlab-users mailing list
etherlab-users@etherlab.org
http://lists.etherlab.org/mailman/listinfo/etherlab-users

Re: [etherlab-users] el7031 stepper drivers - input registers always zero in PDO, ok in SDO

[Graeme Foot]

Have a look for any errors in your dmesg log.

Also, what do your pdoEntries, pdos, syncs structures look like?  Whats your 
firmware revision?  There are a couple of firmware revisions with different 
parameter requirements.


Being a stepper without an encoder, why do you need an actual position?  Set 
the target position and assume that 5ms later it will be there.


Regards,
Graeme.



-Original Message-
From: etherlab-users [mailto:etherlab-users-boun...@etherlab.org] On Behalf Of 
Michal Rawlik
Sent: Wednesday, 14 December 2016 9:28 p.m.
To: etherlab-users@etherlab.org
Subject: [etherlab-users] el7031 stepper drivers - input registers always zero 
in PDO, ok in SDO

Hi,

I am having a peculiar issue with the el7031 stepper motor drivers.

I use them with the predefined PDO assignment "Positioning interface with info 
data":
SM2 (output): 0x1601 0x1602 0x1606
SM3 (input): 0x1A01 0x1A03 0x1A06

I have no problem with the output PDO entries and can operate motors. However, 
when I read the input registers I always get 0 (in particular I care about 
(0x6020 0x01 1 "busy") and (0x6020 0x11 32 "actual position"). At the same time 
I can get the correct values of those registers via SDO.

I do not use distributed clocks, have a cycle time of 5ms, run the program in 
userspace with the ethercat service, on openSUSE Leap 42.2, with generic 
ethernet driver.

I had a look in TwinCAT3 and there it is the same - okay in SDO, always zeros 
in PDO.

Sincerely,
Michał
___
etherlab-users mailing list
etherlab-users@etherlab.org
http://lists.etherlab.org/mailman/listinfo/etherlab-users
___
etherlab-users mailing list
etherlab-users@etherlab.org
http://lists.etherlab.org/mailman/listinfo/etherlab-users

Re: [etherlab-users] DC questions

[Graeme Foot]

e period takes longer) then the time base
* value should be increased each period
*/
void app_setTimeBase(
int64_t in_timeBase
)
{
  u_appTimeBase = in_timeBase;
}

/** add to the app time base value
*
 * if the app clock is slower (ie the period takes longer) then the time base
* value should be increased each period
*/
void app_addTimeBase(
int64_t in_timeBase
)
{
  u_appTimeBase += in_timeBase;
}



Regards,
Graeme.


From: Tommaso [mailto:furiosi.tomm...@gmail.com]
Sent: Monday, 20 June 2016 8:21 p.m.
To: Graeme Foot; gav...@compacsort.com; etherlab-users@etherlab.org
Subject: R: [etherlab-users] DC questions

Thank you both for your answers.

I would like to get again your help in order to find a little example, focused 
only on the synchronization part, for the b method introduced by Graeme, 
because I have already tried something but the application continuosly sends 
the "Failed to get reference clock time: Input/Output error" error.

Thank you again.

Best regards,

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

Re: [etherlab-users] DC questions

[Graeme Foot]

Hi,

1) Distributed clocks can work in a couple of ways, but all ways require a 
slave DC master which should be the first DC slave in the network.  Note: some 
slaves can act as a DC time master even though they are not fully DC capable:

a) EtherCAT master is the master clock:
  - The computer is used as the DC master for the entire system.  
ecrt_master_application_time() must be called every cycle to tell the 
EtherLab master what the current PC time is.
  - Call ecrt_master_sync_reference_clock() to tell the slave DC master to sync 
to the EtherLab masters time.
  - Call ecrt_master_sync_slave_clocks() to tell all other DC slaves to sync to 
the slave DC master

b) Slave DC master is the master clock. What I do is:
  - Get the slave DC masters time using ecrt_master_reference_clock_time() and 
sync the EtherLab masters cycle and time to it
  - Call ecrt_master_sync_slave_clocks() to tell all other DC slaves to sync to 
the slave DC master
  - Call ecrt_master_application_time() with the next cycles master time

Note: With option b you need to adjust your masters PC's time by the drift time 
from the slave DC master time and adjust your realtime cycle to suit.  I do 
this by having a wrapper around the time calls to rt_get_time() and use 
rt_sleep_until() (I use RTAI) rather than using a fixed periodic cycle.

Option b is the best, because option a has way too much jitter and the slaves 
find it very hard to synchronise.  Note: option b is the default option used 
via TwinCAT.


2) Yes, call ecrt_master_sync_slave_clocks() every cycle (and 
ecrt_master_application_time() and ecrt_master_reference_clock_time()).  Just 
before the ecrt_master_send() call to reduce jitter.


3) No, only call ecrt_slave_config_dc() on slaves that support DC and are going 
to be used with DC.


Regards,
Graeme.


-Original Message-
From: etherlab-users [mailto:etherlab-users-boun...@etherlab.org] On Behalf Of 
Tommaso
Sent: Friday, 10 June 2016 7:14 p.m.
To: etherlab-users@etherlab.org
Subject: [etherlab-users] DC questions

Good morning,

In the master documentation is reported, in DC section, that the reference 
clock is the one of the first slave that supports this functionality. This 
reference can be synchronized with the master clock.
My questions, based on the 'dc_user' example, are the following:
1 - calling cyclically the function 'ecrt_master_sync_reference_clock()' 
I have that the reference clock is the one of the master? Only for this case is 
useful to call the function 'ecrt_master_application_time()' or I have to call 
it every time I want to use the DC?
2 - the function 'ecrt_master_sync_slave_clocks()' is used for the 
synchronization of all the slave clocks for every reference clock? If I want to 
exploit the DC functionality I have always to call it cyclically?
3 - it makes sense to call 'ecrt_slave_config_dc()' even for slaves which do 
not support the DC functionality, like the EL2004?

Thank you for your help.

Best regards,

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

Re: [etherlab-users] [etherlab-dev] DC synchronous question

[Graeme Foot]

Hi,

This question is more for the etherlab-users forum 
(etherlab-users@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 Distributed Clocks.

1) Configure each DC slave to use its Distributed Clock using 
ecrt_slave_config_dc()
2) Select an appropriate slave as a slave reference clock using 
ecrt_master_select_reference_clock()
3) Set an initial master clock time just before going realtime using 
ecrt_master_application_time()
4) Once looping in realtime you need to ensure all clocks are synchronized 
using:
  ecrt_master_reference_clock_time()
  ecrt_master_sync_slave_clocks()
  ecrt_master_application_time()

It is best to match the EtherLab masters PC time to the reference slave as this 
produces the most stable environment.  Have a look at some of the Distributed 
Clock demos.  You may also want some of the Distributed Clock patches.  Have a 
search through the old forum posts, there's been a fair few discussions about 
distributed clocks.


Regards,
Graeme.


From: etherlab-dev [mailto:etherlab-dev-boun...@etherlab.org] On Behalf Of 
COOKIY
Sent: Tuesday, 24 May 2016 3:19 p.m.
To: etherlab-dev
Subject: [etherlab-dev] DC synchronous question

Hello everyone:
First, thanks for browsing.Now, we use open-source EtherCAT master to 
control my robot which is a 6 DOF arms.Everything is ok except the DC 
synchronous question, while the DC is essential to run in cycle synchronization 
position mode and I also really don't know the real reason about this and how 
to handle that question.
Then,I will depict my question in detials. When run in profile position 
mode, everything is ok and when it changes to cycle synchronization position 
mode, I found that it can't to synchronize DC with the errors listing in below:
[ 1518.043620] EtherCAT ERROR 0-2: AL status message 0x0032: "PLL error".
 [ 1518.043735] EtherCAT 0-2: Acknowledged state SAFEOP.
 [ 1518.055581] EtherCAT ERROR 0-3: AL status message 0x0032: "PLL error".
 [ 1518.055752] EtherCAT 0-3: Acknowledged state SAFEOP.
 [ 1518.059595] EtherCAT ERROR 0-4: AL status message 0x0032: "PLL error" .
 [ 1518.067537] EtherCAT 0-4: Acknowledged state SAFEOP.
 [ 1518.071643] EtherCAT ERROR 0-5: AL status message 0x0032: "PLL error".
 [ 1518.071862] EtherCAT 0-5: Acknowledged state SAFEOP.
 When this errors occurs, the servo drivers change the states from OP state 
to SAFEOP state. I also ask for this question to beckhoff's staff. He said the 
reason of this question is caused by the CPU jitter and the master of beckhoff 
corporation could handle this question very well. I really don't understand 
this meaning very well.
 It is very grateful that if some experts know the ways to handle with this 
question.Thanks very much!
___
etherlab-users mailing list
etherlab-users@etherlab.org
http://lists.etherlab.org/mailman/listinfo/etherlab-users

Re: [etherlab-users] CX CPU as Master Linux Slave

[Graeme Foot]

If the cstruct info below looks like what you expect then it is possibly a 
problem with the setup (ie the calls to ecrt_master_slave_config(), 
ecrt_slave_config_pdos() etc aren’t matching correctly).  It might also be that 
it requires some extra sdo settings on top of the standard ones.

When the ERROR state is set it should also set the reason in the Alarm Status 
Code register (register 0x134).  use the command:
ethercat reg_read -p0 -tuint16 0x134

Then refer to the following page to figure out what the code means:
http://infosys.beckhoff.com/english.php?content=../content/1033/em37xx/1037010571.html=10272
or 
http://infosys.beckhoff.com/english.php?content=../content/1033/el6201/html/bt_ec_ethercat_al_statuscodes.htm



If you have another computer with windows you could install TwinCAT on it and 
see what TwinCAT’s configuration is to connect to it.


Regards,
Graeme.


From: David Jiménez Mejías [mailto:david.jime...@gtc.iac.es]
Sent: Thursday, 19 May 2016 1:20 a.m.
To: Graeme Foot; etherlab-users@etherlab.org
Subject: RE: [etherlab-users] CX CPU as Master Linux Slave

Hi,

I'm not using a CX PC as Master, it is a x64 Real Time PC with Priest 
Distro. It has a ESD NEt-Card compatible with EtherCAT.

I just configured the data PDOs that I would like to expose vía the EtherCAT 
Slave port of the CX8010.

The cstruct works ok its reply is:

/* Master 0, Slave 0, "CX8010 EtherCAT slave"
 * Vendor ID:   0x0002
 * Product code:0x1f4a6032
 * Revision number: 0x0011
 */
ec_pdo_entry_info_t slave_0_pdo_entries[] = {
{0x7000, 0x01, 1}, /* Relay 1 signal*/
{0x, 0x00, 7}, /* Gap */
{0x7000, 0x02, 1}, /* Relay 2 Signal*/
{0x, 0x00, 7}, /* Gap */
{0x6000, 0x01, 16},/*Temp1*/
{0x6000, 0x02, 16}, /*Temp2*/
};
ec_pdo_info_t slave_0_pdos[] = {
{0x1600, 4, slave_0_pdo_entries + 0}, /* Output Mapping */
{0x1a00, 2, slave_0_pdo_entries + 4}, /* Input Mapping */
};
ec_sync_info_t slave_0_syncs[] = {
{0, EC_DIR_OUTPUT, 0, NULL, EC_WD_DISABLE},
{1, EC_DIR_INPUT, 0, NULL, EC_WD_DISABLE},
{2, EC_DIR_OUTPUT, 1, slave_0_pdos + 0, EC_WD_ENABLE},
{3, EC_DIR_INPUT, 1, slave_0_pdos + 1, EC_WD_DISABLE},
{0xff}
};

and the slave reply:

0  0:0  PREOP  E  CX8010 EtherCAT slave

I don`t know if this show you something more 

Thank you very much

Best regards

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
David Jiménez Mejías




-Original Message-----
From: Graeme Foot <graeme.f...@touchcut.com<mailto:graeme.f...@touchcut.com>>
To: David Jiménez Mejías 
<david.jime...@gtc.iac.es<mailto:david.jime...@gtc.iac.es>>, 
"etherlab-users@etherlab.org<mailto:etherlab-users@etherlab.org>" 
<etherlab-users@etherlab.org<mailto:etherlab-users@etherlab.org>>
Date: Sun, 15 May 2016 22:19:19 +
Subject: RE: [etherlab-users] CX CPU as Master Linux Slave

Hi,

What type of computer are you using as the Linux master?  If it is a Beckhoff 
CX computer via the EBus module it will need the CCAT (or similar) network 
card driver.  However, it sounds like your Linux master is not a CX 
computer and you already have the EtherCAT networking running.

I have not used the CX8010 so can’t offer too much advice but from what I 
understand it ring fences all of the IO on its EBus with its own logic to 
control it.  You then have to choose what IO (or interface) you want to expose 
via its slave interface that the Linux EtherCAT master will access.

What does the ethercat cstruct command return?


Regards,
Graeme.

From: David Jiménez Mejías [mailto:david.jime...@gtc.iac.es]
Sent: Friday, 13 May 2016 11:12 p.m.
To: Graeme Foot; etherlab-users@etherlab.org<mailto:etherlab-users@etherlab.org>
Subject: RE: [etherlab-users] CX CPU as Master Linux Slave

Hi Graeme,

thanks for your answer.
I'm trying to use a CX8010 as TwinCAT Master of its own net. Over it is a Linux 
PC running the Master Linux 1.5.2. We would like to have the CX8010 as slave 
from the Master Linux sharing In/Outs PDOs.

By the moment I keep running the CX8010 as normal, with the slave pdo 
configuration just done.

From the Master Linux I see the slave at PREOP (with Error), with this dmesg 
outputs:

[2061710.482018] EtherCAT 0: 0 slave(s) responding on main device.
[2061710.482020] EtherCAT 0: Stopping EoE thread.
[2061710.482038] EtherCAT 0: EoE thread exited.
[2061710.499211] EtherCAT 0: 1 slave(s) responding on main device.
[2061710.499214] EtherCAT 0: Slave states on main device: PREOP.
[2061710.499718] EtherCAT 0: Scanning bus.
[2061710.640237] EtherCAT 0: Bus scanning completed in 141 ms.
[2061710.640240] EtherCAT 0: Using slave 0 as DC reference clock.
[2061710.640242] EtherCAT 0: Starting EoE thread.
[2061710.655820] IPv6: ADDRCONF(NETDEV_UP): eoe0s0: link is not ready
[2061710.666862] EtherCAT ERROR 0-0: Failed to set SAFEOP state, slave refused 
state change (PREOP + ERROR).
[2061710.

Re: [etherlab-users] Distribute Clock new flow

[Graeme Foot]

Hi,

The DC flow from the post below is an old version, back in the days when RTDM 
was first being added to the master.  I no longer need the separate thread to 
activate the master.

I use a slave as a reference clock, adjusting the PC’s cycle to match.  I 
haven’t used Xenomai or RT-PREMPT but they should only need something similar 
to rt_sleep_until().

My current DC flow is:

configure master
  ecrt_request_master
  ecrt_master_create_domain (x3)

configure slaves (pdos / sdos / dc)
  ecrt_master_get_slave // get slave info and check it matches 
the expected device and revision
  ecrt_master_slave_config
  ecrt_slave_config_pdos
  ecrt_slave_config_create_sdo_request  // I create one general usage SDO per 
module
  ecrt_slave_config_reg_pdo_entry   // one call per pdo entry
  ecrt_slave_config_sdo8 etc// configuration entries
  ecrt_slave_config_dc  // for dc slaves

prepare to run
  ecrt_master_setup_domain_memory   // pre-setup domain memory (via one of 
my patches)
  per domain:
ecrt_domain_data// get domain data address
ecrt_domain_size// get domain data size
allocate memory x2  // for a mask and a cache
  per module:
calculate/cache pdo data addresses
set initial module data/control values
  set up dc clocks:
ecrt_master_application_time// set initial app time (must be in 
phase with realtime cycle)
ecrt_master_select_reference_clock  // select slave to use as reference 
clock
  ecrt_master_activate

start realtime cycle (I use RTAI)
  rt_thread_init
  rt_set_oneshot_mode
  rt_allow_nonroot_hrt
  mlockall
  calc first wake time (in phase with initial ecrt_master_application_time call)
  start_rt_timer
  rt_make_hard_real_time

realtime cycle
  ecrt_master_receive
  ecrt_domain_process x3
  ecrt_domain_state // check WC / state of domains
  ecrt_master_state // check state of master
  see if any modules want to write “special” data
  write cached domain data
  ecrt_domain_queue x3
  sync distributed clock// as close to ecrt_master_send as 
possible
ecrt_master_reference_clock_time// calc diff between expected slave 
time and actual, after first realtime scan
ecrt_master_sync_slave_clocks
ecrt_master_application_time
  ecrt_master_send
  calc slave to master time drift and adjust master clock and cycle period to 
match
  see if any modules want to reset “special” data or calc extra data (eg Actual 
Velocity)

  perform application logic.
  note: any data to be written to the domain memory is actually written to the 
domain cache and mask

  run device logic (eg axis enable / disable logic)

  wait for remainder of cycle
rt_sleep_until

stop realtime cycle (called before wait for remainder of cycle if app is 
flagged to shutdown)
  (while continuing realtime cycle)
  tell modules to prepare to stop, ie stop and disable axes nicely etc
  once safe:
  ecrt_master_deactivate_slaves // from one of my patches, it stops a 
few shutdown errors
  (continue cycling until the rest of the app is ready to shutdown also)

and stop
  rt_make_soft_real_time
  stop_rt_timer
  rt_task_delete
  ecrt_master_deactivate
  ecrt_release_master
  free domain cache/mask memory



The call to ecrt_master_reference_clock_time() is what gives us the reference 
slave clock time.  We compare this to our expected time and the difference is 
the slaves drift compared to the master PC.  I cache a running history of these 
to calc an average drift to figure out my base cycle time in terms of the PC 
clock.  I also gradually adjust the cycle time as required to keep the slave 
and master periods in sync.

The application time needs to be the master PC’s time adjusted by the overall 
drift with the reference slaves clock.



As for the Working counter changed messages I’m not really sure.  Check the 
cable between the last two modules is good / try a new cable maybe.


Regards,
Graeme.



From: 陈成细 [mailto:crazyintermi...@gmail.com]
Sent: Friday, 25 March 2016 1:16 a.m.
To: Graeme Foot
Subject: Distribute Clock new flow

Dear Graeme,

Thanks a lot for your help during last two years .
Now i can run yaskawa driver and motor with ethercat. However sometimes it will 
run into sync error, I am not aware the problem until i bought another 
secondhand Omron driver . I decided to solve this DC issue from the root, so I 
carefully go through all the threads from mailing list which related to DC many 
times.

Of course your 
thread(http://thread.gmane.org/gmane.network.etherlab.user/1335/focus=1349) is 
from A-Z to solve this issue. I would like to use the same method to solve my 
problem, but I have following questions:

1. your DC flow:

configure master

  ecrt_request_master

  ecrt_master_create_domain

configure slaves (pdos / sdos / dc)

  ecrt_master_slave_config

  ecrt_slave_config_pdos

Re: [etherlab-users] configuration

[Graeme Foot]

From: Paul Mulligan [mailto:mulligan...@yahoo.ie]
Sent: Tuesday, 23 February 2016 11:17 p.m.
To: Graeme Foot
Subject: configuration

Hi Graeme,

What in your opinion is the best way to configure an Ethercat system. Do you 
use the ET 9000 configuration tool?

The requirement here is to be able to configure all the SDO and PDO entries for 
the modules with a GUI without having to hard-code this data into the 
application.

Thanks,
Paul


Hi,

What we do in our app is hardcode the functions around configuring and using 
each of the module types we support, and use an XML configuration file to 
define what modules are used for the particular installation.

Our EtherCAT PC is headless, connected to a separate Windows PC that provides 
the GUI and upper level (non-realtime) control logic.  The EtherCAT PC has a 
web server interface that allows control and monitoring of the application via 
the Windows PC.  We have also been working on extending the web interface to 
allow GUI editing of the apps config file.  This is 90% complete, but keeps 
being put on the back burner as other projects keep coming up and it really is 
quite easy to edit XML files direct.


In future versions, if I ever get time, I would like to be able to replace the 
hardcoded functions by instead reading module description (ESI) files, but 
hardcoded functions gives you so much more flexibility and we don’t often need 
to support new module types.

I’ve never used the ET9000 configuration tool so can’t comment as to whether 
that is a good option.  What I can say is that the EtherCAT configuration 
section is a small part of our configuration file so for us using the ET9000 
tool would likely be pointless.


Regards,
Graeme.

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

Re: [etherlab-users] distributed clocks query

[Graeme Foot]

Hi,

I have never been able to get the EL7031 and EL7041 stepper modules to work in 
DC sync mode.  I’ve also never really had enough time to really get in and 
figure out why.  If you do and succeed then it would be appreciated if you 
could post your results.  You could perhaps try to get it working under a 
TwinCAT system then compare the differences.


Some more notes on DC:
- During your app setup, the first call to ecrt_master_application_time() 
defines the “time when the clocks start off for the first time”.  Your realtime 
cycle must then be relative to this time once you go realtime.
- There are two parts to DC.  The first is the synchronization of the slaves 
clocks to the reference slaves clock (and the master clock).  The second is 
choosing which slaves use the dc sync events by calling ecrt_slave_config_dc() 
on every slave you wish to be sync’ed, but this can only be called on slaves 
that support DC to this level.


Regards,
Graeme.

From: etherlab-users [mailto:etherlab-users-boun...@etherlab.org] On Behalf Of 
Paul Mulligan
Sent: Wednesday, 2 March 2016 5:27 a.m.
To: Richard Hacker; etherlab-users@etherlab.org
Subject: Re: [etherlab-users] distributed clocks query

Thanks.

It seems the however that the EL7031 stepper motor module does not work in DC 
mode even tho the AssignActivate word is listed in the device description xml 
file as 0x300.

On Tuesday, 1 March 2016, 17:04:39, Richard Hacker 
> wrote:

DC is quite an intricate aspect of EtherCAT.

In DC enabled slaves, there are two clocks that generate events. You
specify the time at which these clocks run as well as the time when the
clocks start off for the first time. What the slave controller does at
these events is implementation detail and must be documented by the
manufacturer of the slave.

There is documentation available at
http://download.beckhoff.com/download/document/io/ethercat-terminals/ethercatsystem_en.chm
Check out Distributed Clocks -> Slave synchronization -> DC Modes.

In the master, it is configured using
void ecrt_slave_config_dc(
ec_slave_config_t *sc, /**< Slave configuration.*/
uint16_t assign_activate, /**< AssignActivate word.*/
uint32_t sync0_cycle, /**< SYNC0 cycle time [ns].*/
int32_t sync0_shift, /**< SYNC0 shift time [ns].*/
uint32_t sync1_cycle, /**< SYNC1 cycle time [ns].*/
int32_t sync1_shift /**< SYNC1 shift time [ns].*/
);

You will be stetting sync0_cycle to your cycle time in nanoseconds and
play around with sync0_shift somewhere half of your cycle time. The
other values will be zero in your case (in fact, sync1_shift is not even
used in the master!)

To check whether your slave is synchronizing, run:

watch -n0 "ethercat reg_read -pX -tsm32 0x92c"

where X is the position of your slave. This value should be quite low,
in the order of a few hundred. This is a correction value in nanoseconds
of the slave's clock.

On 01.03.2016 12:44, Paul Mulligan wrote:
> Hi,
>
> I'm still unsure as to what values are given for the last four
> parameters of this function. I believe the sync1_cycle and sync1_shift
> can be ignored but how is the sync0_shift value determined? I believe
> the frame should reach all the slaves before this time but also the new
> frame should not be received before this time. In the examples given, a
> scan time of 1ms is used but the sync0_shift value is 4.4 ms. How can
> this be correct?
>
> ecrt_slave_config_dc(modules[index].sc, 0x0300, scanTime, ??, ??, ??, ??);
>
>
> On Monday, 29 February 2016, 15:57:30, Richard Hacker 
> > wrote:
>
>
> I only configure DC on the slaves that are actually required to be
> synchronized.
>
> Otherwise it seems correct what you are doing...
>
> Am 2016-02-29 um 14:45 schrieb Paul Mulligan:
>  > Hi,
>  >
>  > Just a question or two about distributed clocks.
>  >
>  > I have a system with an EL1008 digital input module, EL3001 analogue
>  > input module, two EL7031 stepper motor driver modules and two EL2008
>  > digital output modules in that order. I am using the EK1100 bus coupler
>  > terminal as the first module.
>  >
>  > Do I need to call ecrt_slave_config_dc() for all of these modules before
>  > activating the master, or just the first module on the bus? My
>  > understanding from reading about distributed clocks is that the first
>  > module on the bus with DC capability should be used as the reference
> clock.
>  >
>  >  From looking at the example "dc_user" supplied in the master download,
>  > it calls ecrt_slave_config_dc() only for the IDS_COUNTER module.
>  >
>  > In the cyclic_task(), the functions ecrt_master_application_time(),
>  > ecrt_master_sync_reference_clock(), ecrt_master_sync_slave_clocks() are
>  > then called in that order. I notice ecrt_master_reference_clock_time()
>  > is not used at all here.
>  >
>  > Is this all that is required to control the distributed clocks ? Thank
>  > you in advance.
>  >
>  >
>  > 

Re: [etherlab-users] rtai_rtdm_dc example, "error: system_time_base less than system time" message

[Graeme Foot]

Interesting, it shouldn’t matter which order the modules are in, but for a few 
exceptions.

Some of those exceptions being:

1) You can’t have more than two Passive Terminals grouped together (see 
Mounting of Passive Terminals in any of the Beckhoff documents)

2) Some modules such at the relay output module EL2612 don’t have power 
contacts, so need to be placed at the end of the terminal group

3) Make sure you don’t exceed the power capabilities of the EK1100 module.  
This can provide 2000mA.  Each active terminal consumes some of that power.  
This can be calculated by using the `ethercat slaves -v` command and checking 
each modules “Current consumption” value.  The EL1008 modules use 90mA each, so 
17 of these would be fine, but it sounds like you have other modules which may 
use more (eg: an EL2008 uses 110mA, an EL5101 uses 130mA, an EL2612 uses 150mA 
etc).

Note: you can also use the command `ethercat slaves -v | grep “Current 
consumption”` for a quick summary.  The EK1100 module reports -2000mA because 
it is supplying rather than consuming.

If you have gone over the available current then you will need to insert an 
EL9410 power module (or similar).


Regards,
Graeme.

From: Bilko AS, Oguz Dilmac [mailto:odil...@bilko-automation.com]
Sent: Saturday, 6 February 2016 1:42 a.m.
To: Graeme Foot; etherlab-users@etherlab.org
Subject: Re: [etherlab-users] rtai_rtdm_dc example, "error: system_time_base 
less than system time" message

Hi,

We solved the problem last week.
It turned out we have to place the same kind of bechoff IO modules next to each 
other.

In the group of modules which connected to a EK1100 we had 17 modules. In this 
group, we had four EL1008 one after the other; Then a few other modules; Then 
one EL1008; again afew more modules and finally two more EL1008. When we group 
all the EL1008 modules in a row, the problem disappeared.

Best regards,
Oguz.
26.1.2016 01:49 tarihinde Graeme Foot yazdı:
Hi,

The “system_time_base less than system time” is from the rtai_rtdm_dc example 
code.

In the example it looks like system_time_base is initialised to zero and 
adjusted by a maximum of +-1001 each cycle.  A value of -58905492552780 
indicates that system_time_base is not being correctly initialised or is being 
corrupted with any other values.

As to the motor “knock” every now and then, this is due to the motors dc clock 
not being correctly synchronized with the masters cycle time.  It is due to the 
master either missing or sending two messages to the amps in one cycle every 
now and then.  Sort out your dc timing and the knock will go away.

Regards,
Graeme.


From: etherlab-users [mailto:etherlab-users-boun...@etherlab.org] On Behalf Of 
Bilko AS, Oguz Dilmac
Sent: Tuesday, 26 January 2016 4:37 a.m.
To: etherlab-users@etherlab.org<mailto:etherlab-users@etherlab.org>
Subject: [etherlab-users] rtai_rtdm_dc example, "error: system_time_base less 
than system time" message

Hi,

We have been using EtherCAT master 1.5.2 for about two years. We have 
successfully implemented 4 machines. Each has 5 Kollmorgen AKD servo drives and 
some Beckhoff IO modules.
Now we are implementing a new machine. On this machine we usually get the 
following messages:
...
"system2count() error: system_time_base less than system time 
(system_time_base: -58905492552780, time:680659495658"
"system2count() error: system_time_base less than system time 
(system_time_base: -58905492552858, time:680660495658"
"system2count() error: system_time_base less than system time 
(system_time_base: -58905492552936, time:680661495658"
"system2count() error: system_time_base less than system time 
(system_time_base: -58905492553014, time:680662495658"
...

We implemented our system based on the rtai_rtdm_dc example. Only main 
difference is, we use kernel modules with RTAI instead of LXRT user mod.
We are using "cyclic positon" (8) mode with distributed clock.
We choose the first DC capable device as the reference clock by calling 
ecrt_master_select_reference_clock(master, 0);
The first node on the bus is a AKD servo drive.

The error occurs from the startup and not disappear until we reboot the PC and 
the drives.
When the error occurs, it seems sometimes drives can't update the new position 
reference. Therefore, if it is moving, it tries to stop for one sample and 
continues to the new reference at the next sample.
This causes a loud "knock" sound on the machine.

We didn't get this message with previous 4 machines.
We tried different FW versions of the AKD drives. Also tried to change the bus 
node order of the drives. But nothing changed.
Do you know what can be the cause for this message? How can we fix the problem?

Best regards,
Oguz.
--



Oguz Dilmac

ARGE Bolumu



Bilko AS, R Department



Perpa Ticaret Merkezi B Blok Kat 13 Nr. 2568

TR-34384 Okmeydani Istanbul Turkey

Tel

Re: [etherlab-users] Controlling motors in position controller mode

[Graeme Foot]

Hi,

This module supports “64-fold” micro stepping.  So the number of counts per 
revolution for the Target Position is 200*64 = 12800 steps per revolution.

Regards,
Graeme.


From: etherlab-users [mailto:etherlab-users-boun...@etherlab.org] On Behalf Of 
Paul Mulligan
Sent: Tuesday, 26 January 2016 3:37 a.m.
To: etherlab-users@etherlab.org
Subject: [etherlab-users] Controlling motors in position controller mode

Hi,

I am using the EL7031 to control a motor using the position controller mode but 
I am having issues.

My steps per revolution are at the default of 200 using the setting 8010:06.

My cyclic function executes every 10ms. Every time the function executes, the 
target position (7010:11) is incremented by 2.

I would therefore expect to see the motor turning at one revolution per second 
but instead it is moving very slow. If I increment the target position by 150 
every cycle, it seems to be turning at about 1 rev/s. I'm struggling to make 
sense of why this is.

By using the command line tool, no errors are reported, the motor is configured 
as expected and the full steps per revolution are 200.

Am I missing some other setting or something obvious?

I appreciate any help. Thanks
___
etherlab-users mailing list
etherlab-users@etherlab.org
http://lists.etherlab.org/mailman/listinfo/etherlab-users

Re: [etherlab-users] rtai_rtdm_dc example, "error: system_time_base less than system time" message

[Graeme Foot]

Hi,

The “system_time_base less than system time” is from the rtai_rtdm_dc example 
code.

In the example it looks like system_time_base is initialised to zero and 
adjusted by a maximum of +-1001 each cycle.  A value of -58905492552780 
indicates that system_time_base is not being correctly initialised or is being 
corrupted with any other values.

As to the motor “knock” every now and then, this is due to the motors dc clock 
not being correctly synchronized with the masters cycle time.  It is due to the 
master either missing or sending two messages to the amps in one cycle every 
now and then.  Sort out your dc timing and the knock will go away.

Regards,
Graeme.


From: etherlab-users [mailto:etherlab-users-boun...@etherlab.org] On Behalf Of 
Bilko AS, Oguz Dilmac
Sent: Tuesday, 26 January 2016 4:37 a.m.
To: etherlab-users@etherlab.org
Subject: [etherlab-users] rtai_rtdm_dc example, "error: system_time_base less 
than system time" message

Hi,

We have been using EtherCAT master 1.5.2 for about two years. We have 
successfully implemented 4 machines. Each has 5 Kollmorgen AKD servo drives and 
some Beckhoff IO modules.
Now we are implementing a new machine. On this machine we usually get the 
following messages:
...
"system2count() error: system_time_base less than system time 
(system_time_base: -58905492552780, time:680659495658"
"system2count() error: system_time_base less than system time 
(system_time_base: -58905492552858, time:680660495658"
"system2count() error: system_time_base less than system time 
(system_time_base: -58905492552936, time:680661495658"
"system2count() error: system_time_base less than system time 
(system_time_base: -58905492553014, time:680662495658"
...

We implemented our system based on the rtai_rtdm_dc example. Only main 
difference is, we use kernel modules with RTAI instead of LXRT user mod.
We are using "cyclic positon" (8) mode with distributed clock.
We choose the first DC capable device as the reference clock by calling 
ecrt_master_select_reference_clock(master, 0);
The first node on the bus is a AKD servo drive.

The error occurs from the startup and not disappear until we reboot the PC and 
the drives.
When the error occurs, it seems sometimes drives can't update the new position 
reference. Therefore, if it is moving, it tries to stop for one sample and 
continues to the new reference at the next sample.
This causes a loud "knock" sound on the machine.

We didn't get this message with previous 4 machines.
We tried different FW versions of the AKD drives. Also tried to change the bus 
node order of the drives. But nothing changed.
Do you know what can be the cause for this message? How can we fix the problem?

Best regards,
Oguz.
--


Oguz Dilmac

ARGE Bolumu



Bilko AS, R Department



Perpa Ticaret Merkezi B Blok Kat 13 Nr. 2568

TR-34384 Okmeydani Istanbul Turkey

Tel : +90 212 220 07 40  Fax :   +90 212 210 47 01

e-mail : odil...@bilko-automation.com

web site : http://www.bilko-automation.com


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

Re: [etherlab-users] Controlling motor drivers

[Graeme Foot]

Hi,

We also use the EL7041 in production, but have also used an EL7031 for testing.

The default the PDO mapping is for velocity control.  You need to change it to 
use the position control PDO's.


For the EL7031 the PDO setup I use is:

ec_pdo_entry_info_t EL7031_pdoEntries[] = {
// 0x1602, stepper control (0)
{0x7010, 0x01, 1},// Enable
{0x7010, 0x02, 1},// Reset 
{0x7010, 0x03, 1},// Reduce torque 
{0x, 0x00, 5},//   spacer 
{0x, 0x00, 8},//   spacer 

// 0x1603, stepper pos (5)
{0x7010, 0x11, 32},   // Target position


// 0x1a03, stepper status (6)
{0x6010, 0x01, 1},// Ready to enable 
{0x6010, 0x02, 1},// Ready 
{0x6010, 0x03, 1},// Warning 
{0x6010, 0x04, 1},// Error 
{0x6010, 0x05, 1},// Moving positive 
{0x6010, 0x06, 1},// Moving negative 
{0x6010, 0x07, 1},// Torque reduced 
{0x, 0x00, 1},//   spacer 
{0x, 0x00, 3},//   spacer
{0x6010, 0x0c, 1},// Digital input 1 
{0x6010, 0x0d, 1},// Digital input 2 
{0x1c32, 0x20, 1},// Sync error 
{0x, 0x00, 1},//   spacer 
{0x1803, 0x09, 1},// *** unknown ***
  
};

ec_pdo_info_t EL7031_pdos[] = {
{0x1602, 5, EL7031_pdoEntries + 0},
{0x1603, 1, EL7031_pdoEntries + 5},
{0x1a03, 14, EL7031_pdoEntries + 6},
};

ec_sync_info_t EL7031_syncs[] = {
{0, EC_DIR_OUTPUT, 0, NULL, EC_WD_DISABLE},
{1, EC_DIR_INPUT, 0, NULL, EC_WD_DISABLE},
{2, EC_DIR_OUTPUT, 2, EL7031_pdos + 0, EC_WD_DISABLE},
{3, EC_DIR_INPUT, 1, EL7031_pdos + 2, EC_WD_DISABLE},
{0xff}
};


PDO Item #5 {0x7010, 0x11, 32} is the Target position.


You will want to pre-configure some of the SDO values:

  maxCurrent  0x8010, 0x01
  reducedCurrent  0x8010, 0x02
  nominalVoltage  0x8010, 0x03
  motorCoilResistance 0x8010, 0x04
  motorFullSteps  0x8010, 0x06
  maxSpeedRange   0x8012, 0x05
  reversed0x8012, 0x09


On initialisation you need to set the motor to use the Position Controller mode 
of operation (3):

  ecrt_slave_config_sdo8(dev->slaveConfig, 0x8012, 0x01, 3);


You may also want to set up the distributed clock (eg:)

  ecrt_slave_config_dc(dev->slaveConfig, 0x0300, g_app.scanTimeNS, 50, 0, 
0);


You will probably want to set up a motor enable state machine but the guts of 
it is that you will want to:
 
- before enabling, if the error status bit (PDO Item #9 {0x6010, 0x04, 1}) is 
set
  set the faultReset control bit (PDO Item #1 {0x7010, 0x02, 1}) for around 
100ms

- ensure the readyToEnable status bit (PDO Item #6 {0x6010, 0x01, 1}) is on
  if there is no error set the enable control bit (PDO Item #0 {0x7010, 0x01, 
1})
  wait until the ready status bit (PDO Item #7 {0x6010, 0x02, 1}) is on


Once enabled you need to update the target position (PDO Item #5 {0x7010, 0x11, 
32}) every scan cycle with the position you want to go to.  It is up to you to 
create a motion profile for the motor and then figure out what the target 
position is at each time increment.


Lastly, if you get the warning or error status bits set you can look up what 
the error or warning is via the 0xA010 SDO diagnostic bits (0xA010:0x01 - 
0xA010:0x11).  Note: these are only available via SDO access, so what I do is 
have a state machine that looks them up if the warning or error status bits are 
set.


Hope this helps.


Regards,

Graeme Foot
Kinetic Engineering Design Ltd.

  

-Original Message-
From: etherlab-users [mailto:etherlab-users-boun...@etherlab.org] On Behalf Of 
Thomas Bitsky Jr
Sent: Wednesday, 20 January 2016 3:57 a.m.
To: Paul Mulligan; etherlab-users@etherlab.org
Subject: Re: [etherlab-users] Controlling motor drivers

I use the EL7041 often. He’s a quick copy/paste of how I make it move to 
position. The code snippet below writes to EtherLAB through a library I wrote, 
but the tasks required should be pretty obvious.

Thanks!


static int
stateIdle(void* lp)
{
EL7041StepperInterface* p;  
EL7041_ENTER(p, lp);

if (p->doMove)
{
p->doMove = false;


if ( !lcxReadPdoBit(p->pdoOffset + IX_READY) )
{
PRINT( "EL7041.%s not ready for motion. Cancelling.\n",
__FUNCTION__ );
return StateMachineRunning;
}




lcxWritePdoUInt16(p->pdoOffset + QW_SETACCEL, p->targetAccel );
lcxWritePdoUInt16(p->pdoOffset + QW_SETDECEL, p->targetDecel );
lcxWritePdoUInt16(p->pdoOffset + QW_SETVELOCITY, 
p->targetVelocity );

p->fsm = 
return StateMachineTransition;
}

}

static int
stateWaitWriteMotionParameters

Re: [etherlab-users] Fwd: Problems using ethercat-1.5.2 with Yaskawa Servopack

[Graeme Foot]

Hi,

The default Mode of operation (0x6060) is 0 (No mode change/ no mode assigned). 
 Unless you have changed it and saved it to the EEPROM.  If not you need to set 
it to 8 for Cyclic Sync Position Mode.

You can confirm your current Mode of Operation using 0x6061.

Regards,
Graeme.


From: etherlab-users [mailto:etherlab-users-boun...@etherlab.org] On Behalf Of 
Shu Huang
Sent: Tuesday, 22 September 2015 7:08 p.m.
To: etherlab-users@etherlab.org
Subject: [etherlab-users] Fwd: Problems using ethercat-1.5.2 with Yaskawa 
Servopack


Hello everyone,
We are trying to integrate IgH ethercat master (1.5.2) with Yaskawa Servopack. 
For the moment, basic ethercat PDO communication seems working, but after 
writing a desired target position to the drive, the motor didn't more. Below 
are detail descriptions.

System setup:
IgH ethercat master
master <---> DIO <-> Servopack

Domain1 is used for DIO, and we have separeded a domain2 for write operation, 
and a domain3 for read operation for Sercopack.

After initialization, all slaves are in OP mode. The servopack should be 
working in the default mode (Cyclic Sync Position mode).

Test steps:
0. reading statusword=0x270
1. write controlword: 0x06
2. write controlword: 0x0f (now the servo is on, motor is locked)
3. test by reading statusword=0x237 (is this correct?)
4. actual posotion can be read==> get encoder value OK
5. write target position ==> nothing happened
6. servo-unlock by writing controlword: 0x06 (servo unlock)

Some questions:
1. Why writing the target position value didn't work? Other PDOs seem working?
2. statusword = 0x237, but bit12 indicates: target value ignore??? (does this 
mean anything?)
3. Or, there are other procedure for start-up the servopack?

Other tests: The drive can perform jogging by SigmaWin. (wiring is OK)
Is there anything missing? or what are the other testing sequence we can try?
Thank you very much.

Shu HUANG (a.k.a. Michael)

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

Re: [etherlab-users] Twincat communicate with yaskawa SGDV alarm A12 (Sync Error)

[Graeme Foot]

Hi,

1) If your cycle time is 4ms, I think it should instead be:
0x60C2, 0x01 = 4
0x60C2, 0x02 = -3

Eg:
  ecrt_slave_config_sdo8(dev-slaveConfig, 0x60C2, 0x01, (uint8_t)4);
  ecrt_slave_config_sdo8(dev-slaveConfig, 0x60C2, 0x02, (int8_t)(-3));

Where the first parameter is the significand and the second parameter is the 
exponent.  So:
(0x60C2, 0x01) * 10 ^ (0x60C2, 0x02)  =  4 * 10 ^ -3  =  0.004 seconds  =  4 ms


2) I’m currently patching against 1.5.2 (2526).  Yes it is still quite old but 
I haven’t needed to (or had the time) to move on.  I don’t think any of my 
patches have made it into the master.  My current DC patch is: 
etherlabmaster-1.5.2-2526-c_dc_helpers.patch (attached).  There is still the 
odd issue with some of the slaves taking a while to sync on startup.  This has 
been solved by other people but I haven’t had a chance to add it in myself yet.

I don’t think the EK1100, EL1008 and EL2008 modules are able to be set up as DC 
slaves, but they can be used as the reference clock slave.

Before starting realtime polling I set the reference clock slave using (where 
refSlaveConfig is the slaveConfig of the module I select via a config file):
  ecrt_master_select_reference_clock(ecMod-master, refSlaveConfig);

This is after ecrt_master_application_time() and before ecrt_master_activate().


My realtime loop is:

  // receive process data
  ecrt_master_receive(ecMod-master);

  // process domain data
  for (i = 0; i  EC_DOMAIN_COUNT; i++)
  {
ecrt_domain_process(ecMod-domains[i].domain);
  }

  // check domain state, check master state
  ...

  // prepare pdo data
  ...

  // send process data
  for (i = 0; i  EC_DOMAIN_COUNT; i++)
  {
ecrt_domain_queue(ecMod-domains[i].domain);
  }

  // always sync distributed clock (just before master_send)
  ecMod_syncDistClock(ecMod);

  // do the send
  ecrt_master_send(ecMod-master);

  // update the master clock (if this module provides the ref slave)
  // Note: called after ecrt_master_send to reduce time jitter
  ecMod_updateMasterClock(ecMod);


My syncDistClock function gets the current ref slave time and requests the 
slaves to sync to the ref slave:

  // cache prev master time and get now
  masterTime  = (uint32_t)ecMod-m_dcTime;
  ecMod-m_dcTime = filterTime( rt_get_time_ns() );

  // get lower 32 bit of clock time from reference slave (after first scan)
  if (ecMod-m_getDCDiff)
  {
int  res;
uint32_t slaveTime;
res = ecrt_master_reference_clock_time(ecMod-master, slaveTime);

switch (res)
{
  case 0 :
  {
// calc time diff
ecMod-m_dcDiff = masterTime - slaveTime;
  } break;

  default :
  {
// no ref clock found or datagram failure
ecMod-m_dcDiff = 0;
  }
}
  }
  else
  {
ecMod-m_dcDiff= 0;
ecMod-m_getDCDiff = true;
  }

  // call to sync slaves to ref slave
  // (which is used for ecrt_master_reference_clock_time)
  ecrt_master_sync_slave_clocks(ecMod-master);

  // update the master time for the next cycle (in nano-seconds)
 // (this is required for the master to figure out the modules initial
  //  dc time)
  ecrt_master_application_time(ecMod-master, ecMod-m_dcTime + 
g_app.scanTimeNS);


My updateMasterClock function is responsible for tracking and filtering the 
master time drift.  This drift is added to the rtai time.  So whenever I need 
to get an rtai time I need to wrap it in the filterTime() function.  When I 
need the realtime cycle to sleep for the next period (using 
rt_sleep_until(wakeTime)) the wake time is adjusted by the filtered time.


(Note: error checking removed to hopefully make clearer)


I hope this helps,

Graeme.



From: 陈成细 [mailto:crazyintermi...@gmail.com]
Sent: Friday, 29 May 2015 2:19 p.m.
To: Graeme Foot
Subject: Re: Twincat communicate with yaskawa SGDV alarm A12 (Sync Error)

Dear Graeme Foot,
Thanks for your kindly guide in the mailing list and private email. In the 
recently half year, I do on the track and make in progress to drive my yaskawa 
servopack and servo motor via etherlab master.
First of all, I would like update my status to you.
1. I create three domain, readdomain, write domain for yaskawa, another domain 
for others.
2. I can make motor rotate in free run mode without setup DC
3. Two times success to drive motor with DC, others 5000ms sync error
My setup:
ubuntu 14.04, xenomai real time kernel, etherlab1.52 stable
I do my homework already, and I think the answer already in the mailing list, 
so I have several point need to make clear.

1. http://lists.etherlab.org/pipermail/etherlab-users/2012/001562.html post 
you mention


Hi,

Yes I have thanks.  My cycle time is 1ms.  I have set:

0x60C2, 0x01 = 1

0x60C2, 0x02 = -3

Graeme.
My cycle time use 4ms, I set

0x60C2, 0x01 = 01

0x60C2, 0x02 = FD
refer to
[Inline image 1]

2. Regarding DC patch 
http://thread.gmane.org/gmane.network.etherlab.user/1421, do you have latest 
patch for etherlab1.52 stable, since it is years ago

Re: [etherlab-users] Twincat communicate with yaskawa SGDV alarm A12 (Sync Error)

[Graeme Foot]

Hi,

Good comments to make.

Yes, the DC reference slave should be the first capable slave and definitely 
before (or at least the first) DC enabled slave.  However, I had some EK1100 
modules (which at one stage were my first slaves) that just did not seem to 
provide a settled enough time for the yaskawa SGDV drives.  But when I changed 
my reference slave to an EL1008 slave (the next slave in the system) everything 
was fine.  I suspect the EK1100’s time was running too fast (or too slow, I 
can’t remember) compared to the SGDV’s time and it couldn’t adjust quick enough.

If you don’t call ecrt_master_application_time() before ecrt_master_activate() 
then you can get: No app_time received up to now but master already active..  
However, as you say, you should call ecrt_master_application_time() in phase 
with your realtime cycle time.  I set my time just before going realtime and 
the first realtime period is scheduled to run 50 times my cycle period later.  
The 50 times is to allow the rt_make_hard_real_time() call to go realtime.  As 
we are not yet realtime, this call can take a little time to happen.

Yes, I agree, the ecrt_master_send() should be as consistent as possible.  To 
allow this my cycles sequence is to perform the EtherCAT code below straight 
after waking up.  All other calculations and processing, to prepare for the 
next cycle, are performed after this.

Graeme.


From: Gavin Lambert [mailto:gav...@compacsort.com]
Sent: Tuesday, 2 June 2015 12:52 p.m.
To: Graeme Foot
Cc: etherlab-users@etherlab.org
Subject: RE: [etherlab-users] Twincat communicate with yaskawa SGDV alarm A12 
(Sync Error)

FWIW, while I could be wrong about this, as far as I know it’s generally a bad 
idea to explicitly set the reference clock slave.  It defaults to being the 
first DC-capable slave on the network, and you shouldn’t set it to any other 
slave because of the way the DC sync datagrams work.  Specifically, any 
DC-capable slaves that are topologically earlier than the reference clock will 
not receive the reference clock’s time, but instead whichever value happens to 
have been initialised by the master (I haven’t checked exactly what this will 
be but I expect it’s probably either zero or the master’s time).  As a result 
these slaves will be desynched with the rest of the network.

Of course, you can get away with this if you don’t care about the DC times of 
any slaves prior to the selected reference clock, but it still seems like a bad 
habit unless there’s a very good reason to select some specific device (eg. 
known as a “better” clock) – but then you should try to get it as early in the 
network as possible.

Also, you’re not supposed to call ecrt_master_application_time() before 
ecrt_master_activate(); the master is expecting that the first application_time 
it receives is in phase with the application loop – ideally as close to the 
ecrt_master_send() call as possible.  (The examples don’t really make this 
clear, but the goal is to make the ecrt_master_send()call at as close to the 
desired cycle time as possible.  The sleep is at the other end of the loop 
because there is a natural delay between send and receive anyway and because 
the assumption is that the processing time is reasonably constant.)

From: etherlab-users [mailto:etherlab-users-boun...@etherlab.org] On Behalf Of 
Graeme Foot
Sent: Tuesday, 2 June 2015 11:45
To: 陈成细; etherlab-users@etherlab.orgmailto:etherlab-users@etherlab.org
Subject: Re: [etherlab-users] Twincat communicate with yaskawa SGDV alarm A12 
(Sync Error)

Hi,

1) If your cycle time is 4ms, I think it should instead be:
0x60C2, 0x01 = 4
0x60C2, 0x02 = -3

Eg:
  ecrt_slave_config_sdo8(dev-slaveConfig, 0x60C2, 0x01, (uint8_t)4);
  ecrt_slave_config_sdo8(dev-slaveConfig, 0x60C2, 0x02, (int8_t)(-3));

Where the first parameter is the significand and the second parameter is the 
exponent.  So:
(0x60C2, 0x01) * 10 ^ (0x60C2, 0x02)  =  4 * 10 ^ -3  =  0.004 seconds  =  4 ms


2) I’m currently patching against 1.5.2 (2526).  Yes it is still quite old but 
I haven’t needed to (or had the time) to move on.  I don’t think any of my 
patches have made it into the master.  My current DC patch is: 
etherlabmaster-1.5.2-2526-c_dc_helpers.patch (attached).  There is still the 
odd issue with some of the slaves taking a while to sync on startup.  This has 
been solved by other people but I haven’t had a chance to add it in myself yet.

I don’t think the EK1100, EL1008 and EL2008 modules are able to be set up as DC 
slaves, but they can be used as the reference clock slave.

Before starting realtime polling I set the reference clock slave using (where 
refSlaveConfig is the slaveConfig of the module I select via a config file):
  ecrt_master_select_reference_clock(ecMod-master, refSlaveConfig);

This is after ecrt_master_application_time() and before ecrt_master_activate().


My realtime loop is:

  // receive process data
  ecrt_master_receive(ecMod-master);

  // process domain

Re: [etherlab-users] etherlab-users Digest, Vol 92, Issue 8

[Graeme Foot]

 = 
[ 4543.060078] inputdata = 
[ 4543.060086] EtherCAT DEBUG 0: Configuration changed (aborting state check).
[ 4543.060090] EtherCAT WARNING 0: No app_time received up to now, but master 
already active.
[ 4543.060094] EtherCAT DEBUG 0: Requesting OP...
[ 4543.092062] EtherCAT DEBUG 0-0: Changing state from PREOP to OP.
[ 4543.092070] EtherCAT DEBUG 0-0: Configuring...
[ 4543.116045] EtherCAT DEBUG 0-0: Now in INIT.
[ 4543.116053] EtherCAT DEBUG 0-0: Clearing FMMU configurations...
[ 4543.132022] EtherCAT DEBUG 0-0: Clearing sync manager configurations...
[ 4543.148031] EtherCAT DEBUG 0-0: Clearing DC assignment...
[ 4543.164043] EtherCAT DEBUG 0-0: Configuring mailbox sync managers...
[ 4543.164053] EtherCAT DEBUG 0-0: SM0: Addr 0x1000, Size 128, Ctrl 0x36, En 1
[ 4543.164057] EtherCAT DEBUG 0-0: SM1: Addr 0x1080, Size 128, Ctrl 0x32, En 1
[ 4543.196026] EtherCAT DEBUG 0-0: Now in PREOP.
[ 4543.196035] EtherCAT DEBUG 0-0: SM2: Addr 0x1100, Size   6, Ctrl 0x74, En 1
[ 4543.196039] EtherCAT DEBUG 0-0: SM3: Addr 0x1400, Size   6, Ctrl 0x30, En 1
[ 4543.244011] EtherCAT DEBUG 0-0: Now in SAFEOP.
[ 4543.268055] EtherCAT DEBUG 0-0: Now in OP. Finished configuration.
[ 4543.284095] EtherCAT 0: Slave states on main device: OP.

It seems works well, there are no  errors show on servo driver,except there are 
three highlights above.
I have several questions as follows:
1. How to deal with Sdos, when I set #define SDO_ACCESS 1 , there always show 
request ec_mini: still busy...
 dmesg as follow:
 /ethercat-master$ tool/ethercat sdos

SDO 0x1000, Device 
Type
0x1000:00, r-r-r-, 
uint32, 32 bit, Device Type
0x1000:01, r-r-r-, 
uint32, 32 bit, Device Type
SDO 0x1001, 
Failed to get SDO 
entry: Invalid argument

2. How to make my servo on and motor start to rotate?
I have try follow steps by command lines:
Firstly Set operation mode 0x6060 as 9 which means cyclic velocity mode
Secondly, set control word 0x6040 as 15
Then set target speed 0x607a as 300
  Seems there is no reaction, i check set status 0x6041, there is no change 
even i change 0x6040


So I am wondering how can i make my motor rotate by modify mini.c?
Anyone can give me any hints will be appreciated!

-cheng xi



On Wed, Jan 28, 2015 at 5:18 AM, 
etherlab-users-requ...@etherlab.orgmailto:etherlab-users-requ...@etherlab.org
 wrote:
Send etherlab-users mailing list submissions to
etherlab-users@etherlab.orgmailto:etherlab-users@etherlab.org

To subscribe or unsubscribe via the World Wide Web, visit
http://lists.etherlab.org/mailman/listinfo/etherlab-users
or, via email, send a message with subject or body 'help' to

etherlab-users-requ...@etherlab.orgmailto:etherlab-users-requ...@etherlab.org

You can reach the person managing the list at

etherlab-users-ow...@etherlab.orgmailto:etherlab-users-ow...@etherlab.org

When replying, please edit your Subject line so it is more specific
than Re: Contents of etherlab-users digest...


Today's Topics:

   1. Yaskawa servo Sychronization Error (Ruika You)
   2. Re: Yaskawa servo Sychronization Error (Graeme Foot)


--

Message: 1
Date: Tue, 27 Jan 2015 23:21:25 +0800
From: Ruika You crazylinux...@gmail.commailto:crazylinux...@gmail.com
To: etherlab-users@etherlab.orgmailto:etherlab-users@etherlab.org
Subject: [etherlab-users] Yaskawa servo Sychronization Error
Message-ID:

cabqyfp-lex7zkwt9gbjs36u2zvsnw1xtbmicojt6zo+9jug...@mail.gmail.commailto:cabqyfp-lex7zkwt9gbjs36u2zvsnw1xtbmicojt6zo%2b9jug...@mail.gmail.com
Content-Type: text/plain; charset=utf-8

Dear all,

When I am trying to using etherlab master with yaskawa servo,
sychronization error occur.
dmesg result as follow:
[705599.272444] EtherCAT 0: Link state of ecm0 changed to UP.
[705599.280070] EtherCAT WARNING 0: 1 datagram TIMED OUT!
[705599.292077] EtherCAT 0: 1 slave(s) responding on main device.
[705599.292087] EtherCAT 0: Slave states on main device: INIT.
[705599.292581] EtherCAT 0: Scanning bus.
[705599.316499] EtherCAT 0: Bus scanning completed in 24 ms.
[705599.316509] EtherCAT 0: Using slave 0 as DC reference clock.
[705599.320410] EtherCAT 0: Slave states on main device: PREOP.
[705602.382934] EtherCAT ERROR 0-0: Corrupt mailbox response received!
[705602.382945] EtherCAT DEBUG: 7E 00 01 00 00 63 00 80 04 00 00 00 01 10
05 00
[705602.382965] EtherCAT DEBUG: 00 07 45 72 72 6F 72 20 52 65 67 69 73 74
65 72
[705602.382983] EtherCAT DEBUG: 65 60 9A 60 B1 60 B2 60 B8 60 B9 60 BA 60
BC 60
[705602.383001] EtherCAT DEBUG: C1 60 C2 60 E0 60 E1 60 F4 60 FC 60 FD 60
FE 60
[705602.383019] EtherCAT DEBUG: FF 60 02 65 03 27 10

Re: [etherlab-users] Yaskawa servo Sychronization Error

[Graeme Foot]

Hi,

Ignore the “Corrupt mailbox response received”.  Also have a quick read of:
http://lists.etherlab.org/pipermail/etherlab-users/2010/001071.html

The main problem looks to me like the network is not stable.  First of all make 
sure that all the network cables are plugged in correctly and of a high enough 
standard.  Try different cables.  Cheap cables can cause problems.

Also ensure the realtime loop is polling consistently, with little jitter.

I also notice that you only have one domain.  The yaskawa drives require the 
reads to be separated from the writes in two separate domains.

Are you setting up the drive for Distributed Clock?  If you use the default 
Etherlab master method where the PC clock is the master then the yaskawa drives 
aren’t generally happy.  There is too much jitter.  Search the forum history 
for more info on that one.


A few things for you to start checking.

Regards,
Graeme.


From: etherlab-users [mailto:etherlab-users-boun...@etherlab.org] On Behalf Of 
Ruika You
Sent: Wednesday, 28 January 2015 4:21 a.m.
To: etherlab-users@etherlab.org
Subject: [etherlab-users] Yaskawa servo Sychronization Error

Dear all,
When I am trying to using etherlab master with yaskawa servo, sychronization 
error occur.
dmesg result as follow:
[705599.272444] EtherCAT 0: Link state of ecm0 changed to UP.
[705599.280070] EtherCAT WARNING 0: 1 datagram TIMED OUT!
[705599.292077] EtherCAT 0: 1 slave(s) responding on main device.
[705599.292087] EtherCAT 0: Slave states on main device: INIT.
[705599.292581] EtherCAT 0: Scanning bus.
[705599.316499] EtherCAT 0: Bus scanning completed in 24 ms.
[705599.316509] EtherCAT 0: Using slave 0 as DC reference clock.
[705599.320410] EtherCAT 0: Slave states on main device: PREOP.
[705602.382934] EtherCAT ERROR 0-0: Corrupt mailbox response received!
[705602.382945] EtherCAT DEBUG: 7E 00 01 00 00 63 00 80 04 00 00 00 01 10 05 00
[705602.382965] EtherCAT DEBUG: 00 07 45 72 72 6F 72 20 52 65 67 69 73 74 65 72
[705602.382983] EtherCAT DEBUG: 65 60 9A 60 B1 60 B2 60 B8 60 B9 60 BA 60 BC 60
[705602.383001] EtherCAT DEBUG: C1 60 C2 60 E0 60 E1 60 F4 60 FC 60 FD 60 FE 60
[705602.383019] EtherCAT DEBUG: FF 60 02 65 03 27 10 27 20 27 E0 27 3F 60 40 60
[705602.383037] EtherCAT DEBUG: 41 60 5A 60 5B 60 5C 60 5D 60 5E 60 60 60 61 60
[705602.383055] EtherCAT DEBUG: 62 60 63 60 64 60 65 60 66 60 67 60 68 60 6B 60
[705602.383073] EtherCAT DEBUG: 6C 60 6D 60 6E 60 71 60 72 60 74 60 76 60 77 60
[705670.466102] EtherCAT: Requesting master 0...
[705670.466114] EtherCAT: Successfully requested master 0.
[705670.466230] EtherCAT 0: Domain0: Logical address 0x, 6 byte, 
expected working counter 1.
[705670.466236] EtherCAT 0:   Datagram domain0-0-main: Logical offset 
0x, 6 byte, type LWR.
[705670.466290] EtherCAT 0: Master thread exited.
[705670.466297] EtherCAT 0: Starting EtherCAT-OP thread.
[705670.467927] EtherCAT WARNING 0: 1 datagram TIMED OUT!
[705715.024606] EtherCAT WARNING: Datagram f1fadf0c (domain0-0-main) was 
SKIPPED 1 time.
[705715.464737] EtherCAT WARNING 0: 3 datagrams UNMATCHED!
[705716.183720] EtherCAT WARNING 0-0: Slave did not sync after 5000 ms.
[705716.190654] EtherCAT 0: Domain 0: Working counter changed to 1/1.
[705716.312261] EtherCAT 0: Slave states on main device: OP.
[705716.349656] EtherCAT ERROR 0-0: AL status message 0x001A: Synchronization 
error.
[705716.353660] EtherCAT 0-0: Acknowledged state SAFEOP.
[705716.464063] EtherCAT WARNING 0: 6 datagrams UNMATCHED!
[705717.032627] EtherCAT WARNING: Datagram f1fadf0c (domain0-0-main) was 
SKIPPED 5 times.
[705717.192606] EtherCAT 0: Domain 0: 3 working counter changes - now 0/1.
[705717.464687] EtherCAT WARNING 0: 18 datagrams UNMATCHED!
[705718.036643] EtherCAT WARNING: Datagram f1fadf0c (domain0-0-main) was 
SKIPPED 3 times.
[705719.040649] EtherCAT WARNING: Datagram f1fadf0c (domain0-0-main) was 
SKIPPED 1 time.
[705719.464082] EtherCAT WARNING 0: 3 datagrams UNMATCHED!
[705721.492751] EtherCAT WARNING 0-0: Slave did not sync after 5000 ms.
[705721.499648] EtherCAT 0: Domain 0: Working counter changed to 1/1.
[705722.885394] EtherCAT 0: Domain 0: Working counter changed to 0/1.
[705723.056714] EtherCAT WARNING: Datagram f1fadf0c (domain0-0-main) was 
SKIPPED 1 time.
[705723.464068] EtherCAT WARNING 0: 3 datagrams UNMATCHED!
[705723.888711] EtherCAT 0: Domain 0: Working counter changed to 1/1.
[705726.89] EtherCAT 0: Domain 0: Working counter changed to 0/1.
[705726.901697] EtherCAT ERROR 0-0: AL status message 0x001A: Synchronization 
error.
[705726.904702] EtherCAT 0-0: Acknowledged state SAFEOP.
[705727.072708] EtherCAT WARNING: Datagram f1fadf0c (domain0-0-main) was 
SKIPPED 1 time.
[705727.464031] EtherCAT WARNING 0: 3 datagrams UNMATCHED!
[705727.896710] EtherCAT 0: Domain 0: 2 working counter changes - now 0/1.
[705731.088737] EtherCAT WARNING: Datagram f1fadf0c (domain0-0-main) was 
SKIPPED 1 time.
[705731.464045] EtherCAT WARNING 0: 3 datagrams UNMATCHED!
It seems there are 

Re: [etherlab-users] Enhanced mode for EL5101

[Graeme Foot]

From: etherlab-users [mailto:etherlab-users-boun...@etherlab.org] On Behalf Of 
Roland Pastorino
Sent: Sunday, 11 January 2015 12:31 p.m.
To: etherlab-users@etherlab.org
Subject: [etherlab-users] Enhanced mode for EL5101

Hello everyone,
I have prepared an application using an EK1101 and an EL5101, both from 
Beckhoff.
Everything works as expected.
Now I would like to use the enhanced operating mode of the EL5101 in order to 
get a 32 bit value for the encoder.
Despite many hours of searching and reading I haven't found a single piece of 
information in the Beckhoff manuals that explains how to do that.
Could someone give me a hint on how to enable the enhanced operating mode?
Thanks you.
Best Regards

P.S.: this question has already been asked in 2011 but it has no answer 
(http://lists.etherlab.org/pipermail/etherlab-users/2011/001390.html)

Roland Pastorino

Hi,

I’m using the following pdo entries:

// revision 0x03FF and newer
ec_pdo_entry_info_t EL5101_current_pdoEntries[] = {
  // control (rw)
{0x7010, 0x01, 1},//   enableLatchC
{0x7010, 0x02, 1},//   enableLatchExternP
{0x7010, 0x03, 1},//   setCounter
{0x7010, 0x04, 1},//   enableLatchExternN
{0x, 0x00, 4},//   spacer
{0x, 0x00, 8},//   spacer
{0x7010, 0x11, 32},   // setCounterPos (rw)

  // status (r)
{0x6010, 0x01, 1},//   latchCValid
{0x6010, 0x02, 1},//   latchExternValid
{0x6010, 0x03, 1},//   setCounterDone
{0x6010, 0x04, 1},//   counterUnderflow
{0x6010, 0x05, 1},//   counterOverflow
{0x6010, 0x06, 1},//   statusOfInputStatus
{0x6010, 0x07, 1},//   openCircuit
{0x6010, 0x08, 1},//   extrapolationStall
{0x6010, 0x09, 1},//   statusOfInputA
{0x6010, 0x0A, 1},//   statusOfInputB
{0x6010, 0x0B, 1},//   statusOfInputC
{0x6010, 0x0C, 1},//   statusOfInputGate
{0x6010, 0x0D, 1},//   statusOfExternLatch
{0x6010, 0x0E, 1},//   syncError   // for revision 0x03ff
{0x6010, 0x0F, 1},//   txPDOState  // for revision 0x03ff
{0x6010, 0x10, 1},//   txPDOToggle // for revision 0x03ff
{0x6010, 0x11, 32},   // actual position (r)
{0x6010, 0x12, 32},   // latchPos (r)
};

ec_pdo_info_t EL5101_current_pdos[] = {
{0x1603, 7, EL5101_current_pdoEntries + 0},
{0x1a04, 18, EL5101_current_pdoEntries + 7},
};

ec_sync_info_t EL5101_current_syncs[] = {
{0, EC_DIR_OUTPUT, 0, NULL, EC_WD_DISABLE},
{1, EC_DIR_INPUT, 0, NULL, EC_WD_DISABLE},
{2, EC_DIR_OUTPUT, 1, EL5101_current_pdos + 0, EC_WD_ENABLE},
{3, EC_DIR_INPUT, 1, EL5101_current_pdos + 1, EC_WD_DISABLE},
{0xff}
};


Using 0x1603 and 0x1a04 gives you access to the enhanced 32 bit data.  However, 
I have not figured out how to actually put it into enhanced mode, which is 
required if you want to use the distributed clock.

Also of note, the above pdo configuration is for revision 0x03FF and newer 
modules.  For revision 0x03fe and older modules three of the entries are 
different:

{0x1C32, 0x20, 1},//   syncError // for revision 0x03fe and 
older
{0x1804, 0x07, 1},//   txPDOState// for revision 0x03fe and 
older
{0x1804, 0x09, 1},//   txPDOToggle   // for revision 0x03fe and 
older


Let us know if you figure out how to set up enhanced mode for the distributed 
clocks.


Regards,
Graeme.



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

Re: [etherlab-users] How to change the input and output Map(Yaskawa servopack)?

[Graeme Foot]

 Dear all,
 I got a set yaskawa servopack, it works well with Twincat.Now I am struggling 
 with etherlab master version 1.52.
 First step, I tried ethercat command line, when i change the state from 
 PREOP-SAFEOP-OP, control word 0x6040 always shows 0, can not be changed.
 I do some research from website, I found I got the same issue as follow posts:
 http://lists.etherlab.org/pipermail/etherlab-users/2010/000941.html
 http://thread.gmane.org/gmane.network.etherlab.user/676/focus=683
 http://lists.etherlab.org/pipermail/etherlab-users/2012/001581.html


 As I checked my firmware version is 3.01 is OK.
 I also got reply from yaskawa, the suggested me to change the mapping as 
 follow:
 Original:
 Inputs  mapped to - FMMU0
 Outputs mapped to - FMMU1
 Change - Need to be mapped as:
 Outputs  mapped to - FMMU0
 Inputs mapped to - FMMU1
 I am a newbie in this field, anyone knows how to change this mapping?
 What is more, as Henry Bausley mentioned in above post, his solution is using 
 two domains, input domain and output domain. How to implement it?
 Any ideas?
 Thanks in advance!
 Best regards!
 -chengxi

Hi,

You definitely need to use two domains.  One for the inputs, one for the 
outputs.  In my app I use three.  One for servo inputs, one for servo outputs 
and one for all other modules (that can have inputs and outputs in one domain).

For two domains you need to have two domain pointers:
  ec_domain_t*domRead;
  ec_domain_t*domWrite;

When making the ecrt_slave_config_reg_pdo_entry calls you pass the appropriate 
domain as required.

Then any time you would do something with a domain in your app, just call the 
function multiple times, one for each domain.

Eg:
ecrt_master_receive(master);
ecrt_domain_process(domRead);
ecrt_domain_process(domWrite);
...
ecrt_domain_queue(domRead);
ecrt_domain_queue(domWrite);
ecrt_master_send(master);


if you do a “ethercat slave –v” command, each module has an “Enable notLRW” 
status.  If it is “yes” then the slave needs separate domains for the read and 
write pdo’s.


Hope this gets you started,
Graeme.


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

Re: [etherlab-users] DC sync and arrival times of datagrams

[Graeme Foot]

Which time you use doesn't matter so much as long as it's stable and you get 
minimal jitter.


With RTAI on startup Linux calculates a cpu frequency and calibrates the timer 
against it.  Between cold starts Linux will generally get the same value, but 
if you do a soft restart it will often calculate a different value.  It also 
only calculates to the nearest micro second.  different boxes with the same 
hardware specs may also get different values.  If you need a consistent time 
base then you need to calibrate this value for your hardware and set it 
explicitly on startup.  If you are using RTAI you can do the following 
(allowing you to specify a value to 1 nano second):

MODULE_DIR=`/usr/realtime/bin/rtai-config --module-dir`
insmod ${MODULE_DIR}/rtai_hal.ko rtai_cpufreq_arg=calibrated_value

see: 
https://www.rtai.org/userfiles/documentation/documents/RTAI_User_Manual_34_03.pdf
 or similar

I don't know if other realtime Linux implementations do a similar thing.


But regardless of how well you calibrate your pc clock there will eventually be 
drift between the PC and the EtherCAT modules.  So how does the EtherCAT DC 
system avoid this?

1) assume the PC cycle time is correct and use it as the master time.  
(EtherLabs master default option)

In this case you need to:
- call ecrt_master_application_time() to tell the EtherLabs master what the 
current PC time is
- call ecrt_master_sync_reference_clock() to tell the master DC slave to sync 
to the current PC time
- call ecrt_master_sync_slave_clocks() to tell the remaining DC slaves to sync 
to the master slaves time

This option has a lot of jitter which the EtherCAT slaves often don't like, 
especially if the cycle times are somewhat different.  If you soft reboot and 
haven't calibrated then expect a different cycle time.


2) assume the first EtherCAT DC slave cycle time is correct and use it as the 
master time.  (TwinCAT default option)

In this case you need to:
- call ecrt_master_reference_clock_time() to get the DC slave master time, 
calculate any drift from your PC cycle and adjust your PC cycle to suit
- call ecrt_master_sync_slave_clocks() to tell the remaining DC slaves to sync 
to the master slaves time
- call ecrt_master_application_time () with a psudo time that matches the DC 
slaves time (I generally just use last_time + cycle_time as it's the first 
thing I do on wakeup)


So in summary:
ecrt_master_sync_slave_clocks() is always required to sync the DC slave to the 
master DC slave, then it is up to you whether you want to use option 1 or 2 
above.


Hope this helps,
Graeme.


PS: I use option 2.  I had all sorts of problems with option 1.




From: etherlab-users-boun...@etherlab.org 
[mailto:etherlab-users-boun...@etherlab.org] On Behalf Of Jeroen Proveniers
Sent: Wednesday, 21 May 2014 20:49
Cc: etherlab-users@etherlab.org
Subject: Re: [etherlab-users] DC sync and arrival times of datagrams

Interestingly, the master thinks it sends 5000 datagrams per second, as the 
ethercat master command shows.
I took timestamps using debug level 2, and the scheduling is correct, sometimes 
the delta between datagrams is 203us, but the next delta is 197 then. Average 
is a nice 200us.
It turned out the ACPI_PM timer we use as a timebase is apparently way off, 
about 5% (the slave only receives about 4700 datagrams per second). We changed 
it to HPET (with which we have had issues in the past I heard) and it's 
basically spot on now.

I have to see how we get the master to use actually use slave #0 as reference 
clock (it is set as reference but somehow not used I think).
Cheers,
Jeroen

On Mon, May 19, 2014 at 12:25 PM, Jeroen Van den Keybus 
jeroen.vandenkey...@gmail.commailto:jeroen.vandenkey...@gmail.com wrote:
It looks like the master process isn't scheduling itself properly. To
check, have the master log the timestamps you're using to synchronize
the slaves (whatever you use as argument of
ecrt_master_application_time()). If all is well, you should be sending
timestamps with, on average, EXACTLY the cycle time (what you
programmed to generate SYNC0 in the slaves) as time difference.

Beware of rounding errors when scheduling the master process, as well
as different timebases.


J.

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

Re: [etherlab-users] ecrt_master_deactivate_slaves

[Graeme Foot]

Hi,

I go through a shutdown sequence while continuing my realtime loop with the 
ecrt_master_receive() and ecrt_master_send().

The guts of my main RT thread looks like:

  // main loop
  while (!g_app.shutdown)
  {
// run scan logic
sysMain_scanRT(sysMainData);

// polling hard sleep
sysMain_waitPeriod();
  }

  // shutdown loop
  while (!sysMainData.allModulesStopped)
  {
// run scan logic and shutdown logic
sysMain_scanRT(sysMainData);
sysMain_stopRT(sysMainData);

// polling hard sleep
sysMain_waitPeriod();
  }


So when I want to shut down the second loop is entered which adds the 
sysMain_stopRT() function call.

The sysMain_stopRT() function goes through all my modules telling them to stop. 
 Each module uses a state machine to shut itself down.  When all modules are 
stopped the allModulesStopped flag is set.

For my EtherCAT module it goes through the following states:
- Stop Devices: get all devices to stop what they are doing (eg axes come to a 
controlled stop and set themselves to disabled)
- Wait until all devices are stopped
- Call ecrt_master_deactivate_slaves()
- Wait for (masterState.al_states == 0x02)
- Stopped


So the guts of it is you need to maintain a realtime send/receive loop; call 
ecrt_master_deactivate_slaves() once; then wait for all the slaves to be set to 
PREOP before exiting the RT loop.


Hope this helps,

Graeme.



From: Jun Yuan [mailto:j.y...@rtleaders.com]
Sent: Monday, 13 January 2014 23:38
To: Graeme Foot
Subject: ecrt_master_deactivate_slaves

Hi Graeme,

in your fix 
http://lists.etherlab.org/pipermail/etherlab-users/2013/002162.html, there's a 
new function ecrt_master_deactivate_slaves() that would deactivate the DC 
slaves in time to avoid Sync watchdog error on the slave.
I would like to have this function in my application. My first trial is to put 
the function ecrt_master_deactivate_slaves() after my loop in the realtime 
thread. My realtime thread is like this:
while (running) {
wait_period();
ecrt_master_receive(master);
...
sync_distributed_clocks();
ecrt_master_send(master);
}
ecrt_master_deactivate_slaves(master);
The test failed as sync watchdog error comes out after the master is stopped by 
'running = false'.

Now I realize that ecrt_master_send(master) must be called to sent the 
deactivate messages out to the slaves after the ecrt_master_deactivate_slaves() 
call. But I still don't have a clear idea about how to make things right.
How would you put this function ecrt_master_deactivate_slaves in your 
application?
Regards,
Jun
___
etherlab-users mailing list
etherlab-users@etherlab.org
http://lists.etherlab.org/mailman/listinfo/etherlab-users

Re: [etherlab-users] etherlab dc sync check

[Graeme Foot]

Hi,

It's a while ago now that I looked into it, but I originally had all sorts of 
problems with the dc clock system.  I could never get my yaskawa amps stable 
using the PC clock as the time master.  There is just way too much jitter.  
Instead I wrote the original patch that selects a slave to use as the master 
time for both the rest of slaves and the PC master clock.

As a side note, this is the default method used by TwinCAT.  They call the 
mode: Master time/cycle updated to match ref slave time.

This system in the Etherlab master 1.5.2 is currently broken.  I sent in a 
patch for it a while ago:
http://lists.etherlab.org/pipermail/etherlab-users/2013/002162.html


The second issue is the time it takes to sync a slave.  My memory is a bit 
rusty here and I never had time to fully investigate, but essentially the 
master often seems to calculate an incorrect initial time.  I think I got this 
down to consistently being within +-1ms which takes approx 3 seconds to sync 
(my RT cyctle time is 1ms).

However, the more slaves you have, the longer it takes as the master 
initialises and syncs one slave at a time.


I don't have much time in the next couple of months to help test, but I thought 
I would let you know about the patch above in case you were going to use the 
ref slave as the master time clock.


Regards,
Graeme.


-Original Message-
From: etherlab-users-boun...@etherlab.org 
[mailto:etherlab-users-boun...@etherlab.org] On Behalf Of Jun Yuan
Sent: Saturday, 4 January 2014 03:17
To: Slutsker, Rasty
Cc: etherlab-users@etherlab.org
Subject: Re: [etherlab-users] etherlab dc sync check

Oh, I understand, you're talking about synchronizing the master clock
to the ref slave. This has been implemented in the etherlab master.
You need to use the function ecrt_master_reference_clock_time()
instead of ecrt_master_sync_reference_clock(). An example is given in
example/rtai_rtdm_dc.

Well, I think most of us are still used to sync reference clock to
master. And yes, sync master to ref clock would make the situation a
little bit better, as the ref clock itself doesn't need any adjustment
any more, making the ref clock signal stable for the other slaves. But
since the other slave are still having a bad time offset from the
master to have a same timebase as the ref_clock, they still suffer
from a large diff at the beginning of drift compensation. The problem
is not still there.

I need some volunteers to do a simple experiment for me. You'll just
need a normal master application based on the current etherlabmaster
and a ethercat bus network with at least one slave having DC enabled.
1. running your master application for about 10 minutes. This would be
enough for all the DC sync on the bus get converged. So that all the
DCs are running synchronized. You can check that with ethercat
reg_read -tsm32 0x92c, it should  be something below 1000 ns.
2. turn the debug level of master to 1 using sudo ethercat debug 1.
3. stop the master application and restart it right away, while don't
shut down your slaves. Your slaves should still have a relative good
sync with each other.
4. check you system log, look for the lines like

[ 9766.885265] EtherCAT DEBUG 0-0: DC 64 bit system time offset
calculation: system_time= (corrected with ),
app_time=xxx, diff=
[ 9766.885268] EtherCAT DEBUG 0-0: Setting time offset to xxx
(was xxx) OR: Not touching time offset.
.
[ 9767.292758] EtherCAT DEBUG 0-0: Checking for synchrony.
[ 9767.296758] EtherCAT DEBUG 0-0: Sync after4 ms:xxx ns

send these 4 lines of your system log to me, and tell me the cycle
time of your loop. That's it. Thanks!

On Fri, Jan 3, 2014 at 10:52 AM, Slutsker, Rasty
rasty.sluts...@servotronix.com wrote:
 Master clock is accurate (more or less), but delivery is not, since software 
 is involved.
 I'm just asking why slave(s) shall synchronize to jumpy clock of master? 
 Maybe be it would be more correct, if master could synchronize itself to the 
 first slave and then will run pll adjusting it's clock to the slave's one?
 In that case we can completely eliminate this time-consuming synchronization 
 phase.

 Say,
 a) master sends it's virtual clock to the first slave and that slave becomes 
 a clock master
 b) master re-distributes fist slave's clock to other slaves
 c) master adjust it's clock permanently, relatively to the clock master 
 (first slave)
 d) master periodically re-distributes clock from the first slave to other in 
 order to eliminate time skew in slave.


 
 From: Jun Yuan [j.y...@rtleaders.com]
 Sent: Friday, January 03, 2014 11:10 AM
 To: Slutsker, Rasty
 Cc: Jeroen Van den Keybus; Raz; etherlab-users@etherlab.org
 Subject: Re: [etherlab-users] etherlab dc sync check

 I'm not saying that the clock of the master is inaccurate. I'm saying
 that the master software does a bad job in the calculation of the time
 offset for each slave. It should not use 

Re: [etherlab-users] example code

[Graeme Foot]

Another thing you can look at is the ethercat slaves -v command.

If you have a linear topology then the last slaves DC system time transmission 
delay value tells you how long it takes for a frame to get sent to it, so if 
you double the value you get the approximate round trip time.

If you have a start topology (or various mixtures) then the round trip time 
will be less than double this value.

Then its down to allowing for your realtime jitter and EtherCAT master 
processing overhead etc.

G.


From: etherlab-users-boun...@etherlab.org 
[mailto:etherlab-users-boun...@etherlab.org] On Behalf Of Jeroen Van den Keybus
Sent: Thursday, 21 November 2013 05:34
To: Curt
Cc: etherlab-users@etherlab.org
Subject: Re: [etherlab-users] example code

Using Xenomai and the specific patched drivers, I could easily go beyond 10 kHz 
with an EK1100 and 2 EL2008 on a Core 2 Duo 2.2 Ghz with e1000. I also did 
extensive measurement of delays and came up with about 6.5 us for the IgH 
master and something in the order of 10 us for the NIC from transmit start to 
first symbol on wire and back (last symbol on wire to receive start). So the 
NIC delays are certainly appreciable as well.

Are you running stock Linux (e.g. no RTAI, Xenomai or RT-PREEMPT) ?


J.


2013/11/19 Curt cfi...@cybermetrix.commailto:cfi...@cybermetrix.com
Sorry for the newbie questions.

I've downloaded built and installed the ethercat master 1.5.2.

Used the generic driver to communicated with an Beckhoff EK1101 hub, EL1034
digital input and EL2034 digital output.

I then modified the ./example/user/main.c code to work with these modules.
Seems to work OK.   I then  looped the digital out to a digital in to some
basic performance testing.

At a update rate of 1kHz (1 millisecond), it can detect a change on average of
about 2 ms.I increased the rate to 2kHz,  it can detect a change on
average of 1ms, BUT, I see an occasional, EtherCAT WARNING: Datagram da69fecc
(domain0-0-main) was SKIPPED 1 time.   I don't see this warning at a 1kHz
update rate.

Are these reasonable results, and does this imply that the fastest rate I can
expect without errors/warnings is 1 kHz?

Would I get significantly better results using the Ethercat kernel module for
my chipset?


Thanks,

Curt Fiene
Cybermetrix
___
etherlab-users mailing list
etherlab-users@etherlab.orgmailto:etherlab-users@etherlab.org
http://lists.etherlab.org/mailman/listinfo/etherlab-users

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

[etherlab-users] Looking for Slave firmware update example

[Graeme Foot]

Hi,

I want to update the firmware on an EtherCAT slave (an EL6021 module).  I'm 
using the latest 1.5.2 master.

I take it that I need to use the ethercat foe_write command but I haven't 
been able to find what output-file name I should be using.  Should it be the 
name of the .efw file (or not used so it automatically picks up the name of the 
.efw file)?


Is this general procedure correct? :
- ethercat states -p1 INIT
- ethercat states -p1 BOOT
-- check current state is BOOT
- ethercat foe_write -p1 /tmp/EL6021_FW06.efw
- ethercat states -p1 INIT
- ethercat states -p1 OP
-- repower the slave and check new firmware is active


Thanks,
Graeme Foot

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

Re: [etherlab-users] Looking for Slave firmware update example

[Graeme Foot]

Thanks.

The documentation for this module (from Beckhoff) doesn't mention that a 
filename should be set so I will go with the default .efw filename.

The documentation says to change to OP at the end.  I can't see that it would 
be necessary either.

Graeme.


From: Gavin Lambert [mailto:gav...@compacsort.com]
Sent: Wednesday, 6 November 2013 11:30
To: Graeme Foot; etherlab-users@etherlab.org
Subject: RE: [etherlab-users] Looking for Slave firmware update example

The change to OP seems wrong, but otherwise the procedure below looks about 
right.

One thing to note is that the foe_write command takes two filenames - the other 
you've left unspecified (and so will default to the .efw filename) is the 
internal name sent to the device.  You'll have to check with the vendor whether 
they require a particular name or whether they'll accept any name.  (If there's 
upgrade instructions in the docs, it probably shows how the upgrade is done via 
TwinCAT - you can see what filename is used there, or if it doesn't appear to 
be relevant.)

A quick glance at the docs myself suggests that the device doesn't particularly 
care what filename is used.  But to be sure, you will need to try it.

From: etherlab-users-boun...@etherlab.org 
[mailto:etherlab-users-boun...@etherlab.org] On Behalf Of Graeme Foot
Sent: Wednesday, 6 November 2013 11:17
To: etherlab-users@etherlab.org
Subject: [etherlab-users] Looking for Slave firmware update example

Hi,

I want to update the firmware on an EtherCAT slave (an EL6021 module).  I'm 
using the latest 1.5.2 master.

I take it that I need to use the ethercat foe_write command but I haven't 
been able to find what output-file name I should be using.  Should it be the 
name of the .efw file (or not used so it automatically picks up the name of the 
.efw file)?


Is this general procedure correct? :
- ethercat states -p1 INIT
- ethercat states -p1 BOOT
-- check current state is BOOT
- ethercat foe_write -p1 /tmp/EL6021_FW06.efw
- ethercat states -p1 INIT
- ethercat states -p1 OP
-- repower the slave and check new firmware is active


Thanks,
Graeme Foot

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

[etherlab-users] FW: CX2100 Power Supply Unit, LCD control

[Graeme Foot]

Hi,

I'm using Beckhoff CX20x0 computers for our control system with CX2100-0004 
power supply units.  The PSU also has an LCD display and navigation buttons.

I've written a user space utility that gives you access to the LCD, nav buttons 
and other PSU information (attached).  I based the utility on the i2c Tools 
for Linux which provides user space access to the i2c devices.  The same 
concepts can be used to create a kernel space module as the i2c-dev.h header 
uses the same function prototypes as the kernel space calls.

This information is available via the SMBus which for these PCs is an Intel 
QM67 which has a Series 6/C200 SMBus Controller.  I'm using Linux 2.6.32.11 
which doesn't support this chipset, so I've also attached a patch to enable it 
for this kernel.


Regards,

Graeme Foot,
Kinetic Engineering Design Ltd.


cx2100psu.tar.bz2
Description: cx2100psu.tar.bz2


linux-2.6.32.11-a_i2c.patch
Description: linux-2.6.32.11-a_i2c.patch
___
etherlab-users mailing list
etherlab-users@etherlab.org
http://lists.etherlab.org/mailman/listinfo/etherlab-users

Re: [etherlab-users] How to install and use Etherlab for a Xenomaitarget

[Graeme Foot]

Hi,

 

We are using a Beckhoff CX2020 computer.  We are running it as a non-gui
controller with:

 

Linux 2.6.32.11

RTAI 3.8.1

EtherLabs 1.5.2

 

The CX2020 has two e1000e NICs for the office network.  The EtherCAT NIC
is part of the CX2100-0004 power module but this is specialised hardware
and we needed to write our own driver for it (submitted to the etherlab
forum a while ago).

 

We are building our Linux environment using Buildroot so that it is very
small.

 

 

Linux 2.6.32 does not support the graphics card for this PC but we are
running it headless so not a problem for us.  In the future we are
intending to integrate our gui onto the same PC but we are waiting on
RTAI and a few other things to come together first.

 

 

Regards,

 

Graeme Foot

 



From: Steffen Dalgard [mailto:steffen.s...@gmail.com] 
Sent: Thursday, 20 June 2013 00:42
To: Graeme Foot
Subject: Re: [etherlab-users] How to install and use Etherlab for a
Xenomaitarget

 

Hi,

Thank you for your feedback,

We have tried to find a release supporting newer HW that has support for
Ehterlab, Ubuntu and Xenomai.

It seems to be hard ot find, maybe a dead end.

  We found working Xenomai using Ubuntu 12.04 with a patched 3.5 kernel,
but it is not supported by Etherlab

 

We do need a kernel with RT support but not necessarily Xenomai...

 

You wrote that you were using Etherlab master via RTDM, but using RTAI.

Can you share which releases / kernels that you are using?

 

Best regards

Steffen Dalgard

SINTEF ICT

Norway

 

On Thu, May 16, 2013 at 1:11 AM, Graeme Foot grae...@touchcut.com
wrote:

Boxbe https://www.boxbe.com/overview Graeme Foot
(grae...@touchcut.com) is not on your Guest List
https://www.boxbe.com/approved-list?tc_serial=14152444570tc_rand=26641
7122utm_source=stfutm_medium=emailutm_campaign=ANNO_MWTPutm_content=
001token=Hjk5w06MCHsim%2BkE%2BXEMZbTtwqA%2BTXXMJ7spABspVmqlfWvM7lNh80hl
UB%2F00a8Mkey=eJnd8Q%2BeCThkw7PVpCigMAaxHAX%2BsHy%2FiQ0MxxEI0Ik%3D  |
Approve sender
https://www.boxbe.com/anno?tc_serial=14152444570tc_rand=266417122utm_
source=stfutm_medium=emailutm_campaign=ANNO_MWTPutm_content=001token
=Hjk5w06MCHsim%2BkE%2BXEMZbTtwqA%2BTXXMJ7spABspVmqlfWvM7lNh80hlUB%2F00a8
Mkey=eJnd8Q%2BeCThkw7PVpCigMAaxHAX%2BsHy%2FiQ0MxxEI0Ik%3D  | Approve
domain
https://www.boxbe.com/anno?tc_serial=14152444570tc_rand=266417122utm_
source=stfutm_medium=emailutm_campaign=ANNO_MWTPutm_content=001domt
oken=Hjk5w06MCHsim%2BkE%2BXEMZbTtwqA%2BTXXMJ7spABspVmqlfWvM7lNh80hlUB%2F
00a8Mkey=eJnd8Q%2BeCThkw7PVpCigMAaxHAX%2BsHy%2FiQ0MxxEI0Ik%3D  

 

Hi,

 

I have a user space application connecting to the Etherlab master via
RTDM, but using RTAI.  In theory xenomai should be pretty similar.

 

If you are using the latest 1.5.2 Etherlab master you won't need a
patch.  The patch was to give partial RTDM support before it was fully
supported.

 

 

To get RTDM working you will need to specify the correct flags when
compiling the master:

  --with-xenomai-dir=xenomai directory

  --enable-rtdm

 

All going well you should get a library: /usr/lib/libethercat_rtdm.so

 

When compiling your application link to the library using:
-lethercat_rtdm

 

 

With RTAI you can check your application is using RTDM by calling 'cat
/proc/rtai/scheduler'.  The syscalls value should remain zero.

 

 

Regards,

Graeme Foot.

 



From: etherlab-users-boun...@etherlab.org
[mailto:etherlab-users-boun...@etherlab.org] On Behalf Of Steffen
Dalgard
Sent: Wednesday, 15 May 2013 21:50
To: etherlab-users@etherlab.org
Subject: [etherlab-users] How to install and use Etherlab for a
Xenomaitarget

 

Hi,

We are trying to install Etherlab on a Xenomai target together with ROS
and OROCOS.

The plan is to have a user space rt-application calling the Igh master.

 

Does it exist a procedure for how to get this working?

 

I have tried to read through the mail archive and the examples, but have
only found piecewise information.

   I have found mails mentioning patching of driver connecting Etherlab
master to user space

   It seems to be special lib libetherkat_rtdm.so

 

Hope someone can help :-)

 

Best regards

Steffen Dalgard

SINTEF ICT

Norway

 

 

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

[etherlab-users] Fix for ecrt_master_select_reference_clock

[Graeme Foot]

Hi,

 

I just noticed that ecrt_master_select_reference_clock hasn't been
working.

 

On startup the master auto selects the first DC slave in
ecrt_master_select_reference_clock.

 

Problem 1:

Calling ecrt_master_select_reference_clock selects the slave config to
use, but does not activate it immediately.
ecrt_master_select_reference_clock is only called if the bus is
rescanned, at which point problem 2 happens.

 

Problem 2:

ecrt_master_select_reference_clock is called before slaves are attached
to the slave configs so trying to set up dc_ref_config fails and then no
slave is set up as the dc_ref_clock.

 

 

I have attached a patch that corrects the above problems.  The patch
also contains a few other things I change so I've added a description of
my changes for this problem below.

 

 

master/master.c

 

ec_master_find_dc_ref_clock

- If using dc_ref_config fails then all slaves are scanned for the first
slave to support DC

 

ecrt_master_select_reference_clock

- Calls ec_master_find_dc_ref_clock

- I have removed the dc capabilities check as these are in
ec_master_find_dc_ref_clock anyway

 

master/fsm_master.c

 

ec_fsm_master_state_scan_slave

- I have moved ec_master_calc_dc after ec_master_attach_slave_configs

 

 

Regards,

Graeme Foot.



etherlabmaster-1.5.2-2526-c_dc_helpers.patch
Description: etherlabmaster-1.5.2-2526-c_dc_helpers.patch
___
etherlab-users mailing list
etherlab-users@etherlab.org
http://lists.etherlab.org/mailman/listinfo/etherlab-users

[etherlab-users] RTDM with RTAI

[Graeme Foot]

Hi,

 

I've just been updating my project to use the latest EtherCAT 1.5.2
master (2526), using RTDM with RTAI.

 

The ethercat_rtdm library calls fprintf to log various errors that may
occur.  This knocks the hard realtime thread back to soft realtime due
to making a standard syscall.  I have created a patch that will use
rt_printk instead if RTDM is active (attached).

 

 

It does the following, in ioctl.h: 

 

#ifdef EC_RTDM

#define   KERN_ERR  3

#define EC_PRINT_ERR(fmt, args...) \

printk(KERN_ERR EtherCAT ERROR:  fmt, ##args) 

#else

#define EC_PRINT_ERR(fmt, args...) \

fprintf(stderr, fmt, ##args) 

#endif

 

 

and then changes the fprintf's, eg: from:

fprintf(stderr, Failed to get reference clock time: %s\n,

strerror(EC_IOCTL_ERRNO(ret)));

 

to:

EC_PRINT_ERR(Failed to get reference clock time: %s\n,

strerror(EC_IOCTL_ERRNO(ret)));

 

 

I see there is a TODO item to replace the fprintf calls with return
codes, but you may want to do this in the meantime (or both).

 

 

Regards,

Graeme.



etherlabmaster-1.5.2-2526-aa_lib_fprintf.patch
Description: etherlabmaster-1.5.2-2526-aa_lib_fprintf.patch
___
etherlab-users mailing list
etherlab-users@etherlab.org
http://lists.etherlab.org/mailman/listinfo/etherlab-users

[etherlab-users] Linux device driver for Beckhoff CX2100-0004 power module

[Graeme Foot]

Hi,

 

We've just got ourselves a Beckhoff CX2020 computer with a CX2100-0004
power module to play with.  The power module requires a PCI device
driver to access the network port (and LCD screen and nav buttons).

 

Has anyone had a go at a device driver for one of these modules yet?

 

 

Regards,

Graeme.

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

Re: [etherlab-users] Yaskawa Ethercat via Etherlab

[Graeme Foot]

From: Alwin Damman - LR [mailto:a.dam...@tudelft.nl] 
Sent: Thursday, 21 June 2012 00:55
To: Graeme Foot
Subject: Yaskawa Ethercat via Etherlab

 

Dear mister Graeme Foot,

 

First I will introduce myself, I am an engineer working at the
university of Delft Technologies and working on a control loading system
for some rudder pedals in our fixed simulator.

 

We have also chosen for a Yaskawa drive plus ethercat communication via
Etherlab from IgH. Well at this moment I get stocked at some points.

 

Some weeks ago, I was not able to communicate via pdos and only via
sdos. The reason was the older ethercat controller version of Yaskawa,
it was version 1.0. After sending and return, it is already upgraded to
version 3.05. But now I am not able to let the motor run via sdos or
pdos communication.

 

At the internetforum:
http://lists.etherlab.org/pipermail/etherlab-users/2012/001627.html

I found you with the most hits about the Yaskawa drive and I thought it
could be a good idea to contact you about the setting you have made to
let the system running.

 

Do you have a testfile (cstruct file) for the etherlab software to test
the drive? And would you like to borrow this file with other users like
me?

 

Yours faithfully,

Alwin Damman

 

A. (Alwin) Damman

Phone +31 - 15 - 278 7936 
Fax + 31 - 15 - 278 6480  
Email: a.dam...@tudelft.nl mailto:a.dam...@tudelft.nl 

Visiting Address:

International Research Institute SIMONA 
Room location SIM 1.01 
Anthony Fokkerweg 1 
2629 HC Delft 
The Netherlands 

Postal Address:

Delft University of technology 
Faculty of Aerospace Engineering 
Kluyverweg 1 
2629 HS Delft
The Netherlands

http://www.cs.lr.tudelft.nl http://www.cs.lr.tudelft.nl 

http://www.lr.tudelft.nl

 

===

 

Hi,

 

I'm using Cyclic position mode with the drives.

 

I don't have a small test file or anything that would be easy to read,
so I'll try to summarise it below:

 

My PDO setup is as follows:

 

// Object dictionary on page 8-2 of EtherCAT users manual

 

ec_pdo_entry_info_t yaskawaSGDV_pdoEntries[] = {

{0x6040, 0x00, 16},   // pg 8-21  control (rw)

{0x607a, 0x00, 32},   // pg 8-30  target position (rw) (for cyclic
sync pos mode)

{0x60b1, 0x00, 32},   // pg 8-37  velocity offset (rw) (for cyclic
sync pos mode)

{0x6072, 0x00, 16},   // pg 8-40  max torque (rw) in 0.1%
increments, what is +ve torque lim and - torque lim? pdo or sdo??

{0x60fe, 0x01, 32},   // pg 8-44  outputs (rw) (bits 17, 18, 19
control outputs 1, 2, 3)

{0x60b8, 0x00, 16},   // pg 8-41  latchControl (rw) (bits: 0 enable
latch, 1 single/continuous trigger,

  // 2 0=latch on
S14 | 1=latch on C, 4 enable latch sampling???)

{0x6060, 0x00, 8},// pg 8-28  mode of operation (rw) (8=cyclic
pos, 9=cyclic vel)

 

{0x6041, 0x00, 16},   // pg 8-23  status (r)

{0x6064, 0x00, 32},   // pg 8-34  actual position (r)

{0x606c, 0x00, 32},   // pg 8-38  actual velocity (r) required??

{0x6077, 0x00, 16},   // pg 8-39  actual torque (r)

{0x60f4, 0x00, 32},   // pg 8-35  actual following error (r)

{0x60fd, 0x00, 32},   // pg 8-43  inputs (r) (available inputs: 0
(rev lim), 1 (fwd lim), 2 (hm), 

  //  16 - 22 (via CN1), 25
- 25 (via base block))

{0x60ba, 0x00, 32},   // pg 8-42  latchPos (r) (via touch probe 1)

{0x60b9, 0x00, 16},   // pg 8-42  latchStatus (r) (bits: 0 latch
enabled, 1 latched, 7 latched toggle (for continuous mode))

{0x6061, 0x00, 8},// pg 8-28  current mode of operation

{0x603f, 0x00, 16},   // pg 8-21  last error code

};

 

ec_pdo_info_t yaskawaSGDV_pdos[] = {

{0x1600, 7, yaskawaSGDV_pdoEntries + 0},

{0x1a00, 8, yaskawaSGDV_pdoEntries + 7},

{0x1a01, 2, yaskawaSGDV_pdoEntries + 15},

};

 

ec_sync_info_t yaskawaSGDV_syncs[] = {

{0, EC_DIR_OUTPUT, 0, NULL, EC_WD_DISABLE},

{1, EC_DIR_INPUT, 0, NULL, EC_WD_DISABLE},

{2, EC_DIR_OUTPUT, 1, yaskawaSGDV_pdos + 0, EC_WD_ENABLE},

{3, EC_DIR_INPUT, 2, yaskawaSGDV_pdos + 1, EC_WD_DISABLE},

{0xff}

};

 

 

To configure the drive I call:

 

slaveConfig = ecrt_master_slave_config(master, alias, position,
vendorID, productCode);

ecrt_slave_config_pdos(slaveConfig, EC_END, yaskawaSGDV_syncs);

 

Then for each pdo entry:

 

offset = ecrt_slave_config_reg_pdo_entry(slaveConfig,
yaskawaSGDV_pdoEntries[pdoIdx].index,
yaskawaSGDV_pdoEntries[pdoIdx].subindex, domains[domIdx].domain,
bitPos);  

 

Important Note: you need two separate domains.  One for the read pdo's
and one for the write pdo's.  I also have a third domain for all other
modules pdo's to ensure the yaskawa domains remain separate 

 

 

I think that's it.

 

 

Regards,

Graeme.

 

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

Re: [etherlab-users] Detecting whether an amp has repowered

[Graeme Foot]

Hi,

 

I forgot to mention that I'm not using the builtin homing functionality of the 
drive.  I have found it too restrictive.

 

However, it was the homing parameters that I was thinking of using as my own 
status indicator since they are not otherwise being used.

 

Thanks,

Graeme.

 

 

 



From: Oguz Dilmac [mailto:oguzdil...@bilko-automation.com] 
Sent: Monday, 28 May 2012 21:47
To: etherlab-users@etherlab.org
Cc: Graeme Foot
Subject: Re: [etherlab-users] Detecting whether an amp has repowered

 

Hi Graeme,

About homing status:
At init sequence, I check the status word. In Schneider Lexium series, bit15 
indicates wether Homing is done or not. 
If Yaskawa don't use such a bit, may be reading back the Home Offset (0x607C) 
or Homing Method (0x6098) may suggest you if you already done homing or not.

Best regards,
Oguz.



 

 


26.05.2012 08:54 tarihinde, Graeme Foot yazdı: 

Hi,

 

I would like to detect whether my Yaskawa SGDV amps have been repowered (as 
opposed to just a loss of communication).  Is there any way to nicely do so?

 

The amps have 32bit DC clocks so I can't tell based on the clock time.

What I was thinking I could do was:

- Set a unused value to a random number on startup (via an sdo)

- Read the value via a pdo

If communications are up but the pdo based value does not match the random 
number then the amp has been repowered.  (Needs to be a random number incase 
the amp settings get saved).

 

The reason I would like to do this is that our amps/motors have incremental 
encoders so if power is lost the axis position gets reset to zero.  However 
subsequent axes in the EtherCAT chain also loose communications, but not their 
positions.  Rather than having to rehome the entire machine if there is a loss 
of comms to the amps I would only like to rehome the repowered ones.

 

This situation is particularly relevant when commissioning the machine where 
changing certain configuration parameters requires the amps to be repowered.  
It is also relevant where we have some remote axes which may either loose comms 
or power and I need to know which case it is.

 

 

Also, to really quickly detect that an amp has lost comms I'm reading the amps 
error code value via a pdo.  If the amp misses a frame the read values do not 
get written by the amp.  So just before I queue and send the amps domain 
information I set each amps errorcode in the domain data to a value of 0x.  
Once I receive the response if the value is still 0x then the amp has had a 
comms error.

 

Is this a good way to do it, or is there a better way?

 

 

Regards,

Graeme.






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

Re: [etherlab-users] Getting Emergency messages from EtherCAT Master

[Graeme Foot]

Hi,

Sorry, no I don't.  I've only had time to explore the bits relevant to
the project I'm working on at the moment.


But having a quick look at the master code (in master/fsm_coe.c) :

ec_fsm_coe_check_emergency() is used to process an emergency mailbox
message.  It will output emergency message information as a warning to
the system log.


If you need the emergency information in your app you could possibly
create a patch that stores the last error and have a function you can
call to ask for / reset it.



Regards,
Graeme.


-Original Message-
From: Bilko AS, Oguz Dilmac [mailto:odil...@bilko-automation.com] 
Sent: Tuesday, 29 May 2012 02:14
To: Graeme Foot
Subject: Getting Emergency messages from EtherCAT Master

Hello Graeme,

Thank you for your mails to the Ether-lab user list. They are very 
helpful to me.

Do you know how to get emergency messages from EtherCAT master?
I asked this to the Ether-lab user list a while ago. But no answer yet.

Best regards,
Oguz.

-- 
Oguz Dilmac
ARGE Bolumu

Bilko AS, RD Department

Perpa Ticaret Merkezi B Blok Kat 13 Nr. 2568
TR-34384 Okmeydani Istanbul Turkey
Tel : +90 212 220 07 40  Fax :   +90 212 210 47 01
e-mail : odil...@bilko-automation.com
web site : http://www.bilko-automation.com


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

Re: [etherlab-users] Copley Drive w/ Distributed Clocks Drifting

[Graeme Foot]

Hi,

Just try:
  time += 25
You will get jitter, but will avoid the drift.

Or better yet you can record your GetNsecHWClock() times over time and 
calculate a drift factor so you can do something like:
  time += HWClock - HWClockOld - drift

Relooking at your code below, after the time increment I'd also do:
  HWClockOld = HWClock
Rather than:
  HWClockOld = GetNsecHWClock()
Otherwise you are introducing an extra drift due to the (small) time difference 
between the two GetNsecHWClock() calls.


Graeme.

-Original Message-
From: Henry Bausley [mailto:hbaus...@deltatau.com] 
Sent: Saturday, 28 April 2012 10:01 a.m.
To: Graeme Foot
Cc: etherlab-users@etherlab.org
Subject: RE: [etherlab-users] Copley Drive w/ Distributed Clocks Drifting

Thanks Graeme.  

   I am actually reading my CPUs clock which runs at 1GHz with some
assembler instruction.   However the H/W card of the custom ASIC
generating the interrupt runs off its own clock!!!  
  So it looks as if you pointed out there will be drift between when the delta 
time of my ISR occurrence and the cpu based delta time I am sending to 
ecrt_master_application_time.  If the ASIC had a clock register to read I think 
I would be in business but of course it doesn't.
   I think you have found the flaw.

On Fri, 2012-04-27 at 10:02 +1200, Graeme Foot wrote:
 Hi,
 
 Just a couple of thoughts.
 
 Does GetNsecHWClock read the time from your servo card?  Does the time 
 increment by 25ns every period (ignoring jitter)?  Ie is your 
 clock time drifting with respect to the ISR?
 
 
 I would try moving the get time and ecrt_master_application_time call 
 to just before the ecrt_master_send call.
 
 The reason for this is that ecrt_master_application_time caches the 
 time value and then ecrt_master_send will send the time datagram 
 without making any adjustments to the time value.  So if theres any 
 variance in processing time between ecrt_master_application_time and 
 ecrt_master_send you will be creating a jitter in the time the slave 
 is reading.  (There is already enough jitter just with 
 ecrt_master_send.)
 
 eg:
 
 void PhaseISR()
 {
   static time
 
   ecrt_master_receive
   EC_READs
 
   ServoLoopCalcs()
 
   EC_WRITEs
   Ecrt_domain_queue
 
   HWClock = GetNanosecHWClock()
   if(init_time)
   {
 clockgettime(time)
 init_time = 0
   }
   else
   {
 time += HWClock  - HWClockOld
   }
   HWClockOld = GetNsecHWClock()
   Ecrt_master_application_time(time)
   Ecrt_master_sync_reference_clock
   Ecrt_master_sync_slave_clocks(pshm-ECAT[idxMaster].Master)
 
   Ecrt_master_send
 }
 
 
 What type of slave is being used as the slave reference clock?  I have 
 a Beckhoff CX1020 with a built in coupler (CX1100-0004) with a 32bit dc.
 I found that if this was the reference slave my yaskawa amps did not 
 like syncing to it.  I changed my reference slave to an EK1100 coupler 
 (64bit dc) and things are much more stable.
 
 
 I don't know if this will make any difference but try reversing 
 ecrt_master_sync_reference_clock and ecrt_master_sync_slave_clocks.
 This may (or may not) let the reference slave propagate a more stable 
 time to the rest of the slaves before receiving the updated time from 
 the master.
 
 
 Regards,
 Graeme.
 
 -Original Message-
 From: etherlab-users-boun...@etherlab.org
 [mailto:etherlab-users-boun...@etherlab.org] On Behalf Of Henry 
 Bausley
 Sent: Wednesday, 25 April 2012 09:46
 To: etherlab-users@etherlab.org
 Subject: [etherlab-users] Copley Drive w/ Distributed Clocks Drifting
 
 
 I am working with Copley attempting to use Cyclic Synchronous Torque 
 Mode at 250usec. We have setup up the distributed clocks w/ 
 Sync0_Cycle as 25 and assign activate at 0x330.
 
 What is being seen on the scope is the time at which an EtherCAT frame 
 arrives eventually drifts into when the Sync0 signal occurs on the 
 slave.  When this occurs the motor glitches since the drive cannot 
 accept our torque command and provide feedback at this time.
 
 The engineers at Copley were gracious enough to create a pair of 
 outputs so we could monitor something on the scope. Take a look at the 
 video clip it displays this better than I can explain it.
 
 The lower signal rising edge occurs at SYNC0 time.  The upper signal 
 is high while receiving an EtherCAT frame.
 
 ftp://support.deltatau.com/DT-USA/Henry/CopleyEtherLAB.mp4
 
 
 When we monitor the register 0x92C with watch -n0 ethercat reg read 
 -p0 -tsm32 0x92c
 we see +/- 2000
 
 Our code is virtually identical to the provided examples except it 
 operates in an ISR triggered by a custom servo card.
 
 void PhaseISR()
 {
   static time
 
   ecrt_master_receive
   EC_READs
 
   ServoLoopCalcs()
 
   HWClock = GetNanosecHWClock()
   if(init_time)
   {
 clockgettime(time)
 init_time = 0
   }
   else
   {
 time += HWClock  - HWClockOld
   }
   HWClockOld = GetNsecHWClock()
   Ecrt_master_application_time(time)
 
   Ecrt_master_sync_reference_clock

Re: [etherlab-users] Copley Drive w/ Distributed Clocks Drifting

[Graeme Foot]

Hi,

Just a couple of thoughts.

Does GetNsecHWClock read the time from your servo card?  Does the time
increment by 25ns every period (ignoring jitter)?  Ie is your clock
time drifting with respect to the ISR?


I would try moving the get time and ecrt_master_application_time call to
just before the ecrt_master_send call.

The reason for this is that ecrt_master_application_time caches the time
value and then ecrt_master_send will send the time datagram without
making any adjustments to the time value.  So if theres any variance in
processing time between ecrt_master_application_time and
ecrt_master_send you will be creating a jitter in the time the slave is
reading.  (There is already enough jitter just with ecrt_master_send.)

eg:

void PhaseISR()
{
  static time

  ecrt_master_receive
  EC_READs

  ServoLoopCalcs()

  EC_WRITEs
  Ecrt_domain_queue

  HWClock = GetNanosecHWClock()
  if(init_time)
  {
clockgettime(time)
init_time = 0
  }
  else
  {
time += HWClock  - HWClockOld
  }
  HWClockOld = GetNsecHWClock()
  Ecrt_master_application_time(time)
  Ecrt_master_sync_reference_clock
  Ecrt_master_sync_slave_clocks(pshm-ECAT[idxMaster].Master)

  Ecrt_master_send
}


What type of slave is being used as the slave reference clock?  I have a
Beckhoff CX1020 with a built in coupler (CX1100-0004) with a 32bit dc.
I found that if this was the reference slave my yaskawa amps did not
like syncing to it.  I changed my reference slave to an EK1100 coupler
(64bit dc) and things are much more stable.


I don't know if this will make any difference but try reversing
ecrt_master_sync_reference_clock and ecrt_master_sync_slave_clocks.
This may (or may not) let the reference slave propagate a more stable
time to the rest of the slaves before receiving the updated time from
the master.


Regards,
Graeme.

-Original Message-
From: etherlab-users-boun...@etherlab.org
[mailto:etherlab-users-boun...@etherlab.org] On Behalf Of Henry Bausley
Sent: Wednesday, 25 April 2012 09:46
To: etherlab-users@etherlab.org
Subject: [etherlab-users] Copley Drive w/ Distributed Clocks Drifting


I am working with Copley attempting to use Cyclic Synchronous Torque
Mode at 250usec. We have setup up the distributed clocks w/ Sync0_Cycle
as 25 and assign activate at 0x330.

What is being seen on the scope is the time at which an EtherCAT frame
arrives eventually drifts into when the Sync0 signal occurs on the
slave.  When this occurs the motor glitches since the drive cannot
accept our torque command and provide feedback at this time.

The engineers at Copley were gracious enough to create a pair of outputs
so we could monitor something on the scope. Take a look at the video
clip it displays this better than I can explain it.

The lower signal rising edge occurs at SYNC0 time.  The upper signal is 
high while receiving an EtherCAT frame.

ftp://support.deltatau.com/DT-USA/Henry/CopleyEtherLAB.mp4


When we monitor the register 0x92C with
watch -n0 ethercat reg read -p0 -tsm32 0x92c
we see +/- 2000

Our code is virtually identical to the provided examples except it
operates in an ISR triggered by a custom servo card.

void PhaseISR()
{
  static time

  ecrt_master_receive
  EC_READs

  ServoLoopCalcs()

  HWClock = GetNanosecHWClock()
  if(init_time)
  {
clockgettime(time)
init_time = 0
  }
  else
  {
time += HWClock  - HWClockOld
  }
  HWClockOld = GetNsecHWClock()
  Ecrt_master_application_time(time)

  Ecrt_master_sync_reference_clock
  Ecrt_master_sync_slave_clocks(pshm-ECAT[idxMaster].Master)
  EC_WRITEs
  Ecrt_domain_queue
  Ecrt_master_send
}

My ISR has ~10usec of jitter.  I am using RTL8168B PCIe cards with a
PowerPC AMCC460EX 1Ghz CPU.  

I don't have the setup in my hands but will be receiving it in a few
days.

Any ideas would be greatly appreciated!





Outbound scan for Spam or Virus by Barracuda at Delta Tau

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

Re: [etherlab-users] Failed to calculate bus topology

[Graeme Foot]

Hi,

 

Get rid of the EL9010 terminator and use an EL9011 instead.  The EL9011
is cheaper and as far as I can tell the EL9010 is no longer listed.

 

In the meantime, just leave it off.  The EtherCAT terminals do not
require a terminator.  The EL9011 is just a cover to provide protection
for the exposed connectors.

 

 

The EL9010 opens the port of the terminal it is connected to, but it is
not actually a slave.  When the master is trying to calculate the
topology it iterates through the slaves looking for open ports and
assumes that if a port is open there is a slave connected to it.
Because there is no slave to communicate with when one is expected then
the iteration fails and the error is raised.

 

Important, if the topology can not be calculated then calculating the
propagation delays may also fail.  Valid propagation delays are required
for distributed clocks to be correct.

 

Regards,

Graeme.

 



From: etherlab-users-boun...@etherlab.org
[mailto:etherlab-users-boun...@etherlab.org] On Behalf Of Steven
Hartmann
Sent: Thursday, 22 March 2012 10:08
To: etherlab-users@etherlab.org
Subject: [etherlab-users] Failed to calculate bus topology

 

Hi all,

I'm just getting started with the etherlab master stack, and really
ethercat in general, so please excuse my ignorance.  So far I have read
the documentation I have found (ethercat-1.5-***.pdf) as well was the
readme and install files, then I followed the directions to get the
driver installed.  I also cobbled together some beckhoff ethercat
modules including an EK1101, 3 EL2024s, and an EL2612 as well as an
EL9010 terminator.  I got everything startup up and an able to use the
command line tool to do a few queries to find that it sees all the
slices properly and can change the operational state.  One thing is
bothering me so far:  when I first plug in the ethercat modules I get
the following output in dmesg:

EtherCAT 0: Link state changed to UP.
EtherCAT 0: 6 slave(s) responding.
EtherCAT 0: Slave states: INIT.
EtherCAT 0: Scanning bus.
EtherCAT 0: Bus scanning completed in 440 ms.
EtherCAT ERROR 0: Failed to calculate bus topology.
EtherCAT 0: Slave states: PREOP.

I don't understand what the Failed to calculate but topology message
means, nor what I need to do to avoid it.  Any help would be
appreciated.

Thanks,

Steve

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

Re: [etherlab-users] FW: Distributed Clock with Yaskawa SGDV drives

[Graeme Foot]

Hi,

Ok, ignore what I said earlier.  I was misdiagnosing the problem.


This is what was going on (sorry if it's a bit long):


I'm using RTAI but I was not calibrating my cpu-frequency.  By default Linux 
only calibrates the cpu-freq to the PIT timer to an accuracy of 500 parts per 
million.  So each time I rebooted I could get quite varied cpu-freq values.

When they were outside a good operating range I would often get:
  EtherCAT WARNING 0-9: Slave did not sync after 5001 ms.

And sometimes get:
  EtherCAT DEBUG 0-9: OP - SAFEOP + ERROR.
  EtherCAT ERROR 0-9: AL status message 0x001A: Synchronization error.

The drive would then report an error code of 0x0A12 (sync error).

When I changed my code to start cycling the pdo information and the dc 
information before calling ecrt_master_activate() the problem pretty much went 
away.  But I would often still get the odd sync error at some later stage.


Now after calibrating my cpu-freq value, doing a lot of other stuff and 
generally gathering more knowledge I see the original diagnosis was wrong.  All 
that was happening was that the drives could not stay synced if the masters 
time cycle was too fast or too slow.  Starting to cycle the dc information 
sooner seemed to help them stabilise better on startup but they would still 
sometimes loose sync at a later stage anyway.

(Note: I'm setting my calibrated cpu-freq by using the rtai_cpufreq_arg when 
calling insmod on rtai_hal.ko.)



However, I also had a problem when deactivating the master.  When calling 
ecrt_master_deactivate() the pdo data can no longer be sent (as the pdo memory 
is destroyed).

This would lead to the following errors:
  EtherCAT ERROR 0-7: AL status message 0x001B: Sync manager watchdog.
  EtherCAT 0-7: Acknowledged state SAFEOP.
  EtherCAT ERROR 0-8: AL status message 0x001B: Sync manager watchdog.
  EtherCAT 0-8: Acknowledged state SAFEOP.
  EtherCAT ERROR 0-9: AL status message 0x001A: Synchronization error.
  EtherCAT 0-9: Acknowledged state SAFEOP.
  EtherCAT ERROR 0-10: AL status message 0x001A: Synchronization error.
  EtherCAT 0-10: Acknowledged state SAFEOP.

(Slaves 0-7 and 0-8 are an analog input and output, slaves 0-9 and 0-10 are the 
Yaskawa drives.)

This is due to slaves still being in OP mode for a little bit after the 
deactivate call.  To solve this I have added a new function called 
ecrt_master_deactivate_slaves() (and ecrt_rtdm_master_deactivate_slaves()).

This lets me deactivate the slaves while still sending pdo information.  I wait 
until all the slaves are in PREOP mode (masterState.al_states == 0x02) before I 
stop my hard realtime cycle and call ecrt_master_deactivate().



And last of all there is another problem that I encountered which also helped 
throw me off:

If I use my Beckhoff CX1100-0004 coupler (32bit distributed clock, built into 
the CX1020 PC) as the dc reference slave, the Yaskawa SGDV System Time Diff 
(0x092C:0x092F) is only semi stable and dances around 600 - 800 ns (approx).

When I use the Beckhoff EK1100 coupler (64bit dc) or one of the Yaskawa SGDV 
amps (32bit dc) as the reference slave, the Yaskawa SGDV System Time Diff 
(0x092C:0x092F) is nice and stable at around +-20 ns.

The Yaskawa SGDV also does not provide the Speed Counter Diff (0x0932:0x0933) 
register.


Does anyone else use the Beckhoff CX1100-0004 coupler and have seen similar 
problems?



As part of all this I've made a little patch for the DC clock code, some of 
which you may be interested in.  I'll put this in a separate email.


Regards,
Graeme.



-Original Message-
From: Graeme Foot 
Sent: Tuesday, 13 March 2012 10:52
To: 'Florian Pose'
Cc: etherlab-users@etherlab.org
Subject: RE: [etherlab-users] FW: Distributed Clock with Yaskawa SGDV drives

Hi,

Right, I see what you mean.

I hadn't sorted out my timing issues back then so it is more like due to that.  
I've almost finished what I'm currently working on so I'll revisit it and get 
back to you.  


Graeme.



-Original Message-
From: Florian Pose [mailto:f...@igh-essen.com] 
Sent: Monday, 12 March 2012 22:08
To: Graeme Foot
Cc: etherlab-users@etherlab.org
Subject: Re: [etherlab-users] FW: Distributed Clock with Yaskawa SGDV drives

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Am 12.03.2012 00:03, schrieb Graeme Foot:
 Hi,
 
 The slaves are not in OP before ecrt_master_activate().  They are
 in OP after ecrt_master_activate(), but before the first PDO
 datagrams were sent.

But this is what the application is responsible for. After activating
the master, the ecrt_master_send()/receive() methods have to be called
by the application, otherwise *no* bus communication (including slave
configuration) will take place. That's why I'm not understanding, why
slaves can go to OP before 'seeing' the fist process data...

 I was sorting out a few problems I was having at the time, so it's 
 probably not such an issue anymore.  However the main issue is that
 I'm running from a user space thread

Re: [etherlab-users] Linker problems with stable-1.5 patched with the latest rtdm-patch

[Graeme Foot]

Hi,

In that patch I integrated the functions into the ethercat lxrt library.

My library paths are:
  -L=/usr/realtime/lib

My libraries are:
  -lm \
  -lrt \
  -lethercat \
  -llxrt

My includes are:
  -I=/usr/realtime/include

In the source files:
#include ecrt.h   // for standard ethercat functions
#include ec_rtdm.h// for rtdm ethercat functions


We are using buildroot to build our system so we also use the --sysroot 
compiler flag.


I don't have a /opt/etherlab/lib directory.  I can't see anything else 
particularly different.


Regards,
Graeme.



(Most thanks for the RTDM patch go to Moehwald GmbH, B.Benner.  I'm just 
massaging it for my requirements.)



-Original Message-
From: WIEGAND Ralf [mailto:ralf.wieg...@hexagonmetrology.com] 
Sent: Tuesday, 13 March 2012 09:39
To: Graeme Foot
Cc: etherlab-users@etherlab.org
Subject: Linker problems with stable-1.5 patched with the latest rtdm-patch

Hello Graeme,

first of all, thanks for the great job on the rtdm-patch.

I am trying to use your latest rtdm-patch for the stable-1.5 on revision 2266 
and
get some problems during linking my own application. There are undefined 
references
to every ecrt_rtdm_*** library function. I use the linker-flags 
-L/usr/realtime/lib
-L/opt/etherlab/lib and -llxrt -lrtdm -lethercat. The patch, compilation and
installation of the master runs without any problems. The ld is configured to 
search
libraries under /usr/realtime/lib and /opt/etherlab/lib. I also checked the 
content
of the libethercat library with readelf, but all called library-functions are 
listed
in the output. When i try to read out the ELF information with readelf of the 
ec_rtai_rtdm_example, i get an error that the file isn't an ELF-file.

My system is debian based (lenny) with kernel 2.6.32.11 and rtai-3.8.1.

Do you or anybody on the list have any idea to solve the problem or give me a 
hint ?


Regards,

Ralf Wiegand


Hexagon Metrology GmbH
Siegmund-Hiepe-Str. 2-12
35578 Wetzlar
Deutschland

Phone: +49 6441 207-410
Fax: +49 6441 207-387

E-Mail: ralf.wieg...@hexagonmetrology.com 



Hauptgeschäftsführer: Holger Fritze
Geschäftsführer: Per Holmberg - Erik Steinbacher - Arno Seuren
Amtsgericht Wetzlar, HRB 1201



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

Re: [etherlab-users] Linker problems with stable-1.5 patched withthe latest rtdm-patch

[Graeme Foot]

Hi,

Another thought:

Have you configured to use ENABLE_RTDM and either ENABLE_RTAI or ENABLE_XENOMAI 
when compiling the ethercat package?

(ie using --enable-rtdm)

Regards,
Graeme.


-Original Message-
From: etherlab-users-boun...@etherlab.org 
[mailto:etherlab-users-boun...@etherlab.org] On Behalf Of Graeme Foot
Sent: Tuesday, 13 March 2012 10:39
To: WIEGAND Ralf
Cc: etherlab-users@etherlab.org
Subject: Re: [etherlab-users] Linker problems with stable-1.5 patched withthe 
latest rtdm-patch

Hi,

In that patch I integrated the functions into the ethercat lxrt library.

My library paths are:
  -L=/usr/realtime/lib

My libraries are:
  -lm \
  -lrt \
  -lethercat \
  -llxrt

My includes are:
  -I=/usr/realtime/include

In the source files:
#include ecrt.h   // for standard ethercat functions
#include ec_rtdm.h// for rtdm ethercat functions


We are using buildroot to build our system so we also use the --sysroot 
compiler flag.


I don't have a /opt/etherlab/lib directory.  I can't see anything else 
particularly different.


Regards,
Graeme.



(Most thanks for the RTDM patch go to Moehwald GmbH, B.Benner.  I'm just 
massaging it for my requirements.)



-Original Message-
From: WIEGAND Ralf [mailto:ralf.wieg...@hexagonmetrology.com] 
Sent: Tuesday, 13 March 2012 09:39
To: Graeme Foot
Cc: etherlab-users@etherlab.org
Subject: Linker problems with stable-1.5 patched with the latest rtdm-patch

Hello Graeme,

first of all, thanks for the great job on the rtdm-patch.

I am trying to use your latest rtdm-patch for the stable-1.5 on revision 2266 
and
get some problems during linking my own application. There are undefined 
references
to every ecrt_rtdm_*** library function. I use the linker-flags 
-L/usr/realtime/lib
-L/opt/etherlab/lib and -llxrt -lrtdm -lethercat. The patch, compilation and
installation of the master runs without any problems. The ld is configured to 
search
libraries under /usr/realtime/lib and /opt/etherlab/lib. I also checked the 
content
of the libethercat library with readelf, but all called library-functions are 
listed
in the output. When i try to read out the ELF information with readelf of the 
ec_rtai_rtdm_example, i get an error that the file isn't an ELF-file.

My system is debian based (lenny) with kernel 2.6.32.11 and rtai-3.8.1.

Do you or anybody on the list have any idea to solve the problem or give me a 
hint ?


Regards,

Ralf Wiegand


Hexagon Metrology GmbH
Siegmund-Hiepe-Str. 2-12
35578 Wetzlar
Deutschland

Phone: +49 6441 207-410
Fax: +49 6441 207-387

E-Mail: ralf.wieg...@hexagonmetrology.com 



Hauptgeschäftsführer: Holger Fritze
Geschäftsführer: Per Holmberg - Erik Steinbacher - Arno Seuren
Amtsgericht Wetzlar, HRB 1201



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

Re: [etherlab-users] FW: Distributed Clock with Yaskawa SGDV drives

[Graeme Foot]

Hi,

Right, I see what you mean.

I hadn't sorted out my timing issues back then so it is more like due to that.  
I've almost finished what I'm currently working on so I'll revisit it and get 
back to you.  


Graeme.



-Original Message-
From: Florian Pose [mailto:f...@igh-essen.com] 
Sent: Monday, 12 March 2012 22:08
To: Graeme Foot
Cc: etherlab-users@etherlab.org
Subject: Re: [etherlab-users] FW: Distributed Clock with Yaskawa SGDV drives

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Am 12.03.2012 00:03, schrieb Graeme Foot:
 Hi,
 
 The slaves are not in OP before ecrt_master_activate().  They are
 in OP after ecrt_master_activate(), but before the first PDO
 datagrams were sent.

But this is what the application is responsible for. After activating
the master, the ecrt_master_send()/receive() methods have to be called
by the application, otherwise *no* bus communication (including slave
configuration) will take place. That's why I'm not understanding, why
slaves can go to OP before 'seeing' the fist process data...

 I was sorting out a few problems I was having at the time, so it's 
 probably not such an issue anymore.  However the main issue is that
 I'm running from a user space thread in RTAI.
 
 What I originally had was:
 
 ecrt_master_activate() ... setting up app objects to use pdo data
 etc ... rt_make_hard_real_time() rt_task_make_periodic(...,
 firstScanTime, ...) rt_task_wait_period() while (true) { ...
 ethercat polling stuff etc ... rt_task_wait_period() }
 
 I needed to call ecrt_master_activate() (and then set up objects 
 referring to the pdo data) before making the thread hard realtime.
 In the time it took for the first hard period to start some of the
 slaves had already reached OP mode and missed a couple of PDO
 datagrams.

See above, after ecrt_master_activate() is called, there is no bus
configuration until you call ecrt_master_send() cyclically.

 So instead of that, I added an ethercat function to allow
 pre-assigning of the pdo data from user space so that the pdo data
 objects could be set up before calling ecrt_master_activate().  I'm
 also putting the ecrt_master_activate() call in a non-hard realtime
 helper thread so there is minimal time between the
 ecrt_master_activate() call and the PDO packets starting to be
 sent.
 
 It all comes down to ecrt_master_activate() not being able to be
 called from a hard realtime thread in RTAI because it drops the
 thread out of hard realtime.

Sure, because memory has to be allocated. It never was never meant to
be called in real-time.

So before futher discussions I would like to have an explanation, why
the slaves are configured before the application calls ecrt_master_send().

Could you tell me the exact code revision including all patches you use?

- -- 
Viele Grüße,
Florian
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk9dvNMACgkQABFOIMygR8w43gCfTxQNvONoIgTnwWubf55ih3rA
ekoAnA9IRkZwPkzq+KPxwijhAld5+4Lc
=aGCa
-END PGP SIGNATURE-
___
etherlab-users mailing list
etherlab-users@etherlab.org
http://lists.etherlab.org/mailman/listinfo/etherlab-users