[etherlab-users] R: Re: R: SDO stress
Raz
raziebe at gmail.com
Wed May 29 10:43:57 CEST 2013
i totally agree with you. i can see that as well. i know that if i lock
upload/download with a mutex system passes a nightly stress test.
yet, i still wonder what the bug is.
On Wed, May 29, 2013 at 10:13 AM, paluan.luca at tiscali.it <
paluan.luca at tiscali.it> wrote:
> Maybe some race conditions can happen if multiple reads or writes even
> on different
> drives take place at the same time due to datagram
> overlappings.
> Writing my test program I improved a lot reliability
> reading or writing one SDO value
> at once.
> This is just what I
> experienced.
>
> ----Messaggio originale----
> Da: raziebe at gmail.com
> Data:
> 28/05/2013 16.51
> A: "paluan.luca at tiscali.it"<paluan.luca at tiscali.it>
>
> Cc: "etherlab-users at etherlab.org"<etherlab-users at etherlab.org>
> Ogg: Re:
> Re: [etherlab-users] R: Re: R: SDO stress
>
> 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/
>
>
>
>
>
>
> 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/20130529/422a7ee2/attachment-0005.htm>
More information about the Etherlab-users
mailing list