[etherlab-users] Slaves in PREOP state
Wettach
wettach at robotmakers.de
Thu Oct 6 13:24:50 CEST 2011
On 06.10.2011 12:00, etherlab-users-request at etherlab.org wrote:
> Send etherlab-users mailing list submissions to
> etherlab-users at 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-request at etherlab.org
>
> You can reach the person managing the list at
> etherlab-users-owner at 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. Re: Slaves in PREOP state (Jordi Blanch Carles)
> 2. Re: Slaves in PREOP state (Dr.-Ing. Wilhelm Hagemeister)
> 3. Re: Slaves in PREOP state (Jordi Blanch Carles)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Wed, 05 Oct 2011 13:26:34 +0200
> From: Jordi Blanch Carles <jordi_blanch at encopim.com>
> Subject: Re: [etherlab-users] Slaves in PREOP state
> To: etherlab-users at etherlab.org
> Message-ID: <20111005132634.012fsejfeo48k0cg at webmail.encopim.com>
> Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes";
> format="flowed"
>
> Hello everybody,
>
> as nobody is answering to my colleague's question, I've thought that
> maybe his explanation is difficult to understand, so I'll try to
> explain it in a clearer way.
>
> Our problem is that we have modified the mini.c example module to fit
> our modules: EK1101, EL4132, EL3102, EL2004. After compiling the
> module without errors, when we insmod it, we find that sometimes some
> modules get to the OP state and some others remain at the PREOP state
> or continuously changing among INIT, SAFEOP, PREOP, ... states.
> Everytime we insmod the mini module, the ethercat modules that really
> get the OP state are different, so it seems a random behavior.
>
> We have tried restarting the ethercat devices, restarting the ethercat
> master module, and all different kind of starting combinations, but no
> one is resulting in a good device initialization and/or a defined
> reproducible behavior, so we are completely lost with this problem.
>
> Does anybody know which can be the problem with that? How can we make
> sure that all modules enter the OP state after insmoding the module?
>
> Thank you in advance.
>
> Quoting carlos_jimenez at encopim.com:
>
>> Hello,
>>
>> I'm still doing tests but with all the examples the same thing happens
>> to me, I tried with the example of 'user', 'mini' and 'rtai', and all
>> appear to move modules OP mode or so 'random'.
>>
>> Once I managed to run all 4 modules (EL4132, EL3102, EL1004, EL2004) at
>> a time, but to stop the instance and then on and did not work, just put
>> me in the first module OP way connected.
>>
>> Anyone have any idea what could be the problem?
>>
>> Thank you in advance
>>
>> Quoting carlos_jimenez at encopim.com:
>>
>>> Dear Richard, thanks for your answer.
>>>
>>> I've tried with 'mini.c' example, I've changed the Beckhoff modules
>>> from the example by my modules configuration.
>>> I'm still having the same problem, although digital output works
>>> properly, analog input/output modules are not in 'OP' mode.
>>> At the output of 'dmesg' shows an error message that I don't understand.
>>>
>>> root at rtai:~/etherlabmaster/examples/mini# ethercat slaves
>>> 0 0:0 OP + EK1101 EtherCAT-Koppler (2A E-Bus, ID-Switch)
>>> 1 0:1 INIT + EL2004 4K. Dig. Ausgang 24V, 0.5A
>>> 2 0:2 PREOP + EL4132 2Ch. Ana. Ausgang +/-10V, 16bit
>>> 3 0:3 PREOP + EL3102 2K. Ana. Eingang +/-10V, Diff.
>>>
>>> root at rtai:~/etherlabmaster/examples/mini# dmesg
>>> ....
>>> EtherCAT 0: Domain 0: 10 working counter changes - now 2/5.
>>> ec_mini: Domain1: WC 2.
>>> ec_mini: Domain1: State 1.
>>> EtherCAT ERROR 0: No app_time received up to now, but master
>>> already active).
>>> ec_mini: Domain1: WC 0.
>>> ec_mini: Domain1: State 0.
>>> ec_mini: Domain1: WC 2.
>>> ec_mini: Domain1: State 1.
>>> EtherCAT ERROR 0: No app_time received up to now, but master
>>> already active).
>>> ec_mini: Domain1: WC 0.
>>> ec_mini: Domain1: State 0.
>>> ec_mini: Domain1: WC 2.
>>> ec_mini: Domain1: State 1.
>>> EtherCAT ERROR 0: No app_time received up to now, but master
>>> already active).
>>> ec_mini: Domain1: WC 0.
>>> ec_mini: Domain1: State 0.
>>> ec_mini: Domain1: WC 2.
>>> ec_mini: Domain1: State 1.
>>> EtherCAT ERROR 0: No app_time received up to now, but master
>>> already active).
>>> ec_mini: Domain1: WC 0.
>>> ec_mini: Domain1: State 0.
>>> ec_mini: Domain1: WC 2.
>>> ec_mini: Domain1: State 1.
>>> EtherCAT ERROR 0: No app_time received up to now, but master
>>> already active).
>>> EtherCAT 0: Domain 0: 8 working counter changes - now 2/5.
>>> ec_mini: Domain1: WC 0.
>>> ec_mini: Domain1: State 0.
>>> ec_mini: Domain1: WC 2.
>>> ec_mini: Domain1: State 1.
>>> EtherCAT ERROR 0: No app_time received up to now, but master
>>> already active).
>>> ec_mini: Domain1: WC 0.
>>> ec_mini: Domain1: State 0.
>>> ec_mini: Domain1: WC 2.
>>> ec_mini: Domain1: State 1.
>>> EtherCAT ERROR 0: No app_time received up to now, but master
>>> already active).
>>> ....
>>> ec_mini: Stopping...
>>> ec_mini: Releasing master...
>>> EtherCAT 0: Releasing master...
>>> EtherCAT 0: Master thread exited.
>>> EtherCAT 0: Starting EtherCAT-IDLE thread.
>>> EtherCAT 0: Released.
>>> ec_mini: Unloading.
>>>
>>>
>>>
>>> Quoting Richard Hacker <ha at igh-essen.com>:
>>>
>>>> On Friday 23 September 2011 16:42:00 carlos_jimenez at encopim.com wrote:
>>>>> Hello everybody,
>>>>> I've just started now with EtherCAT stuff and I'm having several
>>>>> problems.
>>>>> I have some Beckhoff modules to make tests, but when I try to run the
>>>>> example program, included in its code, I can't make it work all of them
>>>>> correctly. I have a digital outputs module (EL2004), another one of
>>>>> digital inputs (EL1004). One module of analog outputs (EL41342) and an
>>>>> other of analog inputs (EL3102). I also have the bus coupler (EK1101).
>>>>> I've modified rtai example to make them work, but I found problems in OP
>>>>> mode, not all of them get's slave status, and it doesn't work. Does
>>>>> somebody knows what it happens? I can't find where is the error. Thank
>>>>> you in advance. Here there is my code and my modules configuration:
>>>> Please take small steps.
>>>>
>>>> First of all, try the examples, such as mini.c and rtai_example.c.
>>>> Get them to
>>>> compile and load first. Change your hardware so that the examples
>>>> load. When
>>>> that works, you may start modifying in _small_ steps until you are
>>>> confident
>>>> enough to start your own projects.
>>>>
>>>> Apart from attaching the output of
>>>> ethercat slaves
>>>> also attach output
>>>> dmesg
>>>> (and please not everything, only the important parts!!)
>>>>
>>>> Mit freundlichem Gru?
>>>>
>>>> Richard Hacker
>>>>
>>>> --
>>>> ------------------------------------------------------------------------
>>>>
>>>> Richard Hacker M.Sc.
>>>> richard.hacker at igh-essen.com
>>>> 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. S. Rotth?user,
>>>> - Dr.-Ing. T. Finke,
>>>> - Dr.-Ing. W. Hagemeister
>>>> Tel.: +49 201 / 360-14-0
>>>> http://www.igh-essen.com
>>>>
>>>> ------------------------------------------------------------------------
>>>>
>>>
>>>
>>> --
>>> Carlos Jim?nez
>>>
>>> ENCOPIM S.L.
>>> C/. del Parc 5 (nau 13), P.I. Els Pinetons
>>> E-08291 RIPOLLET (Barcelona)
>>> Tel: (+34) 935 94 23 47
>>> Fax: (+34) 935 94 64 15
>>>
>>> ==========================================================
>>> La informaci?n contenida en la presente transmisi?n es confidencial y su
>>> uso ?nicamente est? permitido a su(s) destinatario(s). Si Ud. no es la
>>> persona destinataria de la presente transmisi?n, rogamos nos lo
>>> comunique de manera inmediata por tel?fono (+34 935 942 347) y destruya
>>> cualquier copia de la misma (tanto digitales como en papel).
>>>
>>> The information contained in this transmission is confidential and is
>>> intended only for the use of the addressee(s). If you are not the
>>> designated recipient of this transmission, please advise us immediately
>>> by telephone (+34 935 942 347) and destroy any copies (digital and
>>> paper).
>>> ==========================================================
>>> _______________________________________________
>>> etherlab-users mailing list
>>> etherlab-users at etherlab.org
>>> http://lists.etherlab.org/mailman/listinfo/etherlab-users
>>
>>
>> --
>> Carlos Jim?nez
>>
>> ENCOPIM S.L.
>> C/. del Parc 5 (nau 13), P.I. Els Pinetons
>> E-08291 RIPOLLET (Barcelona)
>> Tel: (+34) 935 94 23 47
>> Fax: (+34) 935 94 64 15
>>
>> ==========================================================
>> La informaci?n contenida en la presente transmisi?n es confidencial y su
>> uso ?nicamente est? permitido a su(s) destinatario(s). Si Ud. no es la
>> persona destinataria de la presente transmisi?n, rogamos nos lo
>> comunique de manera inmediata por tel?fono (+34 935 942 347) y destruya
>> cualquier copia de la misma (tanto digitales como en papel).
>>
>> The information contained in this transmission is confidential and is
>> intended only for the use of the addressee(s). If you are not the
>> designated recipient of this transmission, please advise us immediately
>> by telephone (+34 935 942 347) and destroy any copies (digital and
>> paper).
>> ==========================================================
>> _______________________________________________
>> etherlab-users mailing list
>> etherlab-users at etherlab.org
>> http://lists.etherlab.org/mailman/listinfo/etherlab-users
>
>
> Jordi Blanch Carles
> Unidad de Ensayo y Control
>
> ENCOPIM S.L.
> C/. del Parc, 5 (nave 13)
> P.I. Els Pinetons
> E-08291 RIPOLLET (Barcelona)
> Tel: (+34) 935 94 23 47
> Fax: (+34) 935 94 64 15
>
> ==========================================================
> La informaci?n contenida en la presente transmisi?n es confidencial y su
> uso ?nicamente est? permitido a su(s) destinatario(s). Si Ud. no es la
> persona destinataria de la presente transmisi?n, rogamos nos lo
> comunique de manera inmediata por tel?fono (+34 935 942 347) y destruya
> cualquier copia de la misma (tanto digitales como en papel).
>
> The information contained in this transmission is confidential and is
> intended only for the use of the addressee(s). If you are not the
> designated recipient of this transmission, please advise us immediately
> by telephone (+34 935 942 347) and destroy any copies (digital and
> paper).
> ======================================================
>
>
> ------------------------------
>
> Message: 2
> Date: Wed, 05 Oct 2011 18:02:03 +0200
> From: "Dr.-Ing. Wilhelm Hagemeister" <hm at igh-essen.com>
> Subject: Re: [etherlab-users] Slaves in PREOP state
> To: Jordi Blanch Carles <jordi_blanch at encopim.com>,
> etherlab-users at etherlab.org
> Message-ID: <4E8C7F7B.9070903 at igh-essen.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> Hello Jordi,
>
> this is a unknown behavior...
>
> please supply:
> - Kernel version
> - Ethercat version
> - Network card
> - Output of "ethercat master" (without running your sample program)
> - Output of "ethercat slaves" (without running your sample program)
> - Sample time of your sample program
>
> try your sample program with only one module and at a slow sample rate
> and with a different network adapter
>
> Regards Wilhelm.
>
> Am 05.10.2011 13:26, schrieb Jordi Blanch Carles:
>> Hello everybody,
>>
>> as nobody is answering to my colleague's question, I've thought that
>> maybe his explanation is difficult to understand, so I'll try to explain
>> it in a clearer way.
>>
>> Our problem is that we have modified the mini.c example module to fit
>> our modules: EK1101, EL4132, EL3102, EL2004. After compiling the module
>> without errors, when we insmod it, we find that sometimes some modules
>> get to the OP state and some others remain at the PREOP state or
>> continuously changing among INIT, SAFEOP, PREOP, ... states. Everytime
>> we insmod the mini module, the ethercat modules that really get the OP
>> state are different, so it seems a random behavior.
>>
>
> ------------------------------
>
> Message: 3
> Date: Thu, 06 Oct 2011 10:41:18 +0200
> From: Jordi Blanch Carles <jordi_blanch at encopim.com>
> Subject: Re: [etherlab-users] Slaves in PREOP state
> To: "Dr.-Ing. Wilhelm Hagemeister" <hm at igh-essen.com>
> Cc: etherlab-users at etherlab.org
> Message-ID: <20111006104118.5n7tyt9rswowggkk at webmail.encopim.com>
> Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes";
> format="flowed"
>
> Hello Wilhelm, here are your questions:
>
> Master:
> EtherCAT: Master driver devel unknown
> EtherCAT: 1 master waiting for devices.
> Intel(R) PRO/1000 Network Driver - version 7.3.21-k5-NAPI
> Copyright (c) 1999-2006 Intel Corporation.
> ec_e1000 0000:01:01.0: PCI->APIC IRQ transform: INT A -> IRQ 18
> ec_e1000 0000:01:01.0: setting latency timer to 64
> ec_e1000: 0000:01:01.0: e1000_probe: (PCI:33MHz:32-bit) 00:18:7d:00:e8:77
> EtherCAT: Accepting device 00:18:7D:00:E8:77 for master 0.
> EtherCAT 0: Starting EtherCAT-IDLE thread.
> ec_e1000: ec0: e1000_probe: Intel(R) PRO/1000 Network Connection
>
> kernel:
> Linux rtai 2.6.34 #2 SMP Wed Aug 31 13:31:18 CEST 2011 i686 GNU/Linux
>
> network:
> 01:01.0 Ethernet controller: Intel Corporation 82547GI Gigabit
> Ethernet Controller
>
> slaves:
> 0 0:0 PREOP + EK1101 EtherCAT-Koppler (2A E-Bus, ID-Switch)
> 1 0:1 PREOP + EL4132 2Ch. Ana. Ausgang +/-10V, 16bit
> 2 0:2 PREOP + EL3102 2K. Ana. Eingang +/-10V, Diff.
> 3 0:3 PREOP + EL2004 4K. Dig. Ausgang 24V, 0.5A
>
> Sampling time: 100 Hz -> 10ms
>
> ethercat:
> root at rtai:~/etherlabmaster/examples/mini# ethercat version
> IgH EtherCAT master devel unknown <------------ Development version
> 1.5 downloaded 1 month ago.
>
> We have also tried connecting only the EL2004 Digital Output module
> and connecting only the EL4132 Analog Output module and decreasing
> sample frequency to 50 Hz and the "erratic" behavior doesn't change,
> sometimes the modules get to the OP state and sometimes not.
>
> Thank you for your help!
>
> Quoting "Dr.-Ing. Wilhelm Hagemeister" <hm at igh-essen.com>:
>
>> Hello Jordi,
>>
>> this is a unknown behavior...
>>
>> please supply:
>> - Kernel version
>> - Ethercat version
>> - Network card
>> - Output of "ethercat master" (without running your sample program)
>> - Output of "ethercat slaves" (without running your sample program)
>> - Sample time of your sample program
>>
>> try your sample program with only one module and at a slow sample rate
>> and with a different network adapter
>>
>> Regards Wilhelm.
>>
>> Am 05.10.2011 13:26, schrieb Jordi Blanch Carles:
>>> Hello everybody,
>>>
>>> as nobody is answering to my colleague's question, I've thought that
>>> maybe his explanation is difficult to understand, so I'll try to explain
>>> it in a clearer way.
>>>
>>> Our problem is that we have modified the mini.c example module to fit
>>> our modules: EK1101, EL4132, EL3102, EL2004. After compiling the module
>>> without errors, when we insmod it, we find that sometimes some modules
>>> get to the OP state and some others remain at the PREOP state or
>>> continuously changing among INIT, SAFEOP, PREOP, ... states. Everytime
>>> we insmod the mini module, the ethercat modules that really get the OP
>>> state are different, so it seems a random behavior.
>>>
>
>
> Jordi Blanch Carles
> Unidad de Ensayo y Control
>
> ENCOPIM S.L.
> C/. del Parc, 5 (nave 13)
> P.I. Els Pinetons
> E-08291 RIPOLLET (Barcelona)
> Tel: (+34) 935 94 23 47
> Fax: (+34) 935 94 64 15
>
> ==========================================================
> La informaci?n contenida en la presente transmisi?n es confidencial y su
> uso ?nicamente est? permitido a su(s) destinatario(s). Si Ud. no es la
> persona destinataria de la presente transmisi?n, rogamos nos lo
> comunique de manera inmediata por tel?fono (+34 935 942 347) y destruya
> cualquier copia de la misma (tanto digitales como en papel).
>
> The information contained in this transmission is confidential and is
> intended only for the use of the addressee(s). If you are not the
> designated recipient of this transmission, please advise us immediately
> by telephone (+34 935 942 347) and destroy any copies (digital and
> paper).
> ======================================================
>
>
> ------------------------------
>
> _______________________________________________
> etherlab-users mailing list
> etherlab-users at etherlab.org
> http://lists.etherlab.org/mailman/listinfo/etherlab-users
>
>
> End of etherlab-users Digest, Vol 53, Issue 3
> *********************************************
Hello,
in the stable-1.5 branch of the ethercat master hg repository there was
a recent bugfix called "Fixed missing return causing slaves not going to
OP.
<http://etherlabmaster.hg.sourceforge.net/hgweb/etherlabmaster/etherlabmaster/rev/7dd86c484192>"
that solved this problem for me.
Regards,
Jens
More information about the Etherlab-users
mailing list