[etherlab-users] R: Re: R: SDO stress
Raz
raziebe at gmail.com
Tue May 28 16:51:51 CEST 2013
I did not say i am sending R/W at the same super packet, and it is
impossible since there is a single datagram for coe.
I have the captures from the drives, and the packets are OK. ie, data does
arrive to the master interface card. yet there are no corruptions and no
unmatches.
On Tue, May 28, 2013 at 5:22 PM, paluan.luca at tiscali.it <
paluan.luca at tiscali.it> wrote:
>
> Multiple Sdo read or write operation at once is for sure an error
> source:
> this is one of the advices I received from servos vendor
> (Kollmorgen support).
> Only one read or one write at once or you'll get
> an error almost immediatly.
> Thanks for your answer.
> Best Regards, Luca
> Paluan
>
> ----Messaggio originale----
> Da: raziebe at gmail.com
> Data:
> 28/05/2013 15.52
> A: "paluan.luca at tiscali.it"<paluan.luca at tiscali.it>
>
> Cc: "etherlab-users at etherlab.org"<etherlab-users at etherlab.org>
> Ogg: Re:
> [etherlab-users] R: Re: R: SDO stress
>
> this problem does not relate to
> R/W , it can happen with just reads.
> The problem lies somewhere in the
> datagram state, for some reason, a
> datagram may be
> sent to to gather
> the mailbox response, but its state remains BUSY. this is
> stops the
> entire
> fsm from performing any other sdo related tasks, as depicted
> here:
>
> void ec_fsm_slave_exec(
> ec_fsm_slave_t *fsm /**< Slave
> state machine. */
> )
> {
> if (fsm->datagram->state ==
> EC_DATAGRAM_SENT
> || fsm->datagram->state == EC_DATAGRAM_QUEUED)
> {
> // datagram was not sent or received yet.
> return;
>
> }
>
> fsm->state(fsm);
> }
>
> code never executs fsm->state(fsm) because
> the top ( on queue) coe datagram
> remains in SENT state. i launched 8
> threads, each performs a sdo read, and
> got stuck in a few minutes. all
> but the top coe remained in the sdo_queue
> queue.
>
> Now, by capturing the
> network traffic i know that the packet is not sent.
> but i can see that
> the packet has changed its state to SENT, but it timed
> out ( i
> replaced wait_event_interruptible to the timed wait version in
>
> ecrt_master_sdo_upload ) .
>
>
>
>
>
> On Thu, May 23, 2013 at 8:15 PM, paluan.
> luca at tiscali.it <
> paluan.luca at tiscali.it> wrote:
>
> > Yes I'm using
> Kollmorgen Servos, I'll try spacing Sdo operation with
> > some idle
> cycles and see if that improves the reliability.
> > I wrote
> > Kollmorgen
> support and they just recommended not to overlap Sdo
> > requests.
> >
> Unfortunatly I cannot avoid Sdo operations during normal
> > cycle since
> some variables cannot be pdo mapped.
> > Thanks Luca
> >
> > ----
> > Messaggio
> originale----
> > Da: tbj at automateddesign.com
> > Data: 23/05/2013
> > 16.19
>
> > A: "paluan.luca at tiscali.it"<paluan.luca at tiscali.it>
> > Cc: "etherlab-
>
> > users at etherlab.org"<etherlab-users at etherlab.org>
> > Ogg: Re:
> [etherlab-
> > users] R: SDO stress
> >
> > This is probably a useless aside,
> but what servo
> > drive are you using? I
> > have nothing but problems
> with SDO reads and
> > writes on the Kollmorgen AKD
> > drive, regardless
> of the EtherCAT master
> > used. If I don't space them out by
> > 100ms or
> so, the drive gives
> > inconsistent responses. I've spent a year
> >
> trying to improve the
> > situation, but to no avail. My plan is to use
> the
> > EtherCAT master as
> > the controller so I can avoid SDO usage with
> the drive.
> >
> > Thomas C.
> > Bitsky Jr. | Lead Developer
> > ADC |
> automateddesign.com
> > P: 630-783-1150
> > F: 630-783-1159 M: 630-632-6679
>
> >
> >
> > On Thu, May 23, 2013 at 5:10 AM,
> > paluan.luca at tiscali.it <
> >
> paluan.luca at tiscali.it> wrote:
> >
> > >
> > >
> > > Hello,
> > >
> > I've been
> struggling with Sdo write since 3 mounths without a
> > >
> > solution up
> to now.
> > > I wrote a stress test which writes and reads what
> >
> > >
> written on three Sdo for three Servos in a preemptive real time loop:
> >
>
> > >
> > > after some hours of work the application hangs and the ethercat
>
> > master
> > > shows a download/upload Sdo Timeout error problem.
> > >
> I've
> > checked that
> > > only one read or one write takes place at a
> time, for
> > example:
> > > start
> > > write SDO1 for first servo
> > > end
> write SDO1 for
> > first servo
> > > start read
> > > SDO1 for first servo
> >
> > end read SDO1 for
> > first servo
> > > start write SDO2 for
> > > first
> servo
> > > end write SDO2 for
> > first servo
> > > start read SDO2 for
> first
> > > servo
> > > end read SDO2 for
> > first servo
> > > ...
> > > start
> write SDO1 for second
> > > servo
> > > end write
> > SDO1 for second servo
> >
> > start read SDO1 for second servo
> > >
> > > end read
> > SDO1 for second
> servo
> > > start write SDO2 for second servo
> > > end
> > > write
> > SDO2
> for second servo
> > > start read SDO2 for second servo
> > > end read
> > >
>
> > SDO2 for second servo
> > > ....
> > > So each write doesn't overlap each
> read
> > for
> > > each servo.
> > > As far as I know managing Sdo inside
> real time loop
> > is not
> > > reliable: I mean it usually works, but for
> a software which
> > manages
> > > Servos is not enough.
> > > If someone has
> advices or suggestions
> > is welcome.
> > >
> > > Best Regards, Luca Paluan
>
> > >
> > > ----Messaggio
> > originale----
> > > Da:
> > > RBenYehuda at manz.com
> >
> > Data: 22/05/2013 13.36
> > > A:
> > "etherlab-users at etherlab.
> > > org"
> <etherlab-users at etherlab.org>
> > > Ogg:
> > [etherlab-users] SDO stress
> >
> >
> > > Hey
> > >
> > >
> > > I have been tracking the
> > following problem:
> > >
> I generate bulk of sdo
> > > reads and sdo writes (
> > upload /
> downloads). after some time the sdo
> > > read
> > > hangs. I made a
> >
> capture with tcpdump and noticed that the
> > > failure lies in etherlab.
>
> > it appears that
> > > after some time etherlab
> > > does not try to send
> a
> > mail box response read from the mailbox, even
> > > though
> > > the
> slave
> > "said" he has the data available ( by replying to read
> > >
> request).
> > >
> > Why this bug fixed ?
> > >
> > > thank you
> > > raz
> > >
> > >
>
> > >
> > _______________________________________________
> > > etherlab-
> users
> > mailing
> > > list
> > > etherlab-users at etherlab.org
> > > http:
> //lists.etherlab.
> > >
> > org/mailman/listinfo/etherlab-users
> > >
> > >
> > >
>
> > >
> > > Senza L’IMU il mercato
> > immobiliare potrebbe riprendersi.
> Inizia ora la
> > > ricerca della tua
> > Casa! http://tiscali.casa.
> it/vendita?partner=Tiscali
> > >
> >
> _______________________________________________
> > > etherlab-users
> >
> mailing list
> > > etherlab-users at etherlab.org
> > > http://lists.etherlab.
>
> > org/mailman/listinfo/etherlab-users
> > >
> >
> >
> >
> >
> > Senza L’IMU il
> mercato immobiliare potrebbe riprendersi. Inizia ora la
> > ricerca della
> tua Casa! http://tiscali.casa.it/vendita?partner=Tiscali
> >
> _______________________________________________
> > etherlab-users
> mailing list
> > etherlab-users at etherlab.org
> > http://lists.etherlab.
> org/mailman/listinfo/etherlab-users
> >
>
>
>
> --
> https://sites.google.
> com/site/ironspeedlinux/
>
>
>
>
>
> Senza L’IMU il mercato immobiliare potrebbe riprendersi. Inizia ora la
> ricerca della tua Casa! http://tiscali.casa.it/vendita?partner=Tiscali
>
--
https://sites.google.com/site/ironspeedlinux/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.etherlab.org/pipermail/etherlab-users/attachments/20130528/b1721baf/attachment-0005.htm>
More information about the Etherlab-users
mailing list