[etherlab-dev] Experiences with ethercat-devel-r1824

Erwin Burgstaller ethercat.berknapp at spamgourmet.com
Thu Sep 24 11:47:58 CEST 2009


Hi!

I've checked out the latest version of the Etherlab master and I didn't
got EoE working. The best thing I got out of it, where lots of:

EtherCAT WARNING: Failed to receive mbox check datagram for eoe0s7

About 500 Messages per second, my send/receive-frequency is currently
at 1000 Hz.

Main difference is that change for the call back methods. For first I
don't see any effort on how the new method is implemented in the rtai
sample.

Basically it has the same problem as before. The callback runs in the
masters context an therefore outside of the real time-task. So because
of the mutex the real-time task may be blocked by a non-real-time task,
which could be delayed for unknown time and reason, if the CPU gets
heavily used, especially by other real-time tasks, of which we have
plenty.

So I decided to use the master callback function just to increase a
counter. In the real-time loop I then will call ecrt_master_send_ext(),
and ecrt_master_receive(), if the counter has been increased inside the
call-back function.

Obviously I did something wrong, but the main question are: 

  * Where to place the calls?, 
  * Why is there no ecrt_master_receive_ext() or something like that?

The real-time loop consists basically of these parts:

    while(run)
    {
       ecrt_master_receive()
       ecrt_domain_process()

       process_data()

       ecrt_master_send()

       wait_for_next_cycle()
   }

So, where would I then place ecrt_master_send_ext() and a second call to
ecrt_master_receive()?

I've tried it before and after the wait for the next cycle, but it
didn't made any difference.

BTW: We've switched to Xenomai, or better said: we're just switching, so
not relaying on any special real-time environment was a good idea while
designing the master, but I think we need a better link between this two
worlds. ;)

A second point: My client module does hang in ecrt_release_master(), so
rmmod does hang, which is nasty as the only way to get out is reboot.

Erwin

-- 
Erwin Burgstaller


More information about the etherlab-dev mailing list