<div dir="ltr"><div><div><div><div><div><div>this problem does not relate to R/W , it can happen with just reads. <br></div>The problem lies somewhere in the datagram state, for some reason, a datagram may be <br></div>sent to to gather the mailbox response, but its state remains BUSY. this is stops the entire<br>
</div>fsm from performing any other sdo related tasks, as depicted here:<br><br>void ec_fsm_slave_exec(<br> ec_fsm_slave_t *fsm /**< Slave state machine. */<br> ) <br>{ <br> if (fsm->datagram->state == EC_DATAGRAM_SENT<br>
|| fsm->datagram->state == EC_DATAGRAM_QUEUED) {<br> // datagram was not sent or received yet.<br> return; <br> } <br> <br> fsm->state(fsm);<br>}<br><br></div>
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.<br>
</div><br>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 ) .<br>
<br><br></div><div><div><div> <br></div></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, May 23, 2013 at 8:15 PM, <a href="mailto:paluan.luca@tiscali.it" target="_blank">paluan.luca@tiscali.it</a> <span dir="ltr"><<a href="mailto:paluan.luca@tiscali.it" target="_blank">paluan.luca@tiscali.it</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Yes I'm using Kollmorgen Servos, I'll try spacing Sdo operation with<br>
some idle cycles and see if that improves the reliability.<br>
I wrote<br>
Kollmorgen support and they just recommended not to overlap Sdo<br>
requests.<br>
Unfortunatly I cannot avoid Sdo operations during normal<br>
cycle since some variables cannot be pdo mapped.<br>
Thanks Luca<br>
<br>
----<br>
Messaggio originale----<br>
Da: <a href="mailto:tbj@automateddesign.com" target="_blank">tbj@automateddesign.com</a><br>
Data: 23/05/2013<br>
16.19<br>
A: "<a href="mailto:paluan.luca@tiscali.it" target="_blank">paluan.luca@tiscali.it</a>"<<a href="mailto:paluan.luca@tiscali.it" target="_blank">paluan.luca@tiscali.it</a>><br>
Cc: "etherlab-<br>
<a href="mailto:users@etherlab.org" target="_blank">users@etherlab.org</a>"<<a href="mailto:etherlab-users@etherlab.org" target="_blank">etherlab-users@etherlab.org</a>><br>
Ogg: Re: [etherlab-<br>
users] R: SDO stress<br>
<div><div><br>
This is probably a useless aside, but what servo<br>
drive are you using? I<br>
have nothing but problems with SDO reads and<br>
writes on the Kollmorgen AKD<br>
drive, regardless of the EtherCAT master<br>
used. If I don't space them out by<br>
100ms or so, the drive gives<br>
inconsistent responses. I've spent a year<br>
trying to improve the<br>
situation, but to no avail. My plan is to use the<br>
EtherCAT master as<br>
the controller so I can avoid SDO usage with the drive.<br>
<br>
Thomas C.<br>
Bitsky Jr. | Lead Developer<br>
ADC | <a href="http://automateddesign.com" target="_blank">automateddesign.com</a><br>
P: <a href="tel:630-783-1150" value="+16307831150" target="_blank">630-783-1150</a><br>
F: <a href="tel:630-783-1159" value="+16307831159" target="_blank">630-783-1159</a> M: <a href="tel:630-632-6679" value="+16306326679" target="_blank">630-632-6679</a><br>
<br>
<br>
On Thu, May 23, 2013 at 5:10 AM,<br>
<a href="mailto:paluan.luca@tiscali.it" target="_blank">paluan.luca@tiscali.it</a> <<br>
<a href="mailto:paluan.luca@tiscali.it" target="_blank">paluan.luca@tiscali.it</a>> wrote:<br>
<br>
><br>
><br>
> Hello,<br>
><br>
I've been struggling with Sdo write since 3 mounths without a<br>
><br>
solution up to now.<br>
> I wrote a stress test which writes and reads what<br>
<br>
> written on three Sdo for three Servos in a preemptive real time loop:<br>
<br>
><br>
> after some hours of work the application hangs and the ethercat<br>
master<br>
> shows a download/upload Sdo Timeout error problem.<br>
> I've<br>
checked that<br>
> only one read or one write takes place at a time, for<br>
example:<br>
> start<br>
> write SDO1 for first servo<br>
> end write SDO1 for<br>
first servo<br>
> start read<br>
> SDO1 for first servo<br>
> end read SDO1 for<br>
first servo<br>
> start write SDO2 for<br>
> first servo<br>
> end write SDO2 for<br>
first servo<br>
> start read SDO2 for first<br>
> servo<br>
> end read SDO2 for<br>
first servo<br>
> ...<br>
> start write SDO1 for second<br>
> servo<br>
> end write<br>
SDO1 for second servo<br>
> start read SDO1 for second servo<br>
><br>
> end read<br>
SDO1 for second servo<br>
> start write SDO2 for second servo<br>
> end<br>
> write<br>
SDO2 for second servo<br>
> start read SDO2 for second servo<br>
> end read<br>
><br>
SDO2 for second servo<br>
> ....<br>
> So each write doesn't overlap each read<br>
for<br>
> each servo.<br>
> As far as I know managing Sdo inside real time loop<br>
is not<br>
> reliable: I mean it usually works, but for a software which<br>
manages<br>
> Servos is not enough.<br>
> If someone has advices or suggestions<br>
is welcome.<br>
><br>
> Best Regards, Luca Paluan<br>
><br>
> ----Messaggio<br>
originale----<br>
> Da:<br>
> <a href="mailto:RBenYehuda@manz.com" target="_blank">RBenYehuda@manz.com</a><br>
> Data: 22/05/2013 13.36<br>
> A:<br>
"etherlab-users@etherlab.<br>
> org"<<a href="mailto:etherlab-users@etherlab.org" target="_blank">etherlab-users@etherlab.org</a>><br>
> Ogg:<br>
[etherlab-users] SDO stress<br>
><br>
> Hey<br>
><br>
><br>
> I have been tracking the<br>
following problem:<br>
> I generate bulk of sdo<br>
> reads and sdo writes (<br>
upload / downloads). after some time the sdo<br>
> read<br>
> hangs. I made a<br>
capture with tcpdump and noticed that the<br>
> failure lies in etherlab.<br>
it appears that<br>
> after some time etherlab<br>
> does not try to send a<br>
mail box response read from the mailbox, even<br>
> though<br>
> the slave<br>
"said" he has the data available ( by replying to read<br>
> request).<br>
><br>
Why this bug fixed ?<br>
><br>
> thank you<br>
> raz<br>
><br>
><br>
><br>
_______________________________________________<br>
> etherlab-users<br>
mailing<br>
> list<br>
> <a href="mailto:etherlab-users@etherlab.org" target="_blank">etherlab-users@etherlab.org</a><br>
> <a href="http://lists.etherlab" target="_blank">http://lists.etherlab</a>.<br>
><br>
org/mailman/listinfo/etherlab-users<br>
><br>
><br>
><br>
><br>
> Senza L’IMU il mercato<br>
immobiliare potrebbe riprendersi. Inizia ora la<br>
> ricerca della tua<br>
Casa! <a href="http://tiscali.casa.it/vendita?partner=Tiscali" target="_blank">http://tiscali.casa.it/vendita?partner=Tiscali</a><br>
><br>
_______________________________________________<br>
> etherlab-users<br>
mailing list<br>
> <a href="mailto:etherlab-users@etherlab.org" target="_blank">etherlab-users@etherlab.org</a><br>
> <a href="http://lists.etherlab" target="_blank">http://lists.etherlab</a>.<br>
org/mailman/listinfo/etherlab-users<br>
><br>
<br>
<br>
<br>
<br>
Senza L’IMU il mercato immobiliare potrebbe riprendersi. Inizia ora la ricerca della tua Casa! <a href="http://tiscali.casa.it/vendita?partner=Tiscali" target="_blank">http://tiscali.casa.it/vendita?partner=Tiscali</a><br>
_______________________________________________<br>
etherlab-users mailing list<br>
<a href="mailto:etherlab-users@etherlab.org" target="_blank">etherlab-users@etherlab.org</a><br>
<a href="http://lists.etherlab.org/mailman/listinfo/etherlab-users" target="_blank">http://lists.etherlab.org/mailman/listinfo/etherlab-users</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br><div dir="ltr"><div><a href="https://sites.google.com/site/ironspeedlinux/" target="_blank">https://sites.google.com/site/ironspeedlinux/</a></div></div>
</div></div>