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 _______________________________________________ etherlab-users mailing list [email protected] http://lists.etherlab.org/mailman/listinfo/etherlab-users
