EtherCAT IGH 安装手册.pdf

发布时间：2022-05-30 发布人：admin 分类：说明书资料大小：0.39M 资料格式：pdf 举报版权申诉

weixin_37915486-10749539-16359647403236677541.pdf-第1页.png

第1页 / 共20页

weixin_37915486-10749539-16359647403236677541.pdf-第2页.png

第2页 / 共20页

weixin_37915486-10749539-16359647403236677541.pdf-第3页.png

第3页 / 共20页

weixin_37915486-10749539-16359647403236677541.pdf-第4页.png

第4页 / 共20页

weixin_37915486-10749539-16359647403236677541.pdf-第5页.png

第5页 / 共20页

weixin_37915486-10749539-16359647403236677541.pdf-第6页.png

第6页 / 共20页

weixin_37915486-10749539-16359647403236677541.pdf-第7页.png

第7页 / 共20页

weixin_37915486-10749539-16359647403236677541.pdf-第8页.png

第8页 / 共20页

1. Introduction

2. Prerequisites

2.1 Hardware Prerequisites

2.2 Software Prerequisites

3. Installation of the EtherCAT Master Software

4. Completing the Installation

5. Using the Command-line Tool

6. A Simple Application Example

7. Reference Information

MMTO EtherCAT User's Guide D. Clark March 31, 2010 Version 0.1

1. Introduction This document describes getting, installing, and using the IgH (Ingenieurgemeinschaft) EtherCAT master software and EtherCAT hardware from Beckhoff Automation for use in MMT systems using a Fedora 12 Linux PC. It is not intended as an exhaustive description or detailed “how-to”, rather it is more of a quick-start to assist knowledgeable persons in getting EtherCAT applications and hardware working. Let's get going! 2. Prerequisites First, you need a Linux PC running Fedora 12. You should bring the machine completely up to date, and apply all yum updates as necessary to have a fresh installation ready to use. As of this writing, the test machine schwarzwald is running Linux 2.6.32.9-70.fc12.i686. 2.1 Hardware Prerequisites Next, your PC should have at least two Ethernet ports, at least one of which is an RJ-45 jack; the other could easily be a wireless connection. The port with the RJ-45 will be dedicated to the EtherCAT connection, and you will need a network connection on the other port for connecting to the internet for downloading software, updates, and other uses. While EtherCAT can handle passing ordinary packet traffic across the Ethernet interface, this is an advanced use case that is more complicated than necessary -- network cards are inexpensive, and your motherboard may even already have two Ethernet ports available. Once you have a running Fedora 12 system with a working internet connection, it's time to install some software to prepare for running EtherCAT. 2.2 Software Prerequisites MMTO uses the IgH EtherCAT master software from www.etherlab.org. In order to effectively download and use the software, some extra packages are required to get, build, install, and create documentation for the software. It is recommended to go ahead and install all these packages before starting work with EtherCAT rather than discover later something is needed and have to go back and fix it before continuing. So, what do we need? For building the IgH master software and documentation, we need a) the source for your running kernel, b) gcc toolchain, c) autoconf and automake tools, d)pdflatex or equivalent for dealing with LaTex files, e) doxygen to generate the C source code documentation, and f)xfig and graphviz for generating documentation graphics, and g) libtool, the GNU portable library tool. The easiest way to get the kernel source is to execute: user@machine> yumdownloader --source kernel Yum will then acquire and install the kernel source at the location /usr/src/kernels/$uname. The next step is to create a symbolic link to the kernel source: user@machine> ln -s /usr/src/kernels/$uname linux If you have automatic updates enabled, as is usually the case with a standard Fedora installation, kernel updates will probably update the /kernels directory with the new kernel source, but will not change the linux symlink. You'll have to do that yourself should the need arise. If you reboot after the kernel update, chances are you'll boot into a kernel that no longer has your EtherCAT installation available

and you'll need to rebuild and re-install the software to get it working again. This is not too difficult or time-consuming, just beware it could come along to make things stop working for you. Your vanilla Fedora installation should come with the gcc toolchain by default, but the EtherCAT software is built and distributed with the autoconf and automake tools, so make sure you have those available to you. Also, you may need libtool, as from the 'make install' step we'll execute later, we have the following message: ---------------------------------------------------------------------- Libraries have been installed in: /opt/etherlab/lib If you ever happen to want to link against installed libraries in a given directory, LIBDIR, you must either use libtool, and specify the full pathname of the library, or use the `-LLIBDIR' flag during linking and do at least one of the following: - add LIBDIR to the `LD_LIBRARY_PATH' environment variable during execution - add LIBDIR to the `LD_RUN_PATH' environment variable during linking - use the `-Wl,-rpath -Wl,LIBDIR' linker flag - have your system administrator add LIBDIR to `/etc/ld.so.conf' See any operating system documentation about shared libraries for more information, such as the ld(1) and ld.so(8) manual pages. ---------------------------------------------------------------------- Now, for building documentation, we need some more packages. In particular, for building the C source code documentation, doxygen is needed. The pdf documentation for the EtherCAT software requires pdflatex, since the primary documentation source file is a LaTex file. In addition, some of the documentation LaTex inputs are graphics files that in turn require the graphviz and xfig packages for conversion. So: user@machine> yum install doxygen | graphviz.i686 | xfig.i686 For dealing with LaTex, try using LyX, a LaTex document editor, or whatever is your preference. Now we are ready to get the actual EtherCAT software and start working with it. We need one final package; IgH has chosen to host their source code on SourceForge as a mercurial repository, so we need to install the mercurial package. Mercurial is a Python-based source control management (SCM) tool similar to trac and git. It is free, and can be either installed via yum or the vendor website at http://mercurial.selenic.com/.

3. Installation of the EtherCAT Master Software IgH maintains a website, as mentioned earlier, at www.etherlab.org. Navigation through the website brings you to the page http://etherlab.org/en/ethercat/index.php, where there is mention of the SourceForge repository, as well as a list of other available software downloads. Don't bother with anything other than the repository versions, as the others are all older versions that are unlikely to work with newer kernels but haven't been taken down to support legacy users. We want to clone the repository to start with a clean slate, so execute: hg clone http://etherlabmaster.hg.sourceforge.net:8000/hgroot/etherlabmaster/etherlabmaster \ ethercat-default All mercurial commands begin with 'hg', so the above clones the repository files into the directory ethercat-default, relative to wherever the hg clone command is executed, so if you entered: /home/user> hg clone... you would have a subdirectory named ethercatdefault under /home/user. There is no rule to use the above as the directory name, you're free to use whichever you wish, so long as you have write permission to the parent directory. Mercurial also offers a way to compare versions and update your local repository. For example, the current parent of the software on schwarzwald is: [dclark@schwarzwald ethercat-default]$ hg parent changeset: 1882:8ae8cc56d910 tag: tip user: Florian Pose date: Fri Mar 19 12:46:57 2010 +0100 summary: Minor fix. The above summarizes the current changeset, date of the last update, and a comment about that changeset. The EtherCAT repository changes on almost a weekly basis, so it's worth checking to see if a more recent version addresses any problems you might have. To get and apply updates from the repository, it's very simple-- First, pull the latest changeset from the repository: [dclark@schwarzwald ethercat-default]$ hg pull \ http://etherlabmaster.hg.sourceforge.net:8000/hgroot/etherlabmaster/etherlabmaster This will bring the latest changes into the project database that mercurial uses for change tracking. But, the source software in your local copy has not (yet) been changed. To apply the current changeset: [dclark@schwarzwald ethercat-default]$ hg update Then all relevant files will be updated. You can revert them, as well. See the tutorials at http://mercurial.selenic.com/wiki/QuickStart for more complete information. It's worth browsing the SourceForge repository for more information on the software version. An interesting way to look at it is to click “graph” from the selections near the top of the page, which will bring up a graphical summary of all the changes, branches, and merges to the software, along with text noting the person, data, and changeset summary comment. At this writing, the current tip in the repository is changeset 1889:131f655c03d3, so the version running on schwarzwald is somewhat out of

date. A clone of the repository will have the 'dist' version of the software in it. Since the automake and autoconf tools are used by the authors to distribute the software, it will be missing some necessary folders for configuring and building the software. Running the bootstrap.sh script will regenerate these necessary files and you'll be ready to configure and build the software. At this point, you're probably wondering, “where is the documentation for building the software?”, and the answer is: in the distribution file tree, as a LaTex source document. Oddly, you must build the software, via 'make doc' to get a pdf version of the documentation, so the process is somewhat circular. You can, however, cheat a bit by downloading the pdf documentation of the master software listed on the download page and get ahead of the game. The pdf documentation lists a number of important switches for configuring the master software. For use by MMTO, we are mainly interested in building the software with a generic network driver, not the available native driver, which only supports a few hardware types, notably the Intel Pro1000e and 8139too network interfaces, which are commonly available. An older native driver for the Intel Pro100e is available, but not supported in recent kernels. For the cost of a single digits to a few tens of microseconds of latency in the data transfer (depending on your hardware), the generic driver makes it possible to support any network driver by use of the underlying kernel modules and traversing the lower levels of the network stack. The test PC schwarzwald has successfully run EtherCAT transfers at 10kHz, and it is unknown what the ultimate limit is (probably around 80 to 100kHz). This is much higher than envisioned maximum rates of 1kHz, so pursuing native network interface drivers and hardware is not recommended at this time. Data transfer time is, of course, highly dependent on the computer hardware and CPU load, so plan to test your hardware to ensure it can support the highest data rates under worst-case conditions. Now we are ready to configure the EtherCAT software. Below is the configuration used for the most recent build on schwarzwald: $ ./configure --enable-generic=yes --enable-8139too=no –with-linux-dir=/usr/s rc/linux The default configuration options allow a native 8139too driver to be be built, with generic driver turned off, so you must set these explicitly. It's also wise to point to the linux sources you want to use, as well. Now to build the software: /home/user/ethercat-default>make /home/user/ethercat-default>make modules For building documentation (optional): /home/user/ethercat-default>make doc Now you need to be root, and execute: /home/user/ethercat-default# make install /home/user/ethercat-default# make modules_install The documentation claims that you should run depmod after modules_install, but on schwarzwald it appears to have been called in the make script, so if your module dependencies don't seem to have made it into the kernel, you might try it. It should be noted that a few other make targets are provided, among them 'clean', 'dist', and

'all'. See the Makefile in the /ethercat-default directory for all the targets. 4. Completing the Installation Once the EtherCAT master software is built and installed, it's time to apply some setup information so the master is attached to the correct Ethernet interface, and the command-line tool is available for use. The EtherCAT master when started looks for a configuration file, /etc/sysconfig/ethercat for variables that define which interface to use and the master device kernel module to load. For schwarzwald, the relevant portion of the file is: MASTER0_DEVICE="00:30:1b:ae:36:0e" and DEVICE_MODULES="generic" The MASTER0_DEVICE is set to the MAC address of the desired network interface hardware, and the module name is identified with the DEVICE_MODULES value. The file is installed with default values during make install, and is richly commented to assist in getting the correct information. The EtherCAT master offers a character device interface for user-space applications, so it's useful to make a udev rule to allow read/write access for them. The rule used on schwarzwald is the file /etc/udev/rules.d/99EtherCAT.rules, and contains only: KERNEL=="EtherCAT[0-9]", MODE="0666" Finally, a command-line tool is available for interacting with the master (e.g. starting, stopping, setting debug levels, and most importantly, utilities). The tool is installed in /opt/etherlab/bin/ethercat, so it's convenient to make a symlink to the tool binary, such as: ethercat-tool -> /opt/etherlab/bin/ethercat this makes it a bit easier to remember what you're doing, since a lot of different things within the system are called, “ethercat”. The EtherCAT master posts messages to the syslog, so you can use dmesg to get relevant information about the master's state. For example, since we've completed the above, we can start the master (as root): [root@schwarzwald dclark]# /etc/init.d/ethercat start Starting EtherCAT master devel done Obviously in a production setup we probably want the EtherCAT to start at boot time, so set your machine up appropriately. If the startup succeeds, we should see the “done” message above, and we should have dmesg entries for the process, which are always prefaced with EtherCAT to make searching the log easier: EtherCAT: Master driver devel 8ae8cc56d910 EtherCAT: 1 master waiting for devices. ec_generic: EtherCAT master generic Ethernet device module devel 8ae8cc56d910 EtherCAT: Accepting device 00:30:1B:AE:36:0E for master 0.

ec_generic: Binding socket to interface 3 (eth2). EtherCAT: Starting EtherCAT-IDLE thread. EtherCAT: Link state changed to UP. EtherCAT: 3 slave(s) responding. EtherCAT: Slave states: PREOP. EtherCAT: Scanning bus. EtherCAT: Bus scanning completed in 207 ms. Notice that the EtherCAT master always reports its parent changeset value, so you can always tell without difficulty the version that's running. It will start the master code, bring up the interface with the MAC address in the sysconfig file, and scan the bus for any slaves that might be active before moving to an idle state waiting for a master instance to be requested (more on this later). 5. Using the Command-line Tool The ethercat-tool above has several useful utilities for getting information about the slaves attached to the bus. Here, I will mention a few of the more useful ones. See the documentation for more information about what commands are available. One of the first things the user will want to know is that the slaves are connected, and which slaves are connected and in what order; the command-line tool makes this possible in a couple of different ways. The simplest is a listing of the slaves: [dclark@schwarzwald ~]$ ./ethercat-tool slaves 0 0:0 PREOP + EK1100 EtherCAT-Koppler (2A E-Bus) 1 0:1 PREOP + EL2004 4Ch. Dig. Output 24V, 0.5A s � 2 0:2 PREOP + EL1014 4Ch. Dig. Input 24V, 10 What is reported here is the bus segment:position for each slave (0:0 through 0:2), the slave's application-layer state, and the slave's model and function. For more complex arrangements, you might want to know about other bus segments and slave connections in a graphical manner. Consider the following: [dclark@schwarzwald ~]$ ./ethercat-tool graph | dot -Tpng > slaves7.png which produces a graphical output of the bus connections, the slaves at each position, and the bus delay time to each slave (next page):

Figure 1. EtherCAT bus graph Here we see visually the interconnection of the slaves, their position values, slave type, distributed clock (DC) width, and output delay. In this example the bus extension RJ-45 from the bus coupler EK1100 at position 0 was used to connect a second EK110 with 3 slaves attached to it to produce a tree arrangement. EtherCAT allows a mix of topology variations, such as star and ring connections, depending on the needs of the application. Suppose now that we wanted more specific information about the slaves. Another useful command is: [dclark@schwarzwald ~]$ ./ethercat-tool pdos === Master 0, Slave 1 === SM0: PhysAddr 0x0f00, DefaultSize 0, ControlRegister 0x44, Enable 9 RxPDO 0x1600 "Channel 1" PDO entry 0x7000:01, 1 bit, "Output" RxPDO 0x1601 "Channel 2" PDO entry 0x7010:01, 1 bit, "Output" RxPDO 0x1602 "Channel 3" PDO entry 0x7020:01, 1 bit, "Output" RxPDO 0x1603 "Channel 4" PDO entry 0x7030:01, 1 bit, "Output" === Master 0, Slave 2 === SM0: PhysAddr 0x1000, DefaultSize 0, ControlRegister 0x00, Enable 0 TxPDO 0x1a00 "Channel 1" PDO entry 0x6000:01, 1 bit, "Input"

分享到：

赞收藏

资料库

EtherCAT IGH 安装手册.pdf

相关推荐

开发技术

热门标签

最新资料