[etherlab-users] R: Re: R: Re: R: SDO stress
paluan.luca at tiscali.it
paluan.luca at tiscali.it
Tue May 28 16:22:15 CEST 2013
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
More information about the Etherlab-users
mailing list