[Etherlab-users] ecrt_master_receive big latency

[zy]

Dear Etherlab users,

         I use the lateset igh with unofficial patchset under Linux-3.18.20 and Xenomai-2.6.5. My NIC is Intel i211.My question is, when I run a simple sample, there is no error even if the running time is very long. I just use QtCreator and make the configuration of slave and igh real-time cycling thread to a dynamic library, I find there is a big latency of calling ecrt_master_receive. My testing method is like this:

 

RTIME begin=rt_time_read();

ecrt_master_receive(master);

ecrt_domain_process(domain);

RTIME end=rt_time_read();

 

The latency (end-begin) will reach 1.5ms about 30 minutes after starting the program. Except this error, almost latency is under 10us. At the same time, I execute “cat /proc/xenomai/faults” and find there will be page fault. I alse execute “cat /proc/xenomai/stat” and find MSW of the real-time thread increases. And there will also be “UNMATCHED Datagram” and “Datagram XXX (domain0-0-main) was SKIPPED XX times” message log.

 

My real-time thread is:

   while(1) {

       wakeupTime = timespec_add(wakeupTime, cycletime);

       clock_nanosleep(CLOCK_TO_USE, TIMER_ABSTIME, &wakeupTime, NULL);

 

       begin_r=rt_timer_read();

       ecrt_master_receive(master);

       ecrt_domain_process(domain1);

       end_r=rt_timer_read();

       receive_time=end_r-begin_r;

       if(receive_time>max_receive_time)

           max_receive_time=receive_time;

            temp[0]=EC_READ_U16(domain1_pd + offset.status_word_6041_0);

            temp[1]=EC_READ_U32(domain1_pd + offset.position_actual_value_6064_0);

            if(once<=800) {target_position=temp[1];once++;}

                   if(temp[0] == 0x218){

           EC_WRITE_U16(domain1_pd+offset.control_word_6040_0, 0x0080 );

       }

       else if( (temp[0]&0x004f) == 0x0040  ){  //temp[0]==0x250

           EC_WRITE_U16(domain1_pd+offset.control_word_6040_0, 0x0006 );

           //printf("1.state = %x\n",temp[0]);

       }

       else if( (temp[0]&0x006f) == 0x0021){ //temp[0]==0x231

           EC_WRITE_U16(domain1_pd+offset.control_word_6040_0, 0x0007 );

           //printf("2.state = %x\n",temp[0]);

        }

       else if( (temp[0]&0x06f) == 0x023){ //temp[0]==0x233

           EC_WRITE_U8(domain1_pd+offset.modes_operation_6060_0, 8);//csp mode

           EC_WRITE_S32(domain1_pd+offset.target_position_607a_0,target_position);

           EC_WRITE_U16(domain1_pd+offset.control_word_6040_0, 0x000f);

       }

       else if( (temp[0]&0x06f) == 0x027){//temp[0]=0x237

           EC_WRITE_S32(domain1_pd+offset.target_position_607a_0,target_position);

                 EC_WRITE_U16(domain1_pd+offset.control_word_6040_0, 0x001f);

       }

                   target_position+=0;

       if (sync_ref_counter) {

           sync_ref_counter--;

       } else {

           sync_ref_counter = 1; // sync every cycle

                            clock_gettime(CLOCK_TO_USE,&time);    //added by me          

                            ecrt_master_sync_reference_clock_to(master, TIMESPEC2NS(time));

       }

       ecrt_master_sync_slave_clocks(master);

 

       begin_s=rt_timer_read();

       //send process data

       ecrt_domain_queue(domain1);

       //ecrt_domain_queue(domain2);

       ecrt_master_send(master);

       end_s=rt_timer_read();

       send_time=end_s-begin_s;

                  

       if(send_time>max_send_time)

           max_send_time=send_time;

    }

 

I check all the possible problem I think:

1. Using libethercat_rtdm.so and ec_igb.

2. Make sure calling ecrt_master_receive after a period of time after calling ecrt_master_send. Sometimes,I find I use an elapsed time to call clock_nanosleep, that is because the latency of ecrt_master_receive.

3. Calling mlockall(MCL_CURRENT | MCL_FUTURE)

 

Does anyone know how to solve this problem?

 

Best regards

Zhou Yang
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.etherlab.org/pipermail/etherlab-users/attachments/20210311/a4140105/attachment-0001.htm>