EtherCAT Igh Master Notes

Building:

  • Directory /home/sandboxes/jbrandt/ethercat-devel-r1590
  • Documentation is available at www.etherlab.org
  • running 'make' builds application and libraries
  • running 'make modules' builds master, driver and example kernel modules
  • running 'make modules_install' installs driver, kernel modules
  • The test program is in examples/user, and does not need to be installed to run.

Running:

  • using lsmod (in /sbin) to list loaded modules
  • To load the development version of the ec_master, ec_8139too driver modules:
    • /etc/rc.d/init.d/ethercat start
  • To kickstart slave using 1.3.2 driver:
    • First stop the R1590 driver:
      • etc/rc.d/init.d/ethercat stop
    • Go to the 1.3.2. driver directory (/home/sandboxes/jbrandt/ethercat-1.3.2)
      • Load the 1.3.2 driver
        • ./start_1_3_2 start
        • ./start_1_3_2 stop
    • Restore the development version driver

  • RTAI example module uses RTAI kernel modules, which must be loaded first using:
    • /usr/realtime/bin/load_rtai_modules start
  • RTAI example module is loaded using:
    • /sbin/insmod [fullpathtomodule]/ec_rtai_sample.ko
  • RTAI example module is unload using:
    • /sbin/rmmod ec_rtai_sample

User-space Test Program

  • located in examples/user
  • Usage: ./ec_user_example [-q] [-f logfile] [-r HZ]
    • -q option for 'quiet mode' log messages go only into logfile, minimal stuff to stdout
    • -f logfile option records messages to a logfile.
    • -r rate_hz option specifies rate in Hertz. Default: 1000

EtherCAT Utility

  • located in /opt/ethercat/bin
  • To print slave state:
    • ethercat slaves -v
  • To trigger state change:
    • ethercat states {op|safeop|preop}
  • To dump SII area in hex:
    • ethercat sii_read | od -xv

EtherCAT Monitoring using Wireshark

The driver if compiled with the EC_DEBUG option will provide a read-only linux network interface called ecdbgm0. Wireshark can be used to snapshot network activity using this interface. Note that when using this interface, the tasking in the example code uses normal kernel tasks, instead of RTAI tasks. The reason is that because it writes into the debug interface, this must run in a normal kernel, not RTAI context. (Will cause a system freeze.)

Modifications to the RTAI Example Module

The basic hacks done on the example module have been:
  • Added DO_WRITE/DO_READ compile tokens to attempt to make module do only writes, or only reads. If both are defined, the master will use the read-modify-write command which is not supported by the slave we are using.
  • PDO numbers were changed from the original example, to the 0x2000, 0x3000 numbers which match the default slave configuration.
  • The RTAI example originally used RTAI tasks. I changed this to use kernel tasks, so that writes into the debug network interface wouldn't crash the system.

Current Issues

  • Reliability Using a modified version of the user-space example, we now have data exchanges between master and slave. However, sporadically we see "unmatched datagrams". The code gives this indication when it is unable to find a matching (outgoing?) packet in its packet queue. This must be an issue in the driver, as there is extensive debug code associated with it. I turned on this debug and was able to see the output during an error. Previously I took a packet trace, and noted that I saw an outbound packet without a matching return packet. (Cause unknown.)
  • Latency Since the slave does not support the read-modify-write packet, when a full round-trip experiment is performed we see a 1-cycle latency. This is because we are sending a write, followed by a read all in the same Ethernet frame. The slave application cannot react in time to respond to the the data and write back its data. Hence the 1-cycle latency.
  • Compatibility Only a special patched version of the 1.3.2 driver is able to wake the slave from a cold-start. Apparently it loads PDO's into the eeprom area (or at least sets up a minimal config) for the other drivers to recognize. I would think the slave should not require re-loading its EEPROM on every cold-start.
  • Timing Although we plan to use RTAI to get rock-solid RT performance, it is not clear to me how the driver will support this. The kernel threads running the driver are not RTAI level threads, and therefore may be preempted.
  • Interface The current example is in user-space, with ioctl's to pass data to the driver. An RTAI application would need to use shared-memory, mailboxes, or fifos to implement a kernel interface. (This is related to the timing issue above.)

-- JoeBrandt - 21 Nov 2008
Topic revision: r3 - 2008-12-22, JoeBrandt
This site is powered by FoswikiCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding NRAO Public Wiki? Send feedback