On 06.10.2011 12:00, [email protected] wrote: > Send etherlab-users mailing list submissions to > [email protected] > > 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 > [email protected] > > You can reach the person managing the list at > [email protected] > > 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 <[email protected]> > Subject: Re: [etherlab-users] Slaves in PREOP state > To: [email protected] > Message-ID: <[email protected]> > 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 [email protected]: > >> 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 [email protected]: >> >>> 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@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@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 <[email protected]>: >>> >>>> On Friday 23 September 2011 16:42:00 [email protected] 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. >>>> [email protected] >>>> 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 >>> [email protected] >>> 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 >> [email protected] >> 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" <[email protected]> > Subject: Re: [etherlab-users] Slaves in PREOP state > To: Jordi Blanch Carles <[email protected]>, > [email protected] > Message-ID: <[email protected]> > 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 <[email protected]> > Subject: Re: [etherlab-users] Slaves in PREOP state > To: "Dr.-Ing. Wilhelm Hagemeister" <[email protected]> > Cc: [email protected] > Message-ID: <[email protected]> > 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@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" <[email protected]>: > >> 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 > [email protected] > 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 _______________________________________________ etherlab-users mailing list [email protected] http://lists.etherlab.org/mailman/listinfo/etherlab-users
