[etherlab-users] R: R: Random Datagram Unmatched

Wed May 22 02:29:38 CEST 2019

Hi Roberto,

    My system stucks if I call clock_gettime in RTAI realtime task, maybe it's similar with Xenomai. And I think it's OK to call clock_gettime(which would cause a system call) in PREEMPT_RT. You can switch to other functions from Xenomai.

Regards
Bryan

From: Viola Roberto
Date: 2019-05-21 21:44
To: Dr.-Ing. Wilhelm Hagemeister; etherlab-users at etherlab.org
Subject: [etherlab-users] R: R: Random Datagram Unmatched
Hallo Wilhelm,
  thanks for your answer. I've already check the timings of my loop.
Running at 1KHz these are the clocks (ns) when i have the issue:

Domain1: WC 0.
Domain1: State 0.
receive[0]=232048932
process[0]=232068191
queue[0]=232070560
send[0]=232071366
aftersend[0]=232077874
receive[1]=233053215 delta from 232077874 is 975341 so 0,975 ms
process[1]=233071905
queue[1]=233096531
send[1]=233097696
aftersend[1]=233113699

Domain1: WC 3.
Domain1: State 2.
receive[-1]=233053215
process[-1]=233071905
queue[0]=233096531
send[0]=233097696
aftersend[0]=233113699
receive[1]=234050115 delta from 233113699 is 936416 so 0,936 ms
process[1]=234068059
queue[1]=234073073
send[1]=234074001
aftersend[1]=234082476

Domain1: WC 0.
Domain1: State 0.
receive[0]=450056645
process[0]=450071880
queue[0]=450074396
send[0]=450075202
aftersend[0]=450082843
receive[1]=451056992 delta from 450082843 is 974149 so 0,974 ms
process[1]=451073978
queue[1]=451084047
send[1]=451085161
aftersend[1]=451098212

Domain1: WC 3.
Domain1: State 2.
receive[0]=451056992
process[0]=451073978
queue[0]=451084047
send[0]=451085161
aftersend[0]=451098212
receive[1]=452056358 delta from 451098212 is 958146 so 0,958 ms
process[1]=452074082
queue[1]=452079176
send[1]=452080059
aftersend[1]=452312695

As you can see the 1KHz seems ok. I've also tried to append 50-100 us of sleep before calling the ecrt_master_receive without success.

For reference this is my main loop:

int cycle_us = 1000;
rt_task_set_periodic(NULL, TM_NOW, cycle_us * 1000);
while (run)
{
rt_task_wait_period(NULL);

// receive EtherCAT
struct timespec receive[2], process[2], queue[2], send[2], aftersend[2];
static __u8 tictoc = 0;
tictoc = !tictoc;
clock_gettime(CLOCK_REALTIME, &receive[tictoc]);
ecrt_master_receive(master);
clock_gettime(CLOCK_REALTIME, &process[tictoc]);
               ecrt_domain_process(domain1);

  rt_check_domain_state();

if (!(cycle_counter % (int)(1000.0 / (cycle_us / 1000.0)))) {
rt_check_master_state();
seconds++;
}

// send process data
clock_gettime(CLOCK_REALTIME, &queue[tictoc]);
ecrt_domain_queue(domain1);
clock_gettime(CLOCK_REALTIME, &send[tictoc]);
ecrt_master_send(master);
clock_gettime(CLOCK_REALTIME, &aftersend[tictoc]);
}

-----Messaggio originale-----
Da: etherlab-users [mailto:etherlab-users-bounces at etherlab.org] Per conto di Dr.-Ing. Wilhelm Hagemeister
Inviato: martedì 21 maggio 2019 15:25
A: etherlab-users at etherlab.org
Oggetto: Re: [etherlab-users] R: Random Datagram Unmatched

Hallo Roberto,

Am 21.05.19 um 14:48 schrieb Viola Roberto:
>
> This crc thing plus the packet’s counter thing by ifconfig push me to
> think that sometimes the ec module ignores a packet even if ethernet
> card receives it. Is is possible?

Yes that is possible. If you query the NIC to early after you send the frame, it might not be back yet. What is the order of your realtime execution? Is it receiving EtherCAT (the previous frame), processing, sending EtherCAT, waiting for next rt-schedule?

Due to jitter, or a to long execution time of your task, sending and receiving the EtherCAT frame might come to close. This might also explain why it is not a function of your cycle time. You have to monitor your execution time and cycle jitter to get to the problem.

>
> What happen when EC gives me this warning? I mean, i will lost the
> informations inside the unmatched packet for sure, but if this issue
> happens when i write a SDO instead of a PDO the EC will retry
> automatically to send another SDO packet?

If you accept frame drops, depends on your application. We usually
accept a frame drop once in a while and don't trigger an emergency stop
or likewise. SDO transfers are handled with state machines. If a request
get's lost, it will be resent or will flag an error (which must be
handled by your application).

Regards Wilhelm.
_______________________________________________
etherlab-users mailing list
etherlab-users at etherlab.org
http://lists.etherlab.org/mailman/listinfo/etherlab-users

Roberto Viola

Technical Dept
+39 0536836680

SYSTEM CERAMICS S.p.A.
Via Ghiarola Vecchia, 73
41042 Fiorano (Mo) ITALY
+39 0536 836111
info at system-electronics.it
http://www.system-electronics.it

Le informazioni contenute in questa email, inclusi i suoi allegati, sono riservate e ad uso esclusivo del destinatario. Qualora le fosse pervenuta per errore, lei non è autorizzato a copiare, inoltrare e/o rendere nota questa email e i suoi allegati, totalmente o parzialmente, e pertanto la preghiamo di cancellarla immediatamente senza visionarne il contenuto e gli allegati.
Avvertenza: la presente casella e-mail ed i messaggi da essa derivanti, sono di esclusivo utilizzo aziendale /lavorativo e mai personale.
Risposte al presente messaggio: si avvisa il destinatario che eventuali sue risposte, potranno essere lette dall’intera azienda /ufficio /reparto di appartenenza del mittente.
The information contained in this e-mail, including attachments, is confidential and exclusively for the use of the intended recipient. If you received this communication by mistake you are not authorized to copy, send and/or publish this message and its attachments, in whole or in part and therefore please delete this message.

-----Messaggio originale-----
Da: etherlab-users [mailto:etherlab-users-bounces at etherlab.org] Per conto di Dr.-Ing. Wilhelm Hagemeister
Inviato: martedì 21 maggio 2019 15:25
A: etherlab-users at etherlab.org
Oggetto: Re: [etherlab-users] R: Random Datagram Unmatched

Hallo Roberto,

Am 21.05.19 um 14:48 schrieb Viola Roberto:
>
> This crc thing plus the packet’s counter thing by ifconfig push me to
> think that sometimes the ec module ignores a packet even if ethernet
> card receives it. Is is possible?

Yes that is possible. If you query the NIC to early after you send the frame, it might not be back yet. What is the order of your realtime execution? Is it receiving EtherCAT (the previous frame), processing, sending EtherCAT, waiting for next rt-schedule?

Due to jitter, or a to long execution time of your task, sending and receiving the EtherCAT frame might come to close. This might also explain why it is not a function of your cycle time. You have to monitor your execution time and cycle jitter to get to the problem.

>
> What happen when EC gives me this warning? I mean, i will lost the
> informations inside the unmatched packet for sure, but if this issue
> happens when i write a SDO instead of a PDO the EC will retry
> automatically to send another SDO packet?

If you accept frame drops, depends on your application. We usually
accept a frame drop once in a while and don't trigger an emergency stop
or likewise. SDO transfers are handled with state machines. If a request
get's lost, it will be resent or will flag an error (which must be
handled by your application).

Regards Wilhelm.
_______________________________________________
etherlab-users mailing list
etherlab-users at etherlab.org
http://lists.etherlab.org/mailman/listinfo/etherlab-users

_______________________________________________
etherlab-users mailing list
etherlab-users at etherlab.org
http://lists.etherlab.org/mailman/listinfo/etherlab-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.etherlab.org/pipermail/etherlab-users/attachments/20190522/af1e0b6a/attachment-0003.htm>