[etherlab-users] R: Re: R: SDO stress

[Raz]

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.luca at tiscali.it <
paluan.luca at tiscali.it> 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: tbj at automateddesign.com
> Data: 23/05/2013
> 16.19
> A: "paluan.luca at tiscali.it"<paluan.luca at tiscali.it>
> Cc: "etherlab-
> users at etherlab.org"<etherlab-users at etherlab.org>
> 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,
> paluan.luca at tiscali.it <
> paluan.luca at tiscali.it> 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:
> > RBenYehuda at manz.com
> > Data: 22/05/2013 13.36
> > A:
> "etherlab-users at etherlab.
> > org"<etherlab-users at etherlab.org>
> > 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 at 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
> > etherlab-users at 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
> etherlab-users at etherlab.org
> http://lists.etherlab.org/mailman/listinfo/etherlab-users
>



-- 
https://sites.google.com/site/ironspeedlinux/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.etherlab.org/pipermail/etherlab-users/attachments/20130528/00adf7b8/attachment-0005.htm>