BOESEL Diego Fernandes | 7 Feb 16:01 2013
Picon

ecrt_slave_config_state and ecrt_slave_config_pdos undefined

Hello all,

I am trying to install Etherlab master in a newer Linux kernel with RT-Preemption: 3.4.0-rt7 #1 SMP PREEMPT RT.

My Etherlab version is 1.5.1

When I do
#make modules
the final messages will be:

  CC [M]  /usr/local/ethercat-1.5.1/master/soe_errors.o
  CC [M]  /usr/local/ethercat-1.5.1/master/soe_request.o
  CC [M]  /usr/local/ethercat-1.5.1/master/sync.o
  CC [M]  /usr/local/ethercat-1.5.1/master/sync_config.o
  CC [M]  /usr/local/ethercat-1.5.1/master/voe_handler.o
  CC [M]  /usr/local/ethercat-1.5.1/master/ethernet.o
  LD [M]  /usr/local/ethercat-1.5.1/master/ec_master.o
  Building modules, stage 2.
  MODPOST 3 modules
WARNING: "ecrt_slave_config_state" [/usr/local/ethercat-1.5.1/examples/mini/ec_mini.ko] undefined!
WARNING: "ecrt_slave_config_pdos" [/usr/local/ethercat-1.5.1/examples/mini/ec_mini.ko] undefined!
  CC      /usr/local/ethercat-1.5.1/devices/ec_generic.mod.o
  LD [M]  /usr/local/ethercat-1.5.1/devices/ec_generic.ko
  CC      /usr/local/ethercat-1.5.1/examples/mini/ec_mini.mod.o
  LD [M]  /usr/local/ethercat-1.5.1/examples/mini/ec_mini.ko
  CC      /usr/local/ethercat-1.5.1/master/ec_master.mod.o
  LD [M]  /usr/local/ethercat-1.5.1/master/ec_master.ko


And from this point on, everything that needs "ecrt_slave_config_state" and "ecrt_slave_config_pdos" will not work anymore, e.g., the mini example.

Before the
#make modules
I do
#./configure --enable-generic --enable-8139too=no
#make

Does anyone know where the problem could be?
Thanks in advance
<div>
<div>Hello all,<br><br>
I am trying to install Etherlab master in a newer Linux kernel with RT-Preemption: 3.4.0-rt7 #1 SMP PREEMPT RT.
<br><br>
My Etherlab version is 1.5.1<br><br>
When I do<br>
#make modules<br>
the final messages will be:<br><br>
&nbsp; CC [M]&nbsp; /usr/local/ethercat-1.5.1/master/soe_errors.o<br>
&nbsp; CC [M]&nbsp; /usr/local/ethercat-1.5.1/master/soe_request.o<br>
&nbsp; CC [M]&nbsp; /usr/local/ethercat-1.5.1/master/sync.o<br>
&nbsp; CC [M]&nbsp; /usr/local/ethercat-1.5.1/master/sync_config.o<br>
&nbsp; CC [M]&nbsp; /usr/local/ethercat-1.5.1/master/voe_handler.o<br>
&nbsp; CC [M]&nbsp; /usr/local/ethercat-1.5.1/master/ethernet.o<br>
&nbsp; LD [M]&nbsp; /usr/local/ethercat-1.5.1/master/ec_master.o<br>
&nbsp; Building modules, stage 2.<br>
&nbsp; MODPOST 3 modules<br>
WARNING: "ecrt_slave_config_state" [/usr/local/ethercat-1.5.1/examples/mini/ec_mini.ko] undefined!<br>
WARNING: "ecrt_slave_config_pdos" [/usr/local/ethercat-1.5.1/examples/mini/ec_mini.ko] undefined!<br>
&nbsp; CC&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; /usr/local/ethercat-1.5.1/devices/ec_generic.mod.o<br>
&nbsp; LD [M]&nbsp; /usr/local/ethercat-1.5.1/devices/ec_generic.ko<br>
&nbsp; CC&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; /usr/local/ethercat-1.5.1/examples/mini/ec_mini.mod.o<br>
&nbsp; LD [M]&nbsp; /usr/local/ethercat-1.5.1/examples/mini/ec_mini.ko<br>
&nbsp; CC&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; /usr/local/ethercat-1.5.1/master/ec_master.mod.o<br>
&nbsp; LD [M]&nbsp; /usr/local/ethercat-1.5.1/master/ec_master.ko<br><br><br>
And from this point on, everything that needs "ecrt_slave_config_state" and "ecrt_slave_config_pdos" will not work anymore, e.g., the mini example.
<br><br>
Before the<br>
#make modules<br>
I do<br>
#./configure --enable-generic --enable-8139too=no<br>
#make<br><br>
Does anyone know where the problem could be?<br>
Thanks in advance<br>
</div>
</div>
raz ben yehuda | 6 Feb 17:10 2013
Picon

FMMU sizes - is it possible to tweak it ?

Florian Hello

I have an old badly configured drive. part of its pdo entries
are cloned in some pdos. for example, the form 0x6040:0x00 appears
in two distinct pdos. 

When i try to operate the master the drive's replies that the master has
bad output configuration. According to this drive spec it does not
accept pdos bigger than 8 bytes.

1. Could it be that the drive thinks a domain is some sort of a big pdo
and refuses to accept this configuration ? 

2. If so , is it possible to simply remove some pdos from the pdo list
while the drive is in PREOP ? How will the drive know the domains'
configuration ? 

raz

Richard Hacker | 5 Feb 09:17 2013

Re: X Windows Manager & Network Connection?

Hi Ian,

If you want real time, you are not allowed to do anything that will 
cause page faults in the entire process. Page faults could be caused by 
anthing where data is transferred: network, disk, pipes (although I have 
heard of setups where pipes work, but I am not convinced of its 
guarantee to work).

In a real time application you:
1) Initialize everything
2) Get all your memory
3) perform mlockall()
4) Go into cyclic mode and don't cause page faults

If you want your application to talk to the world, you will need to 
create a setup of two processes talking via shared memory. On the one 
side your real time application and on the other the "offline", page 
faultable process. Yes, there are 2 processes! Threads don't work. 
(Beware that the offline process does not have all memory locked with 
mlockall(), otherwise it will explode sometime too)

I cannot explain why your previous setup worked, but that is the problem 
about guarantees: if you do not fulfill the prerequisites, you _may_ 
loose, usually when it's most unexpected ;)

We have developed a range of libraries that will help you in your 
endeavor. On the server (real time) side, you use pdserv and for the 
client (gui) you use pdcom. Take a look at our website: www.etherlab.org.

The two libraries talk to each other via network sockets (so you get 
remote access via internet for free). It will take you some programming, 
but I looks as if that is not a problem for you!

Richard

Am 02/04/2013 04:50 PM, schrieb Ian Norton:
> Hi Richard,
>
> I guess that's a true statement.
>
> Are you saying the process that drives the master cannot do anything else in another thread?
>
> By the way I'm using Centos 6.3.
>
> I've never had any issues at all before. In fact, on all other systems I can run some heavy real time graphics
in the GUI (same process) on a system with 4 motors and 32 ADC/DAC channels. It's totally reliable and
continues to operate smoothly. I dont see why changing the AMP should change the system's operation.
>
> Florian has worked on my app. He never hinted about the X-Server point.
>
> In my tests at the moment, the GUI is really quiet. i.e. no i/o going on.
>
> Ian
>
> Ian R.K. Norton
> System Support Engineer
> Aircraft Engineering
> Cranfield Aerospace Ltd
> Cranfield
> Bedford MK43 0AL
> UK
>
> Tel  - +44 (0) 1234 754926
> Fax - +44 (0) 1234 752375
>
>
> 'All technology information within this Email has been Exported from the United Kingdom under Open
General Export Licence (Technology for Military Goods) - BIS Reference: GBOGE2008/00462'
>
>
>
> -----Original Message-----
> From: Richard Hacker [mailto:ha@...]
> Sent: 04 February 2013 14:44
> To: Ian Norton
> Cc: etherlab-users@...
> Subject: Re: [etherlab-users] X Windows Manager & Network Connection?
>
>
> Hello Ian
>
> But it does look like you are talking to the X-Server from within the
> same process (Note: process, which includes its threads!) that is also
> handling EtherCAT. Am I correct?
>
> Am 02/04/2013 03:02 PM, schrieb Ian Norton:
>> Hi Richard
>>
>> No, no, no.
>>
>> I'm not in real time, it's not important. I just have a thread that ticks away at 1Khz and calls the relevant
master routines. In the the millisecond between ticks I calculate a few things and control the motor. The X
windowy bit is just for the programs GUI, and doesn't do much. There's no graphics in the data acq thread.
>>
>> Data calulated in the 1 khz thread is passed to other threads which display a few numbers etc on the GUI.
>>
>> It all been working fine for 3 years. Only since using the AKD has the issue arisen.
>>
>> I just happened to notice that doing something with the window managed seemed to release data into my program.
>>
>> It's as though something is blocked in the bus master?
>>
>> How can the master give me the same data for seconds at a time? It's as though a network packet has not been
sent and I just get the last data that came through.
>>
>> Ian
>>
>> Ian R.K. Norton
>> System Support Engineer
>> Aircraft Engineering
>> Cranfield Aerospace Ltd
>> Cranfield
>> Bedford MK43 0AL
>> UK
>>
>> Tel  - +44 (0) 1234 754926
>> Fax - +44 (0) 1234 752375
>>
>>
>> 'All technology information within this Email has been Exported from the United Kingdom under Open
General Export Licence (Technology for Military Goods) - BIS Reference: GBOGE2008/00462'
>>
>>
>>
>> -----Original Message-----
>> From: Richard Hacker [mailto:ha@...]
>> Sent: 04 February 2013 13:12
>> To: Ian Norton
>> Cc: etherlab-users@...
>> Subject: Re: [etherlab-users] X Windows Manager & Network Connection?
>>
>>
>> Hello Ian
>>
>> Are you trying to get an application running in real time to talk to
>> your X-screen? If that is true, you're in for trouble IMHO :(
>>
>> Regards
>> Richard
>>
>> Am 02/04/2013 12:06 PM, schrieb Ian Norton:
>>> Hi,
>>>
>>> I have a very strange problem.
>>>
>>> I'm running V1.5 in user mode. My app clocks the bus at 1KHz with
>>> ecrt_domain_queue/ecrt_master_send
>>> /ecrt_master_receive/ecrt_domain_process and get my data back with
>>> EC_READ's.
>>>
>>> Devices on the bus vary, but include Kollmorgen S300, Festo pressure
>>> regulators, Beckhof ADC/DAC. I have 7 systems working fine in the field.
>>>
>>> So now we've upgraded the Kollmorgen S300's to AKD drives. Fairly
>>> straightforward move you might think.
>>>
>>> Not so! After an internal initial homing process, the angular positional
>>> data returned from the drive would not show any change, even though the
>>> attached motor was turning. After a time (variable, and anything from .5
>>> secs to 10 secs), a new value would be returned which is massively
>>> different from the previous "static" value, now reflecting the true
>>> position of the motor.
>>>
>>> My app is an X windows program, and by chance I noticed that if I
>>> perfomed a Window manager function, i.e. move a terminal window on top
>>> of my app, it kick started new data to be retrieved from the bus!?
>>>
>>> The code driving the bus has a heartbeat, which never misses a beat,
>>> even when returned data is not changing, so I'm happy the ecrt routines
>>> are being called continuously.
>>>
>>> I use ecrt_master_state and ecrt_domain_state to look for errors but get
>>> none.
>>>
>>> So I'm wondering how the master can return the same data to me when it
>>> is clearly changing at the device. After all, with no errors, it must
>>> think data has been exchanged.
>>>
>>> And, why does an X window manager kick a transfer off? How can it be
>>> linked to the network?
>>>
>>> Anyone had similar issues?
>>>
>>> regards
>>>
>>> Ian R.K. Norton
>>> System Support Engineer
>>> Aircraft Engineering
>>> Cranfield Aerospace Ltd
>>> Cranfield
>>> Bedford MK43 0AL
>>> UK
>>>
>>> Tel  - +44 (0) 1234 754926
>>> Fax - +44 (0) 1234 752375
>>>
>>>
>>> 'All technology information within this Email has been Exported from the
>>> United Kingdom under Open General Export Licence (Technology for
>>> Military Goods) - BIS Reference: GBOGE2008/00462'
>>>
>>>
>>>
>>> ************************************************************
>>>
>>> DISCLAIMER:
>>>
>>> This email and any attachments are confidential to the intended
>>> recipient and may also be privileged. For those other than the recipient
>>> any disclosure, copying, distribution, or any action taken or omitted to
>>> be taken in reliance on such information is prohibited and may be
>>> unlawful. If you are not the intended recipient please delete it from
>>> your system and notify the sender immediately by telephoning +44(0) 1234
>>> 754978 or by immediate reply via e-mail to the Sender.
>>>
>>> Should the content of this Email, including any attachments, require an
>>> Export Licence, this shall have been registered in compliance with
>>> export controls laid down by the UK Export Control Organisation, which
>>> forms part of the UK Department for Business, Innovation and Skills (BIS).
>>>
>>> Emails and other electronic communication with Cranfield Aerospace may
>>> be monitored.
>>>
>>> Thank you.
>>>
>>> Cranfield Aerospace Limited Registered in England No. 2415720 Registered
>>> Office: Cranfield University, Cranfield, Beds, MK43 0AL
>>>
>>> Updated 14-July-2010
>>>
>>>
>>>
>>> Disclaimer added by *CodeTwo Exchange Rules*
>>> www.codetwo.com <http://www.codetwo.com>
>>>
>>>
>>>
>>> _______________________________________________
>>> etherlab-users mailing list
>>> etherlab-users@...
>>> http://lists.etherlab.org/mailman/listinfo/etherlab-users
>>>
>>
>> Mit freundlichem Gruß
>>
>> Richard Hacker
>>
>
> Mit freundlichem Gruß
>
> Richard Hacker
>

Mit freundlichem Gruß

Richard Hacker

-- 
------------------------------------------------------------------------

Richard Hacker M.Sc.
richard.hacker@...
Tel.: +49 201 / 36014-16

Ingenieurgemeinschaft IgH
Gesellschaft für Ingenieurleistungen mbH
Heinz-Bäcker-Str. 34
D-45356 Essen

Amtsgericht Essen HRB 11500
USt-Id.-Nr.: DE 174 626 722
Geschäftsführung:
- Dr.-Ing. T. Finke,
- Dr.-Ing. W. Hagemeister
Tel.: +49 201 / 360-14-0
http://www.igh-essen.com

------------------------------------------------------------------------
Jürgen Kunz | 5 Feb 06:16 2013
Picon

Re: e1000e driver still not working with 3.2 kernel with latest stable-1.5 branch?

Hello Daniel,

I am using this combination for a while now, with 32- and 64-bit versions of the 3.2er Debian RT-Kernel. If there is a EtherCAT device connected to the computer, the driver works fine.
There are two issues in this driver version, if there are no EtherCAT devices connected. The first, the one you mentioned here, is when the EtherCAT Master starts up with no device connected, then the network-adapter is continously reseted until a device is connected. It may hang the computer if no device is connected for a while.
The second issue is that when the link is plugged off, the link state is not updated. Unfortunately, I did not have time yet to correct these issues.

Greetings,
Jürgen Kunz

Am 05.02.2013 01:59, schrieb Daniel Helmick:
Has anyone else gotten this combination of driver and kernel to work?

Here's the /var/log/messages output when I start the ethercat master:

[  869.854110] EtherCAT: Master driver 1.5.1 9cdd7669dc0b
[  869.854252] EtherCAT: 1 master waiting for devices.
[  869.944866] e1000e 0000:04:00.0: PCI INT A disabled
[  869.948134] ec_e1000e: EtherCAT-capable Intel(R) PRO/1000 Network Driver - 1.5.1-k-EtherCAT
[  869.948138] ec_e1000e: Copyright(c) 1999 - 2011 Intel Corporation.
[  869.948202] ec_e1000e 0000:04:00.0: Disabling ASPM L0s
[  869.948261] ec_e1000e 0000:04:00.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17
[  869.948530] ec_e1000e 0000:04:00.0: setting latency timer to 64
[  869.951386] ec_e1000e 0000:04:00.0: irq 65 for MSI/MSI-X
[  869.951393] ec_e1000e 0000:04:00.0: irq 66 for MSI/MSI-X
[  869.951397] ec_e1000e 0000:04:00.0: irq 67 for MSI/MSI-X
[  870.120739] EtherCAT: Accepting 68:05:CA:10:C0:82 as main device for master 0.
[  870.197588] EtherCAT 0: Starting EtherCAT-IDLE thread.
[  870.197651] ec_e1000e 0000:04:00.0: (unregistered net_device): (PCI Express:2.5GT/s:Width x1) 68:05:ca:10:c0:82
[  870.197656] ec_e1000e 0000:04:00.0: (unregistered net_device): Intel(R) PRO/1000 Network Connection
[  870.197687] ec_e1000e 0000:04:00.0: (unregistered net_device): MAC: 3, PHY: 8, PBA No: E46981-008
[  870.197825] ec_e1000e 0000:04:00.0: (unregistered net_device): Reset adapter
[  872.196168] ec_e1000e 0000:04:00.0: (unregistered net_device): Reset adapter
[  874.196169] ec_e1000e 0000:04:00.0: (unregistered net_device): Reset adapter
[  876.196159] ec_e1000e 0000:04:00.0: (unregistered net_device): Reset adapter
[  878.196162] ec_e1000e 0000:04:00.0: (unregistered net_device): Reset adapter


And the reset adapter message occurs every 2 seconds until I stop the ethercat master.

Thanks,
Dan


_______________________________________________ etherlab-users mailing list etherlab-users-TgCWn71uKPpg9hUCZPvPmw@public.gmane.org http://lists.etherlab.org/mailman/listinfo/etherlab-users

--
Dipl.-Inform. Jürgen Kunz

Technische Universität Darmstadt
FG Simulation, Systemoptimierung und Robotik
Hochschulstr. 10
64289 Darmstadt

Tel.: ++49 (0) 6151-16-70383
Fax: ++49 (0) 6151-16-6648
E-Mail: kunz(at)sim.tu-darmstadt.de
Homepage: http://www.sim.tu-darmstadt.de
Attachment (kunz.vcf): text/x-vcard, 494 bytes
<div>
    Hello Daniel,<br><br>
    I am using this combination for a while now, with 32- and 64-bit
    versions of the 3.2er Debian RT-Kernel. If there is a EtherCAT
    device connected to the computer, the driver works fine.<br>
    There are two issues in this driver version, if there are no
    EtherCAT devices connected. The first, the one you mentioned here,
    is when the EtherCAT Master starts up with no device connected, then
    the network-adapter is continously reseted until a device is
    connected. It may hang the computer if no device is connected for a
    while.<br>
    The second issue is that when the link is plugged off, the link
    state is not updated. Unfortunately, I did not have time yet to
    correct these issues.<br><br>
    Greetings,<br>
    J&uuml;rgen Kunz<br><br><div class="moz-cite-prefix">Am 05.02.2013 01:59, schrieb Daniel
      Helmick:<br>
</div>
    <blockquote cite="mid:CAOSNDYaJGLK__eBznFBhjL9eAAg+Cccr8QiveoEAMi7n6GvNtA@..." type="cite">Has anyone else gotten this combination of driver and
      kernel to work?<br><br>
      Here's the /var/log/messages output when I start the ethercat
      master:<br><br>
      [&nbsp; 869.854110] EtherCAT: Master driver 1.5.1 9cdd7669dc0b<br>
      [&nbsp; 869.854252] EtherCAT: 1 master waiting for devices.<br>
      [&nbsp; 869.944866] e1000e 0000:04:00.0: PCI INT A disabled<br>
      [&nbsp; 869.948134] ec_e1000e: EtherCAT-capable Intel(R) PRO/1000
      Network Driver - 1.5.1-k-EtherCAT<br>
      [&nbsp; 869.948138] ec_e1000e: Copyright(c) 1999 - 2011 Intel
      Corporation.<br>
      [&nbsp; 869.948202] ec_e1000e 0000:04:00.0: Disabling ASPM L0s <br>
      [&nbsp; 869.948261] ec_e1000e 0000:04:00.0: PCI INT A -&gt; GSI 17
      (level, low) -&gt; IRQ 17<br>
      [&nbsp; 869.948530] ec_e1000e 0000:04:00.0: setting latency timer to 64<br>
      [&nbsp; 869.951386] ec_e1000e 0000:04:00.0: irq 65 for MSI/MSI-X<br>
      [&nbsp; 869.951393] ec_e1000e 0000:04:00.0: irq 66 for MSI/MSI-X<br>
      [&nbsp; 869.951397] ec_e1000e 0000:04:00.0: irq 67 for MSI/MSI-X<br>
      [&nbsp; 870.120739] EtherCAT: Accepting 68:05:CA:10:C0:82 as main
      device for master 0.<br>
      [&nbsp; 870.197588] EtherCAT 0: Starting EtherCAT-IDLE thread.<br>
      [&nbsp; 870.197651] ec_e1000e 0000:04:00.0: (unregistered net_device):
      (PCI Express:2.5GT/s:Width x1) 68:05:ca:10:c0:82<br>
      [&nbsp; 870.197656] ec_e1000e 0000:04:00.0: (unregistered net_device):
      Intel(R) PRO/1000 Network Connection<br>
      [&nbsp; 870.197687] ec_e1000e 0000:04:00.0: (unregistered net_device):
      MAC: 3, PHY: 8, PBA No: E46981-008<br>
      [&nbsp; 870.197825] ec_e1000e 0000:04:00.0: (unregistered net_device):
      Reset adapter<br>
      [&nbsp; 872.196168] ec_e1000e 0000:04:00.0: (unregistered net_device):
      Reset adapter<br>
      [&nbsp; 874.196169] ec_e1000e 0000:04:00.0: (unregistered net_device):
      Reset adapter<br>
      [&nbsp; 876.196159] ec_e1000e 0000:04:00.0: (unregistered net_device):
      Reset adapter<br>
      [&nbsp; 878.196162] ec_e1000e 0000:04:00.0: (unregistered net_device):
      Reset adapter<br><br><br>
      And the reset adapter message occurs every 2 seconds until I stop
      the ethercat master.<br><br>
      Thanks,<br>
      Dan<br><br><br>_______________________________________________
etherlab-users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:etherlab-users@...">etherlab-users@...</a>
<a class="moz-txt-link-freetext" href="http://lists.etherlab.org/mailman/listinfo/etherlab-users">http://lists.etherlab.org/mailman/listinfo/etherlab-users</a>

    </blockquote>
    <br><div class="moz-signature">-- <br>
      Dipl.-Inform. J&uuml;rgen Kunz<br><br><a href="http://www.tu-darmstadt.de">Technische Universit&auml;t
        Darmstadt</a><br><a href="http://www.sim.tu-darmstadt.de">FG Simulation,
        Systemoptimierung und Robotik</a><br>
      Hochschulstr. 10<br>
      64289 Darmstadt<br><br>
      Tel.: ++49 (0) 6151-16-70383<br>
      Fax: ++49 (0) 6151-16-6648<br>
      E-Mail: kunz(at)sim.tu-darmstadt.de<br>
      Homepage: <a href="http://www.sim.tu-darmstadt.de">http://www.sim.tu-darmstadt.de</a>
</div>
  </div>
Daniel Helmick | 5 Feb 01:59 2013
Picon

e1000e driver still not working with 3.2 kernel with latest stable-1.5 branch?

Has anyone else gotten this combination of driver and kernel to work?

Here's the /var/log/messages output when I start the ethercat master:

[  869.854110] EtherCAT: Master driver 1.5.1 9cdd7669dc0b
[  869.854252] EtherCAT: 1 master waiting for devices.
[  869.944866] e1000e 0000:04:00.0: PCI INT A disabled
[  869.948134] ec_e1000e: EtherCAT-capable Intel(R) PRO/1000 Network Driver - 1.5.1-k-EtherCAT
[  869.948138] ec_e1000e: Copyright(c) 1999 - 2011 Intel Corporation.
[  869.948202] ec_e1000e 0000:04:00.0: Disabling ASPM L0s
[  869.948261] ec_e1000e 0000:04:00.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17
[  869.948530] ec_e1000e 0000:04:00.0: setting latency timer to 64
[  869.951386] ec_e1000e 0000:04:00.0: irq 65 for MSI/MSI-X
[  869.951393] ec_e1000e 0000:04:00.0: irq 66 for MSI/MSI-X
[  869.951397] ec_e1000e 0000:04:00.0: irq 67 for MSI/MSI-X
[  870.120739] EtherCAT: Accepting 68:05:CA:10:C0:82 as main device for master 0.
[  870.197588] EtherCAT 0: Starting EtherCAT-IDLE thread.
[  870.197651] ec_e1000e 0000:04:00.0: (unregistered net_device): (PCI Express:2.5GT/s:Width x1) 68:05:ca:10:c0:82
[  870.197656] ec_e1000e 0000:04:00.0: (unregistered net_device): Intel(R) PRO/1000 Network Connection
[  870.197687] ec_e1000e 0000:04:00.0: (unregistered net_device): MAC: 3, PHY: 8, PBA No: E46981-008
[  870.197825] ec_e1000e 0000:04:00.0: (unregistered net_device): Reset adapter
[  872.196168] ec_e1000e 0000:04:00.0: (unregistered net_device): Reset adapter
[  874.196169] ec_e1000e 0000:04:00.0: (unregistered net_device): Reset adapter
[  876.196159] ec_e1000e 0000:04:00.0: (unregistered net_device): Reset adapter
[  878.196162] ec_e1000e 0000:04:00.0: (unregistered net_device): Reset adapter


And the reset adapter message occurs every 2 seconds until I stop the ethercat master.

Thanks,
Dan

<div><p>Has anyone else gotten this combination of driver and kernel to work?<br><br>Here's the /var/log/messages output when I start the ethercat master:<br><br>[&nbsp; 869.854110] EtherCAT: Master driver 1.5.1 9cdd7669dc0b<br>[&nbsp; 869.854252] EtherCAT: 1 master waiting for devices.<br>

[&nbsp; 869.944866] e1000e 0000:04:00.0: PCI INT A disabled<br>[&nbsp; 869.948134] ec_e1000e: EtherCAT-capable Intel(R) PRO/1000 Network Driver - 1.5.1-k-EtherCAT<br>[&nbsp; 869.948138] ec_e1000e: Copyright(c) 1999 - 2011 Intel Corporation.<br>

[&nbsp; 869.948202] ec_e1000e 0000:04:00.0: Disabling ASPM L0s <br>[&nbsp; 869.948261] ec_e1000e 0000:04:00.0: PCI INT A -&gt; GSI 17 (level, low) -&gt; IRQ 17<br>[&nbsp; 869.948530] ec_e1000e 0000:04:00.0: setting latency timer to 64<br>

[&nbsp; 869.951386] ec_e1000e 0000:04:00.0: irq 65 for MSI/MSI-X<br>[&nbsp; 869.951393] ec_e1000e 0000:04:00.0: irq 66 for MSI/MSI-X<br>[&nbsp; 869.951397] ec_e1000e 0000:04:00.0: irq 67 for MSI/MSI-X<br>[&nbsp; 870.120739] EtherCAT: Accepting 68:05:CA:10:C0:82 as main device for master 0.<br>

[&nbsp; 870.197588] EtherCAT 0: Starting EtherCAT-IDLE thread.<br>[&nbsp; 870.197651] ec_e1000e 0000:04:00.0: (unregistered net_device): (PCI Express:2.5GT/s:Width x1) 68:05:ca:10:c0:82<br>[&nbsp; 870.197656] ec_e1000e 0000:04:00.0: (unregistered net_device): Intel(R) PRO/1000 Network Connection<br>

[&nbsp; 870.197687] ec_e1000e 0000:04:00.0: (unregistered net_device): MAC: 3, PHY: 8, PBA No: E46981-008<br>[&nbsp; 870.197825] ec_e1000e 0000:04:00.0: (unregistered net_device): Reset adapter<br>[&nbsp; 872.196168] ec_e1000e 0000:04:00.0: (unregistered net_device): Reset adapter<br>

[&nbsp; 874.196169] ec_e1000e 0000:04:00.0: (unregistered net_device): Reset adapter<br>[&nbsp; 876.196159] ec_e1000e 0000:04:00.0: (unregistered net_device): Reset adapter<br>[&nbsp; 878.196162] ec_e1000e 0000:04:00.0: (unregistered net_device): Reset adapter<br><br><br>And the reset adapter message occurs every 2 seconds until I stop the ethercat master.<br><br>Thanks,<br>Dan<br></p></div>
Ian Norton | 4 Feb 12:06 2013

X Windows Manager & Network Connection?

Hi,

I have a very strange problem.

I'm running V1.5 in user mode. My app clocks the bus at 1KHz with ecrt_domain_queue/ecrt_master_send /ecrt_master_receive/ecrt_domain_process and get my data back with EC_READ's.

Devices on the bus vary, but include Kollmorgen S300, Festo pressure regulators, Beckhof ADC/DAC. I have 7 systems working fine in the field.

So now we've upgraded the Kollmorgen S300's to AKD drives. Fairly straightforward move you might think.

Not so! After an internal initial homing process, the angular positional data returned from the drive would not show any change, even though the attached motor was turning. After a time (variable, and anything from .5 secs to 10 secs), a new value would be returned which is massively different from the previous "static" value, now reflecting the true position of the motor.

My app is an X windows program, and by chance I noticed that if I perfomed a Window manager function, i.e. move a terminal window on top of my app, it kick started new data to be retrieved from the bus!?

The code driving the bus has a heartbeat, which never misses a beat, even when returned data is not changing, so I'm happy the ecrt routines are being called continuously.

I use ecrt_master_state and ecrt_domain_state to look for errors but get none.

So I'm wondering how the master can return the same data to me when it is clearly changing at the device. After all, with no errors, it must think data has been exchanged.

And, why does an X window manager kick a transfer off? How can it be linked to the network?

Anyone had similar issues?

regards

Ian R.K. Norton
System Support Engineer
Aircraft Engineering
Cranfield Aerospace Ltd
Cranfield
Bedford MK43 0AL
UK

Tel  - +44 (0) 1234 754926
Fax - +44 (0) 1234 752375


'All technology information within this Email has been Exported from the United Kingdom under Open General Export Licence (Technology for Military Goods) - BIS Reference: GBOGE2008/00462'



************************************************************

DISCLAIMER:

This email and any attachments are confidential to the intended recipient and may also be privileged. For those other than the recipient any disclosure, copying, distribution, or any action taken or omitted to be taken in reliance on such information is prohibited and may be unlawful. If you are not the intended recipient please delete it from your system and notify the sender immediately by telephoning +44(0) 1234 754978 or by immediate reply via e-mail to the Sender.

Should the content of this Email, including any attachments, require an Export Licence, this shall have been registered in compliance with export controls laid down by the UK Export Control Organisation, which forms part of the UK Department for Business, Innovation and Skills (BIS).

Emails and other electronic communication with Cranfield Aerospace may be monitored.

Thank you.

Cranfield Aerospace Limited Registered in England No. 2415720 Registered Office: Cranfield University, Cranfield, Beds, MK43 0AL

Updated 14-July-2010



Disclaimer added by CodeTwo Exchange Rules
www.codetwo.com

<div>

<p>Hi,
</p>

<p>I have a very strange problem.
</p>

<p>I'm running V1.5 in user mode. My app clocks the bus at 1KHz with ecrt_domain_queue/ecrt_master_send /ecrt_master_receive/ecrt_domain_process and get my data back with EC_READ's.</p>

<p>Devices on the bus vary, but include Kollmorgen S300, Festo pressure regulators, Beckhof ADC/DAC. I have 7 systems working fine in the field.</p>

<p>So now we've upgraded the Kollmorgen S300's to AKD drives. Fairly straightforward move you might think.
</p>

<p>Not so! After an internal initial homing process, the angular positional data returned from the drive would not show any change, even though the attached motor was turning. After a time (variable, and anything from .5 secs to 10 secs), a new value would be returned which is massively different from the previous "static" value, now reflecting the true position of the motor.</p>

<p>My app is an X windows program, and by chance I noticed that if I perfomed a Window manager function, i.e. move a terminal window on top of my app, it kick started new data to be retrieved from the bus!?</p>

<p>The code driving the bus has a heartbeat, which never misses a beat, even when returned data is not changing, so I'm happy the ecrt routines are being called continuously.</p>

<p>I use ecrt_master_state and ecrt_domain_state to look for errors but get none.
</p>

<p>So I'm wondering how the master can return the same data to me when it is clearly changing at the device. After all, with no errors, it must think data has been exchanged.</p>

<p>And, why does an X window manager kick a transfer off? How can it be linked to the network?
</p>

<p>Anyone had similar issues?
</p>

<p>regards
</p>

<p>Ian R.K. Norton

<br>System Support Engineer

<br>Aircraft Engineering

<br>Cranfield Aerospace Ltd

<br>Cranfield

<br>Bedford MK43 0AL

<br>UK
</p>

<p>Tel&nbsp; - +44 (0) 1234 754926

<br>Fax - +44 (0) 1234 752375
</p>
<br><p>'All technology information within this Email has been Exported from the United Kingdom under Open General Export Licence (Technology for Military Goods) - BIS Reference: GBOGE2008/00462'</p>
<br><p><br>************************************************************ </p>
<p>DISCLAIMER: 
</p>
<p>This email and any attachments are confidential to the intended recipient and 
may also be privileged. For those other than the recipient any disclosure, 
copying, distribution, or any action taken or omitted to be taken in reliance on 
such information is prohibited and may be unlawful. If you are not the intended 
recipient please delete it from your system and notify the sender immediately by 
telephoning +44(0) 1234 754978 or by immediate reply via e-mail to the Sender. 
</p>
<p>Should the content of this Email, including any attachments, require an Export Licence, 
this shall have been registered in compliance with export controls laid down by the 
UK Export Control Organisation, which forms part of the UK Department for Business, Innovation and Skills (BIS). 
</p>
<p>Emails and other electronic communication with Cranfield Aerospace may be 
monitored. 
</p>
<p>Thank you. 
</p>
<p>Cranfield Aerospace Limited Registered in England No. 2415720 Registered Office: 
Cranfield University, Cranfield, Beds, MK43 0AL 
</p>
<p>Updated 14-July-2010 
</p>
<p><br></p>
<div>
<br>Disclaimer added by CodeTwo Exchange Rules<br><a href="http://www.codetwo.com">www.codetwo.com</a>
</div>
<br>
</div>
Jun Yuan | 1 Feb 17:53 2013

Re: Patch for Distributed Clock

Hi,

I've been testing Graeme Foot's DC Patch, which had already been added
into the etherlab master source by Florian. My system is Xenomai 2.6.1
+ Linux 2.6.37.6 + Etherlab(2498:9cdd7669dc0b <at> stable1.5).

First of all, a big thanks to Graeme Foot. It is a brilliant idea to
update the master cycle to match the ref slave time, and this works
wonderful! Great job! My servos run very stable now without any sync
problem. Thank you!

The little problem I found in the patch, however, is

timeDiff = ((timeDiff + (scanTimeNS/2)) % scanTimeNS) - (scanTimeNS/2);

This code doesn't work as it should, especially when timeDiff is negative.

And to the question that why "the time difference returned by
ecrt_rtdm_master_sync_slave_clocks_diff() is often one period out",
this was because that the correction made to the slave system_time was
wrong, see my last email 'Calculation of time_diff in
ec_fsm_master_dc_offset()'.

Regards,
Jun

diff -r 9cdd7669dc0b examples/rtai_rtdm_dc/main.c
--- a/examples/rtai_rtdm_dc/main.c    Thu Jan 10 17:36:41 2013 +0100
+++ b/examples/rtai_rtdm_dc/main.c    Fri Feb 01 17:38:29 2013 +0100
 <at>  <at>  -236,8 +236,9  <at>  <at> 
     prev_dc_diff_ns = dc_diff_ns;

     // normalise the time diff
-    dc_diff_ns =
-        ((dc_diff_ns + (cycle_ns / 2)) % cycle_ns) - (cycle_ns / 2);
+    dc_diff_ns = dc_diff_ns >= 0 ?
+            ((dc_diff_ns + (int32_t)(cycle_ns / 2)) %
(int32_t)cycle_ns) - (cycle_ns / 2) :
+            ((dc_diff_ns - (int32_t)(cycle_ns / 2)) %
(int32_t)cycle_ns) - (cycle_ns / 2) ;

     // only update if primary master
     if (dc_started) {
 <at>  <at>  -249,8 +250,9  <at>  <at> 

         if (dc_filter_idx >= DC_FILTER_CNT) {
             // add rounded delta average
-            dc_adjust_ns +=
-                ((dc_delta_total_ns + (DC_FILTER_CNT / 2)) / DC_FILTER_CNT);
+            dc_adjust_ns += dc_delta_total_ns >= 0 ?
+                ((dc_delta_total_ns + (DC_FILTER_CNT / 2)) / DC_FILTER_CNT) :
+                ((dc_delta_total_ns - (DC_FILTER_CNT / 2)) / DC_FILTER_CNT) ;

             // and add adjustment for general diff (to pull in drift)
             dc_adjust_ns += sign(dc_diff_total_ns / DC_FILTER_CNT);
Yan Prochazka | 25 Jan 19:17 2013

distributed clock offset ?

Hello Everybody!

we currently use 1.5.0 version of EtherCAT master and Distributed Clock 
enabled slaves. Our application runs in user space and uses ecrt.h. DC 
synchronization seems to work perfectly, SYNC0 on all slaves and our 
application is kept in sync nicely, BUT how could I get, in my 
application, the absolute time offsets between time passed cyclically to 
ecrt_master_application_time() and absolute time of a particular slave 
when SYNC0 pulse is generated ?

basically, there are an event generated on the slave at arbitrary time, 
I can get slave time of that event, but I need *somehow* match that 
slave time with SYNC0 time occurrence and with my application time. 
Therefore I need to know offsets between my application time and SYNC0 
absolute times on the slaves.

Does anybody have any ideas or at least hints where and what to look for ?

Thanks a lot,
Jan Prochazka
BOESEL Diego Fernandes | 25 Jan 09:47 2013
Picon

Problem setting up Etherlab Master with Wago 750-354

Hello,

1 - PROBLEM:
I am trying to set-up a Ethercat fieldbus using Etherlab as master and a Wago 750-354 as a slave. However, all
info I get from the Wago slave is null. I am almost sure there is something wrong here.

Here are some screenshoots:

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

#sudo /etc/init.d/ethercat status
Checking for EtherCAT master 1.5.1
Master0  running

#/opt/etherlab/bin/ethercat slave
0  0:0  INIT  E  0x00000000:0x00000000

#/opt/etherlab/bin/ethercat xml
<?xml version="1.0" ?>
<EtherCATInfo>
  <!-- Slave 0 -->
  <Vendor>
    <Id>0</Id>
  </Vendor>
  <Descriptions>
    <Devices>
      <Device>
        <Type ProductCode="#x00000000" RevisionNo="#x00000000"></Type>
      </Device>
    </Devices>
  </Descriptions>
</EtherCATInfo>

2 - SYSTEM
#uname -a
Linux dfb-laptop 2.6.31-11-rt #154-Ubuntu SMP PREEMPT RT Wed Jun 9 12:28:53 UTC 2010 i686 GNU/Linux

3 - INSTALLATION
#./configure --enable-cycles --enable-generic
#make
#make modules

# sudo make install
# sudo make modules install
# sudo depmod

#cd /opt/etherlab
#cp etc/sysconfig/ethercat /etc/sysconfig/
#ln -s /opt/etherlab/etc/init.d/ethercat /etc/init.d/
#insserv ethercat

Then, I configure /etc/sysconfig/ethercat with
MASTER0_DEVICE="00:15:58:31:5e:7c
DEVICE_MODULES="generic"

Does anyone know what I am doing wrong that I can not read correctly my slave device?
Thomas Nelson | 24 Jan 04:15 2013

Accessing same PDO for both read and write

All,

My client has a robotics system using Copley Controls Accelnet Plus drives with a digital input-triggered capture capability that we're trying to use for positioning calibration.  This feature requires the ability to map the same slave CoE object for both read to detect the capture event and write to subsequently rearm the trigger.  Mapping this object to both Tx and Rx PDOs appears to work correctly from the PDO mapping info returned from the master.  However, when I attempt to register the corresponding mapped PDO entries in the domain, I get the same domain offset for both PDOs, preventing the application from managing them independently.

The ecrt_slave_config_reg_pdo_entry() function doesn't have an argument to distinguish the direction of the PDO mapping, so is this capability not supported by the master?

We're using the 1.5.0 release.

Thanks,

Tom Nelson
Consulting Engineer
Granite Computer Sciences, LLC







<div>All,<div><br></div>
<div>My client has a robotics system using Copley Controls Accelnet Plus drives with a digital input-triggered capture capability that we're trying to use for positioning calibration. &nbsp;This feature requires the ability to map the same slave CoE object for both read to detect the capture event and write to subsequently rearm the trigger. &nbsp;Mapping this object to both Tx and Rx PDOs appears to work correctly from the PDO mapping info returned from the master. &nbsp;However, when I attempt to register the corresponding mapped PDO entries in the domain, I get the same domain offset for both PDOs, preventing the application from managing them independently.</div>
<div><br></div>
<div>The&nbsp;ecrt_slave_config_reg_pdo_entry() function doesn't have an argument to distinguish the direction of the PDO mapping, so is this capability not supported by the master?</div>
<div><br></div>
<div>We're using the 1.5.0 release.</div>
<div><br></div>
<div>Thanks,</div>
<div>
<br><div>
<span class="Apple-style-span"><span class="Apple-style-span"><div>
<span class="Apple-style-span"><div>
<span class="Apple-style-span"><div><div><span class="Apple-style-span"><div>Tom Nelson</div>
<div>Consulting Engineer</div>
<div>Granite Computer Sciences, LLC</div>
<div><br></div>
<div><span class="Apple-style-span"><br></span></div></span></div></div></span><br class="Apple-interchange-newline">
</div></span><br class="Apple-interchange-newline">
</div></span><br class="Apple-interchange-newline"></span><br class="Apple-interchange-newline">
</div>
<br>
</div>
</div>
Jun Yuan | 23 Jan 17:36 2013

Calculation of time_diff in ec_fsm_master_dc_offset()

Hello Florian,

I think there might be a bug in the calculation of time_diff between the master clock and the slave clock in fsm_master.c. My temporary solution is to comment out the line 'system_time32 += correction;' in the function ec_fsm_master_dc_offset32() and the line 'system_time += correction;' in ec_fsm_master_dc_offset64().

Here is my story. I've been testing the etherlab master on Xenomai. After several times restart of my master process, I occasionally found something interesting: the DC sync between the master and the slave always takes a long time (approx. 5 second) by each start, and it seems by each time the time diff between the master and the slave is always approx. -4000000 ns.
[16165.453658] EtherCAT DEBUG 0-0: DC 32 bit system time offset calculation: system_time=xxxxxxxxxxx (corrected with 4000000), app_time=xxxxxxxxxx, diff=-3954618

And the checking synchrony will be started with a difference around that diff time.
[16165.521874] EtherCAT DEBUG 0-0: Checking for synchrony.
[16165.529891] EtherCAT DEBUG 0-0: Sync after    4 ms:     3941732 ns

This is odd. Since the master has synchronized with the slave just several seconds ago before the restart, their clocks should not have 4 ms difference in such a short time. And it is strange that the value is always around 4000000 ns. So I digged into the master's source code to find out the reason.

I have etherlab master rev 2498:9cdd7669dc0b <at> stable-1.5 on Xenomai 2.6.1, and my rt task is something like the following:

ecrt_master_application_time(master, dummy_time);

while(true) { // run loop
        wait_period();
        ecrt_master_receive(master);
        ecrt_domain_process(domain1);
        ...
        ecrt_domain_queue(domain1);
        sync_distributed_clocks();
        ecrt_master_send(master);
}

In the function sync_distributed_clocks() there are three calls:
    ecrt_master_application_time(master, dc_time_ns);
    ecrt_master_sync_reference_clock(master);
    ecrt_master_sync_slave_clocks(master);

And here are what I've found:

1. I must call ecrt_master_application_time() once somewhere before my run loop, otherwise I'll get error "No app_time received up to now", and ec_fsm_master_state_dc_read_offset will not be executed. The app time given to the ecrt_master_application_time() at this point is not important, it will not be used anywhere. Calling the function ecrt_master_application_time(master, dummy_time) can avoid master->has_app_time = 0 in ec_fsm_master_enter_write_system_times().

2. The first app_time dc_time_ns given to the ecrt_master_application_time() within the sync_distributed_clocks() in my run loop will be used as slave->master->app_time in the function ec_fsm_master_dc_offset.

3. In ec_fsm_master_dc_offset, there is a variable 'correction', which is somehow always equal to my fsm interval(4000000 ns on my master). I believe this correction should be the time interval since the last read. It is calculated using the variable jiffies_since_read.
jiffies_since_read = jiffies - datagram->jiffies_sent;
jiffies is the current time, datagram->jiffies_sent is the time of the last call ecrt_master_send(master).

The system_time from the ref_sync_datagram is the time of my ref slave. The following line calculates the current system_time of the ref slave clock.
system_time += correction;

Then the time_diff is calcuated as following
time_diff = fsm->slave->master->app_time - system_time;

The problem here however is that the fsm->slave->master->app_time is not the current app_time of the master. It is the app time set in ecrt_master_application_time() just before ecrt_master_send(master). So the current app_time of master should also be approximately calculated as
fsm->slave->master->app_time + correction.

So the correct calculation for the current time_diff should be
time_diff = fsm->slave->master->app_time + correction - system_time;

Now the question is, why bother adding the correction(time interval since read) to the system_time, as the app_time was set by the user at about the same time when the system_time was read?

After commenting out the line 'system_time += correction;', I have now very small time diff between the master and the slave after restart, and the ec_fsm_slave_config_state_dc_sync_check goes way faster because the initial difference becomes small.

I hope this mail could also help those having the warning 'Slave did not sync after 5000 ms'.

Regards,
Jun



diff -r 9cdd7669dc0b master/fsm_master.c
--- a/master/fsm_master.c    Thu Jan 10 17:36:41 2013 +0100
+++ b/master/fsm_master.c    Wed Jan 23 17:09:51 2013 +0100
<at> <at> -976,7 +976,7 <at> <at>
 
     // correct read system time by elapsed time since read operation
     correction = jiffies_since_read * 1000 / HZ * 1000000;
-    system_time32 += correction;
+//    system_time32 += correction;
     time_diff = (u32) slave->master->app_time - system_time32;
 
     EC_SLAVE_DBG(slave, 1, "DC 32 bit system time offset calculation:"
<at> <at> -1013,7 +1013,7 <at> <at>
 
     // correct read system time by elapsed time since read operation
     correction = (u64) (jiffies_since_read * 1000 / HZ) * 1000000;
-    system_time += correction;
+//    system_time += correction;
     time_diff = fsm->slave->master->app_time - system_time;
 
     EC_SLAVE_DBG(slave, 1, "DC 64 bit system time offset calculation:"

<div><p>Hello Florian,<br><br>I think there might be a bug in the calculation of time_diff between the master clock and the slave clock in fsm_master.c. My temporary solution is to comment out the line 'system_time32 += correction;' in the function ec_fsm_master_dc_offset32() and the line 'system_time += correction;' in ec_fsm_master_dc_offset64().<br><br>Here is my story. I've been testing the etherlab master on Xenomai. After several times restart of my master process, I occasionally found something interesting: the DC sync between the master and the slave always takes a long time (approx. 5 second) by each start, and it seems by each time the time diff between the master and the slave is always approx. -4000000 ns. <br><a href="tel:%5B16165.453658" value="+16165453658" target="_blank">[16165.453658</a>] EtherCAT DEBUG 0-0: DC 32 bit system time offset calculation: system_time=xxxxxxxxxxx (corrected with 4000000), app_time=xxxxxxxxxx, diff=-3954618<br><br>And the checking synchrony will be started with a difference around that diff time.<br><a href="tel:%5B16165.521874" value="+16165521874" target="_blank">[16165.521874</a>] EtherCAT DEBUG 0-0: Checking for synchrony.<br><a href="tel:%5B16165.529891" value="+16165529891" target="_blank">[16165.529891</a>] EtherCAT DEBUG 0-0: Sync after&nbsp;&nbsp;&nbsp; 4 ms:&nbsp;&nbsp;&nbsp;&nbsp; 3941732 ns<br><br>This is odd. Since the master has synchronized with the slave just several seconds ago before the restart, their clocks should not have 4 ms difference in such a short time. And it is strange that the value is always around 4000000 ns. So I digged into the master's source code to find out the reason.<br><br>I have etherlab master rev 2498:9cdd7669dc0b <at> stable-1.5 on Xenomai 2.6.1, and my rt task is something like the following:<br><br>ecrt_master_application_time(master, dummy_time);<br><br>while(true) { // run loop<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; wait_period();<br>

&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ecrt_master_receive(master);<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ecrt_domain_process(domain1);<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ...<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ecrt_domain_queue(domain1);<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; sync_distributed_clocks();<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ecrt_master_send(master);<br>}<br><br>In the function sync_distributed_clocks() there are three calls:<br>&nbsp;&nbsp;&nbsp; ecrt_master_application_time(master, dc_time_ns);<br>&nbsp;&nbsp;&nbsp; ecrt_master_sync_reference_clock(master);<br>

&nbsp;&nbsp;&nbsp; ecrt_master_sync_slave_clocks(master);<br><br>And here are what I've found:<br><br>1. I must call ecrt_master_application_time() once somewhere before my run loop, otherwise I'll get error "No app_time received up to now", and ec_fsm_master_state_dc_read_offset will not be executed. The app time given to the ecrt_master_application_time() at this point is not important, it will not be used anywhere. Calling the function ecrt_master_application_time(master, dummy_time) can avoid master-&gt;has_app_time = 0 in ec_fsm_master_enter_write_system_times().<br><br>2. The first app_time dc_time_ns given to the ecrt_master_application_time() within the sync_distributed_clocks() in my run loop will be used as slave-&gt;master-&gt;app_time in the function ec_fsm_master_dc_offset. <br><br>3. In ec_fsm_master_dc_offset, there is a variable 'correction', which is somehow always equal to my fsm interval(4000000 ns on my master). I believe this correction should be the time interval since the last read. It is calculated using the variable jiffies_since_read.<br>jiffies_since_read = jiffies - datagram-&gt;jiffies_sent;<br>jiffies is the current time, datagram-&gt;jiffies_sent is the time of the last call ecrt_master_send(master).<br><br>The system_time from the ref_sync_datagram is the time of my ref slave. The following line calculates the current system_time of the ref slave clock.<br>system_time += correction;<br><br>Then the time_diff is calcuated as following<br>time_diff = fsm-&gt;slave-&gt;master-&gt;app_time - system_time;<br><br>The problem here however is that the fsm-&gt;slave-&gt;master-&gt;app_time is not the current app_time of the master. It is the app time set in ecrt_master_application_time() just before ecrt_master_send(master). So the current app_time of master should also be approximately calculated as<br>

fsm-&gt;slave-&gt;master-&gt;app_time + correction.<br><br>So the correct calculation for the current time_diff should be<br>time_diff = fsm-&gt;slave-&gt;master-&gt;app_time + correction - system_time;<br><br>Now the question is, why bother adding the correction(time interval since read) to the system_time, as the app_time was set by the user at about the same time when the system_time was read?<br><br>After commenting out the line 'system_time += correction;', I have now very small time diff between the master and the slave after restart, and the ec_fsm_slave_config_state_dc_sync_check goes way faster because the initial difference becomes small.<br><br>I hope this mail could also help those having the warning 'Slave did not sync after 5000 ms'.<br><br>Regards,<br>Jun<br><br><br><br>diff -r 9cdd7669dc0b master/fsm_master.c<br>--- a/master/fsm_master.c&nbsp;&nbsp;&nbsp; Thu Jan 10 17:36:41 2013 +0100<br>

+++ b/master/fsm_master.c&nbsp;&nbsp;&nbsp; Wed Jan 23 17:09:51 2013 +0100<br> <at>  <at>  -976,7 +976,7  <at>  <at> <br>&nbsp;<br>&nbsp;&nbsp;&nbsp;&nbsp; // correct read system time by elapsed time since read operation<br>&nbsp;&nbsp;&nbsp;&nbsp; correction = jiffies_since_read * 1000 / HZ * 1000000;<br>

-&nbsp;&nbsp;&nbsp; system_time32 += correction;<br>+//&nbsp;&nbsp;&nbsp; system_time32 += correction;<br>&nbsp;&nbsp;&nbsp;&nbsp; time_diff = (u32) slave-&gt;master-&gt;app_time - system_time32;<br>&nbsp;<br>&nbsp;&nbsp;&nbsp;&nbsp; EC_SLAVE_DBG(slave, 1, "DC 32 bit system time offset calculation:"<br>

 <at>  <at>  -1013,7 +1013,7  <at>  <at> <br>&nbsp;<br>&nbsp;&nbsp;&nbsp;&nbsp; // correct read system time by elapsed time since read operation<br>&nbsp;&nbsp;&nbsp;&nbsp; correction = (u64) (jiffies_since_read * 1000 / HZ) * 1000000;<br>-&nbsp;&nbsp;&nbsp; system_time += correction;<br>+//&nbsp;&nbsp;&nbsp; system_time += correction;<br>

&nbsp;&nbsp;&nbsp;&nbsp; time_diff = fsm-&gt;slave-&gt;master-&gt;app_time - system_time;<br>&nbsp;<br>&nbsp;&nbsp;&nbsp;&nbsp; EC_SLAVE_DBG(slave, 1, "DC 64 bit system time offset calculation:"</p></div>

Gmane