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

[paluan.luca at tiscali.it]

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