文章目錄
- 1. IgH Master 1.5.2 Documentation
-
- 1.1 特性
- 1.2 Architecture
-
- 1.2.1 Master Module
- 1.2.2 Master Phases
- 1.2.3 Process Data
- 1.3 Application Interface
-
- 1.3.1 Master Con figuration
- 1.3.2 Cyclic Operation
- 1.3.3 VoE Handlers
- 1.3.4 Concurrent Master Access
- 1.3.5 Distributed Clocks
- 1.4 Ethernet Devices
-
- 1.4.1 Network Driver Basics
- 1.4.2 Native EtherCAT Device Drivers
- 1.4.3 Generic EtherCAT Device Driver
- 1.4.4 Providing Ethernet Devices
- 1.4.5 Redundancy
- 1.4.6 EtherCAT Device Interface
- 1.4.7 Patching Native Network Drivers
- 1.5 State Machines
-
- 1.5.1 State Machine Theory
- 1.5.2 The Master's State Model
- 1.5.3 The Master State Machine
- 1.5.4 The Slave Scan State Machine
- 1.5.5 The Slave Con guration State Machine
- 1.5.6 The State Change State Machine
- 1.5.7 The SII State Machine
- 1.5.8 The PDO State Machines
- 1.6 Mailbox Protocol Implementations
-
- 1.6.1 Ethernet over EtherCAT (EoE)
- 1.6.2 CANopen over EtherCAT (CoE)
- 1.6.3
- 1.6.4
- 1.7 Userspace Interfaces
-
- 1.7.1 Command-line Tool
- 1.7.2 Userspace Library
- 1.7.3 RTDM Interface
- 1.7.4 System Integration
- 1.7.5 Debug Interfaces
- 1.8 Timing Aspects
-
- 1.8.1 Application Interface Pro ling
- 1.8.2 Bus Cycle Measuring
- 1.9 Installation
-
- 1.9.1 Getting the Software
- 1.9.2 Building the Software
- 1.9.3 Building the Interface Documentation
- 1.9.4 Installing the Software
- 1.9.5 Automatic Device Node Creation
- 2. 實踐分析
-
- 2.1 fsm_master狀态機
- 2.2 初始化流程
- 2.3 程式架構
- 3. 測試
-
- 3.1 實時性測試
- 3.2 一緻性測試
- 4. igh移植
-
- 4.1 xenomai移植
- 4.2 igh移植
1. IgH Master 1.5.2 Documentation
1.1 特性
igh支援以下特性：
- Designed as a kernel module for Linux 2.6 / 3.x.
- Implemented according to IEC 61158-12 [2] [3].
-
Comes with EtherCAT-capable native drivers for several common Ethernet chips, as well as a generic driver for all chips supported by the Linux kernel.
// 帶有支援EtherCAT的原生驅動程式(native drivers)可用于幾種常見的以太網晶片，以及用于Linux核心支援的所有晶片的通用驅動程式(generic driver)。
- The native drivers operate the hardware without interrupts.
// 原生驅動程式操作硬體時不使用中斷。
- Native drivers for additional Ethernet hardware can easily be implemented using the common device interface (see section 4.6) provided by the master module.
// 使用主子產品(master module)提供的通用裝置接口(common device interface)（請參閱第4.6節），可以輕松實作用于其他以太網硬體的原生驅動程式(Native drivers)。
- For any other hardware, the generic driver can be used. It uses the lower layers of the Linux network stack.
// 對于任何其他硬體，可以使用通用驅動程式(generic driver)。 它使用Linux網絡堆棧的較低層。
- The master module supports multiple EtherCAT masters running in parallel.
- The master code supports any Linux realtime extension through its independent architecture.
- RTAI [11] (including LXRT via RTDM), ADEOS, RT-Preempt [12], Xenomai (including RTDM), etc.
- It runs well even without realtime extensions.
-
Common “Application Interface” for applications, that want to use EtherCAT functionality (see chapter 3).
// 想要使用EtherCAT功能的應用程式使用通用“應用程式接口”(Common “Application Interface”)
-
Domains are introduced, to allow grouping of process data transfers with different slave groups and task periods.
// 引入了域，以允許将不同從屬組和任務周期傳輸的過程資料進行分組。
- Handling of multiple domains with different task periods.
// 處理具有不同任務周期的多個域。
- Automatic calculation of process data mapping, FMMU and sync manager configuration within each domain.
// 在每個域内自動計算過程資料映射，FMMU和同步管理器配置。
-
Communication through several finite state machines.
// 通過幾個有限狀态機進行通信。
- Automatic bus scanning after topology changes.
// 拓撲更改後自動進行總線掃描。
- Bus monitoring during operation.
// 運作期間的總線監視。
- Automatic reconfiguration of slaves (for example after power failure) during operation.
// 在運作期間自動重新配置從站（例如，斷電後）。
- Distributed Clocks support (see section 3.5).
- Configuration of the slave's DC parameters through the application interface.
// 通過應用程式接口配置從站的DC參數。
- Synchronization (offset and drift compensation) of the distributed slave clocks to the reference clock.
// 同步分布式從屬時鐘與參考時鐘（偏移和漂移補償）。
- Optional synchronization of the reference clock to the master clock or the other way round.
// 參考時鐘與主時鐘的可選同步，或者相反。
- CANopen over EtherCAT (CoE)
- SDO upload, download and information service.
- Slave configuration via SDOs.
- SDO access from userspace and from the application.
- SDO上傳，下載下傳和資訊服務。
- 通過SDO進行從站配置。
- 從使用者空間和應用程式進行SDO通路。
- Ethernet over EtherCAT (EoE)
- Transparent use of EoE slaves via virtual network interfaces.
- Natively supports either a switched or a routed EoE network architecture.
- 通過虛拟網絡接口透明使用EoE從站。
- 本機支援交換式或路由式EoE網絡體系結構。
- Vendor-specific over EtherCAT (VoE)
- Communication with vendor-specific mailbox protocols via the API.
- 通過API與供應商特定的郵箱協定進行通信。
- File Access over EtherCAT (FoE)
- Loading and storing files via the command-line tool.
- Updating a slave's firmware can be done easily.
- 通過指令行工具加載和存儲檔案。
- 更新從站的固件很容易。
- Servo Profile over EtherCAT (SoE)
- Implemented according to IEC 61800-7 [16].
- Storing IDN configurations, that are written to the slave during startup.
- Accessing IDNs via the command-line tool.
- Accessing IDNs at runtime via the the user-space library.
- 根據IEC 61800-7 [16]實施。
- 存儲在啟動期間寫入從站的IDN配置。
- 通過指令行工具通路IDN。
- 在運作時通過使用者空間庫通路IDN。
- Userspace command-line-tool “ethercat” (see section 7.1)
- Detailed information about master, slaves, domains and bus configuration.
- Setting the master's debug level.
- Reading/Writing alias addresses.
- Listing slave configurations.
- Viewing process data.
- SDO download/upload; listing SDO dictionaries.
- Loading and storing files via FoE.
- SoE IDN access.
- Access to slave registers.
- Slave SII (EEPROM) access.
- Controlling application-layer states.
- Generation of slave description XML and C-code from existing slaves.
- Seamless system integration though LSB compliance.
- Master and network device configuration via sysconfig files.
- Init script for master control.
- Service file for systemd.
- Virtual read-only network interface for monitoring and debugging purposes.
1.2 Architecture
The EtherCAT master is integrated into the Linux kernel. This was an early design decision, which has been made for several reasons:
// EtherCAT主站已內建到Linux核心中。 這是一個早期的設計決定，出于以下幾個原因：
-
Kernel code has significantly better realtime characteristics, i. e. less latency than userspace code. It was foreseeable, that a fieldbus master has a lot of cyclic work to do. Cyclic work is usually triggered by timer interrupts inside the kernel. The execution delay of a function that processes timer interrupts is less, when it resides in kernelspace, because there is no need of time-consuming context switches to a userspace process.
// 核心代碼具有明顯更好的實時特性，例如延遲時間比使用者空間代碼短。 可以預見，現場總線主站有很多周期性的工作要做。 循環工作通常由核心内部的計時器中斷觸發。 當它駐留在核心空間中時，處理計時器中斷的函數的執行延遲較小，因為不需要費時的上下文切換到使用者空間程序。
-
It was also foreseeable, that the master code has to directly communicate with the Ethernet hardware. This has to be done in the kernel anyway (through network device drivers), which is one more reason for the master code being in kernelspace.
// 還可以預見，主代碼必須直接與以太網硬體通信。 無論如何，這必須在核心中完成（通過網絡裝置驅動程式），這也是主代碼位于核心空間中的另一個原因。
下圖是master架構示意圖：
The components of the master environment are described below:
-
Master Module
Kernel module containing one or more EtherCAT master instances(see section 2.1), the “Device Interface” (see section 4.6) and the “Application Interface” (see chapter 3).
//
主站子產品
-
Device Modules
EtherCAT-capable Ethernet device driver modules, that other their devices to the EtherCAT master via the device interface (see section 4.6). These modified network drivers can handle network devices used for EtherCAT operation and “normal” Ethernet devices in parallel. A master can accept a certain device and then is able to send and receive EtherCAT frames. Ethernet devices declined by the master module are connected to the kernel’s network stack as usual.
//
裝置子產品
-
Application
A program that uses the EtherCAT master (usually for cyclic exchange of process data with EtherCAT slaves). These programs are not part of the EtherCAT master code1, but have to be generated or written by the user. An application can request a master through the application interface (see chapter 3). If this succeeds, it has the control over the master: It can provide a bus configuration and exchange process data. Applications can be kernel modules (that use the kernel application interface directly) or userspace programs, that use the application interface via the EtherCAT library (see section 7.2), or the RTDM library (see section 7.3).
//
應用程式
1.2.1 Master Module
The EtherCAT master kernel module
ec_master
can contain multiple master instances.
Each master waits for certain Ethernet device(s) identified by its MAC address(es).
These addresses have to be specified on module loading via the main devices (and optional: backup devices) module parameter. The number of master instances to initialize is taken from the number of MAC addresses given.
The below command loads the master module with a single master instance that waits for one Ethernet device with the MAC address 00:0E:0C:DA:A2:20. The master will be accessible via index 0.
// EtherCAT主核心子產品ec_master可以包含多個主執行個體。
每個主機等待由其MAC位址辨別的某些以太網裝置。
這些位址必須通過主裝置（和可選的：備用裝置）子產品參數在子產品加載時指定。 要初始化的主執行個體的數量來自給定的MAC位址的數量。
以下指令使用一個主執行個體加載主子產品，該主執行個體等待一個MAC位址為00：0E：0C：DA：A2：20的以太網裝置。 主機可以通過索引0通路。
# modprobe ec_master main_devices=00:0E:0C:DA:A2:20
MAC addresses for multiple masters have to be separated by commas:
# modprobe ec_master main_devices=00:0E:0C:DA:A2:20,00:e0:81:71:d5:1c
The two masters can be addressed by their indices 0 and 1 respectively (see Figure 2.2). The master index is needed for the ecrt_master_request() function of the application interface (see chapter 3) and the --master option of the ethercat command-line tool (see section 7.1), which defaults to 0.
// 這兩個主機可以分别通過其索引0和1進行尋址（見圖2.2）。 應用程式界面的ecrt_master_request（）函數（請參見第3章）和ethercat指令行工具的–master選項（請參見7.1節）需要master索引，該索引預設為0。
-
Debug Level
ethercat debug <LEVEL >
Set the master 's debug level .
Debug messages are printed to syslog .
Arguments :
LEVEL can have one of the following values :
0 for no debugging output ,
1 for some debug messages , or
2 for printing all frame contents (use with caution !).
Numerical values can be specified either with decimal (no prefix ), octal ( prefix '0') or hexadecimal ( prefix '0x ') base .
-
Init Script
In most cases it is not necessary to load the master module and the Ethernet driver modules manually. There is an init script available, so the master can be started as a service (see section 7.4). For systems that are managed by systemd [7], there is also a service file available.
// 初始化腳本在大多數情況下，不需要手動加載主子產品和以太網驅動程式子產品。 有一個可用的初始化腳本，是以可以将主伺服器作為服務啟動（請參閱第7.4節）。 對于由systemd [7]管理的系統，還有一個服務檔案可用。
-
Syslog
# dmesg | tail -2
EtherCAT : Master driver 1.5.2
EtherCAT : 2 masters waiting for devices .
# tail -2 /var/log/messages
Jul 4 10:22:45 ethercat kernel : EtherCAT : Master driver 1.5.2
Jul 4 10:22:45 ethercat kernel : EtherCAT : 2 masters waiting for devices .
1.2.2 Master Phases
Every EtherCAT master provided by the master module (see section 2.1) runs through several phases (see Figure 2.3):
// 主站子產品（請參閱第2.1節）提供的每個EtherCAT主站都經曆多個階段（請參見圖2.3）：
-
Orphaned phase
This mode takes effect, when the master still waits for its Ethernet device(s) to connect. No bus communication is possible until then.
// 孤立階段當主機仍在等待其以太網裝置連接配接時，此模式生效。 在此之前，無法進行總線通訊。
-
Idle phase
takes effect when the master has accepted all required Ethernet devices, but is not requested by any application yet. The master runs its state machine (see section 5.3), that automatically scans the bus for slaves and executespending operations from the userspace interface (for example SDO access). Thecommand-line tool can be used to access the bus, but there is no process data exchange because of the missing bus configuration.
// 當主機已接受所有必需的以太網裝置，但尚未被任何應用程式請求時，空閑階段将生效。 主機運作其狀态機（請參閱第5.3節），該狀态機自動在總線上掃描從機，并從使用者空間接口執行支出操作（例如SDO通路）。 可以使用指令行工具通路總線，但是由于缺少總線配置，是以沒有過程資料交換。
-
Operation phase
The master is requested by an application that can provide a bus configuration and exchange process data.
// 操作階段主程式由可以提供總線配置并交換過程資料的應用程式請求。
1.2.3 Process Data
This section shall introduce a few terms and ideas how the master handles process data.
// 本節将介紹一些術語和構想，說明主伺服器如何處理過程資料。
-
Process Data Image
Slaves offer their inputs and outputs by presenting the master so-called “Process Data Objects” (PDOs). The available PDOs can be either determined by reading out the slave’s TxPDO and RxPDO SII categories from the E2PROM (in case of fixed PDOs) or by reading out the appropriate CoE objects (see section 6.2), if available. The application can register the PDOs’ entries for exchange during cyclic operation. The sum of all registered PDO entries defines the “process data image”, which is exchanged via datagrams with “logical” memory access (like LWR, LRD or LRW) introduced in [2, sec. 5.4].
// 過程資料映像從站通過Master上所謂的“過程資料對象”（PDO）提供其輸入和輸出。 從機可以通過從E2PROM中讀取的TxPDO和RxPDO SII類别（對于固定PDO）來确定可用的PDO，或者通過讀取适當的CoE對象（請參見6.2節）來确定。 應用程式可以注冊PDO的條目以在循環操作期間進行交換。 所有已注冊的PDO條目的總和定義了“過程資料映像”，它通過資料報與在[2，5.4節]中介紹的"邏輯"存儲器通路（例如LWR，LRD或LRW）進行交換。
-
Process Data Domains
The process data image can be easily managed by creating so-called “domains”, which allow grouped PDO exchange. They also take care of managing the datagram structures needed to exchange the PDOs. Domains are mandatory for process data exchange, so there has to be at least one. They were introduced for the following reasons:
// 過程資料域通過建立允許分組的PDO交換的所謂“域”，可以輕松地管理過程資料映像。他們還負責管理交換PDO所需的資料報結構。域對于過程資料交換是必不可少的，是以必須至少有一個。引入它們的原因如下：
- The maximum size of a datagram is limited due to the limited size of an Ethernet frame: The maximum data size is the Ethernet data field size minus the EtherCAT frame header, EtherCAT datagram header and EtherCAT datagram footer: 1500 - 2 - 12 - 2 = 1484 octets. If the size of the process data image exceeds this limit, multiple frames have to be sent, and the image has to be partitioned for the use of multiple datagrams. A domain manages this auto-matically.
//資料報的最大大小由于以太網幀的大小而受到限制：最大資料大小是以太網資料字段的大小減去EtherCAT幀頭，EtherCAT資料報頭和EtherCAT資料報的頁腳：1500-2-12-2 = 1484個八位位組。如果過程資料映像的大小超過此限制，則必須發送多個幀，并且必須對映像進行分區以使用多個資料報。域自動進行管理。
- Not every PDO has to be exchanged with the same frequency: The values of PDOs can vary slowly over time (for example temperature values), so exchanging them with a high frequency would just waste bus bandwidth. For this reason, multiple domains can be created, to group different PDOs and so allow separate exchange.
//并非每個PDO都必須以相同的頻率進行交換：PDO的值會随時間緩慢變化（例如溫度值），是以以高頻率進行交換會浪費總線帶寬。是以，可以建立多個域，以将不同的PDO分組，進而允許單獨交換。
There is no upper limit for the number of domains, but each domain occupies one FMMU in each slave involved, so the maximum number of domains is de facto limited by the slaves.
//域的數量沒有上限，但是每個域在每個涉及的從站中都占用一個FMMU，是以，最大的域數實際上受從站的限制。
-
FMMU Configuration
An application can register PDO entries for exchange. Every PDO entry and its parent PDO is part of a memory area in the slave’s physical memory, that is protected by a sync manager [2, sec. 6.7] for synchronized access.
// FMMU配置應用程式可以注冊PDO條目以進行交換。每個PDO條目及其父PDO都是從站實體記憶體中存儲區域的一部分，該區域由同步管理器保護[2秒。 6.7]用于同步通路。
In order to make a sync manager react on a datagram accessing its memory, it is necessary to access the last byte covered by the sync manager. Otherwise the sync manager will not react on the datagram and no data will be exchanged. That is why the whole synchronized memory area has to be included into the process data image:
// 為了使同步管理器對通路其記憶體的資料報做出反應，有必要通路同步管理器覆寫的最後一個位元組。否則，同步管理器将不會對資料報做出反應，也不會交換任何資料。這就是為什麼整個同步存儲區必須包含在過程資料映像中的原因：
For example, if a certain PDO entry of a slave is registered for exchange with a certain domain, one FMMU will be configured to map the complete sync-manager-protected memory, the PDO entry resides in. If a second PDO entry of the same slave is registered for process data exchange within the same domain, and it resides in the same sync-manager-protected memory as the first one, the FMMU configuration is not altered, because the desired memory is already part of the domain’s process data image. If the second PDO entry would belong to another sync-manager-protected area, this complete area would also be included into the domains process data image. Figure 2.4 gives an overview, how FMMUs are configured to map physical memory to logical process data images.
// 例如，如果注冊了從屬伺服器的某個PDO條目以與某個域交換，則将配置一個FMMU來映射完整的受同步管理器保護的記憶體，該PDO條目将駐留在其中。如果同一從屬裝置的另一個PDO條目在同一域中注冊以進行過程資料交換，并且它與第一個存在于相同的受同步管理器保護的存儲器中，FMMU配置不會更改，因為所需的存儲器已經是域的過程資料映像的一部分。如果第二個PDO條目将屬于另一個同步管理器保護的區域，則該完整區域也将包含在域過程資料映像中。圖2.4概述了FMMU如何配置為将實體記憶體映射到邏輯過程資料映像。
1.3 Application Interface
The application interface provides functions and data structures for applications to access an EtherCAT master. The complete documentation of the interface is included as Doxygen [13] comments in the header file
include/ecrt.h
. It can either be read directly from the file comments, or as a more comfortable HTML documentation.The HTML generation is described in section 9.3.The following sections cover a general description of the application interface.
// 應用程式接口為應用程式提供通路EtherCAT主站的功能和資料結構。 接口的完整文檔作為Doxygen [13]注釋包含在頭檔案include / ecrt.h中。 它可以直接從檔案注釋中讀取，也可以作為更舒适的HTML文檔讀取。第9.3節介紹了HTML的生成。以下各節介紹了應用程式界面的一般說明。
Every application should use the master in two steps:
// 每個應用程式都應分兩個步驟使用master：
`Configuration` The master is requested and the configuration is applied. For example, domains are created, slaves are congured and PDO entries are registered (see section 3.1).
// 配置請求主伺服器并應用配置。 例如，建立域，配置從站并注冊PDO條目（請參閱第3.1節）。
`Operation` Cyclic code is run and process data are exchanged (see section 3.2).
// 操作運作循環代碼并交換過程資料（請參閱第3.2節）。
Example Applications There are a few example applications in the
examples/sub-directory
of the master code. They are documented in the source code.
// 示例應用程式在主代碼的“ examples / sub-directory”中有一些示例應用程式。 它們記錄在源代碼中。
1.3.1 Master Con figuration
The bus confi guration is supplied via the application interface. Figure 3.1 gives an overview of the objects, that can be confi gured by the application.
- Slave Con figuration
The application has to tell the master about the expected bus topology. This can be done by creating “slave configurations”. A slave configuration can be seen as an expected slave. When a slave configuration is created, the application provides the bus position (see below), vendor id and product code.
// 該應用程式必須告知主機有關預期的總線拓撲。 這可以通過建立“從站配置”來完成。 從站配置可以視為預期的從站。 建立從站配置後，應用程式将提供總線位置（請參見下文），供應商ID和産品代碼。
When the bus configuration is applied, the master checks, if there is a slave with the given vendor id and product code at the given position. If this is the case, the slave configuration is “attached” to the real slave on the bus and the slave is configured according to the settings provided by the application. The state of a slave configuration can either be queried via the application interface or via the command-line tool (see subsection 7.1.3).
// 應用總線配置後，主伺服器将檢查在給定位置是否存在具有給定供應商ID和産品代碼的從屬裝置。 在這種情況下，從站配置将“附加”到總線上的實際從站，并且根據應用程式提供的設定來配置從站。 可以通過應用程式界面或指令行工具查詢從配置的狀态（請參見第7.1.3節）。
ethercat config [ OPTIONS ]
Show slave configurations .
Without the -- verbose option , slave configurations are
output one -per - line . Example :
1001:0 0x0000003b/0x02010000 3 OP
| | | |
| | | \- Application - layer
| | | state of the attached
| | | slave , or '-', if no
| | | slave is attached .
| | \- Absolute decimal ring
| | position of the attached
| | slave , or '-' if none
| | attached .
| \- Expected vendor ID and product code ( both
| hexadecimal ).
\- Alias address and relative position ( both decimal ).
With the -- verbose option given , the configured PDOs and
SDOs are output in addition .
Configuration selection :
Slave configurations can be selected with
the --alias and -- position parameters as follows :
1) If neither the --alias nor the -- position option
is given , all slave configurations are displayed .
2) If only the -- position option is given , an alias
of zero is assumed ( see 4)).
3) If only the --alias option is given , all slave
configurations with the given alias address
are displayed .
4) If both the --alias and the -- position option are
given , the selection can match a single
configuration , that is displayed , if it exists .
Command - specific options :
--alias -a <alias > Configuration alias (see above ).
-- position -p <pos > Relative position (see above ).
-- verbose -v Show detailed configurations .
Numerical values can be specified either with decimal (no
prefix ), octal ( prefix '0') or hexadecimal ( prefix '0x ') base .
Slave Position
The slave position has to be specified as a tuple of “alias” and “position”. This allows addressing slaves either via an absolute bus position, or a stored identifier called “alias”, or a mixture of both. The alias is a 16-bit value stored in the slave’s E2PROM. It can be modified via the command-line tool (see subsection 7.1.2). Table 3.1 shows, how the values are interpreted.
// 從站位置必須将從站位置指定為“别名”和“位置”的元組。 這允許通過絕對總線位置或存儲的稱為“别名”的辨別符或二者的混合來尋址從站。 别名是存儲在從站的E2PROM中的16位值。 可以通過指令行工具對其進行修改（請參見7.1.2小節）。 表3.1顯示了如何解釋這些值。
Position addressing. The position parameter is interpreted as the absolute ring position in the bus.
// (Alias = 0)位置尋址。 位置參數被解釋為總線中的絕對環位置。
Alias addressing. The position parameter is interpreted as relative position after the first slave with the given alias address.
// (Alias != 0)别名尋址。 position參數被解釋為具有給定别名位址的第一個從站之後的相對位置。
Figure 3.2 shows an example of how slave configurations are attached. Some of the configurations were attached, while others remain detached. The below lists gives the reasons beginning with the top slave configuration.
// 圖3.2顯示了如何附加從站配置的示例。 一些配置已附加，而其他配置仍保持分離。 下面的清單給出了從頂級從站配置開始的原因。
1. A zero alias means to use simple position addressing. Slave 1 exists and vendor id and product code match the expected values.
// 别名為零意味着使用簡單的位置尋址。 從站1存在，并且供應商ID和産品代碼與期望值比對。
2. Although the slave with position 0 is found, the product code does not match, so the configuration is not attached.
// .盡管找到了位置為0的從站，但産品代碼不比對，是以未附加組态。
3. The alias is non-zero, so alias addressing is used. Slave 2 is the rst slave with alias 0x2000. Because the position value is zero, the same slave is used.
// 别名非零，是以使用别名尋址。 從站2是别名為0x2000的第一個從站。 由于位置值為零，是以使用相同的從站。
4. There is no slave with the given alias, so the configuration can not be attached.
// 沒有具有給定别名的從站，是以無法附加配置。
5. Slave 2 is again the first slave with the alias 0x2000, but position is now 1, so slave 3 is attached.
// 從站2再次是别名為0x2000的第一個從站，但是位置現在為1，是以連接配接了從站3。
If the master sources are configured with
--enable-wildcards
, then 0xffffffff matches every vendor ID and/or product code.
// 如果主源配置有–enable-wildcards，則0xffffffff會比對每個供應商ID和/或産品代碼。
1.3.2 Cyclic Operation
To enter cyclic operation mode, the master has to be \activated" to calculate the process data image and apply the bus configuration for the first time. After activation, the application is in charge to send and receive frames. The configuration can not be changed after activation.
// 要進入循環操作模式，必須先“激活主站”以計算過程資料映像并首次應用總線配置。激活後，應用程式負責發送和接收幀。激活後不能更改配置。
1.3.3 VoE Handlers
During the configuration phase, the application can create handlers for the VoE mail-box protocol described in section 6.3. One VoE handler always belongs to a certain slave configuration, so the creation function is a method of the slave configuration.
// 在配置階段，應用程式可以為6.3節中描述的VoE郵箱協定建立處理程式。一個VoE處理程式始終屬于某個從屬配置，是以建立功能是從屬配置的一種方法。
A VoE handler manages the VoE data and the datagram used to transmit and receive VoE messages. Is contains the state machine necessary to transfer VoE messages.
// VoE handler管理VoE資料和用于發送和接收VoE消息的資料報。是包含傳輸VoE消息所需的狀态機。
The VoE state machine can only process one operation at a time. As a result, either a read or write operation may be issued at a time1. After the operation is initiated, the handler must be executed cyclically until it is finished. After that, the results of the operation can be retrieved.
// VoE狀态機一次隻能處理一個操作。結果，可以在時間1發出讀取或寫入操作。啟動該操作後，必須循環執行該處理程式，直到完成為止。之後，可以檢索操作結果。
A VoE handler has an own datagram structure, that is marked for exchange after each execution step. So the application can decide, how many handlers to execute before sending the corresponding EtherCAT frame(s).
// VoE handler具有自己的資料報結構，該資料報結構被标記為在每個執行步驟之後都可以交換。是以，應用程式可以确定在發送相應的EtherCAT幀之前要執行多少個handler。
For more information about the use of VoE handlers see the documentation of the application interface functions and the example applications provided in the examples/ directory.
// 有關使用VoE處理程式的更多資訊，請參見examples /目錄中提供的應用程式接口功能和示例應用程式的文檔。
1.3.4 Concurrent Master Access
In some cases, one master is used by several instances, for example when an application does cyclic process data exchange, and there are EoE-capable slaves that require to exchange Ethernet data with the kernel (see section 6.1). For this reason, the master is a shared resource, and access to it has to be sequentialized. This is usually done by locking with semaphores, or other methods to protect critical sections.
// 在某些情況下，多個執行個體使用一個主裝置，例如，當應用程式進行循環過程資料交換時，并且有支援EoE的從裝置需要與核心交換以太網資料（請參見6.1節）。是以，主伺服器是共享資源，必須按順序對它進行通路。通常，通過使用信号量鎖定或其他保護關鍵部分的方法來完成此操作。
The master itself can not provide locking mechanisms, because it has no chance to know the appropriate kind of lock. For example if the application is in kernelspace and uses RTAI functionality, ordinary kernel semaphores would not be sufficient. For that, an important design decision was made: The application that reserved a master must have the total control, therefore it has to take responsibility for providing the appropriate locking mechanisms. If another instance wants to access the master, it has to request the bus access via callbacks, that have to be provided by the application. Moreover the application can deny access to the master if it considers it to be awkward at the moment.
// 主機本身不能提供鎖定機制，因為它沒有機會知道适當的鎖定類型。例如，如果應用程式在核心空間中并使用RTAI功能，那麼普通的核心信号量将不夠。為此，做出了一個重要的設計決策：保留主伺服器的應用程式必須擁有全部控制權，是以它必須負責提供适當的鎖定機制。如果另一個執行個體想要通路主機，則它必須通過回調請求總線通路，而回調必須由應用程式提供。此外，如果應用程式認為此主機現在很尴尬，則可以拒絕其通路。
Figure 3.3 exemplary shows, how two processes share one master: The application’s cyclic task uses the master for process data exchange, while the master-internal EoE process uses it to communicate with EoE-capable slaves. Both have to access the bus from time to time, but the EoE process does this by “asking” the application to do the bus access for it. In this way, the application can use the appropriate locking mechanism to avoid accessing the bus at the same time. See the application interface documentation (chapter 3) for how to use these callbacks.
// 圖3.3示例顯示了兩個程序如何共享一個主機：應用程式的循環任務使用主機進行程序資料交換，而主機内部的EoE程序使用它與支援EoE的從機進行通信。兩者都必須不時通路總線，但是EoE程序通過“詢問”應用程式對其進行總線通路來做到這一點。這樣，應用程式可以使用适當的鎖定機制來避免同時通路總線。有關如何使用這些回調的資訊，請參見應用程式接口文檔（第3章）。
1.3.5 Distributed Clocks
From version 1.5, the master supports EtherCAT’s “Distributed Clocks” feature. It is possible to synchronize the slave clocks on the bus to the “reference clock” (which is the local clock of the first slave with DC support) and to synchronize the reference clock to the “master clock” (which is the local clock of the master). All other clocks on the bus (after the reference clock) are considered as “slave clocks” (see Figure 3.4).
// 從1.5版開始，主站支援EtherCAT的“分布式時鐘”功能。 可以将總線上的從時鐘同步到“參考時鐘”（這是具有DC支援的第一個從時鐘的本地時鐘），也可以将參考時鐘同步到“主時鐘”（這是DC的本地時鐘）。 大師）。 總線上的所有其他時鐘（參考時鐘之後）都被視為“從時鐘”（見圖3.4）。
-
Local Clocks
Any EtherCAT slave that supports DC has a local clock register with nanosecond resolution. If the slave is powered, the clock starts from zero, meaning that when slaves are powered on at different times, their clocks will have different values. These “offsets” have to be compensated by the distributed clocks mechanism. On the other hand, the clocks do not run exactly with the same speed, since the used quarts units have a natural frequency deviation. This deviation is usually very small, but over longer periods, the error would accumulate and the difference between local clocks would grow. This clock “drift” has also to be compensated by the DC mechanism.
// 本地時鐘任何支援DC的EtherCAT從站都有一個納秒分辨率的本地時鐘寄存器。 如果從站通電，則時鐘從零開始，這意味着從站在不同時間通電時，其時鐘将具有不同的值。 這些“偏移”必須通過分布式時鐘機制進行補償。 另一方面，由于使用的誇脫機關具有自然的頻率偏差，是以時鐘的運作速度并不完全相同。 這種偏差通常很小，但是在更長的時間内，誤差會累積，本地時鐘之間的差異也會增大。 該時鐘“漂移”也必須通過DC機制進行補償。
-
Application Time
The common time base for the bus has to be provided by the application. This application time tapp is used
// 應用程式時間總線的通用時基必須由應用程式提供。 使用此應用程式時間tapp
1. to configure the slaves' clock offsets (see below),
2. to program the slave's start times for sync pulse generation (see below).
3. to synchronize the reference clock to the master clock (optional).
1.配置從站的時鐘偏移（見下文），
2.對從站的啟動時間進行程式設計以生成同步脈沖（請參見下文）。
3.使參考時鐘與主時鐘同步（可選）。
-
Offset Compensation
For the offset compensation, each slave provides a “System Time Offset” register toff, that is added to the internal clock value tint to get the “System Time” tsys:
// 失調補償為了進行失調補償，每個從機都提供一個“系統時間偏移”寄存器toff，将其添加到内部時鐘值tint中以獲得“系統時間” tsys：
igh (學習筆記)1. IgH Master 1.5.2 Documentation2. 實踐分析3. 測試4. igh移植
The master reads the values of both registers to calculate a new system time offset in a way, that the resulting system time shall match the master’s application time tapp:
// 主機讀取兩個寄存器的值以某種方式計算新的系統時間偏移，以使所得的系統時間與主機的應用時間tapp相比對：
The small time offset error resulting from the different times of reading and writing the registers will be compensated by the drift compensation.
// 由于寄存器的讀寫時間不同而産生的較小的時間偏移誤差将通過漂移補償得到補償。
-
Drift Compensation
The drift compensation is possible due to a special mechanism in each DC-capable slave: A write operation to the “System time” register will cause the internal time control loop to compare the written time (minus the programmed transmission delay, see below) to the current system time. The calculated time error will be used as an input to the time controller, that will tune the local clock speed to be a little faster or slower2, according to the sign of the error.
// 漂移補償可以通過每個具有DC功能的從站中的特殊機制來進行漂移補償：對“系統時間”寄存器的寫操作将使内部時間控制環路比較寫入時間（減去程式設計的傳輸延遲，請參見下文 ）到目前系統時間。 計算出的時間誤差将用作時間控制器的輸入，時間控制器将根據誤差的符号将本地時脈速度調整為更快或更慢2。
-
Transmission Delays
The Ethernet frame needs a small amount of time to get from slave to slave. The resulting transmission delay times accumulate on the bus and can reach microsecond magnitude and thus have to be considered during the drift compensation. EtherCAT slaves supporting DC provide a mechanism to measure the transmission delays: For each of the four slave ports there is a receive time register.
// 傳輸延遲以太網幀從從站到從站需要花費少量時間。 由此産生的傳輸延遲時間會累積在總線上，并可能達到微秒級，是以必須在漂移補償期間加以考慮。 支援DC的EtherCAT從站提供了一種測量傳輸延遲的機制：對于四個從端口，每個端口都有一個接收時間寄存器。
A write operation to the receive time register of port 0 starts the measuring and the current system time is latched and stored in a receive time register once the frame is received on the corresponding port. The master can read out the relative receive times, then calculate time delays between the slaves (using its knowledge of the bus topology), and finally calculate the time delays from the reference clock to each slave. These values are programmed into the slaves’ transmission delay registers. In this way, the drift compensation can reach nanosecond synchrony.
// 一旦在相應端口上接收到幀，對端口0的接收時間寄存器的寫操作就開始測量，并且目前系統時間被鎖存并存儲在接收時間寄存器中。 主機可以讀取相對接收時間，然後（使用其對總線拓撲的了解）計算從機之間的時間延遲，最後計算從參考時鐘到每個從機的時間延遲。 這些值被程式設計到從站的傳輸延遲寄存器中。 這樣，漂移補償可以達到納秒級同步。
-
Checking Synchrony
DC-capable slaves provide the 32-bit “System time difference” register at address 0x092c, where the system time difference of the last drift compensation is stored in nanosecond resolution and in sign-and-magnitude coding3. To check for bus synchrony, the system time difference registers can also be cyclically read via the command-line-tool (see subsection 7.1.14):
// 檢查具有同步能力的DC從站在位址0x092c處提供32位“系統時間差”寄存器，其中最後一次漂移補償的系統時間差以納秒分辨率和符号幅度編碼存儲。 要檢查總線同步，還可以通過指令行工具循環讀取系統時差寄存器（請參見小節7.1.14）：
$ watch -n0 "ethercat reg read -p4 -tsm32 0x92c"
-
Sync Signals
Synchronous clocks are only the prerequisite for synchronous events on the bus. Each slave with DC support provides two “sync signals”, that can be programmed to create events, that will for example cause the slave application to latch its inputs on a certain time. A sync event can either be generated once or cyclically, depending on what makes sense for the slave application. rogramming the sync signals is a matter of setting the so-called “AssignActivate” word and the sync signals’ cycle- and shift times. The AssignActivate word is slave-specific and has to be taken from the XML slave description (Device -> Dc), where also typical sync signal configurations “OpModes” can be found.
// 同步信号同步時鐘隻是總線上同步事件的前提條件。 每個具有DC支援的從站都提供兩個“同步信号”，可以對其進行程式設計以建立事件，例如，這些事件将導緻從屬應用程式在特定時間鎖存其輸入。 同步事件可以一次生成，也可以循環生成，具體取決于對從屬應用程式有意義。 設定同步信号的文法是設定所謂的“ AssignActivate”字和同步信号的周期和移位時間的問題。 AssignActivate字是從屬特定的，必須從XML從屬描述（裝置-> Dc）中擷取，在該處也可以找到典型的同步信号配置“ OpModes”。
1.4 Ethernet Devices
The EtherCAT protocol is based on the Ethernet standard, so a master relies on standard Ethernet hardware to communicate with the bus.
// EtherCAT協定基于以太網标準，是以主站依靠标準以太網硬體與總線進行通信。
The term device is used as a synonym for Ethernet network interface hardware.
// 術語device被用作以太網網絡接口硬體的同義詞。
-
Native Ethernet Device Drivers
There are native device driver modules (see section 4.2) that handle Ethernet hardware, which a master can use to connect to an EtherCAT bus. They offer their Ethernet hardware to the master module via the device interface (see section 4.6) and must be capable to prepare Ethernet devices either for EtherCAT (realtime) operation or for “normal” operation using the kernel’s network stack. The advantage of this approach is that the master can operate nearly directly on the hardware, which allows a high performance. The disadvantage is, that there has to be an EtherCAT-capable version of the original Ethernet driver.
// 本機以太網裝置驅動程式有一些本機裝置驅動程式子產品（請參閱第4.2節）處理以太網硬體，主機可以使用這些子產品連接配接到EtherCAT總線。他們通過裝置接口（請參見4.6節）将其以太網硬體提供給主子產品，并且必須能夠使用核心的網絡堆棧為EtherCAT（實時）操作或“正常”操作準備以太網裝置。這種方法的優點是主機可以直接在硬體上直接運作，進而實作高性能。缺點是原始以太網驅動程式必須具有支援EtherCAT的版本。
-
Generic Ethernet Device Driver
From master version 1.5, there is a generic Ethernet device driver module (see section 4.3), that uses the lower layers of the network stack to connect to the hardware. The advantage is, that arbitrary Ethernet hardware can be used for EtherCAT operation, independently of the actual hardware driver (so all Linux Ethernet drivers are supported without modifications). The disadvantage is, that this approach does not support realtime extensions like RTAI, because the Linux network stack is addressed. Moreover the performance is a little worse than the native approach, because the Ethernet frame data have to traverse the network stack.
// 通用以太網裝置驅動程式從主版本1.5開始，有一個通用以太網裝置驅動程式子產品（請參閱第4.3節），該子產品使用網絡堆棧的下層連接配接到硬體。優點是，可以将任意以太網硬體用于EtherCAT操作，而與實際的硬體驅動程式無關（是以，所有Linux以太網驅動程式都無需修改即可支援）。缺點是該方法不支援RTAI等實時擴充，因為已解決了Linux網絡堆棧。此外，由于以太網幀資料必須周遊網絡堆棧，是以性能比本地方法稍差。
1.4.1 Network Driver Basics
EtherCAT relies on Ethernet hardware and the master needs a physical Ethernet device to communicate with the bus. Therefore it is necessary to understand how Linux handles network devices and their drivers, respectively.
// EtherCAT依賴于以太網硬體，并且主站需要實體以太網裝置才能與總線進行通信。是以，有必要了解Linux如何分别處理網絡裝置及其驅動程式。
-
Tasks of a Network Driver
Network device drivers usually handle the lower two layers of the OSI model, that is the physical layer and the data-link layer. A network device itself natively handles the physical layer issues: It represents the hardware to connect to the medium and to send and receive data in the way, the physical layer protocol describes. The network device driver is responsible for getting data from the kernel’s networking stack and forwarding it to the hardware, that does the physical transmission. If data is received by the hardware respectively, the driver is notified (usually by means of an interrupt) and has to read the data from the hardware memory and forward it to the network stack. There are a few more tasks, a network device driver has to handle, including queue control, statistics and device dependent features.
// 網絡驅動程式的任務網絡裝置驅動程式通常處理OSI模型的下兩層，即實體層和資料鍊路層。網絡裝置本身就可以處理實體層問題：實體層協定描述了它代表連接配接到媒體以及以某種方式發送和接收資料的硬體。網絡裝置驅動程式負責從核心的網絡堆棧中擷取資料，并将其轉發到進行實體傳輸的硬體。如果資料分别由硬體接收，則通知驅動程式（通常通過中斷），并且必須從硬體存儲器讀取資料并将其轉發到網絡堆棧。網絡裝置驅動程式還必須處理一些其他任務，包括隊列控制，統計資訊和與裝置相關的功能。
-
Driver Startup
Usually, a driver searches for compatible devices on module loading. For PCI drivers, this is done by scanning the PCI bus and checking for known device IDs. If a device is found, data structures are allocated and the device is taken into operation.
// 驅動程式啟動通常，驅動程式會在子產品加載時搜尋相容的裝置。對于PCI驅動程式，這是通過掃描PCI總線并檢查已知裝置ID來完成的。如果找到裝置，則會配置設定資料結構并使該裝置投入運作。
-
Interrupt Operation
A network device usually provides a hardware interrupt that is used to notify the driver of received frames and success of transmission, or errors, respectively. The driver has to register an interrupt service routine (ISR), that is executed each time, the hardware signals such an event. If the interrupt was thrown by the own device (multiple devices can share one hardware interrupt), the reason for the interrupt has to be determined by reading the device’s interrupt register. For example, if the flag for received frames is set, frame data has to be copied from hardware to kernel memory and passed to the network stack.
// 中斷操作網絡裝置通常提供硬體中斷，該硬體中斷用于分别通知驅動程式接收到的幀以及傳輸成功或發生錯誤。驅動程式必須注冊一個中斷服務程式（ISR），該程式每次在硬體發出此類事件信号時執行。如果中斷是由自己的裝置抛出的（多個裝置可以共享一個硬體中斷），則必須通過讀取裝置的中斷寄存器來确定中斷的原因。例如，如果設定了接收幀的标志，則必須将幀資料從硬體複制到核心記憶體，然後傳遞到網絡堆棧。
-
The net_device Structure
The driver registers a net_device structure for each device to communicate with the network stack and to create a “network interface". In case of an Ethernet driver, this interface appears as ethX, where X is a number assigned by the kernel on registration. The net_device structure receives events (either from userspace or from the network stack) via several callbacks, which have to be set before registration. Not every callback is mandatory, but for reasonable operation the ones below are needed in any case:
// net_device結構該驅動程式為每個裝置注冊一個net_device結構，以便與網絡堆棧進行通信并建立“網絡接口”，如果是以太網驅動程式，則該接口顯示為ethX，其中X是核心在其中配置設定的數字。 net_device結構通過幾個回調接收事件（從使用者空間或從網絡堆棧），這些回調必須在注冊之前進行設定，并非每個回調都是強制性的，但是為了合理的操作，在任何情況下都需要以下回調：
open() This function is called when network communication has to be started, for example after a command ip link set ethX up from userspace. Frame reception has to be enabled by the driver.
// open（）當必須啟動網絡通信時，例如在從使用者空間設定ipX指令ethX之後，将調用此函數。幀接收必須由驅動程式啟用。
stop() The purpose of this callback is to \close" the device, i. e. make the hardware stop receiving frames.
// stop（）該回調的目的是“關閉”裝置，即使硬體停止接收幀。
hard_start_xmit() This function is called for each frame that has to be transmitted.The network stack passes the frame as a pointer to an sk_buff structure ("socket buffer", see below), which has to be freed after sending.
// hard_start_xmit（）對于必須傳輸的每個幀都調用此函數。網絡堆棧将幀作為指向sk_buff結構（“套接字緩沖區”，見下文）的指針傳遞，該結構必須在發送後釋放。
get_stats() This call has to return a pointer to the device's net_device_stats structure, which permanently has to be lled with frame statistics. This means, that every time a frame is received, sent, or an error happened, the appropriate counter in this structure has to be increased.
// get_stats（）此調用必須傳回指向裝置的net_device_stats結構的指針，該結構必須永久填充幀統計資訊。這意味着，每當接收，發送幀或發生錯誤時，都必須增加此結構中的适當計數器。
The actual registration is done with the register_netdev() call, unregistering is done with unregister_netdev().
// 實際注冊是通過register_netdev（）調用完成的，登出是通過unregister_netdev（）完成的。
-
The netif Interface
All other communication in the direction interface -> network stack is done via the netif_*() calls. For example, on successful device opening, the network stack has to be notified, that it can now pass frames to the interface. This is done by calling netif_start_queue(). After this call, the hard_start_xmit() callback can be called by the network stack. Furthermore a network driver usually manages a frame transmission queue. If this gets filled up, the network stack has to be told to stop passing further frames for a while. This happens with a call to netif_stop_queue(). If some frames have been sent, and there is enough space again to queue new frames, this can be notified with netif_wake_queue(). Another important call is netif_receive_skb()1: It passes a frame to the network stack, that was just received by the device. Frame data has to be included in a so-called “socket buffer” for that (see below).
// 所有接口->網絡堆棧方向的其他通信都是通過netif _ *（）調用完成的。例如，成功打開裝置後，必須通知網絡堆棧，網絡堆棧現在可以将幀傳遞到接口。這是通過調用netif_start_queue（）完成的。調用之後，網絡堆棧可以調用hard_start_xmit（）回調。此外，網絡驅動程式通常管理幀傳輸隊列。如果已填滿，則必須告知網絡堆棧暫時停止傳遞其他幀。調用netif_stop_queue（）會發生這種情況。如果已經發送了一些幀，并且又有足夠的空間來排隊新幀，則可以通過netif_wake_queue（）進行通知。另一個重要的調用是netif_receive_skb（）1：它将幀傳遞給網絡堆棧，該幀剛被裝置接收到。為此，幀資料必須包含在所謂的“套接字緩沖區”中（請參見下文）。
-
Socket Buffers
Socket buffers are the basic data type for the whole network stack. They serve as containers for network data and are able to quickly add data headers and footers, or strip them off again. Therefore a socket buffer consists of an allocated buffer and several pointers that mark beginning of the buffer (head), beginning of data (data), end of data (tail) and end of buffer (end). In addition, a socket buffer holds network header information and (in case of received data) a pointer to the net_device, it was received on. There exist functions that create a socket buffer (dev_alloc_skb()), add data either from front (skb_push()) or back (skb_put()), remove data from front (skb_pull()) or back (skb_trim()), or delete the buffer (kfree_skb()). A socket buffer is passed from layer to layer, and is freed by the layer that uses it the last time. In case of sending, freeing has to be done by the network driver.
// 套接字緩沖區套接字緩沖區是整個網絡堆棧的基本資料類型。它們充當網絡資料的容器，并且能夠快速添加資料标題和頁腳，或再次剝離它們。是以，套接字緩沖區由配置設定的緩沖區和幾個标記緩沖區的指針組成，這些指針标記緩沖區的開始（頭），資料的開始（資料），資料的結束（尾）和緩沖區的結束（結束）。另外，套接字緩沖區儲存網絡标頭資訊和（在接收到資料的情況下）指向net_device的指針，該資訊将在其上被接收。存在建立套接字緩沖區（dev_alloc_skb（）），從正面（skb_push（））或背面（skb_put（））添加資料，從正面（skb_pull（））或背面（skb_trim（））删除資料的函數，或者删除緩沖區（kfree_skb（））。套接字緩沖區從一層傳遞到另一層，并由上次使用它的層釋放。在發送的情況下，必須由網絡驅動程式完成釋放。
1.4.2 Native EtherCAT Device Drivers
There are a few requirements, that applies to Ethernet hardware when used with anative Ethernet driver with EtherCAT functionality.
// 與具有EtherCAT功能的以太網驅動程式一起使用時，有一些要求适用于以太網硬體。
-
Dedicated Hardware
For performance and realtime purposes, the EtherCAT master needs direct and exclusive access to the Ethernet hardware. This implies that the network device must not be connected to the kernel’s network stack as usual, because the kernel would try to use it as an ordinary Ethernet device.
// 專用硬體為了性能和實時性，EtherCAT主站需要直接和排他地通路以太網硬體。 這意味着網絡裝置不能像往常一樣連接配接到核心的網絡堆棧，因為核心會嘗試将其用作普通的以太網裝置。
-
Interrupt-less Operation
EtherCAT frames travel through the logical EtherCAT ring and are then sent back to the master. Communication is highly deterministic: A frame is sent and will be received again after a constant time, so there is no need to notify the driver about frame reception: The master can instead query the hardware for received frames, if it expects them to be already received. Figure 4.1 shows two work ows for cyclic frame transmission and reception with and without interrupts.
// 無中斷運作EtherCAT幀通過邏輯EtherCAT環行，然後發送回主站。 通信是高度确定性的：發送幀并将在固定時間後再次接收，是以無需通知驅動程式有關幀接收的資訊：主裝置可以代替硬體向硬體查詢接收到的幀（如果它希望已接收到幀） 收到。 圖4.1顯示了有和沒有中斷的循環幀發送和接收的兩個工作流。
igh (學習筆記)1. IgH Master 1.5.2 Documentation2. 實踐分析3. 測試4. igh移植 In the left workflow “Interrupt Operation”, the data from the last cycle is first processed and a new frame is assembled with new datagrams, which is then sent. The cyclic work is done for now. Later, when the frame is received again by the hardware, an interrupt is triggered and the ISR is executed. The ISR will fetch the frame data from the hardware and initiate the frame dissection: The datagrams will be processed, so that the data is ready for processing in the next cycle.
// 在左側的工作流“中斷操作”中，首先處理來自最後一個周期的資料，然後将新的幀與新的資料報組裝在一起，然後将其發送。循環工作現在已經完成。稍後，當硬體再次接收到該幀時，将觸發中斷并執行ISR。 ISR将從硬體中擷取幀資料并啟動幀剖析：将處理資料報，以便準備好在下一個周期中進行處理。
In the right workflow “Interrupt-less Operation”, there is no hardware interrupt enabled. Instead, the hardware will be polled by the master by executing the ISR. If the frame has been received in the meantime, it will be dissected. The situation is now the same as at the beginning of the left workflow: The received data is processed and a new frame is assembled and sent. There is nothing to do for the rest of the cycle.
// 在正确的工作流“無中斷操作”中，沒有啟用硬體中斷。相反，硬體将通過執行ISR由主機輪詢。如果在此期間已接收到幀，則将其解剖。現在的情況與左工作流程開始時的情況相同：處理接收到的資料，并組裝并發送新的幀。在剩餘的周期中，沒有任何事情要做。
The interrupt-less operation is desirable, because hardware interrupts are not conducive in improving the driver’s realtime behaviour: Their indeterministic incidences contribute to increasing the jitter. Besides, if a realtime extension (like RTAI) is used, some additional effort would have to be made to prioritize interrupts.
// 無中斷操作是理想的，因為硬體中斷不利于改善駕駛員的實時行為：不确定的事件會增加抖動。此外，如果使用實時擴充（如RTAI），則必須付出一些額外的努力來确定中斷的優先級。
-
Ethernet and EtherCAT Devices
Another issue lies in the way Linux handles devices of the same type. For example, a PCI driver scans the PCI bus for devices it can handle. Then it registers itself as the responsible driver for all of the devices found. The problem is, that an unmodified driver can not be told to ignore a device because it will be used for EtherCAT later. There must be a way to handle multiple devices of the same type, where one is reserved for EtherCAT, while the other is treated as an ordinary Ethernet device.
// 以太網和EtherCAT裝置另一個問題在于Linux處理相同類型裝置的方式。例如，PCI驅動程式掃描PCI總線以查找其可以處理的裝置。然後，它會将自己注冊為找到的所有裝置的負責任驅動程式。問題是，無法告知未修改的驅動程式忽略裝置，因為該裝置稍後将用于EtherCAT。必須有一種方法可以處理多個相同類型的裝置，其中一個裝置保留用于EtherCAT，而另一個裝置則視為普通的以太網裝置。
For all this reasons, the author decided that the only acceptable solution is to modify standard Ethernet drivers in a way that they keep their normal functionality, but gain the ability to treat one or more of the devices as EtherCAT-capable. Below are the advantages of this solution:
// 出于所有這些原因，作者認為唯一可接受的解決方案是修改标準以太網驅動程式，使其保持其正常功能，但具有将一個或多個裝置視為具有EtherCAT功能的能力。以下是此解決方案的優點：
- No need to tell the standard drivers to ignore certain devices.
- One networking driver for EtherCAT and non-EtherCAT devices.
- No need to implement a network driver from scratch and running into issues, the former developers already solved.
- 無需告訴标準驅動程式忽略某些裝置。
- 一個網絡驅動程式用于EtherCAT和非EtherCAT裝置。
- 以前的開發人員已經解決了，無需從頭開始實作網絡驅動程式而不會遇到問題。
The chosen approach has the following disadvantages:
// 該方法具有以下缺點：
- The modified driver gets more complicated, as it must handle EtherCAT and non-EtherCAT devices.
- Many additional case differentiations in the driver code.
- Changes and bug fixes on the standard drivers have to be ported to the EtherCAT-capable versions from time to time.
- 修改後的驅動程式變得更加複雜，因為它必須處理EtherCAT和非EtherCAT裝置。
- 驅動程式代碼中的許多區分判斷。
- 對标準驅動程式的更改和錯誤修複必須不時移植到支援EtherCAT的版本。
1.4.3 Generic EtherCAT Device Driver
Since there are approaches to enable the complete Linux kernel for realtime operation [12], it is possible to operate without native implementations of EtherCAT-capable Ethernet device drivers and use the Linux network stack instead. Figure 2.1 shows the “Generic Ethernet Driver Module”, that connects to local Ethernet devices via the network stack. The kernel module is named ec_generic and can be loaded after the master module like a native EtherCAT-capable Ethernet driver.
// 由于存在使完整的Linux核心實作實時操作的方法[12]，是以可以在不具有EtherCAT功能的以太網裝置驅動程式的本機實作的情況下進行操作，而是使用Linux網絡堆棧。圖2.1顯示了“通用以太網驅動程式子產品”，該子產品通過網絡堆棧連接配接到本地以太網裝置。核心子產品名為ec_generic，可以在主子產品之後加載，就像支援EtherCAT的本地以太網驅動程式一樣。
The generic device driver scans the network stack for interfaces, that have been registered by Ethernet device drivers. It oers all possible devices to the EtherCAT master. If the master accepts a device, the generic driver creates a packet socket (see man 7 packet) with socket_type set to SOCK_RAW, bound to that device. All functions of the device interface (see section 4.6) will then operate on that socket.
// 通用裝置驅動程式會在網絡堆棧中掃描以太網裝置驅動程式已注冊的接口。将所有可能的裝置提供給EtherCAT主站。如果主機接受裝置，則通用驅動程式會建立一個資料包套接字（請參見man 7資料包），其socket_type設定為SOCK_RAW，并綁定到該裝置。然後，裝置接口的所有功能（請參見4.6節）将在該插槽上運作。
Below are the advantages of this solution:
// 以下是此解決方案的優點：
- Any Ethernet hardware, that is covered by a Linux Ethernet driver can be used for EtherCAT.
- No modifications have to be made to the actual Ethernet drivers.
- Linux以太網驅動程式涵蓋的任何以太網硬體都可以用于EtherCAT。
- 無需修改實際的以太網驅動程式。
The generic approach has the following disadvantages:
// 通用方法具有以下缺點：
- The performance is a little worse than the native approach, because the frame data have to traverse the lower layers of the network stack.
- It is not possible to use in-kernel realtime extensions like RTAI with the generic driver, because the network stack code uses dynamic memory allocations and other things, that could cause the system to freeze in realtime context.
- 性能比本地方法差一點，因為幀資料必須周遊網絡堆棧的較低層。
- 不能将RTAI之類的核心内實時擴充與通用驅動程式一起使用，因為網絡堆棧代碼使用動态記憶體配置設定等功能，這可能導緻系統在實時上下文中當機。
-
Device Activation
In order to send and receive frames through a socket, the Ethernet device linked to that socket has to be activated, otherwise all frames will be rejected. Activation has to take place before the master module is loaded and can happen in several ways:
// 裝置激活為了通過套接字發送和接收幀，必須激活連結到該套接字的以太網裝置，否則将拒絕所有幀。 必須在加載主子產品之前進行激活，激活可以通過以下幾種方式進行：
- Ad-hoc, using the command ip link set dev ethX up (or the older ifconfig ethX up),
- 臨時，使用指令ip連結将dev ethX設定為up（或将較舊的ifconfig ethX設定為up），
- Configured, depending on the distribution, for example using ifcfg les (/etc/sysconfig/network/ifcfg-ethX) in openSUSE and others. This is the better choice, if the EtherCAT master shall start at system boot time. Since the Ethernet device shall only be activated, but no IP address etc. shall be assigned, it is enough to use STARTMODE=auto as configuration.
- 根據發行版本進行配置，例如在openSUSE和其他版本中使用ifcfg les（/etc/sysconfig/network/ifcfg-ethX）。 如果EtherCAT主站應在系統啟動時啟動，則這是更好的選擇。 由于僅應激活以太網裝置，而不能配置設定IP位址等，是以使用STARTMODE = auto作為配置就足夠了。
1.4.4 Providing Ethernet Devices
After loading the master module, additional module(s) have to be loaded to offer devices to the master(s) (see section 4.6). The master module knows the devices to choose from the module parameters (see section 2.1). If the init script is used to start the master, the drivers and devices to use can be specified in the sysconfig file (see subsection 7.4.2).
// 加載主子產品後，必須加載其他子產品才能将裝置提供給主子產品（請參見第4.6節）。 主子產品知道要從子產品參數中選擇的裝置（請參見第2.1節）。 如果使用init腳本啟動主伺服器，則可以在sysconfig檔案中指定要使用的驅動程式和裝置（請參見7.4.2小節）。
Modules offering Ethernet devices can be
// 提供以太網裝置的子產品可以是
- native EtherCAT-capable network driver modules (see section 4.2) or
- the generic EtherCAT device driver module (see section 4.3).
- 具有本地EtherCAT功能的網絡驅動程式子產品（請參閱第4.2節）或
- 通用的EtherCAT裝置驅動程式子產品（請參見第4.3節）。
1.4.5 Redundancy
Redundant bus operation means, that there is more than one Ethernet connection from the master to the slaves. Process data exchange datagrams are sent out on every master link, so that the exchange is still complete, even if the bus is disconnected somewhere in between.
// 備援總線操作意味着從主站到從站之間有多個以太網連接配接。過程資料交換資料報在每個主鍊路上發送，是以即使總線之間的某個地方斷開連接配接，交換仍将完成。
Prerequisite for fully redundant bus operation is, that every slave can be reached by at least one master link. In this case a single connection failure (i. e. cable break) will never lead to incomplete process data. Double-faults can not be handled with two Ethernet devices.
// 完全備援總線操作的前提條件是，至少一個主鍊路可以通路每個從站。在這種情況下，單個連接配接故障（即電纜斷開）将永遠不會導緻不完整的過程資料。用兩個以太網裝置不能處理雙重故障。
Redundancy is configured with the --with-devices switch at configure time (see chapter 9) and using the backup_devices parameter of the ec_master kernel module (see section 2.1) or the appropriate variable MASTERx_BACKUP in the (sys-)config file (see subsection 7.4.2).
// 在配置時使用–with-devices開關配置備援（請參見第9章），并使用ec_master核心子產品的backup_devices參數（請參見第2.1節）或（sys-）config檔案中的相應變量MASTERx_BACKUP（請參見小節）進行配置。 7.4.2）。
Bus scanning is done after a topology change on any Ethernet link. The application interface (see chapter 3) and the command-line tool (see section 7.1) both have methods to query the status of the redundant operation.
// 在任何以太網鍊路上更改拓撲後，都會執行總線掃描。應用程式界面（請參見第3章）和指令行工具（請參見第7.1節）都具有查詢備援操作狀态的方法。
1.4.6 EtherCAT Device Interface
An anticipation to the section about the master module (section 2.1) has to be made in order to understand the way, a network device driver module can connect a device to a specific EtherCAT master.
// 為了了解主子產品這一節（第2.1節），必須預見到這一點，網絡裝置驅動程式子產品才能将裝置連接配接到特定的EtherCAT主站。
The master module provides a “device interface” for network device drivers. To use this interface, a network device driver module must include the header devices/ecdev.h, coming with the EtherCAT master code. This header offers a function interface for EtherCAT devices. All functions of the device interface are named with the prefix ecdev.
// 主子產品為網絡裝置驅動程式提供“裝置接口”。 要使用此接口，網絡裝置驅動程式子產品必須包含EtherCAT主代碼随附的頭檔案device/ecdev.h。 該頭提供了EtherCAT裝置的功能接口。 裝置接口的所有功能均以字首ecdev命名。
The documentation of the device interface can be found in the header file or in the appropriate module of the interface documentation (see section 9.3 for generation instructions).
// 裝置接口的文檔可以在頭檔案或接口文檔的相應子產品中找到（有關生成說明，請參見9.3節）。
1.4.7 Patching Native Network Drivers
This section will describe, how to make a standard Ethernet driver EtherCAT-capable, using the native approach (see section 4.2). Unfortunately, there is no standard procedure to enable an Ethernet driver for use with the EtherCAT master, but there are a few common techniques.
// 本節将介紹如何使用原生方法（參見第4.2節）使标準的以太網驅動程式具有EtherCAT功能。不幸的是，沒有标準的過程可以使以太網驅動程式與EtherCAT主站一起使用，但是有一些通用技術。
1. A first simple rule is, that netif_*() calls must be avoided for all EtherCAT devices. As mentioned before, EtherCAT devices have no connection to the network stack, and therefore must not call its interface functions.
1.第一個簡單的規則是，必須避免對所有EtherCAT裝置進行netif _ *（）調用。如前所述，EtherCAT裝置沒有與網絡堆棧的連接配接，是以不得調用其接口功能。
2. Another important thing is, that EtherCAT devices should be operated without interrupts. So any calls of registering interrupt handlers and enabling interrupts at hardware level must be avoided, too.
2.另一個重要的事情是，EtherCAT裝置應無中斷運作。是以，也必須避免任何在硬體級别注冊中斷處理程式和啟用中斷的調用。
3. The master does not use a new socket buffer for each send operation: Instead there is a fix one allocated on master initialization. This socket buffer is filled with an EtherCAT frame with every send operation and passed to the hard_start_xmit() callback. For that it is necessary, that the socket buffer is not be freed by the network driver as usual.
3.master不為每個發送操作使用新的套接字緩沖區：而是在主伺服器初始化上配置設定了一個固定緩沖區。該套接字緩沖區在每次發送操作時都填充有一個EtherCAT幀，并傳遞給hard_start_xmit（）回調。為此，有必要確定網絡驅動程式不像往常那樣釋放套接字緩沖區。
An Ethernet driver usually handles several Ethernet devices, each described by a net_device structure with a priv_data eld to attach driver-dependent data to the structure. To distinguish between normal Ethernet devices and the ones used by EtherCAT masters, the private data structure used by the driver could be extended by a pointer, that points to an ec_device_t object returned by ecdev_offer() (see section 4.6) if the device is used by a master and otherwise is zero.
// 以太網驅動程式通常處理多個以太網裝置，每個裝置由net_device結構描述，帶有priv_data字段，用于将與驅動程式相關的資料附加到該結構。為了區分普通的以太網裝置和EtherCAT主裝置使用的裝置，可以使用指針擴充驅動程式使用的私有資料結構，該指針指向ecdev_offer（）傳回的ec_device_t對象（請參見4.6節）（如果使用了裝置）由一個主，否則為零。
The RealTek RTL-8139 Fast Ethernet driver is a “simple” Ethernet driver and can be taken as an example to patch new drivers. The interesting sections can be found by searching the string “ecdev” in the file devices/8139too-2.6.24-ethercat.c.
// RealTek RTL-8139快速以太網驅動程式是“簡單”的以太網驅動程式，可以作為修補新驅動程式的示例。通過在檔案devices / 8139too-2.6.24-ethercat.c中搜尋字元串“ ecdev”，可以找到有趣的部分。
1.5 State Machines
Many parts of the EtherCAT master are implemented as finite state machines (FSMs). Though this leads to a higher grade of complexity in some aspects, is opens many new possibilities.
// EtherCAT主站的許多部分都實作為有限狀态機（FSM）。 盡管這在某些方面導緻了更進階别的複雜性，但也打開了許多新的可能性。
The below short code example exemplary shows how to read all slave states and moreover illustrates the restrictions of “sequential” coding:
// 下面的短代碼示例示例說明了如何讀取所有從屬狀态，此外還說明了“順序”編碼的限制：
ec_datagram_brd ( datagram , 0x0130 , 2); // prepare datagram
if ( ec_master_simple_io (master , datagram )) return -1;
slave_states = EC_READ_U8 ( datagram -> data ); // process datagram
The ec_master_simple_io() function provides a simple interface for synchronously sending a single datagram and receiving the result1. Internally, it queues the specified datagram, invokes the ec_master_send_datagrams() function to send a frame with the queued datagram and then waits actively for its reception.
// ec_master_simple_io（）函數提供了一個簡單的接口，用于同步發送單個資料報并接收result1。在内部，它對指定的資料報進行排隊，調用ec_master_send_datagrams（）函數發送帶有排隊的資料報的幀，然後主動等待其接收。
This sequential approach is very simple, reflecting in only three lines of code. The disadvantage is, that the master is blocked for the time it waits for datagram reception. There is no difficulty when only one instance is using the master, but if more instances want to (synchronously2) use the master, it is inevitable to think about an alternative to the sequential model.
// 這種順序方法非常簡單，僅反映三行代碼。缺點是，主機在等待資料報接收的時間内被阻塞。當隻有一個執行個體正在使用master時，沒有任何困難，但是如果有更多執行個體想要（同步地）使用master，則不可避免地要考慮順序模型的替代方案。
Master access has to be sequentialized for more than one instance wanting to send and receive datagrams synchronously. With the present approach, this would result in having one phase of active waiting for each instance, which would be non-acceptable especially in realtime circumstances, because of the huge time overhead.
// 對于多個要同步發送和接收資料報的執行個體，必須對主機通路進行順序化。使用本方法，這将導緻具有一個階段的活動等待每個執行個體，這是不可接受的，尤其是在實時情況下，這是因為時間開銷很大。
A possible solution is, that all instances would be executed sequentially to queue their datagrams, then give the control to the next instance instead of waiting for the datagram reception. Finally, bus IO is done by a higher instance, which means that all queued datagrams are sent and received. The next step is to execute all instances again, which then process their received datagrams and issue new ones.
// 一種可能的解決方案是，将順序執行所有執行個體以将其資料報排隊，然後将控制權交給下一個執行個體，而不是等待資料報接收。最後，總線IO由更高的執行個體完成，這意味着所有排隊的資料報都已發送和接收。下一步是再次執行所有執行個體，然後處理它們接收的資料報并發出新的資料報。
This approach results in all instances having to retain their state, when giving the control back to the higher instance. It is quite obvious to use a finite state machine model in this case. section 5.1 will introduce some of the theory used, while the listings below show the basic approach by coding the example from above as a state machine:
// 當将控件交還給更高的執行個體時，此方法導緻所有執行個體必須保留其狀态。在這種情況下，使用有限狀态機模型是很明顯的。 5.1節将介紹一些使用的理論，而下面的清單通過将上面的示例編碼為狀态機來顯示基本方法：
// state 1
ec_datagram_brd ( datagram , 0x0130 , 2); // prepare datagram
ec_master_queue (master , datagram ); // queue datagram
next_state = state_2 ;
// state processing finished
After all instances executed their current state and queued their datagrams, these are sent and received. Then the respective next states are executed:
// 在所有執行個體執行了它們的目前狀态并将它們的資料報排隊之後，這些資料包便被發送和接收。然後執行相應的下一個狀态：
// state 2
if ( datagram -> state != EC_DGRAM_STATE_RECEIVED ) {
next_state = state_error ;
return; // state processing finished
}
slave_states = EC_READ_U8 ( datagram -> data ); // process datagram
// state processing finished .
See section 5.2 for an introduction to the state machine programming concept used in the master code.
// 有關主代碼中使用的狀态機程式設計概念的介紹，請參見5.2節。
1.5.1 State Machine Theory
A finite state machine [9] is a model of behavior with inputs and outputs, where the outputs not only depend on the inputs, but the history of inputs. The mathematical definition of a finite state machine (or finite automaton) is a six-tuple with
// 有限狀态機[9]是具有輸入和輸出的行為模型，其中輸出不僅取決于輸入，而且取決于輸入的曆史。 有限狀态機（或有限自動機）的數學定義是一個六元組，具有
狀态轉移函數通常由狀态轉移表或狀态轉移圖指定。狀态轉移表供了狀态機行為的矩陣視圖（請參見表5.1）。矩陣行對應于狀态（S = {s0; s1; s2}），列對應于輸入符号。表内容在第i行和第j列中代表該情況的下一個狀态（可能還包括輸出），
The state diagram for the same example looks like the one in Figure 5.1. The states are represented as circles or ellipses and the transitions are drawn as arrows between them. Close to a transition arrow can be the condition that must be fulfilled to allow the transition. The initial state is marked by a filled black circle with an arrow pointing to the respective state.
// 同一示例的狀态圖類似于圖5.1中的狀态圖。 狀态用圓圈或橢圓表示，過渡用箭頭表示。 靠近過渡箭頭可能是滿足過渡所必須滿足的條件。 初始狀态由實心黑色圓圈标記，箭頭指向相應狀态。
Deterministic and non-deterministic state machines
A state machine can be deterministic, meaning that for one state and input, there is one (and only one) following state. In this case, the state machine has exactly one starting state. Non-deterministic state machines can have more than one transitions for a single state-input combination. There is a set of starting states in the latter case.
// 确定性和非确定性狀态機狀态機。可以是确定性的，這意味着對于一個狀态和輸入，隻有一個（隻有一個）跟随狀态。 在這種情況下，狀态機僅具有一個啟動狀态。 對于單個狀态輸入組合，非确定性狀态機可以具有多個轉換。 在後一種情況下，有一組啟動狀态。
Moore and Mealy machines
There is a distinction between so-called Moore machines, and Mealy machines. Mathematically spoken, the distinction lies in the output function
w:
.If it only depends on the current state (w : S -> T), the machine corresponds to the “Moore Model”. Otherwise, if
w
is a function of a state and the input alphabet (w : S x E -> T ) the state machine corresponds to the “Mealy model”. Mealy machines are the more practical solution in most cases, because their design allows machines with a minimum number of states. In practice, a mixture of both models is often used.
// Moore和Mealy機器在所謂的Moore機器和Mealy機器之間有差別。 從數學上講，差別在于輸出函數“ w：”。如果僅取決于目前狀态（w：S-> T），則該機器對應于“摩爾模型”。 否則，如果“ w”是狀态的函數并且輸入字母（w：S x E-> T），則狀态機對應于“ Mealy模型”。 在大多數情況下，小型機器是更實用的解決方案，因為它們的設計允許機器具有最少數量的狀态。 實際上，經常使用兩種模型的混合。
Misunderstandings about state machines
There is a phenomenon called “state explosion”, that is often taken as a counter-argument against general use of state machines in complex environments. It has to be mentioned, that this point is misleading [10]. State explosions happen usually as a result of a bad state machine design: Common mistakes are storing the present values of all inputs in a state, or not dividing a complex state machine into simpler sub state machines. The EtherCAT master uses several state machines, that are executed hierarchically and so serve as sub state machines. These are also described below.
// “關于狀态機的誤解”存在一種稱為“狀态爆炸”的現象，通常被視為反對在複雜環境中普遍使用狀态機的一種說法。 必須指出的是，這一點具有誤導性[10]。 狀态爆炸通常是由于狀态機設計不佳而發生的：常見錯誤是将所有輸入的目前值存儲在狀态中，或者沒有将複雜的狀态機劃分為更簡單的子狀态機。 EtherCAT主站使用多個狀态機，這些狀态機是分層執行的，是以可以用作子狀态機。 這些也在下面描述。
1.5.2 The Master’s State Model
This section will introduce the techniques used in the master to implement state machines.
// 本節将介紹master中用于實作狀态機的技術。
State Machine Programming
There are certain ways to implement a state machine in C code. An obvious way is to implement the different states and actions by one big case differentiation:
// 狀态機程式設計有一些方法可以用C代碼實作狀态機。 一種明顯的方法是通過區分大寫來實作不同的狀态和動作：
enum { STATE_1 , STATE_2 , STATE_3 };
int state = STATE_1 ;
void state_machine_run (void * priv_data ) {
switch ( state ) {
case STATE_1 :
action_1 ();
state = STATE_2 ;
break;
case STATE_2 :
action_2 ()
if ( some_condition ) state = STATE_1 ;
else state = STATE_3 ;
break;
case STATE_3 :
action_3 ();
state = STATE_1 ;
break;
}
}
For small state machines, this is an option. The disadvantage is, that with an increasing number of states the code soon gets complex and an additional case differentiation is executed each run. Besides, lots of indentation is wasted.
// 對于小型狀态機，這是一個選擇。 缺點是，随着狀态數量的增加，代碼很快變得複雜，并且每次運作都會執行額外的區分大小寫。 此外，浪費了很多縮進。
The method used in the master is to implement every state in an own function and to store the current state function with a function pointer:
// master中使用的方法是在自己的函數中實作每個狀态，并使用函數指針存儲目前狀态函數：
void (* state )(void *) = state1 ;
void state_machine_run (void * priv_data ) {
state ( priv_data );
}
void state1 (void * priv_data ) {
action_1 ();
state = state2 ;
}
void state2 (void * priv_data ) {
action_2 ();
if ( some_condition ) state = state1 ;
else state = state2 ;
}
void state3 (void * priv_data ) {
action_3 ();
state = state1 ;
}
In the master code, state pointers of all state machines are gathered in a single object of the ec_fsm_master_t class. This is advantageous, because there is always one instance of every state machine available and can be started on demand.
// 在master代碼中，所有狀态機的狀态指針都聚集在ec_fsm_master_t類的單個對象中。 這是有利的，因為每個狀态機總是存在一個執行個體，并且可以按需啟動。
Mealy and Moore
If a closer look is taken to the above listing, it can be seen that the actions executed (the “outputs” of the state machine) only depend on the current state. This accords to the “Moore” model introduced in section 5.1. As mentioned, the “Mealy” model offers a higher exibility, which can be seen in the listing below:
// Mealy和Moore如果仔細檢視上面的清單，可以看到執行的動作（狀态機的“輸出”）僅取決于目前狀态。 這符合5.1節中介紹的“Moore”模型。 如前所述，“ Mealy”模型具有更高的适用性，可以在下面的清單中看到：
1 void state7 (void * priv_data ) {
2 if ( some_condition ) {
3 action_7a ();
4 state = state1 ;
5 }
6 else {
7 action_7b ();
8 state = state8 ;
9 }
10 }
3 - 7 The state function executes the actions depending on the state transition, that is about to be done.
The most flexible alternative is to execute certain actions depending on the state, followed by some actions dependent on the state transition:
// 最靈活的選擇是根據狀态執行某些操作，然後根據狀态轉換執行一些操作：
void state9 (void * priv_data ) {
action_9 ();
if ( some_condition ) {
action_9a ();
state = state7 ;
}
else {
action_9b ();
state = state10 ;
}
}
This model is often used in the master. It combines the best aspects of both approaches.
// 該模型通常在master中使用。 它結合了兩種方法的最佳方面。
Using Sub State Machines
To avoid having too much states, certain functions of the EtherCAT master state machine have been sourced out into sub state machines. This helps to encapsulate the related workflows and moreover avoids the “state explosion” phenomenon described in section 5.1. If the master would instead use one big state machine, the number of states would be a multiple of the actual number. This would increase the level of complexity to a non-manageable grade.
// 使用子狀态機為避免狀态過多，已将EtherCAT主狀态機的某些功能提供給子狀态機。這有助于封裝相關的工作流程，并且避免了5.1節中描述的“狀态爆炸”現象。如果主機改為使用一個大狀态機，則狀态數将是實際數的倍數。這會将複雜性級别提高到無法管理的水準。
Executing Sub State Machines
If a state machine starts to execute a sub state machine, it usually remains in one state until the sub state machine terminates. This is usually done like in the listing below, which is taken out of the slave configuration state machine code:
// 執行子狀态機如果狀态機開始執行子狀态機，則通常會保持一種狀态，直到子狀态機終止。通常，如下面的清單所示，它是從屬裝置配置狀态機代碼中删除的：
1 void ec_fsm_slaveconf_safeop ( ec_fsm_t *fsm)
2 {
3 fsm -> change_state (fsm ); // execute state change
4 // sub state machine
5
6 if (fsm -> change_state == ec_fsm_error ) {
7 fsm -> slave_state = ec_fsm_end ;
8 return;
9 }
10
11 if (fsm -> change_state != ec_fsm_end ) return;
12
13 // continue state processing
14 ...
3 change_state is the state pointer of the state change state machine. The state function, the pointer points on, is executed. . .
// 3 change_state是狀态更改狀态機的狀态指針。指針指向的狀态函數被執行。 。 。
6 ... either until the state machine terminates with the error state . . .
// 6。 。 。直到狀态機以錯誤狀态終止。 。 。
11 ... or until the state machine terminates in the end state. Until then, the "higher" state machine remains in the current state and executes the sub state machine again in the next cycle.
// 11。 。 。或直到狀态機終止于結束狀态。在此之前，“較高”狀态機保持目前狀态，并在下一個循環中再次執行子狀态機。
State Machine Descriptions
The below sections describe every state machine used in the EtherCAT master. The textual descriptions of the state machines contain references to the transitions in the corresponding state transition diagrams, that are marked with an arrow followed by the name of the successive state. Transitions caused by trivial error cases (i. e. no response from slave) are not described explicitly. These transitions are drawn as dashed arrows in the diagrams.
// 狀态機描述以下各節描述了EtherCAT主站中使用的每個狀态機。狀态機的文本描述包含對相應狀态轉換圖中的轉換的引用，這些轉換标記有箭頭，後跟連續狀态的名稱。由瑣碎的錯誤情況（即，從裝置沒有響應）引起的轉換沒有明确描述。這些過渡在圖中以虛線箭頭繪制。
1.5.3 The Master State Machine
The master state machine is executed in the context of the master thread. Figure 5.2 shows its transition diagram. Its purposes are:
// 主狀态機在主線程的上下文中執行。 圖5.2顯示了其過渡圖。 其目的是：
Bus monitoring
The bus topology is monitored. If it changes, the bus is (re-)scanned.
// 總線監視監視總線拓撲。 如果更改，則對總線進行（重新）掃描。
Slave configuration
The application-layer states of the slaves are monitored. If a slave is not in the state it supposed to be, the slave is (re-)configured.
// 從站配置監視從站的應用程式層狀态。 如果從站未處于應有的狀态，則将（重新）配置該從站。
Request handling
Requests (either originating from the application or from external sources) are handled. A request is a job that the master shall process asynchronously, for example an SII access, SDO access, or similar.
// 請求處理處理請求（來自應用程式或來自外部源）。 請求是主機必須異步處理的工作，例如SII通路，SDO通路或類似操作。
1.5.4 The Slave Scan State Machine
The slave scan state machine, which can be seen in Figure 5.3, leads through the process of reading desired slave information.
// 從機掃描狀态機（如圖5.3所示）引導着讀取所需從機資訊的過程。
The scan process includes the following steps:
// 掃描過程包括以下步驟：
Node Address
The node address is set for the slave, so that it can be node-addressed for all following operations.
// “節點位址”節點位址是為從站設定的，是以可以為随後的所有操作指定節點位址。
AL State
The initial application-layer state is read.
// AL狀态讀取初始應用層狀态。
Base Information
Base information (like the number of supported FMMUs) is read from the lower physical memory.
// 基本資訊從較低的實體記憶體中讀取基本資訊（如支援的FMMU的數量）。
Data Link
Information about the physical ports is read.
// 資料連結讀取有關實體端口的資訊。
SII Size
The size of the SII contents is determined to allocate SII image memory.
// “ SII大小”确定SII内容的大小以配置設定SII圖像存儲器。
SII Data
The SII contents are read into the master’s image.
// `SII資料’SII内容被讀入主映像。
PREOP
If the slave supports CoE, it is set to PREOP state using the State change FSM (see section 5.6) to enable mailbox communication and read the PDO configuration via CoE.
//
PREOP
如果從屬裝置支援CoE，則使用狀态更改FSM（請參閱第5.6節）将其設定為PREOP狀态，以啟用郵箱通信并通過CoE讀取PDO配置。
PDOs
The PDOs are read via CoE (if supported) using the PDO Reading FSM (see section 5.8). If this is successful, the PDO information from the SII (if any) is overwritten.
// `PDOs’使用PDO讀取FSM通過CoE（如果支援）讀取PDO（請參見5.8節）。如果成功，則将覆寫來自SII的PDO資訊（如果有）。
1.5.5 The Slave Con guration State Machine
The slave configuration state machine, which can be seen in Figure 5.4, leads through the process of configuring a slave and bringing it to a certain application-layer state.
// 從機配置狀态機（如圖5.4所示）引導了配置從機并将其置于特定應用程式層狀态的過程。
INIT
The state change FSM is used to bring the slave to the INIT state.
// INIT狀态改變FSM用于使從機進入INIT狀态。
FMMU Clearing
To avoid that the slave reacts on any process data, the FMMU configuration are cleared. If the slave does not support FMMUs, this state is skipped. If INIT is the requested state, the state machine is finished.
// “ FMMU清除”為了避免從站對任何過程資料作出反應，将清除FMMU配置。如果從站不支援FMMU，則跳過此狀态。如果INIT是請求的狀态，則狀态機完成。
Mailbox Sync Manager Configuration
If the slaves support mailbox communication, the mailbox sync managers are configured. Otherwise this state is skipped.
// 郵箱同步管理器配置如果從伺服器支援郵箱通信，則配置郵箱同步管理器。否則，将跳過此狀态。
PREOP
The state change FSM is used to bring the slave to PREOP state. If this is the requested state, the state machine is finished.
//
PREOP
狀态改變FSM用于使從機進入PREOP狀态。如果這是請求的狀态，則狀态機完成。
SDO Configuration
If there is a slave configuration attached (see section 3.1), and there are any SDO configurations are provided by the application, these are sent to the slave.
// “ SDO配置”如果附加了從屬配置（請參閱第3.1節），并且應用程式提供了任何SDO配置，則将這些配置發送到從屬。
PDO Configuration
The PDO configuration state machine is executed to apply all necessary PDO configurations.
// “ PDO配置”執行PDO配置狀态機以應用所有必需的PDO配置。
PDO Sync Manager Configuration
If any PDO sync managers exist, they are configured.
// “ PDO同步管理器配置”如果存在任何PDO同步管理器，則将對其進行配置。
FMMU Configuration
If there are FMMUs configurations supplied by the application (i. e. if the application registered PDO entries), they are applied.
//
FMMU配置
如果應用程式提供了FMMU配置（即，如果應用程式注冊了PDO條目），則将應用它們。
SAFEOP
The state change FSM is used to bring the slave to SAFEOP state. If this is the requested state, the state machine is finished.
// SAFEOP狀态更改FSM用于使從裝置進入SAFEOP狀态。如果這是請求的狀态，則狀态機完成。
OP
The state change FSM is used to bring the slave to OP state. If this is the requested state, the state machine is finished.
// `OP’狀态更改FSM用于使從裝置進入OP狀态。如果這是請求的狀态，則狀态機完成。
1.5.6 The State Change State Machine
The state change state machine, which can be seen in Figure 5.5, leads through the process of changing a slave’s application-layer state. This implements the states and transitions described in [3, sec. 6.4.1].
// 如圖5.5所示，狀态更改狀态機引導着更改從站的應用程式層狀态的過程。這實作了[3，sec。中描述的狀态和轉換。 6.4.1]。
Start
The new application-layer state is requested via the "AL Control Request"register (see [3, sec. 5.3.1]).
// “開始”通過“ AL控制請求”寄存器請求新的應用層狀态（請參閱[3，第5.3.1節]）。
Check for Response
Some slave need some time to respond to an AL state change command, and do not respond for some time. For this case, the command is issued again, until it is acknowledged.
// “檢查響應”某些從站需要一些時間來響應AL狀态更改指令，并且不響應一段時間。對于這種情況，将再次發出指令，直到确認為止。
Check AL Status
If the AL State change datagram was acknowledged, the “AL Control Response” register (see [3, sec. 5.3.2]) must be read out until the slave changes the AL state.
// “檢查AL狀态”如果确認了AL狀态更改資料報，則必須讀出“ AL控制響應”寄存器（請參閱[3，第5.3.2節]），直到從站更改AL狀态為止。
AL Status Code
If the slave refused the state change command, the reason can be read from the “AL Status Code” field in the “AL State Changed” registers (see [3, sec. 5.3.3]).
// “ AL狀态代碼”如果從站拒絕了狀态更改指令，則可以從“ AL狀态已更改”寄存器中的“ AL狀态代碼”字段中讀取原因（請參閱[3，第5.3.3節]）。
Acknowledge State
If the state change was not successful, the master has to acknowledge the old state by writing to the “AL Control request” register again.
// “确認狀态”如果狀态更改失敗，則主機必須通過再次寫入“ AL控制請求”寄存器來确認舊狀态。
Check Acknowledge
After sending the acknowledge command, it has to read out the “AL Control Response” register again.
// “檢查确認”發送确認指令後，它必須再次讀出“ AL控制響應”寄存器。
The “start ack” state is a shortcut in the state machine for the case, that the master wants to acknowledge a spontaneous AL state change, that was not requested.
// “開始确認”狀态是狀态機的快捷方式，适用于以下情況，即主機希望确認未請求的自發AL狀态更改。
1.5.7 The SII State Machine
The SII state machine (shown in Figure 5.6) implements the process of reading or writing SII data via the Slave Information Interface described in [2, sec. 6.4].
// SII狀态機（如圖5.6所示）實作了通過從機資訊接口讀取或寫入SII資料的過程，該過程在[2，sec。 6.4]。
This is how the reading part of the state machine works:
// 這是狀态機的讀取部分的工作方式：
Start Reading
The read request and the requested word address are written to the SII attribute.
// 開始讀取将讀取請求和請求的字位址寫入SII屬性。
Check Read Command
If the SII read request command has been acknowledged, a timer is started. A datagram is issued, that reads out the SII attribute for state and data.
// 檢查讀取指令如果已确認SII讀取請求指令，則會啟動計時器。發出一個資料報，該資料報讀取狀态和資料的SII屬性。
Fetch Data
If the read operation is still busy (the SII is usually implemented as an E2PROM), the state is read again. Otherwise the data are copied from the datagram.
// 擷取資料如果讀取操作仍然很忙（通常将SII實作為E2PROM），則将再次讀取狀态。否則，資料将從資料報中複制。
The writing part works nearly similar:
// 寫作部分的工作原理幾乎相似：
Start Writing
A write request, the target address and the data word are written to the SII attribute.
// 開始寫入将寫入請求，目标位址和資料字寫入SII屬性。
Check Write Command
If the SII write request command has been acknowledged, a timer is started. A datagram is issued, that reads out the SII attribute for the state of the write operation.
// 檢查寫指令如果已确認SII寫請求指令，則啟動計時器。發出一個資料報，該資料報從SII屬性中讀取寫操作的狀态。
Wait while Busy
If the write operation is still busy (determined by a minimum wait time and the state of the busy flag), the state machine remains in this state to avoid that another write operation is issued too early.
// 忙時等待如果寫操作仍然很忙（由最小等待時間和忙标志的狀态決定），則狀态機将保持在此狀态，以避免過早發出另一個寫操作。
1.5.8 The PDO State Machines
The PDO state machines are a set of state machines that read or write the PDO assignment and the PDO mapping via the “CoE Communication Area” described in [3, sec. 5.6.7.4]. For the object access, the CANopen over EtherCAT access primitives are used (see section 6.2), so the slave must support the CoE mailbox protocol.
// PDO狀态機是一組狀态機，它們通過[3 5.6.7.4]中所述”的“ CoE通信區域”來讀取或寫入PDO配置設定和PDO映射。對于對象通路，使用基于EtherCAT的CANopen通路原語（請參見6.2節），是以從站必須支援CoE郵箱協定。
PDO Reading FSM
This state machine (Figure 5.7) has the purpose to read the complete PDO configuration of a slave. It reads the PDO assignment for each Sync Manager and uses the PDO Entry Reading FSM (Figure 5.8) to read the mapping for each assigned PDO.
// “ PDO讀取FSM”該狀态機（圖5.7）旨在讀取從機的完整PDO配置。它讀取每個Sync Manager的PDO配置設定，并使用PDO Entry Reading FSM（圖5.8）讀取每個配置設定的PDO的映射。
Basically it reads the every Sync manager’s PDO assignment SDO’s (0x1C1x) number of elements to determine the number of assigned PDOs for this sync manager and then reads out the subindices of the SDO to get the assigned PDO’s indices. When a PDO index is read, the PDO Entry Reading FSM is executed to read the PDO’s mapped PDO entries.
// 基本上，它會讀取每個Sync Manager的PDO配置設定SDO（0x1C1x）個元素，以确定為此同步管理器配置設定的PDO數量，然後讀取SDO的子索引來擷取配置設定的PDO索引。讀取PDO索引後，将執行PDO條目讀取FSM，以讀取PDO的映射PDO條目。
PDO Entry Reading FSM
This state machine (Figure 5.8) reads the PDO mapping (the PDO entries) of a PDO. It reads the respective mapping SDO (0x1600 { 0x17ff, or 0x1a00 { 0x1bff) for the given PDO by reading first the subindex zero (number of elements) to determine the number of mapped PDO entries. After that, each subindex is read to get the mapped PDO entry index, subindex and bit size.
// “ PDO條目讀取FSM”此狀态機（圖5.8）讀取PDO的PDO映射（PDO條目）。它通過先讀取子索引零（元素數量）來确定映射的PDO條目的數量，進而讀取給定PDO的相應映射SDO（0x1600 {0x17ff或0x1a00 {0x1bff））。之後，讀取每個子索引以獲得映射的PDO條目索引，子索引和位大小。
1.6 Mailbox Protocol Implementations
The EtherCAT master implements the CANopen over EtherCAT (CoE), Ethernet over EtherCAT (EoE), File-access over EtherCAT (FoE), Vendor-specific over EtherCAT (VoE) and Servo Profile over EtherCAT (SoE) mailbox protocols. See the below sections for details.
// EtherCAT master實作了CoE、EoE、FoE、VoE、SoE等郵箱協定
1.6.1 Ethernet over EtherCAT (EoE)
The EtherCAT master implements the Ethernet over EtherCAT mailbox protocol [3,sec. 5.7] to enable the tunneling of Ethernet frames to special slaves, that can either have physical Ethernet ports to forward the frames to, or have an own IP stack to receive the frames.
// EtherCAT master實作了在EtherCAT郵箱協定之上傳輸普通Ethernet，通過隧道的方式傳輸普通Ethernet幀給某個從機，從站可以把這些幀轉發到另一個普通的Ethernet實體端口。這樣的從站相當于一個EtherCAT<->Ethernet網關。
-
Virtual Network Interfaces
The master creates a virtual EoE network interface for every EoE-capable slave. These interfaces are called either
// Master為每個EoE的slave建立一個虛拟EoE網絡接口
eoeXsY
for a slave without an alias address (see subsection 7.1.2), where X is the master index and Y is the slave’s ring position, or
// slave沒有别名位址，X是Master編号，Y是slave的位置
eoeXaY
for a slave with a non-zero alias address, where X is the master index and Y is the decimal alias address.
// slave有别名位址，X是Master編号，Y是slave的十進制别名位址
Frames sent to these interfaces are forwarded to the associated slaves by the master. Frames, that are received by the slaves, are fetched by the master and forwarded to the virtual interfaces.
// 發送到這些虛拟網絡接口的資料幀由master轉發到slave，slave接收到的ethernet資料幀最後由master轉發到虛拟網絡接口。
This bears the following advantages:
// 這些具有哪些優勢：
- Flexibility: The user can decide, how the EoE-capable slaves are interconnected with the rest of the world.
- 靈活性：
- Standard tools can be used to monitor the EoE activity and to congure the EoE interfaces.
- 标準工具
- The Linux kernel's layer-2-bridging implementation (according to the IEEE 802.1D MAC Bridging standard) can be used natively to bridge Ethernet traffic between EoE-capable slaves.
- The Linux kernel's network stack can be used to route packets between EoE-capable slaves and to track security issues, just like having physical network interfaces.
1.6.2 CANopen over EtherCAT (CoE)
The CANopen over EtherCAT protocol [3, sec. 5.6] is used to configure slaves and exchange data objects on application level.
// 在EtherCAT之上實作CANopen協定，用來在應用層級配置slave和交換資料對象。
-
SDO Download State Machine
The best time to apply SDO configurations is during the slave’s PREOP state, because mailbox communication is already possible and slave’s application will start with updating input data in the succeeding SAFEOP state. Therefore the SDO configuration has to be part of the slave configuration state machine (see section 5.5): It is implemented via an SDO download state machine, that is executed just before entering the slave’s SAFEOP state. In this way, it is guaranteed that the SDO configurations are applied each time, the slave is reconfigured.
// 應用SDO配置最好的時機是slave在pre-operational狀态，因為郵箱通信已經ok并且slave應用将要在Safe-operation下更新資料資料。是以SDO配置将會成為slave配置狀态機的一部分：它通過SDO下載下傳狀态機實作，在進入safe-operation狀态之前執行。這樣確定每一次SDO配置得到應用，slave被重配置。
The transition diagram of the SDO Download state machine can be seen in Figure 6.2.
START
The beginning state of the CoE download state machine. The “SDO Download Normal Request” mailbox command is sent. -> REQUEST
REQUEST
It is checked, if the CoE download request has been received by the slave. After that, a mailbox check command is issued and a timer is started. -> CHECK
CHECK
If no mailbox data is available, the timer is checked.
- If it timed out, the SDO download is aborted. -> ERROR
- Otherwise, the mailbox is queried again. -> CHECK
If the mailbox contains new data, the response is fetched. -> RESPONSE
RESPONSE
If the mailbox response could not be fetched, the data is invalid, the wrong protocol was received, or a “Abort SDO Transfer Request” was received, the SDO download is aborted. -> ERROR
If a “SDO Download Normal Response” acknowledgement was received, the SDO download was successful. -> END
END
The SDO download was successful.
ERROR
The SDO download was aborted due to an error.
1.6.3
1.6.4
1.7 Userspace Interfaces
For the master runs as a kernel module, accessing it is natively limited to analyzing Syslog messages and controlling using modutils.
// Master作為一個核心子產品來運作，通過modutils來控制并且通過分析Syslog資訊來分析。
It was necessary to implement further interfaces, that make it easier to access the master from userspace and allow a finer influence. It should be possible to view and to change special parameters at runtime.
// 它需要實作更多的接口，用來在使用者态更加友善的通路master。它可以在運作的時候檢視和更改參數。
Bus visualization is another point: For development and debugging purposes it is necessary to show the connected slaves with a single command, for instance (see section 7.1).
// 總線可視化是另外一個點：為了開發和調試目的，需要用單個指令顯示出連接配接的所有slave。
The application interface has to be available in userspace, to allow userspace programs to use EtherCAT master functionality. This was implemented via a character device and a userspace library (see section 7.2).
// 應用接口在使用者空間可用，運作使用者程式使用EtherCAT master功能。這些通過字元裝置和使用者空間庫來實作
Another aspect is automatic startup and configuration. The master must be able to automatically start up with a persistent configuration (see section 7.4).
// 另一方面是自動啟動和配置。master需要使用固定的配置自動啟動。
A last thing is monitoring EtherCAT communication. For debugging purposes, there had to be a way to analyze EtherCAT datagrams. The best way would be with a popular network analyzer, like Wireshark [8] or others (see section 7.5).
// 最後一件事是監控EtherCAT通訊。最好的方法是普通的網絡分析，類似Wireshark。
This chapter covers all these points and introduces the interfaces and tools to make all that possible.
1.7.1 Command-line Tool
Each master instance will get a character device as a userspace interface. The devices are named /dev/EtherCATx, where x (0 ~ n) is the index of the master.
// 每個master執行個體使用一個字元裝置作為使用者空間接口。裝置指令為
/dev/EtherCATx
Device Node Creation The character device nodes are automatically created, if the udev Package is installed. See section 9.5 for how to install and configure it.
// 在udev安裝的情況下，會自動給字元裝置建立節點檔案。
# 1. Setting Alias Addresses
ethercat alias [ OPTIONS ] <ALIAS >
# 2. Displaying the Bus Conguration
ethercat config [ OPTIONS ]
# 3. Output PDO information in C Language
ethercat cstruct [ OPTIONS ]
# 4. Displaying Process Data
ethercat data [ OPTIONS ]
# 5. Setting a Master's Debug Level
ethercat debug <LEVEL >
# 6. Congured Domains
ethercat domains [ OPTIONS ]
# 7. SDO Access
ethercat download [ OPTIONS ] <INDEX > <SUBINDEX > <VALUE >
[ OPTIONS ] <INDEX > <VALUE >
...
1.7.2 Userspace Library
The native application interface (see chapter 3) resides in kernelspace and hence is only accessible from inside the kernel. To make the application interface available from userspace programs, a userspace library has been created, that can be linked to programs under the terms and conditions of the LGPL, version 2 [5].
// 原生應用接口位于核心空間是以隻能在核心下通路。為了讓應用接口在使用者空間程式有效，使用者空間庫被建立，它可以在LGPL下連結到程式。
The library is named libethercat. Its sources reside in the lib/ subdirectory and are build by default when using make. It is installed in the lib/ path below the installation prefix as libethercat.a (for static linking), libethercat.la (for the use with libtool ) and libethercat.so (for dynamic linking).
// 這個庫命名為libethercat。源代碼在
lib/
目錄下。安裝
lib/
目錄下的libethercat.a/libethercat.la/libethercat.so。
- Using the Library
The application interface header ecrt.h can be used both in kernel and in user context.
//應用接口頭檔案
ecrt.h
在kernel和user上下文中都能使用。
The following minimal example shows how to build a program with EtherCAT functionality. An entire example can be found in the examples/user/ path of the master sources.
//以下是一個小執行個體用來展示怎麼建構一個使用EtherCAT功能的程式。完整的執行個體可以在
examples/user/
路徑下找到
#include <ecrt .h>
int main (void)
{
ec_master_t * master = ecrt_request_master (0);
if (! master )
return 1; // error
pause (); // wait for signal
return 0;
}
The program can be compiled and dynamically linked to the library with the below command:
gcc ethercat.c -o ectest -I/opt/etherlab/include \
-L/opt/etherlab/lib -lethercat \
-Wl,--rpath -Wl,/opt/etherlab/lib
The library can also be linked statically to the program:
gcc -static ectest.c -o ectest -I/opt/etherlab/include \
/opt/etherlab/lib/libethercat.a
- Implementation
Basically the kernel API was transferred into userspace via the master character device (see chapter 2, Figure 2.1 and subsection 7.1.1).
// 基本的kernel API通過字元裝置傳遞到使用者空間。
The function calls of the kernel API are mapped to the userspace via an ioctl() interface. The userspace API functions share a set of generic ioctl() calls. The kernel part of the interface calls the according API functions directly, what results in a minimum additional delay (see subsection 7.2.3).
// 函數調用kernel API通過ioctl()映射到使用者空間。使用者空間API函數共享一系列通用的ioctl()調用。核心直接調用API函數，是以它的延時最小。
For performance reasons, the actual domain process data (see section 2.3) are not copied between kernel and user memory on every access: Instead, the data are memory-mapped to the userspace application. Once the master is configured and activated, the master module creates one process data memory area spanning all domains and maps it to userspace, so that the application can directly access the process data. As a result, there is no additional delay when accessing process data from userspace.
// 因為性能的原因，實際的域過程資料在每次通路時不會在核心空間和使用者空間之間拷貝：資料使用memory-mapped來映射到使用者空間應用。當master被配置成激活，master module建立一個包含所有域的過程資料記憶體區域用來映射到使用者空間，是以應用能夠直接的通路過程資料。是以，使用者空間通路過程資料沒有額外的延時。
-
Kernel/User API Differences
Because of the memory-mapping of the process data, the memory is managed internally by the library functions. As a result, it is not possible to provide external memory for domains, like in the kernel API. The corresponding functions are only available in kernelspace. This is the only difference when using the application interface in userspace.
// 核心和使用者API的不同。因為過程資料的memory-mapping，這塊記憶體被庫函數内部管理。是以它不可能想核心API一樣給域提供外部記憶體。這是在使用使用者空間應用接口時唯一的不同。
- Timing
An interesting aspect is the timing of the userspace library calls compared to those of the kernel API. Table 7.1 shows the call times and standard deviancies of typical (and time-critical) API functions measured on an Intel Pentium 4 M CPU with 2:2 GHz and a standard 2.6.26 kernel.
// 一個有趣的方面是使用者空間庫和核心空間API調用時間的比較。下表列出了一個典型執行個體：
The test results show, that for this configuration, the userspace API causes about 1 us additional delay for each function, compared to the kernel API.
// 使用者空間API相比較核心API有1us的延時
1.7.3 RTDM Interface
When using the userspace interfaces of realtime extensions like Xenomai or RTAI, the use of ioctl() is not recommended, because it may disturb realtime operation. To accomplish this, the Real-Time Device Model (RTDM) [17] has been developed. The master module provides an RTDM interface (see Figure 2.1) in addition to the normal character device, if the master sources were configured with --enable-rtdm (see chapter 9).
// 當實時擴充環境(Xenomai or RTAI)下使用使用者空間接口時，不推薦使用ioctl()，因為它會妨礙實時操作。為了完成目的，RTDM被開發。master module在普通字元裝置基礎上額外提供一個RTDM接口，如果master在配置時使用了
--enable-rtdm
選項。
To force an application to use the RTDM interface instead of the normal character device, it has to be linked with the libethercat rtdm library instead of libethercat. The use of the libethercat rtdm is transparent, so the EtherCAT header ecrt.h with the complete API can be used as usual.
// 為了強制應用使用RTDM接口來替代普通字元裝置，它必須連結到rtdm libethercat庫用來替代普通的libethercat庫。rtdm libethercat庫對應用是透明的，是以EtherCAT頭檔案
ecrt.h
中定義的API像往常一樣使用。
To make the example in Listing 7.1 use the RTDM library, the linker command has to be altered as follows:
gcc ethercat-with-rtdm .c -o ectest -I/opt/etherlab/include \
-L/opt/etherlab/lib -lethercat_rtdm \
-Wl ,--rpath -Wl,/opt/etherlab/lib
1.7.4 System Integration
To integrate the EtherCAT master as a service into a running system, it comes with an init script and a sysconfig file, that are described below. Modern systems may be managed by systemd [7]. Integration of the master with systemd is described in subsection 7.4.4.
// 把EtherCAT master當成一個service內建進系統，它由init腳本和sysconfig檔案組成。更先進的系統由systemd管理。
- Init Script
The EtherCAT master init script conforms to the requirements of the “Linux Standard Base” (LSB, [6]). The script is installed to
etc/init.d/ethercat
below the installation prefix and has to be copied (or better: linked) to the appropriate location (see chapter 9), before the master can be inserted as a service. Please note, that the init script depends on the sysconfig file described below.
// EtherCAT master初始化腳本遵循LSB的需求，腳本安裝到
etc/init.d/ethercat
。初始化腳本依賴sysconfig檔案
To provide service dependencies (i. e. which services have to be started before others) inside the init script code, LSB defines a special comment block. System tools can extract this information to insert the EtherCAT init script at the correct place in the startup sequence:
// 為了在init腳本中提供service依賴，LSB定義一個特殊的通用子產品。系統工具可以解析這些資訊，以便決定正确的啟動順序：
# Required - Start : $local_fs $syslog $network
# Should - Start : $time ntp
# Required - Stop : $local_fs $syslog $network
# Should - Stop : $time ntp
# Default - Start : 3 5
# Default - Stop : 0 1 2 6
# Short - Description : EtherCAT master
# Description : EtherCAT master 1.5.2
### END INIT INFO
- Syscon g File
For persistent configuration, the init script uses a sysconfig file installed to
etc/sysconfig/ethercat
(below the installation prefix), that is mandatory for the init script. The sysconfig file contains all configuration variables needed to operate one or more masters. The documentation is inside the file and included below:
// init腳本使用安裝的
etc/sysconfig/ethercat
sysconfig檔案中的固定配置。sysconfig檔案包含所有的配置變量
#------------------------------------------------------------------------------
#
# Main Ethernet devices .
#
# The MASTER <X> _DEVICE variable specifies the Ethernet device for a master
# with index 'X '.
#
# Specify the MAC address ( hexadecimal with colons ) of the Ethernet device to
# use. Example : "00:00:08:44: ab :66"
#
# The broadcast address "ff:ff:ff:ff:ff:ff" has a special meaning : It tells
# the master to accept the first device offered by any Ethernet driver .
#
# The MASTER <X> _DEVICE variables also determine , how many masters will be
# created : A non - empty variable MASTER0_DEVICE will create one master , adding a
# non - empty variable MASTER1_DEVICE will create a second master , and so on.
#
MASTER0_DEVICE =""
# MASTER1_DEVICE =""
#
# Backup Ethernet devices
#
# The MASTER <X> _BACKUP variables specify the devices used for redundancy . They
# behaves nearly the same as the MASTER <X> _DEVICE variable , except that it
# does not interpret the ff:ff:ff:ff:ff:ff address .
#
# MASTER0_BACKUP =""
#
# Ethernet driver modules to use for EtherCAT operation .
#
# Specify a non - empty list of Ethernet drivers , that shall be used for
# EtherCAT operation .
#
# Except for the generic Ethernet driver module , the init script will try to
# unload the usual Ethernet driver modules in the list and replace them with
# the EtherCAT - capable ones . If a certain ( EtherCAT - capable ) driver is not
# found , a warning will appear .
#
# Possible values : 8139 too , e100 , e1000 , e1000e , r8169 , generic , ccat , igb .
# Separate multiple drivers with spaces .
#
# Note : The e100 , e1000 , e1000e , r8169 , ccat and igb drivers are not built by
# default . Enable them with the --enable -<driver > configure switches .
#
# Attention : When using the generic driver , the corresponding Ethernet device
# has to be activated ( with OS methods , for example 'ip link set ethX up ') ,
# before the master is started , otherwise all frames will time out.
#
DEVICE_MODULES =""
#
# Flags for loading kernel modules .
#
# This can usually be left empty . Adjust this variable , if you have problems
# with module loading .
#
# MODPROBE_FLAGS ="-b"
#------------------------------------------------------------------------------
For systems managed by systemd (see subsection 7.4.4), the sysconfig file has moved to /etc/ethercat.conf. Both versions are part of the master sources and are meant to used alternatively.
// 對于systemd系統，配置檔案移動到
/etc/ethercat.conf
檔案
- Starting the Master as a Service
After the init script and the sysconfig file are placed into the right location, the EtherCAT master can be inserted as a service. The different Linux distributions offer different ways to mark a service for starting and stopping in certain runlevels. For example, SUSE Linux provides the insserv command:
// 不同的linux發行版使用不同的指令來啟動和停止service到不同的運作等級。SUSE提供以下指令
# insserv ethercat
The init script can also be used for manually starting and stopping the EtherCAT master. It has to be executed with one of the parameters start, stop, restart or status.
// 手工停止和啟動service
# /etc/init.d/ethercat restart
Shutting down EtherCAT master done
Starting EtherCAT master done
- Integration with systemd
Distributions using systemd instead of the SysV init system are using service files to describe how a service is to be maintained. Listing 7.2 lists the master’s service file:
// 某些發行版使用systemd，以下是master的service檔案：
#
# EtherCAT master kernel modules
#
[ Unit ]
Description = EtherCAT Master Kernel Modules
#
# Uncomment this , if the generic Ethernet driver is used . It assures , that the
# network interfaces are configured , before the master starts .
#
# Requires = network . service # Stop master , if network is stopped
# After = network . service # Start master , after network is ready
#
# Uncomment this , if a native Ethernet driver is used . It assures , that the
# network interfaces are configured , after the Ethernet drivers have been
# replaced . Otherwise , the networking configuration tools could be confused .
#
# Before = network.service
[ Service ]
Type = oneshot
RemainAfterExit = yes
ExecStart = /opt/etherlab/sbin/ethercatctl start
ExecStop = /opt/etherlab/sbin/ethercatctl stop
[ Install ]
WantedBy = multi-user.target
The
ethercatctl
command is used to load and unload the master and network driver modules in a similar way to the former init script (subsection 7.4.1). Because it is installed into the
sbin/
directory, it can also be used separately:
// ethercatctl指令用來加載和解除安裝master和網絡驅動子產品。因為它安裝在
sbin/
目錄，是以也可以手工調用
# ethercatctl start
When using systemd and/or the ethercatctl command, the master configuration must be in /etc/ethercat.conf instead of /etc/sysconfig/ethercat! The latter is ignored. The configuration options are exactly the same.
// 當使用systemd的ethercatctl指令時，對應/etc/ethercat.conf配置檔案
1.7.5 Debug Interfaces
EtherCAT buses can always be monitored by inserting a switch between master and slaves. This allows to connect another PC with a network monitor like Wireshark [8], for example. It is also possible to listen to local network interfaces on the machine running the EtherCAT master directly. If the generic Ethernet driver (see section 4.3) is used, the network monitor can directly listen on the network interface connected to the EtherCAT bus.
// EtherCAT總線可以在master和slave之間插入一個交換機來做監控，這允許使用網絡監控例如Wireshark來連接配接其他的PC。它也可能直接在master本地網口上進行監聽。如果使用
generic Ethernet driver
，可以監聽連接配接到EtherCAT總線上的本地網絡接口。
When using native Ethernet drivers (see section 4.2), there are no local network interfaces to listen to, because the Ethernet devices used for EtherCAT are not registered at the network stack. For that case, so-called “debug interfaces” are supported, which are virtual network interfaces allowing to capture EtherCAT traffic with a network monitor (like Wireshark or tcpdump) running on the master machine without using external hardware. To use this functionality, the master sources have to be configured with the --enable-debug-if switch (see chapter 9).
// 當使用原生EtherCAT驅動，沒有本地網絡接口可以監聽，因為用于EtherCAT的網絡裝置沒有在網絡協定棧上注冊。對于這種情況，使用"debug interfaces"來支援，它是一個虛拟的網絡接口允許抓取EtherCAT傳輸(類似Wireshark or tcpdump)不需要額外的硬體。使用這個功能，master源碼需要使用
--enable-debug-if
配置選項。
Every EtherCAT master registers a read-only network interface per attached physical Ethernet device. The network interfaces are named ecdbgmX for the main device, and ecdbgbX for the backup device, where X is the master index. The below listing shows a debug interface among some standard network interfaces:
// 每個EtherCAT master注冊一個隻讀的網絡接口附加到實體網口上。network interfaces在主裝置上命名為
ecdbgmX
，在備份裝置上命名為
ecdbgbX
。下面是一些debug interface和一些标準的network interfaces：
# ip link
lo: <LOOPBACK ,UP > mtu 16436 qdisc noqueue
link / loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
eth0 : <BROADCAST , MULTICAST > mtu 1500 qdisc noop qlen 1000
link / ether 00:13:46:3 b:ad:d7 brd ff:ff:ff:ff:ff:ff
ecdbgm0 : <BROADCAST , MULTICAST > mtu 1500 qdisc pfifo_fast qlen 1000
link / ether 00:04:61:03: d1 :01 brd ff:ff:ff:ff:ff:ff
While a debug interface is enabled, all frames sent or received to or from the physical device are additionally forwarded to the debug interface by the corresponding master.
// 當debug interface使能，所有從實體網口發送和接收的資料幀由對應master轉發到debug interface。
Network interfaces can be enabled with the below command:
// 網絡接口可以使用以下指令使能：
# ip link set dev ecdbgm0 up
Please note, that the frame rate can be very high. With an application connected, the debug interface can produce thousands of frames per second.
// 請注意，幀速率非常高。在應用連接配接時，debug interface每秒處理幾千個資料幀。
Attention The socket buffers needed for the operation of debug interfaces have to be allocated dynamically. Some Linux realtime extensions (like RTAI) do not allow this in realtime context!
// 注意debug interfaces的socket buffer需要動态配置設定，某些Linux實時擴充不允許在實時上下文中操作。
1.8 Timing Aspects
Although EtherCAT’s timing is highly deterministic and therefore timing issues are rare, there are a few aspects that can (and should be) dealt with.
// 盡管EtherCAT的時間非常确定，是以時間問題非常罕見。但是還是有些方面需要處理。
1.8.1 Application Interface Pro ling
One of the most important timing aspects are the execution times of the application interface functions, that are called in cyclic context. These functions make up an important part of the overall timing of the application. To measure the timing of the functions, the following code was used:
// 最重要的時序方面之一是應用程式接口函數的執行時間，這些時間在循環上下文中調用。 這些功能構成了應用程式總體時序的重要組成部分。 為了測量功能的時序，使用了以下代碼:
c0 = get_cycles ();
ecrt_master_receive ( master );
c1 = get_cycles ();
ecrt_domain_process ( domain1 );
c2 = get_cycles ();
ecrt_master_run ( master );
c3 = get_cycles ();
ecrt_master_send ( master );
c4 = get_cycles ();
Between each call of an interface function, the CPU timestamp counter is read. The counter differences are converted to us with help of the cpu_khz variable, that contains the number of increments per ms.
// 在每次調用接口函數之間，都會讀取CPU時間戳計數器。 計數器差異在cpu_khz變量的幫助下轉換為us，該變量包含每毫秒增量的數量。
For the actual measuring, a system with a 2:0 GHz CPU was used, that ran the above code in an RTAI thread with a period of 100 us. The measuring was repeated n = 100 times and the results were averaged. These can be seen in Table 8.1.
// 為了進行實際測量，使用了具有2：0 GHz CPU的系統，該系統在RTAI線程中以100 us的時間運作上述代碼。 重複測量n = 100次，并将結果取平均值。 這些可以在表8.1中看到。
It is obvious, that the functions accessing hardware make up the lion’s share. The ec_master_receive() executes the ISR of the Ethernet device, analyzes datagrams and copies their contents into the memory of the datagram objects. The ec_master_send() assembles a frame out of different datagrams and copies it to the hardware buffers.
// 顯而易見，通路硬體的功能構成了最大的份額。 ec_master_receive（）執行以太網裝置的ISR，分析資料報并将其内容複制到資料報對象的記憶體中。 ec_master_send（）從不同的資料報中組裝出一幀并将其複制到硬體緩沖區。
Interestingly, this makes up only a quarter of the receiving time.
// 有趣的是，這僅占接收時間的四分之一。
The functions that only operate on the masters internal data structures are very fast (t < 1 us). Interestingly the runtime of ec_domain_process() has a small standard deviancy relative to the mean value, while this ratio is about twice as big for ec_master_run(): This probably results from the latter function having to execute code depending on the current state and the different state functions are more or less complex.
// 僅對主機内部資料結構起作用的功能非常快（t <1 us）。 有趣的是，ec_domain_process（）的運作時相對于平均值具有較小的标準偏差，而該比率大約是ec_master_run（）的兩倍：這可能是由于後者函數必須根據目前狀态和不同情況執行代碼而導緻的 狀态函數或多或少複雜。
For a realtime cycle makes up about 10 us, the theoretical frequency can be up to 100 kHz. For two reasons, this frequency keeps being theoretical:
// 對于大約10 us的實時周期，理論頻率可以高達100 kHz。 由于兩個原因，該頻率一直是理論上的：
1. The processor must still be able to run the operating system between the real-time cycles.
// 1.處理器必須仍然能夠在實時周期之間運作作業系統。
2. The EtherCAT frame must be sent and received, before the next realtime cycle begins. The determination of the bus cycle time is difficult and covered in subsection 8.0.2.
// 2.在下一個實時周期開始之前，必須發送和接收EtherCAT幀。 總線循環時間的确定很困難，這在8.0.2小節中有介紹。
1.8.2 Bus Cycle Measuring
For measuring the time, a frame is “on the wire”, two timestamps must be taken:
// 對測量這個時間，資料線上上，兩個時間出需要得到
1. The time, the Ethernet hardware begins with physically sending the frame.
// 以太網硬體實體層發送資料幀
2. The time, the frame is completely received by the Ethernet hardware.
// 以太網硬體完成資料幀的接收
Both times are diffcult to determine. The first reason is, that the interrupts are disabled and the master is not notified, when a frame is sent or received (polling would distort the results). The second reason is, that even with interrupts enabled, the time from the event to the notification is unknown. Therefore the only way to confidently determine the bus cycle time is an electrical measuring.
// 所有的時間都非常難以确定。第一個原因是中斷被屏蔽，當一個資料幀發送和接收時master沒有通知(輪詢會歪曲結果)。第二個原因是，就算中斷使能，這個通知事件的時間也是未知。是以唯一确定總線周期的方法就是電子測量。
Anyway, the bus cycle time is an important factor when designing realtime code, because it limits the maximum frequency for the cyclic task of the application. In practice, these timing parameters are highly dependent on the hardware and often a trial and error method must be used to determine the limits of the system.
// 無論如何，總線循環時間是設計實時代碼時的重要因素，因為它限制了應用程式循環任務的最大頻率。實際上，這些時序參數高度依賴于硬體，通常必須使用反複試驗法來确定系統的極限。
The central question is: What happens, if the cycle frequency is too high? The answer is, that the EtherCAT frames that have been sent at the end of the cycle are not yet received, when the next cycle starts. First this is noticed by ecrt domain process(), because the working counter of the process data datagrams were not increased. The function will notify the user via Syslog1. In this case, the process data keeps being the same as in the last cycle, because it is not erased by the domain. When the domain datagrams are queued again, the master notices, that they are already queued (and marked as sent). The master will mark them as unsent again and output a warning, that datagrams were “skipped”.
// 中心問題是：如果循環頻率太高，會發生什麼？答案是，在下一個周期開始時，尚未收到在周期結束時發送的EtherCAT幀。首先，這是由ecrt_domain_process（）注意到的，因為過程資料資料報的工作計數器沒有增加。該功能将通過Syslog1通知使用者。在這種情況下，過程資料将保持與上一個周期相同，因為該域不會删除該資料。當域資料報再次排隊時，主機會注意到它們已經排隊（并标記為已發送）。主機将再次将它們标記為未發送，并輸出一條警告，指出資料報已“跳過”。
On the mentioned 2:0 GHz system, the possible cycle frequency can be up to 25 kHz without skipped frames. This value can surely be increased by choosing faster hardware. Especially the RealTek network hardware could be replaced by a faster one.
// 在提到的2：0 GHz系統上，可能的周期頻率可以高達25 kHz，而不會跳過幀。通過選擇更快的硬體，可以肯定地增加該值。特别是RealTek網絡硬體可以用更快的硬體代替。
Besides, implementing a dedicated ISR for EtherCAT devices would also contribute to increasing the latency. These are two points on the author’s to-do list.
// 此外，為EtherCAT裝置實施專用的ISR也将有助于增加延遲。這是作者的任務清單上的兩點。
1.9 Installation
1.9.1 Getting the Software
There are several ways to get the master software:
// 有幾種擷取主軟體的方法：
1.An official release (for example 1.5.2), can be downloaded from the master’s website1 at the EtherLab project [1] as a tarball.
// 1.可以從EtherLab項目[1]的管理者網站1下載下傳官方版（例如1.5.2）的壓縮包。
2.The most recent development revision (and moreover any other revision) can be obtained via the Mercurial [14] repository on the master’s project page on SourceForge.net2. The whole repository can be cloned with the command
// 2.可以通過SourceForge.net2上主項目頁面上的Mercurial [14]存儲庫獲得最新的開發修訂版（以及任何其他修訂版）。 可以使用以下指令克隆整個存儲庫
hg clone http :// etherlabmaster .hg. sourceforge .net / hgweb /etherlabmaster / etherlabmaster local-dir
3.Without a local Mercurial installation, tarballs of arbitrary revisions can be downloaded via the “bz2” links in the browsable repository pages3.
// 3.如果沒有本地Mercurial安裝，則可以通過可浏覽的存儲庫頁面3中的“ bz2”連結下載下傳任意版本的tarball。
1.9.2 Building the Software
After downloading a tarball or cloning the repository as described in section 9.1, the sources have to be prepared and configured for the build process.
// 在按9.1節所述下載下傳tarball或克隆存儲庫後，必須為建構過程準備和配置源。
When a tarball was downloaded, it has to be extracted with the following commands:
// 下載下傳壓縮包時，必須使用以下指令将其解壓縮：
$ tar xjf ethercat-1.5.2.tar.bz2
$ cd ethercat-1.5.2/
The software configuration is managed with Autoconf [15] so the released versions contain a configure shell script, that has to be executed for configuration (see below).
// 軟體配置由Autoconf [15]管理，是以發行的版本包含配置shell腳本，必須執行該腳本以進行配置（請參見下文）。
-
Bootstrap
When downloading or cloning directly from the repository, the configure script does not yet exist. It can be created via the bootstrap.sh script in the master sources. The autoconf and automake packages are required for this.
//
Bootstrap
-
Con guration and Build
$ ./configure
$ make
$ make modules
Table 9.1 lists important con guration switches and options.
1.9.3 Building the Interface Documentation
The source code is documented using Doxygen [13]. To build the HTML documentation, the Doxygen software has to be installed. The below command will generate the documents in the subdirectory doxygen-output:
// 使用Doxygen [13]記錄了源代碼。 要生成HTML文檔，必須安裝Doxygen軟體。 以下指令将在子目錄doxygen-output中生成文檔：
$ make doc
The interface documentation can be viewed by pointing a browser to the file doxygen-output/html/index.html. The functions and data structures of the application interface a covered by an own module “Application Interface”.
// 可以通過将浏覽器指向檔案doxygen-output / html / index.html來檢視接口文檔。 應用程式接口的功能和資料結構由自己的子產品“應用程式接口”覆寫。
1.9.4 Installing the Software
The below commands have to be entered as root: The first one will install the EtherCAT header, init script, sysconfig file and the userspace tool to the prefix path. The second one will install the kernel modules to the kernel’s modules directory. The final depmod call is necessary to include the kernel modules into the modules.dep file to make it available to the modprobe command, used in the init script.
// 必須以root使用者身份輸入以下指令：第一個指令将EtherCAT标頭，初始化腳本，sysconfig檔案和使用者空間工具安裝到字首路徑。第二個将核心子產品安裝到核心的modules目錄。最後的depmod調用對于将核心子產品包括到modules.dep檔案中是必需的，以使其可用于init腳本中的modprobe指令。
# make install
# make modules install
If the target kernel’s modules directory is not under /lib/modules, a different destination directory can be specified with the DESTDIR make variable. For example:
// 如果目标核心的子產品目錄不在
/lib/modules
下，則可以使用DESTDIR make變量指定其他目标目錄。例如：
# make DESTDIR=/vol/nfs/root modules install
This command will install the compiled kernel modules to
/vol/nfs/root/lib/modules
, prepended by the kernel release.
// 該指令會将已編譯的核心子產品安裝到核心發行版之前的
/vol/nfs/root/lib/modules
中。
If the EtherCAT master shall be run as a service4 (see section 7.4), the init script and the sysconfig file (or the systemd service file, respectively) have to be copied (or linked) to the appropriate locations. The below example is suitable for SUSE Linux. It may vary for other distributions.
// 如果EtherCAT主站應作為service運作（請參見7.4節），則必須将init腳本和sysconfig檔案（或分别為systemd服務檔案）複制（或連結）到适當的位置。以下示例适用于SUSE Linux。對于其他發行版，它可能有所不同。
# cd /opt/etherlab
# cp etc/sysconfig/ethercat /etc/sysconfig/
# ln -s etc/init.d/ethercat /etc/init.d/
# insserv ethercat
Now the sysconfig file /etc/sysconfig/ethercat (see subsection 7.4.2), or the configuration file /etc/ethercat.conf, if using systemd, has to be customized. The minimal customization is to set the MASTER0_DEVICE variable to the MAC address of the Ethernet device to use (or ff:ff:ff:ff:ff:ff to use the first device offered) and selecting the driver(s) to load via the DEVICE_MODULES variable.
// 現在，必須自定義sysconfig檔案/ etc / sysconfig / ethercat（請參見7.4.2小節），或配置檔案/etc/ethercat.conf（如果使用systemd）。最小的自定義方法是将MASTER0_DEVICE變量設定為要使用的以太網裝置的MAC位址（或使用提供的第一個裝置使用ff：ff：ff：ff：ff：ff），然後選擇要通過驅動程式加載的驅動程式。 DEVICE_MODULES變量。
After the basic configuration is done, the master can be started with the below command:
// 完成基本配置後，可以使用以下指令啟動主伺服器：
# /etc/init.d/ethercat start
When using systemd, the following command can be used alternatively:
// 使用systemd時，可以交替使用以下指令：
# ethercatctl start
At this time, the operation of the master can be observed by viewing the Syslog messages, which should look like the ones below. If EtherCAT slaves are connected to the master’s EtherCAT device, the activity indicators should begin to flash.
// 這時，可以通過檢視Syslog消息來觀察主伺服器的操作，該消息應如下所示。如果将EtherCAT從站連接配接到主站的EtherCAT裝置，則活動訓示燈應開始閃爍。
1 EtherCAT : Master driver 1.5.2
2 EtherCAT : 1 master waiting for devices .
3 EtherCAT Intel (R) PRO /1000 Network Driver - version 6.0.60 - k2
4 Copyright (c) 1999 -2005 Intel Corporation .
5 PCI : Found IRQ 12 for device 0000:01:01.0
6 PCI : Sharing IRQ 12 with 0000:00:1 d.2
7 PCI : Sharing IRQ 12 with 0000:00:1 f.1
8 EtherCAT : Accepting device 00:0 E:0C:DA:A2 :20 for master 0.
9 EtherCAT : Starting master thread .
10 ec_e1000 : ec0: e1000_probe : Intel (R) PRO /1000 Network
11 Connection
12 ec_e1000 : ec0: e1000_watchdog_task : NIC Link is Up 100 Mbps
13 Full Duplex
14 EtherCAT : Link state changed to UP.
15 EtherCAT : 7 slave (s) responding .
16 EtherCAT : Slave states : PREOP .
17 EtherCAT : Scanning bus.
18 EtherCAT : Bus scanning completed in 431 ms.
# 1 - 2 The master module is loading, and one master is initialized.
# 3 - 8 The EtherCAT-capable e1000 driver is loading. The master accepts the device with the address 00:0E:0C:DA:A2:20.
# 9 - 16 The master goes to idle phase, starts its state machine and begins scanning the bus.
1.9.5 Automatic Device Node Creation
The ethercat command-line tool (see section 7.1) communicates with the master via a character device. The corresponding device nodes are created automatically, if the udev daemon is running. Note, that on some distributions, the udev package is not installed by default.
// ethercat指令行工具（請參閱第7.1節）通過字元裝置與主機通信。如果udev守護程式正在運作，則會自動建立相應的裝置節點。請注意，在某些發行版中，預設情況下未安裝udev軟體包。
The device nodes will be created with mode 0660 and group root by default. If “normal” users shall have reading access, a udev rule le (for example /etc/udev/rules.d/99-EtherCAT.rules) has to be created with the following contents:
// 預設情況下，将使用模式0660群組root建立裝置節點。如果“普通”使用者具有閱讀權限，則必須建立具有以下内容的udev規則檔案（例如/etc/udev/rules.d/99-EtherCAT.rules）：
KERNEL ==" EtherCAT [0 -9]*" , MODE ="0664"
After the udev rule file is created and the EtherCAT master is restarted with
/etc/init.d/ethercat restart
, the device node will be automatically created with the desired rights:
// 建立udev規則檔案并使用
/etc/init.d/ethercat restart
重新啟動EtherCAT主站之後，将自動以所需的權限建立裝置節點：
# ls -l /dev/EtherCAT0
crw -rw -r-- 1 root root 252 , 0 2008 -09 -03 16:19 /dev / EtherCAT0
Now, the ethercat tool can be used (see section 7.1) even as a non-root user. If non-root users shall have writing access, the following udev rule can be used instead:
// 現在，即使是非root使用者也可以使用ethercat工具（請參閱7.1節）。如果非root使用者具有寫通路權，則可以使用以下udev規則代替：
KERNEL ==" EtherCAT [0 -9]*" , MODE ="0664" , GROUP =" users "
2. 實踐分析
2.1 fsm_master狀态機
fsm_master結構體:
struct ec_fsm_master {
ec_master_t *master; /**< master the FSM runs on */
ec_datagram_t *datagram; /**< datagram used in the state machine */
unsigned int retries; /**< retries on datagram timeout. */
void (*state)(ec_fsm_master_t *); /**< master state function */
ec_device_index_t dev_idx; /**< Current device index (for scanning etc.).
*/
int idle; /**< state machine is in idle phase */
unsigned long scan_jiffies; /**< beginning of slave scanning */
uint8_t link_state[EC_MAX_NUM_DEVICES]; /**< Last link state for every
device. */
unsigned int slaves_responding[EC_MAX_NUM_DEVICES]; /**< Number of
responding slaves
for every device. */
unsigned int rescan_required; /**< A bus rescan is required. */
ec_slave_state_t slave_states[EC_MAX_NUM_DEVICES]; /**< AL states of
responding slaves for
every device. */
ec_slave_t *slave; /**< current slave */
ec_sii_write_request_t *sii_request; /**< SII write request */
off_t sii_index; /**< index to SII write request data */
ec_sdo_request_t *sdo_request; /**< SDO request to process. */
ec_fsm_coe_t fsm_coe; /**< CoE state machine */
ec_fsm_soe_t fsm_soe; /**< SoE state machine */
ec_fsm_pdo_t fsm_pdo; /**< PDO configuration state machine. */
ec_fsm_change_t fsm_change; /**< State change state machine */
ec_fsm_slave_config_t fsm_slave_config; /**< slave state machine */
ec_fsm_slave_scan_t fsm_slave_scan; /**< slave state machine */
ec_fsm_sii_t fsm_sii; /**< SII state machine */
};
以IDLE為例，狀态機周期調用關系如下圖所示：
其中ec_master_idle_thread()的調用周期與系統滴答時間有關：
//send interval in IDLE phase
ec_master_set_send_interval(master, 1000000/HZ);
2.2 初始化流程
源代碼執行指令
sudo /etc/init.d/ethercat start
，将會從檔案module.c檔案中的ec_init_module函數中開始往下執行初始化流程。
- ec_init_module
主要用于生成/dev/EtherCAT裝置，并且調用ec_master_init初始化主機相關資訊。
ec_master_init（）的主要工作内容：
1.設定IDLE模式下資料發送周期；
2.初始化資料包隊列；
3.初始化網絡裝置；
4.初始化master主狀态機；
5.初始化參考時鐘資料包；
6.初始化時鐘資料包；
7.初始化對時監測資料包；
8.初始化字元裝置，/dev/EtherCAT0;
9.初始化RTDM裝置；
- IDLE狀态程序
裝置打開後，裝置調用ec_master_enter_idle_phase，該函數中将啟用ec_master_idle_thread程序
ec_master_idle_thread以設定的周期（send_interval）發送資料包并處理，其流程如下：
2.3 程式架構
3. 測試
3.1 實時性測試
在DC同步模式下，Ethercat主站能否在規定的時間内發送過程資料幀，是影響整個系統性能的關鍵因素，本文介紹如何使用Wireshark抓取總線上的Ethercat資料包，并将主站發過程資料幀的時間間隔以曲線的形式顯示出來。
- 連接配接ET2000
将ET2000串接在網絡中：
- 啟用ESL協定
打開Wireshark -> 分析 ->啟用的協定對話框，勾選esl_eth：
- 抓取資料
抓取的資料如下，其中EtherCAT Switch Link下的timestamp是ET2000添加到資料包末尾的時間戳，機關為ns。而Time下的時間為運作Wireshark的Windows系統添加的時間戳。
- 篩選資料
由于隻分析主站發送資料的時間，即working counter 為0的資料，使用過濾規則
(eth.type == 0x88a4) && (ecat.cnt == 0)
過濾資料，并導出為另一個檔案，例如導出到D:\test.pcap
- 使用tshark導出時間戳
使用tshark指令将ET2000的時間戳導出為csv檔案：
導出結果為：
- 繪圖
将csv中的發送時間間隔繪制成曲線圖，可看出該主站的時間抖動在60us左右:
作為對比，Windows的時間戳抖動達到200us。
可見，ET2000的時間戳才能反映真實的主站實時性。
- 性能分析
采用WireShark中的進階功能IO Graphs，對采集到的實驗室現場資料封包，進行綜合的資料統計和分析：
[外鍊圖檔轉存失敗,源站可能有防盜鍊機制,建議将圖檔儲存下來直接上傳(img-vUZmwHZM-1604106304843)(imge/profinet/wireshark_io_graphs.PNG)]
3.2 一緻性測試
在EtherCAT從站開發過程中，使用ETG官方提供的一緻性測試軟體對産品進行一緻性測試是非常有必要的。
- 擷取軟體
EtherCAT Conformance Test Tool，簡稱CTT，需要以ETG會員的身份進行購買，訂貨資訊為ET9400，每次購買的有效期為一年，過期後需重新購買。
ETG官網上關于CTT的介紹： https://www.ethercat.org.cn/cn/products/2b8481d0918740ae91af0aece1ff8c2f.htm
- 一緻性測試
購買CTT并安裝後，就可以對從站進行一緻性測試了。
首先，把從站的裝置描述檔案(xml)拷貝到CTT安裝目錄對應的檔案夾下：
C:\Program Files (x86)\EtherCAT Conformance Test\DeviceDescriptions
打開CTT軟體，建立工程後，右鍵點選EtherCAT Devices添加裝置：
如果檢測到從站，ECAT Link将顯示為True：
點選OK後将顯示檢測到的從站，右鍵點選Tests下的EtherCAT标簽，添加預設測試案例：
點選工具欄中綠色三角圖示即開始測試，測試完成後将生成測試報告，對于不通過項會顯示紅色，可根據提示對從站代碼或裝置描述檔案進行修改。
測試完成後的結果如下：
- 測試内容簡介
CTT将測試案例分成幾大類，分别以TF-XXXX命名，展開後可看到各大類下的測試案例：
測試案例簡要分析：
(1) TF-1300 EtherCAT Slave Information
主要測試裝置描述檔案(xml）中的内容是否與從站EERPOM中的内容一緻，包括Vendor ID, PDO配置，FMMU配置，以及資料字典等等。
(2) TF-1100 Data Link Layer
主要測試郵箱通信。
(3) TF-1200 EtherCAT State Machine
主要測試狀态機，init, preop, safeop, op這些狀态的互相跳轉是否正常。
(4) TF-1201 Explicit Device Identification
特殊ID裝置的測試，被跳過。
(5) TF-2300 AL CoE SDO service
測試資料字典在不同總線狀态下的讀寫是否正确。
(6) TF-2302 CoE SDO Complete Access
如果從站聲明支援Complete Access功能，将對該功能進行測試。
(7) TF-2301 AL CoE Object Dictionary
測試從站離線和線上資料字典是否一緻。
(8) TF-4100 CiA402 OD
測試CiA402相關資料字典，本測試案例中從站不是CiA402裝置，是以相關測試被忽略。
- 一緻性認證
通過一緻性測試後，就可以到ETG相關機構申請一緻性認證，除了CTT相關測試内容，一緻性認證還包括從站裝置的訓示燈是否規範，與其它産品的相容性等。通過後就可以拿到一緻性認證的證書，并在産品上貼上一緻性認證标簽。
4. igh移植
4.1 xenomai移植
1、ipipe更新檔：
tar -xvf linux-4.4.182.tar.xz
cd linux-4.4.182/
patch -p1 < ../ipipe-core-4.4.182-x86-15.patch
2、xenomai更新檔：
tar -xvf xenomai-3.0.10.tar.bz2
cd xenomai-3.0.10
./scripts/prepare-kernel.sh --linux=/home/myc/vx/igh/linux-4.4.182 --arch=x86_64 --outpatch=../xenomai-3.0.10.patch
cd linux-4.4.182/
patch -p1 < ../xenomai-3.0.10.patch
3、編譯核心
cd linux-4.4.182/
cp /boot/config-4.4.0-176-generic .config
make menuconfig
make bzImage -j4
make modules -j4
4、安裝
安裝子產品：
make INSTALL_MOD_STRIP=1 modules_install
安裝ramfa和核心：
sudo mkinitramfs /lib/modules/4.4.182+/ -o /boot/initrd.img-4.4.182-xenomai
sudo cp arch/x86/boot/bzImage /boot/vmlinuz-4.4.182-xenomai
sudo cp System.map /boot/System.map-4.4.182-xenomai
sudo update-grub2
5、安裝應用程式：
cd xenomai-3.0.10
./configure --with-core=cobalt --enable-smp --enable-pshared
./configure --with-core=cobalt --enable-smp --enable-pshared CFLAGS="-fPIC"
sudo make install
6、測試：
[email protected]:~$ dmesg | grep -i xenomai
[ 0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-4.4.182-xenomai root=UUID=bdc34999-c918-4a67-a92d-9bd7732e3820 ro quiet splash
[ 0.000000] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-4.4.182-xenomai root=UUID=bdc34999-c918-4a67-a92d-9bd7732e3820 ro quiet splash
[ 2.674918] [Xenomai] scheduling class idle registered.
[ 2.674919] [Xenomai] scheduling class rt registered.
[ 2.699489] I-pipe: head domain Xenomai registered.
[ 2.738189] [Xenomai] Cobalt v3.0.10
$ sudo /usr/xenomai/bin/latency
== Sampling period: 100 us
== Test mode: periodic user-mode task
== All results in microseconds
warming up...
RTT| 00:00:15 (periodic user-mode task, 100 us period, priority 99)
RTH|----lat min|----lat avg|----lat max|-overrun|---msw|---lat best|--lat worst
RTD| 3.443| 730.867| 19528.564| 67967| 0| 3.443| 19528.564
RTD| 2.027| 729.319| 46168.093| 135725| 0| 2.027| 46168.093
RTD| 1.948| 580.795| 33114.187| 188888| 0| 1.948| 46168.093
RTD| 1.492| 379.718| 28321.906| 221916| 0| 1.492| 46168.093
RTD| 4.358| 431.370| 27549.434| 260074| 0| 1.492| 46168.093
RTD| 2.397| 729.442| 26226.420| 327974| 0| 1.492| 46168.093
RTD| 3.094| 382.390| 27201.676| 361266| 0| 1.492| 46168.093
RTD| 2.892| 381.338| 35848.720| 394314| 0| 1.492| 46168.093
^C---|-----------|-----------|-----------|--------|------|-------------------------
4.2 igh移植
1、配置
# 原生版本igh
unzip ethercat-master.zip
cd ethercat-master/
# intel xenomai 版本
unzip xenomai-ethercat-master.zip
cd xenomai-ethercat-master
./configure --with-linux-dir=/home/myc/vx/igh/linux-4.4.182 --with-module-dir=/lib/modules/4.4.182+/ --enable-generic --enable-rtdm --with-xenomai-dir=/usr/xenomai --enable-cycles --enable-hrtimer --enable-8139too=no
2、編譯
make
make modules
libtool問題：
autoreconf -ivf
3、安裝：
sudo make install
sudo make modules_install
4、systemd配置：
建立ethercat.service檔案：
sudo vim /usr/lib/systemd/user/ethercat.service
ethercat.service檔案内容：
#
# EtherCAT master kernel modules
#
[ Unit ]
Description = EtherCAT Master Kernel Modules
#
# Uncomment this , if the generic Ethernet driver is used . It assures , that the
# network interfaces are configured , before the master starts .
#
# Requires = network . service # Stop master , if network is stopped
# After = network . service # Start master , after network is ready
#
# Uncomment this , if a native Ethernet driver is used . It assures , that the
# network interfaces are configured , after the Ethernet drivers have been
# replaced . Otherwise , the networking configuration tools could be confused .
#
# Before = network.service
[ Service ]
Type = oneshot
RemainAfterExit = yes
ExecStart = /opt/etherlab/sbin/ethercatctl start
ExecStop = /opt/etherlab/sbin/ethercatctl stop
[ Install ]
WantedBy = multi-user.target
拷貝配置檔案并編輯：
sudo cp /opt/etherlab/etc/ethercat.conf /etc/
sudo vim /etc/ethercat.conf
ethercat.conf檔案内容：
MASTER0_DEVICE="00:0c:29:74:35:3b"
DEVICE_MODULES="generic"
啟動ethercat service:
systemctl restart ethercat
5、使用者态指令行測試：
sudo /opt/etherlab/bin/ethercat config