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. yet, i still wonder what the bug is.
On Wed, May 29, 2013 at 10:13 AM, [email protected] < [email protected]> wrote: > Maybe some race conditions can happen if multiple reads or writes even > on different > drives take place at the same time due to datagram > overlappings. > Writing my test program I improved a lot reliability > reading or writing one SDO value > at once. > This is just what I > experienced. > > ----Messaggio originale---- > Da: [email protected] > Data: > 28/05/2013 16.51 > A: "[email protected]"<[email protected]> > > Cc: "[email protected]"<[email protected]> > Ogg: Re: > Re: [etherlab-users] R: Re: R: SDO stress > > 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. > 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. > > > > On Tue, May 28, 2013 at 5: > 22 PM, [email protected] < > [email protected]> wrote: > > > > > > 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: > [email protected] > > Data: > > 28/05/2013 15.52 > > A: "paluan.luca@tiscali. > it"<[email protected]> > > > > Cc: "[email protected]" > <[email protected]> > > 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. > > [email protected] < > > [email protected]> 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: > [email protected] > > > Data: 23/05/2013 > > > 16.19 > > > > > A: "paluan. > [email protected]"<[email protected]> > > > Cc: "etherlab- > > > > > > [email protected]"<[email protected]> > > > 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, > > > [email protected] < > > > > > paluan. > [email protected]> 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: > > > > [email protected] > > > > > > > Data: 22/05/2013 13.36 > > > > A: > > > "etherlab-users@etherlab. > > > > > org" > > <[email protected]> > > > > 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@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 > > > > [email protected] > > > > 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 > > > [email protected] > > > > 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 > > > > > > -- > 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 > -- https://sites.google.com/site/ironspeedlinux/
_______________________________________________ etherlab-users mailing list [email protected] http://lists.etherlab.org/mailman/listinfo/etherlab-users
