[etherlab-users] R: Re: Re: R: Re: R: SDO stress

paluan.luca at tiscali.it paluan.luca at tiscali.it
Wed May 29 09:13:58 CEST 2013 

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

More information about the Etherlab-users mailing list