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