<div dir="ltr"><div>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.<br></div>yet, i still wonder what the bug is.<br></div><div class="gmail_extra">

<br><br><div class="gmail_quote">On Wed, May 29, 2013 at 10:13 AM, <a href="mailto:paluan.luca@tiscali.it">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">Maybe some race conditions can happen if multiple reads or writes even<br>
on different<br>
drives take place at the same time due to datagram<br>
overlappings.<br>
Writing my test program I improved a lot reliability<br>
reading or writing one SDO value<br>
at once.<br>
This is just what I<br>
experienced.<br>
<div class="im"><br>
----Messaggio originale----<br>
Da: <a href="mailto:raziebe@gmail.com">raziebe@gmail.com</a><br>
Data:<br>
</div>28/05/2013 16.51<br>
<div class="im">A: "<a href="mailto:paluan.luca@tiscali.it">paluan.luca@tiscali.it</a>"<<a href="mailto:paluan.luca@tiscali.it">paluan.luca@tiscali.it</a>><br>
<br>
Cc: "<a href="mailto:etherlab-users@etherlab.org">etherlab-users@etherlab.org</a>"<<a href="mailto:etherlab-users@etherlab.org">etherlab-users@etherlab.org</a>><br>
Ogg: Re:<br>
Re: [etherlab-users] R: Re: R: SDO stress<br>
<br>
</div><div class="im">I did not say i am sending<br>
R/W at the same super packet, and it is<br>
impossible since there is a<br>
single datagram for coe.<br>
I have the captures from the drives, and the<br>
packets are OK. ie, data does<br>
arrive to the master interface card. yet<br>
there are no corruptions and no<br>
unmatches.<br>
<br>
<br>
<br>
</div><div class="im">On Tue, May 28, 2013 at 5:<br>
</div><div class="im">22 PM, <a href="mailto:paluan.luca@tiscali.it">paluan.luca@tiscali.it</a> <<br>
<a href="mailto:paluan.luca@tiscali.it">paluan.luca@tiscali.it</a>> wrote:<br>
<br>
><br>
><br>
Multiple Sdo read or write operation at once is for sure an error<br>
><br>
source:<br>
> this is one of the advices I received from servos vendor<br>
><br>
(Kollmorgen support).<br>
> Only one read or one write at once or you'll<br>
get<br>
> an error almost immediatly.<br>
> Thanks for your answer.<br>
</div><div class="im">> Best<br>
Regards, Luca<br>
> Paluan<br>
><br>
> ----Messaggio originale----<br>
> Da:<br>
</div><a href="mailto:raziebe@gmail.com">raziebe@gmail.com</a><br>
> Data:<br>
> 28/05/2013 15.52<br>
> A: "paluan.luca@tiscali.<br>
it"<<a href="mailto:paluan.luca@tiscali.it">paluan.luca@tiscali.it</a>><br>
><br>
<div class="im">> Cc: "<a href="mailto:etherlab-users@etherlab.org">etherlab-users@etherlab.org</a>"<br>
<<a href="mailto:etherlab-users@etherlab.org">etherlab-users@etherlab.org</a>><br>
> Ogg: Re:<br>
> [etherlab-users] R: Re: R:<br>
SDO stress<br>
><br>
</div><div><div class="h5">> this problem does not relate to<br>
> R/W , it can happen<br>
with just reads.<br>
> The problem lies somewhere in the<br>
> datagram state,<br>
for some reason, a<br>
> datagram may be<br>
> sent to to gather<br>
> the mailbox<br>
response, but its state remains BUSY. this is<br>
> stops the<br>
> entire<br>
><br>
fsm from performing any other sdo related tasks, as depicted<br>
> here:<br>
><br>
<br>
> void ec_fsm_slave_exec(<br>
>         ec_fsm_slave_t *fsm /**< Slave<br>
><br>
state machine. */<br>
>         )<br>
> {<br>
>     if (fsm->datagram->state ==<br>
><br>
EC_DATAGRAM_SENT<br>
>         || fsm->datagram->state ==<br>
EC_DATAGRAM_QUEUED)<br>
> {<br>
>         // datagram was not sent or received<br>
yet.<br>
>         return;<br>
><br>
> }<br>
><br>
>     fsm->state(fsm);<br>
> }<br>
><br>
> code<br>
never executs fsm->state(fsm) because<br>
> the top ( on queue) coe<br>
datagram<br>
> remains in SENT state. i launched 8<br>
> threads, each performs<br>
a sdo read, and<br>
> got stuck in a few minutes. all<br>
> but the top coe<br>
remained in the sdo_queue<br>
> queue.<br>
><br>
> Now, by capturing the<br>
> network<br>
traffic i know that the packet is not sent.<br>
> but i can see that<br>
> the<br>
packet has changed its state to SENT, but it timed<br>
> out ( i<br>
><br>
replaced  wait_event_interruptible to the timed wait version in<br>
><br>
><br>
ecrt_master_sdo_upload ) .<br>
><br>
><br>
><br>
><br>
><br>
> On Thu, May 23, 2013 at 8:15 PM,<br>
paluan.<br>
> <a href="mailto:luca@tiscali.it">luca@tiscali.it</a> <<br>
> <a href="mailto:paluan.luca@tiscali.it">paluan.luca@tiscali.it</a>> wrote:<br>
><br>
> > Yes<br>
I'm using<br>
> Kollmorgen Servos, I'll try spacing Sdo operation with<br>
> ><br>
some idle<br>
> cycles and see if that improves the reliability.<br>
> > I<br>
wrote<br>
> > Kollmorgen<br>
> support and they just recommended not to overlap<br>
Sdo<br>
> > requests.<br>
> ><br>
> Unfortunatly I cannot avoid Sdo operations<br>
during normal<br>
> > cycle since<br>
> some variables cannot be pdo mapped.<br>
><br>
> Thanks Luca<br>
> ><br>
> > ----<br>
> > Messaggio<br>
> originale----<br>
> > Da:<br>
<a href="mailto:tbj@automateddesign.com">tbj@automateddesign.com</a><br>
> > Data: 23/05/2013<br>
> > 16.19<br>
><br>
> > A: "paluan.<br>
<a href="mailto:luca@tiscali.it">luca@tiscali.it</a>"<<a href="mailto:paluan.luca@tiscali.it">paluan.luca@tiscali.it</a>><br>
> > Cc: "etherlab-<br>
><br>
> ><br>
<a href="mailto:users@etherlab.org">users@etherlab.org</a>"<<a href="mailto:etherlab-users@etherlab.org">etherlab-users@etherlab.org</a>><br>
> > Ogg: Re:<br>
><br>
[etherlab-<br>
> > users] R: SDO stress<br>
> ><br>
> > This is probably a useless<br>
aside,<br>
> but what servo<br>
> > drive are you using? I<br>
> > have nothing but<br>
problems<br>
> with SDO reads and<br>
> > writes on the Kollmorgen AKD<br>
> ><br>
drive, regardless<br>
> of the EtherCAT master<br>
> > used. If I don't space<br>
them out by<br>
> > 100ms or<br>
> so, the drive gives<br>
> > inconsistent<br>
responses. I've spent a year<br>
> ><br>
> trying to improve the<br>
> > situation,<br>
but to no avail. My plan is to use<br>
> the<br>
> > EtherCAT master as<br>
> > the<br>
controller so I can avoid SDO usage with<br>
> the drive.<br>
> ><br>
> > Thomas C.<br>
<br>
> > Bitsky Jr. | Lead Developer<br>
> > ADC |<br>
> <a href="http://automateddesign.com" target="_blank">automateddesign.com</a><br>
> > P:<br>
<a href="tel:630-783-1150" value="+16307831150">630-783-1150</a><br>
> > F: <a href="tel:630-783-1159" value="+16307831159">630-783-1159</a> M: <a href="tel:630-632-6679" value="+16306326679">630-632-6679</a><br>
><br>
> ><br>
> ><br>
> > On Thu,<br>
May 23, 2013 at 5:10 AM,<br>
> > <a href="mailto:paluan.luca@tiscali.it">paluan.luca@tiscali.it</a> <<br>
> ><br>
> paluan.<br>
<a href="mailto:luca@tiscali.it">luca@tiscali.it</a>> wrote:<br>
> ><br>
> > ><br>
> > ><br>
> > > Hello,<br>
> > ><br>
> > I've<br>
been<br>
> struggling with Sdo write since 3 mounths without a<br>
> > ><br>
> ><br>
solution up<br>
> to now.<br>
> > > I wrote a stress test which writes and<br>
reads what<br>
> ><br>
> > ><br>
> written on three Sdo for three Servos in a<br>
preemptive real time loop:<br>
> ><br>
><br>
> > ><br>
> > > after some hours of work<br>
the application hangs and the ethercat<br>
><br>
> > master<br>
> > > shows a<br>
download/upload Sdo Timeout error problem.<br>
> > ><br>
> I've<br>
> > checked<br>
that<br>
> > > only one read or one write takes place at a<br>
> time, for<br>
> ><br>
example:<br>
> > > start<br>
> > > write SDO1 for first servo<br>
> > > end<br>
> write<br>
SDO1 for<br>
> > first servo<br>
> > > start read<br>
> > > SDO1 for first servo<br>
><br>
><br>
> > end read SDO1 for<br>
> > first servo<br>
> > > start write SDO2 for<br>
> ><br>
> first<br>
> servo<br>
> > > end write SDO2 for<br>
> > first servo<br>
> > > start<br>
read SDO2 for<br>
> first<br>
> > > servo<br>
> > > end read SDO2 for<br>
> > first<br>
servo<br>
> > > ...<br>
> > > start<br>
> write SDO1 for second<br>
> > > servo<br>
> > ><br>
end write<br>
> > SDO1 for second servo<br>
> ><br>
> > start read SDO1 for second<br>
servo<br>
> > ><br>
> > > end read<br>
> > SDO1 for second<br>
> servo<br>
> > > start<br>
write SDO2 for second servo<br>
> > > end<br>
> > > write<br>
> > SDO2<br>
> for second<br>
servo<br>
> > > start read SDO2 for second servo<br>
> > > end read<br>
> > ><br>
><br>
> ><br>
SDO2 for second servo<br>
> > > ....<br>
> > > So each write doesn't overlap<br>
each<br>
> read<br>
> > for<br>
> > > each servo.<br>
> > > As far as I know managing<br>
Sdo inside<br>
> real time loop<br>
> > is not<br>
> > > reliable: I mean it<br>
usually works, but for<br>
> a software which<br>
> > manages<br>
> > > Servos is<br>
not enough.<br>
> > > If someone has<br>
> advices or suggestions<br>
> > is<br>
welcome.<br>
> > ><br>
> > > Best Regards, Luca Paluan<br>
><br>
> > ><br>
> > > ----<br>
Messaggio<br>
> > originale----<br>
> > > Da:<br>
> > > <a href="mailto:RBenYehuda@manz.com">RBenYehuda@manz.com</a><br>
> ><br>
> ><br>
Data: 22/05/2013 13.36<br>
> > > A:<br>
> > "etherlab-users@etherlab.<br>
> > ><br>
org"<br>
> <<a href="mailto:etherlab-users@etherlab.org">etherlab-users@etherlab.org</a>><br>
> > > Ogg:<br>
> > [etherlab-users]<br>
SDO stress<br>
> ><br>
> ><br>
> > > Hey<br>
> > ><br>
> > ><br>
> > > I have been tracking the<br>
<br>
> > following problem:<br>
> > ><br>
> I generate bulk of sdo<br>
> > > reads and<br>
sdo writes (<br>
> > upload /<br>
> downloads).  after some time the sdo<br>
> > ><br>
read<br>
> > > hangs.  I made a<br>
> ><br>
> capture with tcpdump and noticed that<br>
the<br>
> > > failure lies in etherlab.<br>
><br>
> > it appears that<br>
> > > after<br>
some time etherlab<br>
> > > does not try to send<br>
> a<br>
> > mail box response<br>
read from the mailbox, even<br>
> > > though<br>
> > > the<br>
> slave<br>
> > "said"<br>
he has the data available ( by replying to read<br>
> > ><br>
> request).<br>
> > ><br>
<br>
> > Why this bug fixed ?<br>
> > ><br>
> > > thank you<br>
> > > raz<br>
> > ><br>
> > ><br>
><br>
<br>
> > ><br>
> > _______________________________________________<br>
> > ><br>
etherlab-<br>
> users<br>
> > mailing<br>
> > > list<br>
> > > etherlab-users@etherlab.<br>
org<br>
> > > http:<br>
> //lists.etherlab.<br>
> > ><br>
> ><br>
org/mailman/listinfo/etherlab-users<br>
> > ><br>
> > ><br>
> > ><br>
><br>
> > ><br>
> > ><br>
Senza L’IMU il mercato<br>
> > immobiliare potrebbe riprendersi.<br>
> Inizia<br>
ora la<br>
> > > ricerca della tua<br>
> > Casa!  <a href="http://tiscali.casa" target="_blank">http://tiscali.casa</a>.<br>
><br>
it/vendita?partner=Tiscali<br>
> > ><br>
> ><br>
><br>
_______________________________________________<br>
> > > etherlab-users<br>
><br>
><br>
> mailing list<br>
> > > <a href="mailto:etherlab-users@etherlab.org">etherlab-users@etherlab.org</a><br>
> > > <a href="http://lists" target="_blank">http://lists</a>.<br>
etherlab.<br>
><br>
> > org/mailman/listinfo/etherlab-users<br>
> > ><br>
> ><br>
> ><br>
> ><br>
><br>
><br>
> > Senza L’IMU il<br>
> mercato immobiliare potrebbe riprendersi. Inizia<br>
ora la<br>
> > ricerca della<br>
> tua Casa!  <a href="http://tiscali.casa.it/vendita" target="_blank">http://tiscali.casa.it/vendita</a>?<br>
partner=Tiscali<br>
> ><br>
> _______________________________________________<br>
><br>
> etherlab-users<br>
> mailing list<br>
> > <a href="mailto:etherlab-users@etherlab.org">etherlab-users@etherlab.org</a><br>
> ><br>
<a href="http://lists.etherlab" target="_blank">http://lists.etherlab</a>.<br>
> org/mailman/listinfo/etherlab-users<br>
> ><br>
><br>
><br>
><br>
<br>
</div></div>> --<br>
> <a href="https://sites.google" target="_blank">https://sites.google</a>.<br>
> com/site/ironspeedlinux/<br>
<div class="im HOEnZb">><br>
><br>
><br>
><br>
><br>
><br>
Senza L’IMU il mercato immobiliare potrebbe riprendersi. Inizia ora la<br>
<br>
> ricerca della tua Casa!  <a href="http://tiscali.casa.it/vendita" target="_blank">http://tiscali.casa.it/vendita</a>?<br>
partner=Tiscali<br>
><br>
<br>
<br>
<br>
</div><span class="HOEnZb"><font color="#888888">--<br>
<a href="https://sites.google.com/site/ironspeedlinux/" target="_blank">https://sites.google.com/site/ironspeedlinux/</a><br>
</font></span><div class="HOEnZb"><div class="h5"><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>


</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>